【大資料】李國傑院士：大資料和人工智慧要特別重視大眾的剛性需求（深度）

大家晚上好，感謝大家參與這次分享，感謝 InfoQ AI 前線組織這次瀚思科技主題月！我們成立於三年前，按行業劃分是一家安全公司。但和大家熟知的賣防毒軟體的傳統安全公司很不一樣，瀚思幫助各種中大型企業搭建安全大資料的分析平臺，在平臺上實時執行各種機器學習演算法的安全分析策略，最終幫助企業定位各種安全問題。所以我們自認為也是一家大資料 +AI 公司。

我們常被人問到，為什麼要選擇這個“大資料 +AI+ 安全”這個對工程能力要求很高的混搭方向呢？

第一，當然是因為看好這個方向，我們認為這個方向是網路安全領域發展的大趨勢。這個趨勢雖然今天說起來顯而易見，畢竟現在所有的新舊安全廠商都說自己有 AI 能力，但三年前，安全界大部分人都不清楚 AI 能具體解決哪些安全問題，套用 AI 界的熱門話題詞，也就是常說的不清楚“AI 怎麼落地”，整個安全界也是在這幾年內摸索前進才有了些共識。

那第二的原因更直接，那就是，我們以前做過這個方向，有信心有能力在這個方向上，比別的其他廠家做得更好。從 2004 年開始，我們就用 SVM 演算法對病毒樣本分類，然後在 Hadoop 剛興起不久的 2008 年就開始基於 Hadoop 和 HBase 搭建大規模網際網路網站安全分析平臺。所以這個主題月的幾個分享的議題也是結合大資料 +AI 落地上這幾年的一些經驗，和大家探討下整個平臺搭建成功的關鍵因素。

考慮到大多數人都是對 AI 和大資料感興趣，這次系列分享，除了病毒樣本分類議題外，會特意簡化安全領域的相關知識，比如不會說網站滲透是怎麼做的、APT 攻擊模型包含幾階段等等，而把重點放在大資料平臺建設的主要技術點上，也就是和其他行業大資料平臺的共性上。

但共性並不代表所有平臺具體技術選型會完全一樣，具體業務需求、效能方面要達到的硬指標等，直接決定哪些技術方案可行或不可行。舉個極端例子，很多客戶自認為的大資料平臺建設需求其實是偽需求，資料並沒有大到需要 NoSQL 或者 Spark，常規的 MySQL 資料庫叢集就足夠支援客戶要的全部 OLAP 場景。並不是大資料平臺就一定比非大資料平臺各方面都有優勢。

怎麼挑選最適合的大資料技術是本次分享的一個主題，因為時間限制，會忽略很多技術細節，最後的參考頁我會列出更詳細的參考書籍。後續分享我們會從在三個不同細分領域的具體實踐方法來把這個主題梳理得更清楚。

大家先來看下一個典型的大資料分析平臺層次架構是怎樣：

1.最底下是資料收集層，典型大資料平臺的資料來源多種多樣，比如日誌、文字、網路流、甚至視訊、聲音等等。除了資料量大、速度高外、這些資料的一個重要特徵是非結構化，也就是不能齊整地轉換成傳統資料庫的表。某些資料經過處理後，能轉成結構化形式存入常規資料庫；如果實在不能結構化，就只能使用非傳統資料庫來儲存，比如輸入一句話在海量文字中查詢，這種只能靠文件資料庫。資料收集層會耗費系統開發非常多的精力，我們的經驗是多達 30%-50%。但除非採視訊這種很特別的資料，這部分相對技術難點低，而工作量巨大，髒活累活多，因為每種資料來源可能對應幾種採集和解析邏輯，尤其解析邏輯常常現場需要修改。很多業務系統運維人員都未必清楚目前運維日誌的格式含義。

我們的經驗是：先堆人力，支援好常見的資料來源，然後解析模組允許使用指令碼語言，現場對資料來源解析方法做修改。

資料進行結構化時往往會把原始資料對映到預定義好的一組字典，比如定義好 HTTP 訪問日誌必須有源 IP、域名、URL 等欄位，才方便頂層業務程式做通用的分析邏輯，而不是每次部署時要根據欄位名改分析邏輯。對我們這種賣業務層給客戶的廠家，這一步是必須的。但這種把 schema 先固定後分析的缺點也很明顯，使用者一旦發現 schema 錯誤或者有缺陷，更換成本很高。如果是臨時起意的分析場景，應該儘量避免這步。比如使用 Spark SQL，臨時根據一步步分析結果來定義 schema。

2.資料採集後進入儲存與通用分析層，兩者耦合度很高。儲存層是技術選型最複雜的元件，後面會重點談。先說分析，分析有兩大類場景 - 互動式離線分析 和 實時流分析 - 實現機制截然不同，但最近也有把兩個二合一的新框架趨勢，比如 Apache Beam。兩場景可以簡單粗暴地以實時性來分：前者延遲秒級以上，後者亞秒級。分析層基本都是選用開源軟體，目前看起來 Apache Spark，在 2.x 推出結構化流處理 Structured Streaming 後，有大一統趨勢。

3.最上是和實踐業務對應的業務應用層。大家聽到的對大資料平臺分析的分享往往不談這層，因為這層和下面兩層會分屬於不同部門開發。但我們因為商業模式的原因，會給客戶提供整個全三層的平臺。我們的經驗是這層常常決定整個專案的成敗，因為任何系統都是給客戶使用得好才能產生價值，而一般的客戶是不會通過程式設計來使用整個平臺，尤其是領導，可見的永遠是視覺化層。不過這次時間限制，不會具體談視覺化這個大議題。後面看是否需要專門安排瀚思的 UED 團隊來分析大資料分析的專門視覺化設計。

總結下一般分析平臺包含這幾大元件：

資料採集元件：採集端混合多種技術，ETL 邏輯多，目前沒有普遍滿足需求的採集端開源實現（Elasticsearch 帶的各種 Beats 算做得很好的），需要各種自行開發。採集後標配都走 Kafka 進儲存元件或者處理平臺。

資料儲存元件：技術選型最複雜，一般採用 NoSQL 滿足大資料要求。有可能混合多種 NoSQL。也可以不用資料庫，直接依賴處理平臺的資料持久化功能（檔案、Parquet 等）。

互動批處理資料處理平臺：一般都是 Spark，領先優勢在擴大。

實時流資料處理平臺：Spark Streaming/Structured Streaming、Storm/Heron、Flink 和新出的 Kafka Streams，其他選擇少見。

基於規則 + 機器學習演算法的分析層：Spark MLlib，或者追求高效能，用定製的小平臺。

視覺化分析呈現層：支援 Spark 上的各種 OLAP 自帶的 BI 應用層，或者定製。

雲部署、監控：YARN、Docker 等。或者雲平臺自帶部署、監控功能。

真確定業務資料量大到常規資料庫無法支撐，或者需要秒級實時分析，才需要開發大資料分析平臺。技術選型最忌諱的是看大公司用啥就用啥，因為大資料技術目前沒全面能解決所有場景的（雖然 Spark 在這個方向努力），都對目標場景互有取捨。比如 Flink 重點在流處理上，SQL 支援落後於 Spark。而 Spark MLlib 對 R 和 Python 開發的演算法程式支援得好，代價是效能不如專門的分散式演算法平臺。更不用說一票 NoSQL 都往往對特定讀寫模式做優化，比如擅長 OLAP 就不能用來圖分析等等。 如果沒有極端場景需求，目前看來 Spark 2.x 上二次開發就能滿足。當然需要額外定製開發資料採集層和視覺化層。

對選型不確定，同時實在不及看各開源專案內部實行機制的話，儘快對最主要場景做效能測試幫助判斷。各家自己發的效能測試報告都是挑對自己有利的場景，大資料軟體一般只擅長特定一些場景，所以官方測試報告基本沒參考價值。

發這張老圖不是為了恐嚇有選擇困難症的架構師。資料庫是電腦科學內歷史悠久的一個方向，加上市場需求巨大，導致有幾大類各種細分方向。從初期 OLTP 場景，到 70 年代 OLAP 場景興起，再到 2000 初因為 MPP 分散式架構不能擴充套件到幾十臺以上機器，不支援大資料場景，而誕生各種放棄傳統關係型資料庫 OLTP 一些約束的 NoSQL（Not Only SQL），再到大資料 OLAP、想結合傳統關係型資料庫 ACID 嚴謹性和 NoSQL 可擴充套件性的 NewSQL，每次轉向都有很多新的設計選擇，當然也有很多反覆。並不總是轉向後的方案就一定比原本的方案好。

NoSQL 最初是為解決大資料下的擴充套件性問題，捨棄 CAP 中的一致性 Consistency，優先保證可用性 Availability，分割槽容忍性 Partition tolerance。當然實際測試很多對 P 保障完全也沒有宣傳地那麼好。對一致性問題多采用最終一致性來延遲解決。當然最終具體怎麼個一致法，不同業務邏輯有不同的做法。因為分析平臺大多用 OLAP 場景，OLTP 場景下怎麼做複雜 CAP 取捨和我們關係沒那麼大。

NoSQL 對大資料分析平臺的直接影響在於支援非結構化資料支援，NoSQL 籠統可以分為 4 類：鍵值、文件、列儲存 和 圖資料庫。文件和列儲存資料庫最為常用，鍵值資料庫因為 API 介面比較原始形態、功能少，不常作為主力資料庫。圖資料庫在特殊領域，比如反欺詐，有巨大的優勢，但目前開源方案沒有做得特別成熟的。我們自己 4 種都有用到（分別是 RocksDB、Elasticsearch、Cassandra、JanusGraph），因為安全場景特殊性，主要使用前兩類。

NoSQL 陣營早期對外介面都不遵從 SQL 標準，有自己一套需要額外學習、互相之間不相容的查詢語法／API。除非自己的介面／視覺化層做得完備，不方便推廣給更大普通群體。

NewSQL 因為著力解決的問題，暫時和分析平臺關係不大，這次跳過不談。

MapReduce 的論文發表在 2004 年，它的簡單程式設計模型大大簡化了大規模分散式資料處理的學習門檻，同時比以前複雜的分散式程式設計模型更容易在海量機器上執行（MPP 幾十臺提升到上千臺）。加上又有 Google 的光環，開源版本 Hadoop 一出來後，很快成為業界大資料的標配。

但 Hadoop 並不瞭解 MapReduce 在 Google 內部的任務執行特點，因為 Google 是把 MapReduce 和優先順序更高的上線業務分析任務跑到同樣叢集上，大多數任務 MapReduce 可以隨時被打斷搶佔，Google 內部統計執行時間超過 1 小時的 MapReduce 任務，5% 的概率會被中途打斷，所以 MapReduce 會有很多看起來低效能資源浪費的設計。這種不重效率的架構設計結果是企業花大價錢部署好的大 Hadoop 叢集，發現十幾臺機器跑的 MapReduce 任務還不如一臺機器上稍微做優化的普通版本完成得快，而且 MapReduce 本身的功能過於簡單，企業需要在上面再封裝一層才方便使用。所以到今天其實 Hadoop 的部署很多隻剩下資源排程和 HDFS 在用。

具體分析 MapReduce 程式設計模型為何慢有很多原因，其中重要一環是企業實際都是多個 MapReduce 任務串接才能完成一個業務分析，Hadoop 對串接好的工作流並不做優化，上一個 MapReduce 的輸出寫到硬碟上的 HDFS，下一個 MapReduce 再從硬碟讀入資料，可想而知能有多慢。所以從 Flume 開始的大資料處理框架，都有基於整個工作流的程式設計模型和各種優化策略。比如沒在執行迭代的時候，Spark 和 Flink 的工作流模型都是各種運算元組合而成的有向無環圖。運算元也不僅限於 map 和 reduce，而是有各種各種操作，大大方便二次開發。

根據 Databricks 的統計，大部分公司使用批處理都是為了實現互動式查詢，以前是使用 SQL 從資料庫資料庫裡查結構化資料，而且通過 Spark SQL 查放在 HDFS 或者其他各種資料來源上的結構化／非結構化資料。所以 Spark 社群一直把 SQL 作為重點投入。

流處理平臺來自使用者期望對資料能有更實時的分析能力，當時基於 micro-batch 的 Spark 延遲至少在 1 秒以上，而且 API 對流分析非常不友好，比如缺乏流控、複雜視窗功能。Storm 算是第一個為大眾所知的流處理平臺。這塊最近兩年開始競爭激烈，除了 Flink 外，還有 Storm 的改版 Heron ，Kafka 的功能擴充套件版 Kafka Streams，新版已經支援流 SQL，Apache Beam 這種源於 Google Cloud Dataflow 定位更是要支援多平臺，同時統一流處理和批處理的 API。

Databricks 官方目標是構建大一統（OLAP+OLTP+ 流處理）的平臺，讓客戶拋棄目前怪異的 lamda 架構（獨立的流處理和批處理平臺組合）。目前看起來進展不錯。類似的大一統開源版還有 SnappyData、Splice Machine，也都是基於 Spark。

這種 lambda 架構是常見的方案，也是目前各種技術成熟度下的權宜之計。非實時離線計算系統操作全量資料集、實時／準實時線上系統分析源源不斷新增的資料集，也就是線上系統做增量分析。業務層會把雙系統對使用者隱藏起來，把分析結果顯得是來自一個系統，當然業務系統也經常協調雙系統會有各種分析結果不一致問題。

這也是我們以前採用的模式，預計隨著流計算的成熟，大部分採用 lambda 結構的都會遷移到純流式計算上，比如 Spark 結構化流處理。

在我看來有三點：

1. 功能沒有特別短板，能覆蓋各種通用場景：互動 SQL、流計算、演算法迭代、圖計算。新的非開源版號稱同時在 Amazon S3 上支援 OLAP + OLTP；圖中就是 DataBricks 公佈的大一統資料平臺架構。

2. SQL（SQL-92） 的相容支援度；

3. 公司／社群運營得非常好，看 Spark 支援多少種開發語言就知道，而且工程能力超強，新版本開發各種功能速度都很快。以前流處理受限於 micro-batch 架構，功能簡單，時延大於 1 秒，受到 Flink 和 Storm 等陣營的衝擊，很快就推出了號稱吞吐量和時延都比 Flink 優良幾倍，不過還沒正式釋出的的持續結構化流計算。

所以一般沒特殊場景需求，用 Spark 2.x 是最保險的選擇。

我們又再次面對眾多選擇，很多絕大部分還是沒聽說過的。這說明流處理平臺還不像批處理平臺一家（Spark）獨大。這有幾個原因：

1. 市場出現時間很短，第一個開源版知名的流處理平臺 Storm 2011 年才出來。

2. 需求變化大，目前主要的高效能需求推動力來自物聯網平臺，對效能要求遠超出一般企業的流處理需求，而這個潛在市場又出奇地大，導致將來流平臺會往這市場傾斜，優先考慮效能。

3. 不像互動式 SQL 分析，流處理很少是獨立的一個使用場景，使用者期望和批處理一體化，也就是統一分析平臺。

Spark 1.x 流處理一直被詬病是偽流處理，不像是 Storm 或者 Flink，從一開始就為流處理設計。舉個最簡單的例子，1.x 連事件時間都不支援，永遠使用進流處理平臺的時間為準，連流處理基本功能都不滿足。

新引入的結構化流雖然底層還是 microbatch，但測試延遲和吞吐量表現都優於老版。從 API 乍看起來，和 spark.mllib 變成 spark.ml 一樣，都是 RDD 往 DataFrame API 遷移，但底層設計理念有很多變化，Spark 想通過結構化流處理讓資料分析（比如以 SQL 為媒介）不再嚴格區分實時線上和非實時離線，也就是拋棄前面說的 lambda 架構，對持續到來的資料做到像是查詢一張持續增長的表。為實現這個目標，Spark 加了很多流處理必須的功能，比如事件時間、流控、多種事件視窗等等。不過 10 月剛釋出的 Spark 2.2 中，結構化流處理才變成 production quality，所以實際質量怎樣待看。

目前看起來 Spark 2 基礎流處理功能沒問題，API 不如 Flink 那麼完備，複雜功能需要額外開發，延遲和吞吐量仍然比 Flink 差，效能真要超過 Flink 估計得等 拋棄 microbatch 的 continuous processing 技術正式釋出。另外有些限制，比如不能聚合後再聚合，直接不符合我們現在的業務場景。所以我們還是使用 Flink。後續分享會討論技術細節。

Gartner 2017 對各廠家的資料科學平臺統計發現基本所有平臺都原生支援 Spark。除了 Spark MLlib 本身底層 API 豐富，原生包含 ETL 庫、分類、聚類、協同過濾、模型評測等演算法外，和額外花大力氣對演算法工程師常用的 Python 和 R 做好支援分不開。雖然有天生架構缺陷，運算元組合不能有環，演算法常見必需的迭代機制要通過比如 P2P broadcast 機制來實現。Flink 雖然考慮了迭代場景，但因為工程實現，我們實際測試中總體而言不如 Spark。兩者對於一般演算法效能都可以，但複雜演算法下，明顯受限於迭代機制的同步／通訊成本、引數數量大小等，不如專有演算法平臺。

專門定製的平臺肯定比通用平臺在特別場景下有效能優勢，比如 ACM DEBS Grand Challenge 流處理比賽這幾年的第一名都是自行開發的流處理平臺。演算法平臺上的優勢差異更大，好幾個都宣傳速度高達 Spark MLlib 的百倍，當然這明顯是挑場景宣傳。

簡單說 Spark 的主要侷限在迭代和海量引數上，GPU 支援一年前已有。即使 Flink 通過把帶反饋環的任務拓撲轉換為有向無環圖拓撲來原生支援迭代功能，但也只能支援簡單迭代，做不到類似 MPI 框架的複雜迭代功能。另外機器學習中如果應用場景需要訓練海量引數，而引數又大到無法放入機器記憶體的話，Spark 現在的引數共享機制無法工作。必須依賴第三方在 Spark 上實現的 Parameter Server。

類似 Tensorflow on Spark 這種方案，主要目的是藉助 Spark API 降低程式設計門檻，效能或者穩定性未必勝過原生的分散式版本。比如有 Bug 把兩 worker 分到一個 GPU core 上。

在大資料分析平臺上執行的大部分演算法屬於有監督演算法（分類等），少量屬於無監督演算法（聚類、或者異常檢測）。常見的兩類演算法一般都是全量資料訓練版本，並不支援增量訓練。比如使用者分類，輸入資料得是過往 N 天所有使用者的行為特徵，一旦做好分類。新增了一天資料，訓練得重新用 N+1 天資料開始一輪。

全量資料訓練顯而易見的缺陷就是慢，但對於有監督演算法，可以藉助前面所講的 lambda 架構，有了 N 天資料訓練後的模型，在新一天中，所有分類需求使用 N 天模型。等這天結束再開始 N+1 天資料訓練出新模型。Spark 從 1.4 開始就支援工業界的 PMML 模型格式匯出，模型匯入可以藉助第三方庫比如 jpmml-spark。

無監督學習的典型應用場景，比如物聯網領域、網路安全領域大量需要的異常檢測，需要對演算法做特殊改進以支援增量資料計算。全量計算速度跟不上，而 Lambda 架構損失實效性，兩者都不適合流計算。

我們快速過了遍瀚思在開發安全大資料分析平臺前前後後涉及的主要技術點。重點放在各種大資料技術的來源和側重上。因為大資料技術發展非常快，我們儘量做到技術總結符合最新發展狀況。當然肯定有錯誤遺漏之處，非常歡迎大家指出。

簡單說，我們的經驗是如下幾點：

1. 瞭解每種大資料技術的具體取捨，也就是需要了解技術發展的歷史，和具體內部架構細節。

2. 具體化要支援的場景，然後才定技術選型。不要盲目照搬別人的選型方案，因為很大可能場景不同。

3. 根據非結構資料型別和讀寫模式來選擇儲存方案，因為大資料分析平臺一般不需要 OLTP 交易功能。

4. 如無特殊場景需求，使用 Spark 2.x 作為通用平臺。當然特殊場景有各種特殊方案，比如用 Flink 做實時資料分析，自己開發 Parameter Server 搭建推薦演算法平臺等等。

今天分享先到這，感謝大家！後續三個分享會對今天提到的幾個議題做進一步具體案例說明。想加入我們南京或者成都分部做大資料／演算法開發的，直接郵件 hr@hansight.com，也歡迎大家關注瀚思的微信。

A：態勢感知這個方向沒錯，企業安全應該避免以往那種各種為政地堆積各種安全產品，而是幫助企業真正把企業安全進行全生命週期的安全管理。不過目前各家態勢感知產品過於著力於表面的簡單視覺化，比如地圖之類。我們認為態勢感知得把底層基本功打紮實，比如大資料分析平臺做好，才能談高層次的感知。大安全行業發展趨勢肯定是走更加自動化人工智慧話的道路，因為攻擊方只會越來越自動、越來越靠人工智慧。

A：目前我們看到的應用有這些：1 有監督學習下的病毒樣本檢測2 無監督學習下的異常檢測3 自然語言輔助安全處理自動化4 決策推理系統。

A：學習 AI 從基礎概念入手，然後 Kaggle 上拿公開資料練習，再拿安全領域資料練習。

A：Structured Streaming 最底層仍然是 microbatch，也就是偽流處理架構，和 flink 這種一開始就為流處理設計的架構比，延遲和吞吐量更差。有些功能也無法做到，比如來一條記錄就處理。雖然 Spark2 ss 也終於加了事件時間和流控，功能上還差 Flink  很多。但 Spark2 SS 將來的 continuous processing 可以徹底拋棄 microbatch，宣稱能到 1ms 下延遲。當然要等正式釋出才好判斷。

A：和上一個回答相關，簡單說就是 Spark 實時性和功能豐富度不能滿足我們需要，而且我們開始做 UBA 時候，Spark 還是 1.x，沒有 Structured Streaming，所以選擇很簡單。Flink 的另外優勢是豐富的 API，自己也各種功能都支援，比如  圖計算、機器學習 等。

A：我們基本不用預測，以前專案經驗用過預測演算法是基於 LSTM 的，也就是 RNN 一種。這方法通過查詢 Kaggle sales forecast 關鍵字能找到很多公開的 Kaggle 競賽得獎方案。

A：我們的日誌就是存到 ES，沒單獨提 ES 是因為目前 ES 很成熟，而且強調文字搜尋功能的話，基本只有 ES 一個選擇。solr 生態圈太小。不過我們認為 ES 做分析場景有很多限制，比如  aggregration 的記憶體控制，所以複雜分析是放 Spark/Flink 上做。

A：我們實驗過幾乎所有開源圖資料庫，大規模計算下都有各種 scalability 問題，比如 特別多邊的點，partition 後效率有問題。資料量不大的話，圖資料庫非常適合關聯資訊分析，比如反欺詐、威脅情報。建議規模大的話，得自己設計繞開開源圖資料庫的各種限制。

A：實際客戶部署大概最大 500TB，還在持續增長中。實驗室模擬測試過 PB 場景下的查詢。我們因為是分析場景，讀遠遠大於寫，所以只要看叢集的 scalability 問題。我們會參考

https://aphyr.com/posts/323-call-me-maybe-elasticsearch-1-5-0

對各種引擎的測試方法，在實驗室環境下進行類似測試。

A：

1. 有監督學習（病毒、域名、網頁內容等）樣本分類

2. NLP 語言／語音互動幫助分析人員自動化處理流程

A：我們有場景引擎，輸入是 CEP 和機器學習分析的結果，匹配場景規則。引擎基於 Drools 改的， CEP、機器學習演算法是自己寫的。

A：APT 最近風聲沒兩年前猛，業界前陣子都在談低技術的勒索軟體和黑產刷單的。我們認為 APT 只是低端的少了，高階的越發高階，主流沙箱方案根本無能無力。應對方法有：

1. 威脅情報

2. 基於多維度的行為分析

3. 病毒樣本靜態演算法分析

A：國內安全企業，近幾年應該注意滿足廣大企業急劇擴大化的合規需求。未來注意防禦高度自動化、人工智慧化的攻擊手段。

萬曉川  

瀚思科技聯合創始人兼首席科學家，擁有安全領域10項美國專利，並在核心安全演算法、APT沙箱、異常檢測（Anomaly Detection）和使用者行為分析（User Behavior Analysis）方面稱得上世界級專家。

畢業於東南大學少年班。萬曉川先生曾是全球最知名的安全公司-趨勢科技（Trendmicro）中國研發中心技術級別最高的核心技術人員，擔任過趨勢科技專利委員會中國區主席。

本文系“產業智慧官”（公眾號ID：AI-CPS）收集整理，轉載請註明出處！

版權宣告：由產業智慧官（公眾號ID：AI-CPS）推薦的文章，除非確實無法確認，我們都會註明作者和來源。部分文章推送時未能與原作者取得聯絡。若涉及版權問題，煩請原作者聯絡我們，與您共同協商解決。聯絡、投稿郵箱：erp_vip@hotmail.com