資安

所有成功的數字化轉型，尤其是數字金融的轉型建設，有沒有現成的規律？ 近日，在由AI金融評論聯合主辦的「鯨犀產業數字峰會」上，阿里巴巴集團副總裁、阿里雲智能新金融事業部總經理劉偉光，以“數字金融發展路徑與實踐思考”為題，分享了他們在金融數字化轉型浪潮中的所見所得。 鯨犀產業數字峰會，是由業內最頂尖的企業家、工程領袖、CIO、解決方案專家、投資家，聯合發起的數字化系列論壇。 致力於將全新的數字化管理思維和實踐案例，推向傳統產業界、AI界、互聯網界、投資界、經濟學界。 從阿里雲服務眾多金融機構的經驗中，劉偉光總結，所有今天成功的數字化轉型，特別是數字金融領域，都有這樣的建設規律： 第一，真正自上而下一把手工程，全員驅動。 第二，更加強調內外部協同高效的數字化能力的貫穿。 第三，更加強調與外部機構合作當中的生態開放能力，數據開放能力和數據的計算能力。更加面向未來，構建智能化體系。 劉偉光曾創建Pivotal軟件大中華區分公司，開創了企業級大數據以及企業級雲計算PaaS平臺的市場先河。 這次他也在演講中，給“業務連接-業務創新-業務效率”三個階段，清晰地劃出了漏斗式的建設路徑： 連接階段：要在前端構建一個非常完整的數字化、移動化的數據運營體系，實現業務的外部場景嵌入化，為營銷、風控提供有力支撐。 創新階段：企業架構要有完整的轉型，對業務系統真正實現完整的重構，實現對數據能力的高效運用。構建快速的業務響應能力，和所有業務模塊的組合創新能力，就是這個時代要求的必經之路。 效率階段：構建金融科技與業務的結合，對業務有真正的賦能。 以下為劉偉光的演講全文，雷鋒網《AI金融評論》做了不改變原意的編輯： 非常高興與大家在線上見面。今天的演講主題是《數字金融發展路徑與實踐思考》，我將結合阿里巴巴自身的業務實踐、與外部金融機構合作探索的經驗來分享。 數字金融的“三疊浪” 首先我們來看數字金融發展的三個不同階段，後信息化時代、數字化時代、智能化時代。 一、後信息化時代：自從2000年之後，中國各行各業的信息化都有了高速發展，尤其是金融行業，在創新技術的應用上走在了世界的前列。 隨著技術的不斷應用，我們看到推動了互聯網金融、直銷銀行、移動銀行的高速發展，提升了對客戶的體驗。 但是在這個時代，還有大量的市場空間沒有被覆蓋，諸如金融市場、投研、投顧、供應鏈等很多領域需要被新的技術所賦能、所覆蓋。 […]

作者：許力 阿里雲原生多模數據庫Lindorm與東軟雲科技推出聯合解決方案，共建面向未來的車聯網數字化運營運維雲平臺。東軟雲科技阿里車聯網雲能夠提供海量實時監控車輛、駕駛行為、第三方交通天氣等數據源數據存儲融合，支撐車廠、服務提供商等客戶運營大量駕駛人用戶數據，快速建立駕駛行為分析模型，面向保險、車廠、商業車隊、智慧城市等領域提供數據運營與分析服務。目前，該聯合解決方案已在東軟睿馳、江鈴汽車、長城汽車等客戶中得到廣泛應用和實踐落地。 東軟集團深耕車載業務近30年，為國內外知名汽車廠商、Tier1客戶提供從操作系統開發、核心技術授權到車載應用定製包括車載信息娛樂系統定製化服務及測試服務、儀表定製化開發、HMI定製化開發、車身控制系統軟件開發、導航&DB編譯服務、車聯網、車載測試的整體智能座艙軟件解決方案和服務。作為阿里雲MSP合作伙伴，東軟擁有近300名ACP工程師，卓越的雲架構設計、上雲遷移、雲上實施、雲上運維，以及銀行級別的安全保障和雲優化服務能力。能夠提供基於阿里雲的車聯網雲上服務，為車聯網解決方案的運營保駕護航。 隨著智能網聯汽車創新場景和相關業務不斷豐富，在線車輛採集上傳雲端的數據量激增，數據種類和結構多樣化，目前常用數據存儲技術手段侷限於利用多種開源數據庫（Opentsdb、HBase、Solr等）自建數據庫存儲系統集群，建設、使用、運維成本隨數據量和業務場景快速增加，急需專業、高性價比、免運維的數據庫存儲方案。 阿里雲原生多模數據庫Lindorm致力於提供“存得起，看得見”的非結構化、半結構化的數據存儲與處理解決方案，廣泛服務於阿里巴巴集團內部和外部用戶，特別是物聯網、車聯網等智能、互聯繫統海量數據存儲，具備高性價比存儲、開放生態兼容、多引擎異構數據融合等能力。Lindorm憑藉以下優勢為東軟車聯網業務構建了海量數據雲存儲一站服務平臺。 車聯網海量監控數據存儲成本最低，依靠自研數據壓縮存儲、冷熱分離、存算分離技術將時序監控數據存儲成本降到極致； 完美對接HBase、OpenTSDB、InfluxDB、PhoneixQL、CassandraQL等大多數主流數據存儲生態接口，數據遷移、生態共生方案最完備； 提供時序、寬表、索引、文件等多種引擎協作存儲能力，為客戶屏蔽多類型、異構數據處理複雜性問題； 企業級穩定性保障、大於99.99%數據可靠性保障，免運維，專業技術團隊售後支持。 基於東軟雲科技阿里車聯網數字化運營運維雲平臺，客戶能夠運用車聯大數據進行智能分析，提供車況分析、用戶畫像分析及出行分析，從而向車廠研發部、質量部提供業務決策依據，幫助車廠深入洞察用戶，提升運營效率，實現精準營銷以及業務創新。具體應用場景如下： 車廠產品變革及質量監控：通過對車聯網大數據的採集分析，從經濟性、環境、可靠性、安全性、故障等方面挖掘數據價值，從而向車廠研發部、質量部提供業務決策依據，用於整車廠產品變革。 車主駕駛評價及出行助手：根據車主駕駛習慣特徵，提升車輛行車效率，最大程度減少車主顧慮，為車主提供駕駛評估和安全指導，提供出行幫助，促進汽車品牌智能化服務轉型。 汽車後市場服務：整合車聯大數據中的人、車數據，根據不同行業客戶的特點，提供定製化的個性服務，充分體現“自有數據運營”的價值。 精準營銷：基於線下位置的數據採集，通過人與地理位置的結合、變化、頻次等狀態，實現人群標籤劃分、線下場景捕捉，提供精準的用戶畫像，幫助車廠深入洞察用戶，提升運營效率，實現精準營銷以及業務創新。 除此之外，東軟雲科技阿里車聯網聯合方案還能提供人、車、出行多維度分析，提升車廠決策及運營能力支撐，典型應用場景包括： 車況分析：提供車輛性能分析和故障分析，為車廠研發部門、採購部門、質量部門提供車況分析，包括燃油經濟性、怠速、故障分析、性能分析等，從而提升整車廠的決策能力，為車廠各生產設計環節帶來價值。 用戶畫像：基於購車履歷、用車頻度、活動區域的分析，幫助車廠洞察購車人群分佈，消費偏好等，為車輛銷售定位、銷售策略提供客觀的參考依據，從而實現精準營銷以及業務創新。 出行分析：整合車輛行駛過程中的時空數據，對車輛行車數據和風險行為進行識別並加以刻畫，提供駕駛行為分析、車輛風險畫像、路線軌跡洞察，綜合反映車輛行駛習慣及風險，為車廠客觀瞭解車輛出行狀況提供數據支撐。 東軟雲科技雲解決方案和服務事業部 副總經理傅春江表示：“數據是車聯網賦能車廠和車聯網服務提供商提升客戶體驗，構建技術競爭力的關鍵，阿里雲原生多模數據庫Lindorm具備極具競爭力的數據存儲性價比和技術優勢，做到了讓車聯網數據存得起、看得見！” 根據IDC預測，2023年全球智慧城市技術投資將達到1894.6億美元，作為智慧城市核心系統之一的車聯網運營運維支撐數據存儲也將同步快速增加，東軟雲科技阿里雲聯合解決方案圍繞車聯網系統建設數據存儲痛點問題，強強聯合共建行業支撐數字基礎設施。

背景：2020年9月16日，Snowflake成功IPO，交易首日市場估值達到704億美元，募集資金34億美元。Snowflake成為迄今為止規模最大的軟件IPO，市值最高突破1200億美元。Snowflake提供基於雲的數據存儲和分析服務，一般被稱為 “數據倉庫即服務”，它允許企業用戶使用基於雲的硬件和軟件來存儲和分析數據。Snowflake自2014年起在亞馬遜S3上運行，自2018年起在微軟Azure上運行，自2019年起在谷歌雲平臺上運行，其Snowflake Data Exchange允許客戶發現、交換和安全地共享數據。[維基百科] Snowflake取得了巨大的商業成功，技術是如何支撐起它的千億美元市值呢？它技術強在哪？OLAP內核技術愛好者浙川為大家傾情解讀Snowflake的核心技術原理。本文為該系列三。 雲服務組件 多租戶是Snowflake雲服務組件非常重要的特點。雲服務組件中的每一個組件，例如併發訪問控制、優化器、事務管理器等，都是需要能夠長期運行並可以被許多用戶同時共享的。多租戶的特性大大提升了系統的利用率，並且降低了系統的管理開銷，相比於每個用戶都會獨立佔用系統資源的傳統架構，多租戶可以降低系統的整體成本。 為了高可靠性和高可擴展性，每個雲服務組件都會有自己的副本。因此，即便某個雲服務組件掛掉，也不會導致數據丟失或者服務不可用。雲服務組件掛掉可能會導致一些正在運行的查詢任務失敗，但由於數據沒有丟失，Snowflake只需要簡單地重新運行這些查詢任務就行了。 查詢管理與優化。用戶的查詢請求會首先發送到Snowflake的雲服務組件上，雲服務組件會對查詢進行前期處理，包括查詢解析、權限控制、查詢計劃優化、文件映射等。Snowflake的優化器採用了傳統的自頂向下的瀑布模型（Cascades-style）和基於開銷的優化（cost-based optimization，CBO）。優化器所依賴的統計數據，全部由Snowflake在數據加載和更新時進行自動統計。由於Snowflake並不支持索引，因此Snowflake搜索計劃的空間會比較小。同時，Snowflake並不是在前期解析查詢的是時候一併把所有計劃都生成好，而是將一部分計劃的生成推遲到執行階段，比如針對join的數據分佈計劃就是在執行時才產生的。這樣設計的優點是可以降低優化器生成低效計劃的概率，同時也提升了系統的魯棒性，而代價是可能查詢執行的時候並不能獲得極致的性能。更重要的是，這樣的設計會使查詢執行性能變得更加可預測，進而提升用戶使用Snowflake的體驗。 優化器產生的計劃會下發給該查詢對應虛擬倉庫的所有計算節點上執行，當計劃執行的過程中，雲服務組件會持續不斷地監測執行狀態，統計性能指標並跟蹤計算節點的健康情況。這些信息都是後續性能分析和日誌審計的重要依據，並通過圖形化接口向用戶展示。 併發訪問控制。Snowflake的併發訪問控制也是在雲服務組件中實現的。Snowflake的主要負載為分析型負載，分析型負載大多是複雜查詢、批量插入、批量更新等。在這樣的負載場景下，Snowflake通過ACID事務和快照隔離（snapshot isolation，SI）來實現併發訪問控制。在快照隔離的機制下，一個事務內所有的讀操作都會統一使用事務開始時的快照，這也意味著一個事務內所有的讀操作都會看到同一個版本的數據，同時併發執行的另一個事務內的數據修改操作對這個事務的讀操作來說是不可見的。 Snowflake的快照隔離機制是基於多版本併發控制（multi-version concurrency control,MVCC）實現的。由於Snowflake的表數據文件一旦存放到S3上，文件就不可以改變了，因此採用多版本併發控制是一個很自然的選擇。在Snowflake中，如果想要修改一個文件，那麼只能把這個文件刪除，並用新的包含修改內容的文件來替換它。更進一步，在Snowflake中，如果對一個表做了寫操作（數據插入、更新、刪除），那麼會對應產生一個新版本的表，舊版本表的文件都會被刪除，新版本表的文件被重新添加進來。當然，除了涉及寫操作的數據文件需要進行實際物理文件的刪除和替換外，其他文件的刪除和添加都是在元數據中進行操作。如前面章節所述，Snowflake的元數據管理就是key-value存儲。 除了快照隔離外，Snowflake還使用快照來實現時間追蹤和數據對象高效克隆。 剪枝。如何保證某個查詢請求只訪問和它相關的數據，是查詢處理要解決的一個很重要的問題。傳統數據庫大多都會創建類似B+樹索引來支持數據訪問。儘管創建索引對於事務處理中的數據訪問非常有效，對於類似Snowflake這樣的系統來說，索引反而可能會帶來很多問題。首先，索引會帶來的很多的隨機I/O訪問請求，這對於採用列式存儲（尤其帶壓縮）和S3的系統來說是一個非常嚴重的額外開銷。其次，索引還會大幅增加實際存儲的數據容量，以及增高數據加載時間。最後，索引還會降低用戶的使用體驗，尤其對於Snowflake來說：用戶還需要花額外的時間和精力去主動地創建索引。 對於大規模數據分析場景來說，一個可以替代索引的技術為：min-max剪枝。對於一塊數據來說（該塊數據可以是一頁，也可以是一個文件），系統會單獨維護這塊數據相關的元信息，其中最重要的元信息是這個塊中數據的最大值和最小值。結合查詢的過濾條件，這些min-max信息可以被用來判斷該數據塊內的數據是否會被查詢用到。例如，假設數據塊1中列x的min值是3、max值是5，數據塊2中列x的min值是4、max值是6，那麼對於包含where x>=6過濾條件的查詢來說，數據塊1中的數據肯定不會被用到，數據塊2中的數據才會被用到。和索引不一樣的是，類似min-max這樣的元數據所消耗的空間非常小，而且訪問會非常快。需要強調的是，這裡的min-max不一定是數值（整數、浮點數）的min-max，還有可能是日期、字符等的min-max。

作者：閒魚技術——莫癲 前言 在研發團隊發展到一定規模，同一領域問題不可避免地會存在多種解決方案。典型的，不同業務線會開發和使用不同的測試框架，很多業務線會重新開發特徵中心、配置中心、規則引擎和投放平臺。不可否認有業務特殊性或者已有方案無法滿足等原因導致合理建設，其中有重造輪子的現象。 作者在半年前開始投身閒魚會玩社區治理，從用什麼方案、是不是會重造輪子的自我懷疑，到後面沉澱會玩社區的通用審核系統高效應對運營需求的豁然開朗，這段經歷頗有收益。本文通過還原這段經歷和其中的思考，談談在解決相同領域的問題如何避免陷入重造輪子的泥潭，達到高效解決業務問題實現最大技術價值的目標。 不要重複自己 軟件工程中一個基本原則：DRY(不要重複自己)，也就是強調抽象和複用，這是避免重造輪子最基礎的要求。運用算法、設計模型和框架設計思想，能從不同角度和不同層次避免重複自己，而長期駐紮業務線的同學還需要對業務抽象，從解決一個又一個的業務問題，轉變成解決一類又一類問題的工作方式解放生產力。 不像平臺型產品經理在前期就會描繪好產品的完整藍圖，業務線產品經理則更多時候是將用戶側的產品形態或者運營的單點工具訴求翻譯成源源不斷的需求文檔，前後需求之間可能有關聯也可能沒關聯。在時間和空間不連續的需求中，識別出通用流程和可複用能力，提前抽象、規劃和設計就變得極其重要而有難度。在閒魚會玩社區業務起步階段我們對社區治理方面的需求進行了充分調研和提煉： 緊跟業務目標和政策法規：會玩社區定位為一個純淨、有調性和有氛圍的社區，需要運營全面洞察和協作把控社區的人、內容和場。同時網信辦加大網絡信息整治和處罰力度，對自查自糾的完整全面和及時性提出了更高的需求； 調研行業和競對解決方案：閒魚會玩是一個同時承載UGC和PGC內容的社區，同所有同類社區一樣，內容、話題和創作者等社區各維度元素在安全防控、分類和原創保護等都有著剛性的審核或標註訴求； 與合作方充分交流：團隊內外不乏在業務和技術上沉澱深厚的前輩，這是個吸收別人經驗和驗證自身想法的很好契機； 這些方式幫忙高效定位業務現處階段和中長期在同領域的訴求，結合當前需求，可以合理看到需要支撐風險決策、治理和打標等審核或類審核需求，具備業務接入、崗位培訓、審核、質檢和不斷優化效能的通用流程，不同的業務關鍵指標的訴求也基本一致，只是對人效和實時性的敏感程度不同而已。可以沉澱通用且支持擴展的審核系統承載上述業務，避免自我複製輪子快速接入業務。審核業務抽象 不要重複別人 另一種更為常見的重造輪子就是重複別人。澳大利亞的JohnKeogh於2001年申請註冊“圓形的交通設施”（輪子）為專利，於當年被評為2001年的搞笑諾貝爾獎科技獎。開源社區以及企業內部的軟件輪子頻出，不乏幾種原因： 閒暇時間個人學習或興趣驅動 不知道已有可用解決方案 別人東西體驗太差 已有方案不能完全滿足需求，無法適配、擴展，或成本過高 已有實現無人維護或者維護成本過高 戰略原因對戰略方向用賽馬方式進行內部競爭 組織架構原因導致無法合作或者合作效率低

作者 | 陳厚道  馮慶來源 | 阿里巴巴雲原生公眾號 導讀：本文將對 RocketMQ-Exporter 的設計實現做一個簡單的介紹，讀者可通過本文瞭解到 RocketMQ-Exporter 的實現過程，以及通過 RocketMQ-Exporter 來搭建自己的 RocketMQ 監控系統。RocketMQ 在線可交互教程現已登錄知行動手實驗室，PC 端登錄 start.aliyun.com 即可直達。 RocketMQ

作為近年來最受關注的新零售行業獨角獸，KK集團已完成一期門店系統上雲！記者日前獲悉，KK集團攜手阿里雲，加速以數字技術驅動業務。 KK集團創立於2015年，旗下的KK館、KKV、THE COLORIST調色師等多個品牌都名列所在賽道的頭部。今年4月，KK集團入選《2020胡潤全球獨角獸榜》，併成為CB Insights發佈的全球零售科技前瞻報告中唯一的實體商業獨角獸。與此同時，高速擴張的KK集團對IT系統提出了高安全、低成本、高彈性等要求。 鑑於此，KK集團選擇與阿里雲合作，藉助阿里云云原生組網方案，快速構建跨地域互聯網絡，實現“千店一網”，既保障了傳輸網絡鏈路優化，又低成本地解決了連鎖店模式中普遍存在的門店系統數據傳輸難題。 據介紹，“千店一網”將使得KK集團所有門店的數據能夠實時在線，為數據驅動業務打下基礎。未來，KK集團還將和阿里雲在數據中臺、智能運營平臺等方面深化合作，進而在選貨、供應鏈、倉儲、門店等多個環節實現更加全面的智能化運營。 今年3月，全球企業增長諮詢公司Frost & Sullivan發佈的《中國新零售行業研究報告》顯示，阿里雲佔中國零售行業50%的市場份額。阿里雲公開表示，未來3年投入2000億，加碼新基建，此舉將為零售業加速數字化轉型提供更多支持和服務。（內容來源於快科技官方百家號） 歡迎掃碼加入阿里雲新零售行業學習交流釘釘群 加入釘釘群可享有以下權益↓

3 月 29 日，阿里雲計算峰會在深圳召開。 會上，阿里“計算”家族的技術領頭人悉數到場，針對企業如何選擇最佳上雲路徑，如何保證雲上數據安全，如何解決雲上網絡問題以及如何構建企業雲上安全體系進行了分享和討論。 張獻濤 十年計算更迭，只為雲上的高效穩定 2020 年註定是不平凡的一年，疫情打破了很多常規的生活和工作方式，業內也出現了很多新的名詞，比如雲辦公、雲教育等，這背後都是雲計算在發生作用。 作為一家雲計算公司，阿里雲在 2020 年和客戶一起打破了太多不可能。年初，阿里雲決定免費開放一切 AI 算力，數天內支持了全國 20+ 家機構；幫助釘釘進行百倍擴容，支撐了過億人在家上學辦公，同時也支持了猿輔導在流量爆發情況下的正常運行；申通快遞核心系統全面上雲，IT 投入降低了 30%，並使用了阿里雲的容器 ACK、神龍裸金屬方案、雲數據庫平滑度過了雙 11。

作者 | 蕭逸來源 | 阿里技術公眾號 一 緣起 過去的一年，藉著《如何畫好一張架構圖？》、《2020總結（個人篇）：關於個人成長的再認知》以及《2020 總結（團隊篇）：招之即來，來之即戰，戰之必勝》這三篇文章的熱度，成為了2020的年度優秀作者，我個人習慣於回看自己「如何做到的」，所以藉著這篇文章也回看一下自己在寫文章過程中的一些成長，也希望能夠對大家有一些啟發。 二 書寫是為了更好的思考 1 寫文章的底層邏輯 我還記得很多年前在劉未鵬的博客中看到了《書寫是為了更好的思考》[1]這篇文章，從那個時候開始，寫文章就像一顆種子一樣種在了我的心裡，對我的成長影響甚遠，長得枝繁葉茂。 在我看來，對於任何問題的思考，想清楚、講清楚、寫清楚是三個完全不同的維度。 「想清楚」似乎是一件比較容易的事情，特別是在夜深人靜的時候，圍繞某一個問題，大腦可以非常活躍的閃爍著各種各樣的靈感，這個過程有點像頭腦風暴，讓自己興奮不已，但事實是我經常會「被大腦騙的團團轉」。 「講清楚」就是發現自我被騙的過程，那些思考的閃光點一旦遇上邏輯，就會發現很難走通，對於問題的思考也遠遠沒有頭腦裡的那般流暢，於是「在腦子裡講給別人聽」就變成了一個邏輯完善的過程，在此之後才是對一個問題相對完整的思考。 「寫清楚」是一個很好的反思過程，把「講給別人聽」的邏輯，通過文字書寫出來，大腦就再也不用費力去存儲那些內容，更多的精力可以用於不斷的反思自己的觀點，體系化的完善那些觀點，因為往往寫出來的時候才發現需要有很多背景要交代，有很多思考邏輯需要斟酌，有一些漏洞會被識別，有一些自己不完整的知識體系被覺察，這個過程中的成長其實才是最寶貴的。 所以，回看我自己，「為了更好的思考」可能是我寫文章的最底層邏輯，也是一把成長的鑰匙。去年我曾在團隊的週會上分享過一個主題《有效的輸出/成果是成長的唯一指標》，而寫文章我認為就是一種非常有效的輸出方式。 2

主要內容： 一、探討運維人員安全職責 二、解析數據庫業界案例事件 三、雲上數據庫安全問題解決方案   一、探討運維人員安全職責 1）數據安全現狀 企業IT關注點包括架構、性能、成本，IDC權威調研機構數據顯示，全球74.6%的企業最關心的問題是安全性，安全性永遠是第一位，數據庫是安全重中之重。 運維人員安全職責：從維護數據到支撐業務，根據業務相關性分成3層： ·第一層是數據的安全性，也就是如何防止託庫。保障好數據庫安全，這一層的能力更專注在數據庫本身防護，比如加密技術，權限控制技術。比如數據庫被暴力破解，因為沒有加密，被黑客攻破後把這個數據完全蕩走，在日常的運維過程當中接觸最多，需要對數據庫做內在或者外圍加固，防止數據庫系統被攻破，把裡面的數據拖走或者是毀壞。 ·第二層是業務安全，這一層會更關注在流程機制安全上，如何杜絕刪庫跑路。比如內部人員，因為本身流程不規範，出現了業界最常說的刪庫跑路行為，是業務安全的屬性，需要運維人員去完善。 ·第三層則是業務合規，這一點特別是在一些金融、保險、政府等敏感行業上，本身會有數據合規需求，比如兩地三中心、操作審計等監管必須能力。為什麼這一點會是最重要的，大家日常做運維肯定都知道，眼前的事情肯定最重要，一旦不合規，業務都上不了線，那業務數據本身也就產生不了價值。所以從業務相關角度來講，業務合規安全性最重要。 二、解析數據庫業界案例事件 1）安全無小事 數據庫安全問題，70%甚至80%以上都是由人禍造成的。不管是外在或者是內部的人，不管是因為客觀性攻擊數據庫，或者是主觀性破壞數據庫，人禍都佔了很大部分。整體上做數據庫的安全防護時，技術往往是一方面，更多的行為是在於人冶上面，怎樣通過這種流程跟手段有效的控制，在技術之外，把安全性的防護做好，是在整個數據庫安全領域裡，面臨的最為頭疼的一個問題。 人禍之外，天災屬於不可抗力因素，比如地震、海嘯或者其他極端的影響，施工團隊把機房電纜光纜給挖斷了，發生了火災等。這個行為的出現是不可抗力，且無法杜絕，我們需要通過本身的運維手段加固、防護，在發生事情時，解決事情對企業帶來的影響。 2）安全事件 人禍叢生，誰來背鍋？ 人禍安全事件帶來了哪些影響？下面列舉了兩個案例： 第一個案例:在17年-18年的時候，MongoDB作為流行的非關係型數據庫,3.2還是3.4版本上面出現了本身開源軟件上的版本漏洞。這個版本漏洞導致一旦數據庫暴露在公網，有很多的手段可以通過免密登錄的方式直接登錄數據庫。

內容簡要： 一、深度學習在醫療領域的應用 二、自然語言處理在醫療領域的實踐     一、深度學習在醫療領域的應用 （一）深度學習取得成功依賴於多個元素 深度學習三大要素：充足的數據、足夠的算力、不斷革新的算法。 （二）深度學習在許多醫學問題上取得成功 l  醫學圖像分類和分割 CNN l  文本中信息抽取、疾病預測 CNN、RNN、Transformer l  病患語音識別和機器翻譯 RNN、Seq2Seq l  體徵監測和疾病風險評估