瀚思科技如何整合複雜技術打造數據分析平台？

前言：隨著企業安全邊界的擴大化模糊化、各類威脅新出速度越來越快、影響越來越廣，視企業安全邊界為靜態、仍然依賴各種特徵碼技術的傳統安全思路早已落後，無法實際解決安全問題。必須通過各種創新，整合大數據、人工智慧、可視化等領域的最新技術進展，安全產品才能解決目前和將來的企業安全難題。

但如何選擇並整合各種技術是複雜系統工程，比常規企業安全軟體開發需要考慮更多因素。本次分享中對大數據、人工智慧、可視化的最新進展和應用案例做個總結，重點討論大數據平台雲部署運維、交互批處理與實時流處理的關係、有監督學習解決的安全問題和大數據可視化這四個細分領域。[本文根據萬曉川先生在InfoQ AI前線社區技術分享整理]

大家晚上好，感謝大家參與這次分享，感謝

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，每次轉向都有很多新的設計選擇，當然也有很多反覆。並不總是轉向後的方案就一定比原本的方案好。

【SQL -> NoSQL】

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 結構化流處理。

【為何 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 流處理／結構化流處理目前的局限性】

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。後續分享會討論技術細節。

【Spark 作為演算法分析／AI 平台】

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 搭建推薦演算法平台等等。

推薦閱讀：