隨著企業(yè)安全邊界的擴大化模糊化、各類威脅新出速度越來越快、影響越來越廣，視企業(yè)安全邊界為靜態(tài)、仍然依賴各種特征碼技術的傳統(tǒng)安全思路早已落后，無法實際解決安全問題。必須通過各種創(chuàng)新，整合、人工智能、可視化等領域的最新技術進展，安全產(chǎn)品才能解決目前和將來的企業(yè)安全難題。

但如何選擇并整合各種技術是復雜系統(tǒng)工程，比常規(guī)企業(yè)安全軟件開發(fā)需要考慮更多因素。本次分享中對大數(shù)據(jù)、、可視化的最新進展和應用案例做個總結(jié)，重點討論大數(shù)據(jù)平臺云部署運維、交互批處理與實時流處理的關系、有監(jiān)督學習解決的安全問題和大數(shù)據(jù)可視化這四個細分領域。

以下：

大家晚上好，感謝大家參與這次分享！我們成立于三年前，按行業(yè)劃分是一家安全公司。但和大家熟知的賣殺毒軟件的傳統(tǒng)安全公司很不一樣，瀚思幫助各種中大型企業(yè)搭建安全大數(shù)據(jù)的分析平臺，在平臺上實時運行各種機器學習算法的安全分析策略，最終幫助企業(yè)定位各種安全問題。所以我們自認為也是一家大數(shù)據(jù) +AI 公司。

我們常被人問到，為什么要選擇這個“大數(shù)據(jù) +AI+ 安全”這個對工程能力要求很高的混搭方向呢？

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

那第二的原因更直接，那就是，我們以前做過這個方向，有信心有能力在這個方向上，比別的其他廠家做得更好。從 2004 年開始，我們就用 SVM 算法對病毒樣本分類，然后在 Hadoop 剛興起不久的 2008 年就開始基于 Hadoop 和 HBase 搭建大規(guī)模互聯(lián)網(wǎng)網(wǎng)站安全分析平臺。所以這個主題月的幾個分享的議題也是結(jié)合大數(shù)據(jù) +AI 落地上這幾年的一些經(jīng)驗，和大家探討下整個平臺搭建成功的關鍵因素。

關于本月技術分享

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

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

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

典型的一個企業(yè)數(shù)據(jù)分析平臺

大家先來看下一個典型的層次架構(gòu)是怎樣：

1.最底下是數(shù)據(jù)收集層，典型大數(shù)據(jù)平臺的數(shù)據(jù)來源多種多樣，比如日志、文本、網(wǎng)絡流、甚至視頻、聲音等等。除了數(shù)據(jù)量大、速度高外、這些數(shù)據(jù)的一個重要特征是非結(jié)構(gòu)化，也就是不能齊整地轉(zhuǎn)換成傳統(tǒng)數(shù)據(jù)庫的表。某些數(shù)據(jù)經(jīng)過處理后，能轉(zhuǎn)成結(jié)構(gòu)化形式存入常規(guī)數(shù)據(jù)庫；如果實在不能結(jié)構(gòu)化，就只能使用非傳統(tǒng)數(shù)據(jù)庫來存儲，比如輸入一句話在海量文本中查找，這種只能靠文檔數(shù)據(jù)庫。數(shù)據(jù)收集層會耗費系統(tǒng)開發(fā)非常多的精力，我們的經(jīng)驗是多達 30%-50%。但除非采視頻這種很特別的數(shù)據(jù)，這部分相對技術難點低，而工作量巨大，臟活累活多，因為每種數(shù)據(jù)源可能對應幾種采集和解析邏輯，尤其解析邏輯常常現(xiàn)場需要修改。很多業(yè)務系統(tǒng)運維人員都未必清楚目前運維日志的格式含義。

我們的經(jīng)驗是：先堆人力，支持好常見的數(shù)據(jù)源，然后解析模塊允許使用腳本語言，現(xiàn)場對數(shù)據(jù)源解析方法做修改。

數(shù)據(jù)進行結(jié)構(gòu)化時往往會把原始數(shù)據(jù)映射到預定義好的一組字典，比如定義好 HTTP 訪問日志必須有源 IP、域名、URL 等字段，才方便頂層業(yè)務程序做通用的分析邏輯，而不是每次部署時要根據(jù)字段名改分析邏輯。對我們這種賣業(yè)務層給客戶的廠家，這一步是必須的。但這種把 schema 先固定后分析的缺點也很明顯，用戶一旦發(fā)現(xiàn) schema 錯誤或者有缺陷，更換成本很高。如果是臨時起意的分析場景，應該盡量避免這步。比如使用 Spark SQL，臨時根據(jù)一步步分析結(jié)果來定義 schema。

2.數(shù)據(jù)采集后進入存儲與通用分析層，兩者耦合度很高。存儲層是技術選型最復雜的組件，后面會重點談。先說分析，分析有兩大類場景 – 交互式離線分析 和 實時流分析 – 實現(xiàn)機制截然不同，但最近也有把兩個二合一的新框架趨勢，比如 Apache Beam。兩場景可以簡單粗暴地以實時性來分：前者延遲秒級以上，后者亞秒級。分析層基本都是選用開源軟件，目前看起來 Apache Spark，在 2.x 推出結(jié)構(gòu)化流處理 Structured Streaming 后，有大一統(tǒng)趨勢。

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

核心組件

總結(jié)下一般分析平臺包含這幾大組件：

數(shù)據(jù)采集組件：采集端混合多種技術，ETL 邏輯多，目前沒有普遍滿足需求的采集端開源實現(xiàn)（Elasticsearch 帶的各種 Beats 算做得很好的），需要各種自行開發(fā)。采集后標配都走 Kafka 進存儲組件或者處理平臺。

數(shù)據(jù)存儲組件：技術選型最復雜，一般采用 NoSQL 滿足大數(shù)據(jù)要求。有可能混合多種 NoSQL。也可以不用數(shù)據(jù)庫，直接依賴處理平臺的數(shù)據(jù)持久化功能（文件、Parquet 等）。

交互批處理數(shù)據(jù)處理平臺：一般都是 Spark，領先優(yōu)勢在擴大。

實時流數(shù)據(jù)處理平臺：Spark Streaming/Structured Streaming、Storm/Heron、Flink 和新出的 Kafka Streams，其他選擇少見。

基于規(guī)則 + 機器學習算法的分析層：Spark MLlib，或者追求高性能，用定制的小平臺。

可視化分析呈現(xiàn)層：支持 Spark 上的各種 OLAP 自帶的 BI 應用層，或者定制。

云部署、監(jiān)控：YARN、Docker 等。或者云平臺自帶部署、監(jiān)控功能。

設計數(shù)據(jù)（分析）平臺的一般技術選擇原則

真確定業(yè)務數(shù)據(jù)量大到常規(guī)數(shù)據(jù)庫無法支撐，或者需要秒級實時分析，才需要開發(fā)大數(shù)據(jù)分析平臺。技術選型最忌諱的是看大公司用啥就用啥，因為大數(shù)據(jù)技術目前沒全面能解決所有場景的（雖然 Spark 在這個方向努力），都對目標場景互有取舍。比如 Flink 重點在流處理上，SQL 支持落后于 Spark。而 Spark MLlib 對 R 和 Python 開發(fā)的算法程序支持得好，代價是性能不如專門的分布式算法平臺。更不用說一票 NoSQL 都往往對特定讀寫模式做優(yōu)化，比如擅長 OLAP 就不能用來圖分析等等。 如果沒有極端場景需求，目前看來 Spark 2.x 上二次開發(fā)就能滿足。當然需要額外定制開發(fā)數(shù)據(jù)采集層和可視化層。

對選型不確定，同時實在不及看各開源項目內(nèi)部實行機制的話，盡快對最主要場景做性能測試幫助判斷。各家自己發(fā)的性能測試報告都是挑對自己有利的場景，大數(shù)據(jù)軟件一般只擅長特定一些場景，所以官方測試報告基本沒參考價值。

存儲組件的選擇？

發(fā)這張老圖不是為了恐嚇有選擇困難癥的架構(gòu)師。數(shù)據(jù)庫是計算機科學內(nèi)歷史悠久的一個方向，加上市場需求巨大，導致有幾大類各種細分方向。從初期 OLTP 場景，到 70 年代 OLAP 場景興起，再到 2000 初因為 MPP 分布式架構(gòu)不能擴展到幾十臺以上機器，不支持大數(shù)據(jù)場景，而誕生各種放棄傳統(tǒng)關系型數(shù)據(jù)庫 OLTP 一些約束的 NoSQL（Not Only SQL），再到大數(shù)據(jù) OLAP、想結(jié)合傳統(tǒng)關系型數(shù)據(jù)庫 ACID 嚴謹性和 NoSQL 可擴展性的 NewSQL，每次轉(zhuǎn)向都有很多新的設計選擇，當然也有很多反復。并不總是轉(zhuǎn)向后的方案就一定比原本的方案好。

SQL -> NoSQL

NoSQL 最初是為解決大數(shù)據(jù)下的擴展性問題，舍棄 CAP 中的一致性 Consistency，優(yōu)先保證可用性 Availability，分區(qū)容忍性 Partition tolerance。當然實際測試很多對 P 保障完全也沒有宣傳地那么好。對一致性問題多采用最終一致性來延遲解決。當然最終具體怎么個一致法，不同業(yè)務邏輯有不同的做法。因為分析平臺大多用 OLAP 場景，OLTP 場景下怎么做復雜 CAP 取舍和我們關系沒那么大。

NoSQL 對大數(shù)據(jù)分析平臺的直接影響在于支持非結(jié)構(gòu)化數(shù)據(jù)支持，NoSQL 籠統(tǒng)可以分為 4 類：鍵值、文檔、列存儲 和 圖數(shù)據(jù)庫。文檔和列存儲數(shù)據(jù)庫最為常用，鍵值數(shù)據(jù)庫因為 API 接口比較原始形態(tài)、功能少，不常作為主力數(shù)據(jù)庫。圖數(shù)據(jù)庫在特殊領域，比如反欺詐，有巨大的優(yōu)勢，但目前開源方案沒有做得特別成熟的。我們自己 4 種都有用到（分別是 RocksDB、Elasticsearch、Cassandra、JanusGraph），因為安全場景特殊性，主要使用前兩類。

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

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

數(shù)據(jù)處理基礎技術演進

MapReduce 的論文發(fā)表在 2004 年，它的簡單編程模型大大簡化了大規(guī)模分布式數(shù)據(jù)處理的學習門檻，同時比以前復雜的分布式編程模型更容易在海量機器上運行（MPP 幾十臺提升到上千臺）。加上又有 Google 的光環(huán)，開源版本 Hadoop 一出來后，很快成為業(yè)界大數(shù)據(jù)的標配。

但 Hadoop 并不了解 MapReduce 在 Google 內(nèi)部的任務運行特點，因為 Google 是把 MapReduce 和優(yōu)先級更高的上線業(yè)務分析任務跑到同樣集群上，大多數(shù)任務 MapReduce 可以隨時被打斷搶占，Google 內(nèi)部統(tǒng)計執(zhí)行時間超過 1 小時的 MapReduce 任務，5% 的概率會被中途打斷，所以 MapReduce 會有很多看起來低性能資源浪費的設計。這種不重效率的架構(gòu)設計結(jié)果是企業(yè)花大價錢部署好的大 Hadoop 集群，發(fā)現(xiàn)十幾臺機器跑的 MapReduce 任務還不如一臺機器上稍微做優(yōu)化的普通版本完成得快，而且 MapReduce 本身的功能過于簡單，企業(yè)需要在上面再封裝一層才方便使用。所以到今天其實 Hadoop 的部署很多只剩下資源調(diào)度和 HDFS 在用。

具體分析 MapReduce 編程模型為何慢有很多原因，其中重要一環(huán)是企業(yè)實際都是多個 MapReduce 任務串接才能完成一個業(yè)務分析，Hadoop 對串接好的工作流并不做優(yōu)化，上一個 MapReduce 的輸出寫到硬盤上的 HDFS，下一個 MapReduce 再從硬盤讀入數(shù)據(jù)，可想而知能有多慢。所以從 Flume 開始的大數(shù)據(jù)處理框架，都有基于整個工作流的編程模型和各種優(yōu)化策略。比如沒在執(zhí)行迭代的時候，Spark 和 Flink 的工作流模型都是各種算子組合而成的有向無環(huán)圖。算子也不僅限于 map 和 reduce，而是有各種各種操作，大大方便二次開發(fā)。

根據(jù) Databricks 的統(tǒng)計，大部分公司使用批處理都是為了實現(xiàn)交互式查詢，以前是使用 SQL 從數(shù)據(jù)庫數(shù)據(jù)庫里查結(jié)構(gòu)化數(shù)據(jù)，而且通過 Spark SQL 查放在 HDFS 或者其他各種數(shù)據(jù)來源上的結(jié)構(gòu)化／非結(jié)構(gòu)化數(shù)據(jù)。所以 Spark 社區(qū)一直把 SQL 作為重點投入。

流處理平臺來自用戶期望對數(shù)據(jù)能有更實時的分析能力，當時基于 micro-batch 的 Spark 延遲至少在 1 秒以上，而且 API 對流分析非常不友好，比如缺乏流控、復雜窗口功能。Storm 算是第一個為大眾所知的流處理平臺。這塊最近兩年開始競爭激烈，除了 Flink 外，還有 Storm 的改版 Heron ，Kafka 的功能擴展版 Kafka Streams，新版已經(jīng)支持流 SQL，Apache Beam 這種源于 Google Cloud Dataflow 定位更是要支持多平臺，同時統(tǒng)一流處理和批處理的 API。

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

常見 批處理 + 流處理 混合架構(gòu)

這種 lambda 架構(gòu)是常見的方案，也是目前各種技術成熟度下的權(quán)宜之計。非實時離線計算系統(tǒng)操作全量數(shù)據(jù)集、實時／準實時在線系統(tǒng)分析源源不斷新增的數(shù)據(jù)集，也就是在線系統(tǒng)做增量分析。業(yè)務層會把雙系統(tǒng)對用戶隱藏起來，把分析結(jié)果顯得是來自一個系統(tǒng)，當然業(yè)務系統(tǒng)也經(jīng)常協(xié)調(diào)雙系統(tǒng)會有各種分析結(jié)果不一致問題。

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

為何 Spark 是批處理的標配

在我看來有三點：

• 功能沒有特別短板，能覆蓋各種通用場景：交互 SQL、流計算、算法迭代、圖計算。新的非開源版號稱同時在 Amazon S3 上支持 OLAP + OLTP；圖中就是 DataBricks 公布的大一統(tǒng)數(shù)據(jù)平臺架構(gòu)。
• SQL（SQL-92） 的兼容支持度；
• 公司／社區(qū)運營得非常好，看 Spark 支持多少種開發(fā)語言就知道，而且工程能力超強，新版本開發(fā)各種功能速度都很快。以前流處理受限于 micro-batch 架構(gòu)，功能簡單，時延大于 1 秒，受到 Flink 和 Storm 等陣營的沖擊，很快就推出了號稱吞吐量和時延都比 Flink 優(yōu)良幾倍，不過還沒正式發(fā)布的的持續(xù)結(jié)構(gòu)化流計算。

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

流處理平臺的選擇

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

• 市場出現(xiàn)時間很短，第一個開源版知名的流處理平臺 Storm 2011 年才出來。
• 需求變化大，目前主要的高性能需求推動力來自物聯(lián)網(wǎng)平臺，對性能要求遠超出一般企業(yè)的流處理需求，而這個潛在市場又出奇地大，導致將來流平臺會往這市場傾斜，優(yōu)先考慮性能。
• 不像交互式 SQL 分析，流處理很少是獨立的一個使用場景，用戶期望和批處理一體化，也就是統(tǒng)一分析平臺。

Spark 流處理／結(jié)構(gòu)化流處理目前的局限性

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

新引入的結(jié)構(gòu)化流雖然底層還是 microbatch，但測試延遲和吞吐量表現(xiàn)都優(yōu)于老版。從 API 乍看起來，和 spark.mllib 變成 spark.ml 一樣，都是 RDD 往 DataFrame API 遷移，但底層設計理念有很多變化，Spark 想通過結(jié)構(gòu)化流處理讓數(shù)據(jù)分析（比如以 SQL 為媒介）不再嚴格區(qū)分實時在線和非實時離線，也就是拋棄前面說的 lambda 架構(gòu)，對持續(xù)到來的數(shù)據(jù)做到像是查詢一張持續(xù)增長的表。為實現(xiàn)這個目標，Spark 加了很多流處理必須的功能，比如事件時間、流控、多種事件窗口等等。不過 10 月剛發(fā)布的 Spark 2.2 中，結(jié)構(gòu)化流處理才變成 production quality，所以實際質(zhì)量怎樣待看。

目前看起來 Spark 2 基礎流處理功能沒問題，API 不如 Flink 那么完備，復雜功能需要額外開發(fā)，延遲和吞吐量仍然比 Flink 差，性能真要超過 Flink 估計得等 拋棄 microbatch 的 continuous processing 技術正式發(fā)布。另外有些限制，比如不能聚合后再聚合，直接不符合我們現(xiàn)在的業(yè)務場景。所以我們還是使用 Flink。后續(xù)分享會討論技術細節(jié)。

Spark 作為算法分析／AI 平臺

Gartner 2017 對各廠家的數(shù)據(jù)科學平臺統(tǒng)計發(fā)現(xiàn)基本所有平臺都原生支持 Spark。除了 Spark MLlib 本身底層 API 豐富，原生包含 ETL 庫、分類、聚類、協(xié)同過濾、模型評測等算法外，和額外花大力氣對算法工程師常用的 Python 和 R 做好支持分不開。雖然有天生架構(gòu)缺陷，算子組合不能有環(huán)，算法常見必需的迭代機制要通過比如 P2P broadcast 機制來實現(xiàn)。Flink 雖然考慮了迭代場景，但因為工程實現(xiàn)，我們實際測試中總體而言不如 Spark。兩者對于一般算法性能都可以，但復雜算法下，明顯受限于迭代機制的同步／通訊成本、參數(shù)數(shù)量大小等，不如專有算法平臺。

專有算法平臺的性能優(yōu)勢

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

簡單說 Spark 的主要局限在迭代和海量參數(shù)上，GPU 支持一年前已有。即使 Flink 通過把帶反饋環(huán)的任務拓撲轉(zhuǎn)換為有向無環(huán)圖拓撲來原生支持迭代功能，但也只能支持簡單迭代，做不到類似 MPI 框架的復雜迭代功能。另外機器學習中如果應用場景需要訓練海量參數(shù)，而參數(shù)又大到無法放入機器內(nèi)存的話，Spark 現(xiàn)在的參數(shù)共享機制無法工作。必須依賴第三方在 Spark 上實現(xiàn)的 Parameter Server。

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

有監(jiān)督算法 & 無監(jiān)督算法

在大數(shù)據(jù)分析平臺上運行的大部分算法屬于有監(jiān)督算法（分類等），少量屬于無監(jiān)督算法（聚類、或者異常檢測）。常見的兩類算法一般都是全量數(shù)據(jù)訓練版本，并不支持增量訓練。比如用戶分類，輸入數(shù)據(jù)得是過往 N 天所有用戶的行為特征，一旦做好分類。新增了一天數(shù)據(jù)，訓練得重新用 N+1 天數(shù)據(jù)開始一輪。

全量數(shù)據(jù)訓練顯而易見的缺陷就是慢，但對于有監(jiān)督算法，可以借助前面所講的 lambda 架構(gòu)，有了 N 天數(shù)據(jù)訓練后的模型，在新一天中，所有分類需求使用 N 天模型。等這天結(jié)束再開始 N+1 天數(shù)據(jù)訓練出新模型。Spark 從 1.4 開始就支持工業(yè)界的 PMML 模型格式導出，模型導入可以借助第三方庫比如 jpmml-spark。

無監(jiān)督學習的典型應用場景，比如物聯(lián)網(wǎng)領域、網(wǎng)絡安全領域大量需要的異常檢測，需要對算法做特殊改進以支持增量數(shù)據(jù)計算。全量計算速度跟不上，而 Lambda 架構(gòu)損失實效性，兩者都不適合流計算。

總結(jié)

我們快速過了遍瀚思在開發(fā)安全大數(shù)據(jù)分析平臺前前后后涉及的主要技術點。重點放在各種大數(shù)據(jù)技術的來源和側(cè)重上。因為大數(shù)據(jù)技術發(fā)展非常快，我們盡量做到技術總結(jié)符合最新發(fā)展狀況。當然肯定有錯誤遺漏之處，非常歡迎大家指出。

簡單說，我們的經(jīng)驗是如下幾點：

• • 了解每種大數(shù)據(jù)技術的具體取舍，也就是需要了解技術發(fā)展的歷史，和具體內(nèi)部架構(gòu)細節(jié)。
  • 具體化要支持的場景，然后才定技術選型。不要盲目照搬別人的選型方案，因為很大可能場景不同。
  • 根據(jù)非結(jié)構(gòu)數(shù)據(jù)類型和讀寫模式來選擇存儲方案，因為大數(shù)據(jù)分析平臺一般不需要 OLTP 交易功能。
  • 如無特殊場景需求，使用 Spark 2.x 作為通用平臺。當然特殊場景有各種特殊方案，比如用 Flink 做實時數(shù)據(jù)分析，自己開發(fā) Parameter Server 搭建推薦算法平臺等等。

今天分享先到這，感謝大家！