10億筆Log分析靠SDACK架構，趨勢3度翻轉資安大數據平臺架構

在2008年時，趨勢科技就已經開始擁抱大數據平臺Hadoop，利用它檢查數十億個網站，檢查其中是否有可疑的惡意程式，他們也發展出自家的Hadoop版本TMH（Trend Micro Hadoop）。但是到了2015年，日益猖狂的APT攻擊，並沒有固定的判斷特徵，趨勢得要從系統每日收集的Log資料中，尋找是否有被滲透的蹤跡。

但若繼續使用Hadoop，儲存分析過程中暴增的的資料量，得讓趨勢付出許多硬體投資成本。單憑人力，更不可能解讀每天數十億的日誌事件，勢必要透過新的大數據平臺，探尋其中的線索。

設計大數據平臺時碰上的4V挑戰

不過，負責設計這個資安大數據平臺時，趨勢科技資深工程師陳煜倫第一個挑戰，就是大數據界俗稱4V的考驗：多樣性（Variety）、資料量（Volume）、資料流（Velocity），以及真實性（Veracity）。

他解釋，此平臺所要分析的Log數據多樣性繁雜，企業內部每個員工的一舉一動，都會在AD伺服器、Proxy代理伺服器中留下Log紀錄。

第2個挑戰則是龐大的資料量，陳煜倫舉例，每日光是單一類型Log資料，就會產生超過10億筆的紀錄。

再者，因應即時串流分析需求，平臺必須具備快速分析、整理資料的能力，否則只會留下堆積如山的未處理數據。最後，資料在流動的過程中，難免因網路傳輸等因素而產生毀損。為了不讓這些異常數據造成分析準確率降低，必須篩選、過濾出具代表性的資料。

大數據平臺得能水平擴充和即時分析

而陳煜倫所設計的平臺，並非一次到位，而是歷經3次架構翻新，才找出目前最合適的SDACK架構。他表示，此大數據平臺除了要具備彈性水平擴充、即時串流分析能力，也要能處理大量Log資料。

第1個版本的大數據平臺，主要由Kafka、Flume以及Spark三大核心元件所組成，利用Kafka及Flume進行資料前置處理，最後則是透過Spark進行資料處理與分析。

陳煜倫解釋，當資料流進入平臺時，第一關會通過Kafka，利用它儲存Log資料，作為緩衝層。他表示，Kafka是一個分散式資料串流平臺，除具備執行即時運算、處理高吞吐量資料的能力，也能根據線上環境需求，水平擴充新的Kafka叢集。此外，Kafka也有提供副本複製（Replica）的功能，增進系統可用性。

下一步，資料則經由Kafka，傳送至Flume，進行ETL處理（Extract-Transform-Load，萃取、轉換及載入）。透過Flume，開發者可以自行設計、實作Log資料的邏輯。而它也提供相容於Kafka的資料傳輸介面，「可以很輕易地從Kafka撈取資料」，在完成資料萃取的處理程序後，Flume則再將資料流導入Kafka，「讓後續分析不需要進行前置處理，藉此增進演算法運算效率。」

而核心演算法則是布建在Spark平臺，「除了具備水平擴充能力，最重要的是，它能同步支援即時串流分析及批次處理。」

另外，Spark也具備方便資料科學家使用的工具，例如，開發者可使用機器學習模組MLib，將演算法實作於Spark之上。而圖像API模組GraphX可用於分析相異類型Log資料間的關係，讓資料科學家判讀各數據的相關性。

最後，系統產生的分析報告，除了儲存在PostgreSQL資料庫中，陳煜倫也透過Node.js搭建的網站入口，提供用戶查詢服務。

趨勢科技資深軟體工程師陳煜倫表示，建構大數據平臺並沒有標準答案，「重要的是了解問題的本質，在使用過程中，慢慢地進行調整。」。

系統得隨需求不停改變

第1版的架構設計看似足以應付用戶的需要，「但是需求是不斷改變，必須持續增加新功能」，像是前端接收資料的Kafka平臺，它並沒有相容常見的Log資料傳輸協定，例如TCP、Syslog等，必須額外在客戶端也架設Kafka才能傳送資料，「這樣是多此一舉。」

再者，平臺除了即時串流的能力，也不可忽略批次處理程序的重要性。陳煜倫表示，要透過統計分析、機器學習，產出有價值的統計、分析模型，「必須累積一段時間的Log資料，而非不停一直進行即時分析。」而趨勢科技內部的資料科學家也提出需求，想利用Spark執行更多的批次處理工作。最後，Log資料肇因網路傳輸，使傳送過程延遲，導致資料完整性不足，「得要確保演算法不因此而準確率降低。」

靠Fluentd解決資料傳輸介面問題

第2版本的架構中，陳煜倫則導入雙資料流架構，支援即時及批次處理工作，並引進開源Log收集器Fluentd及Redis。他表示，別於Kafka，Fluentd則提供更多資料傳輸介面套件，可以支援TCP、UDP及Syslog等協定。

此外，Fluentd也可以作為資料傳輸的緩衝，等待延遲的資料都傳送完畢，再一併引入下個處理流程，「確保Spark在特定時間區間內，收集資料都是完整。」

第2次翻修後的架構，「其實仍舊不足。」陳煜倫苦笑著解釋，他原本盤算利用Fluentd解決資料傳輸延遲，但是第2版的設計仍然無法解決，「究竟緩衝時間要設定多長？」他舉例，假設開發者設定緩衝時間1小時，但資料卻晚了2個小時才送達，還是會造成資料完整性不足。

不僅如此，第2版架構中，他也結合了Kafka、Fluentd及Redis，想要通吃批次、即時處理，「但這違反Kafka的初衷，它的目的並不是用於處理批次工作。」

結合Kafka、Akka，取代Flume資料ETL功能

面臨2度修改架構的需求，陳煜倫的朋友便建議他，不妨參考近年火紅的SMACK架構（Spark、Mesos、Akka、Cassandra、Kafka）。

這次，陳煜倫結合了Akka Stream以及Kafka API模組Kafka Stream，用來取代原本Flume元件的資料ETL功能。他解釋，Akka Stream與Fluentd的功能類似，利用領域特定語言（DSL）進行開發，處理資料流程也更方便。而利用Reactive Kafka，則可以方便開發者與Kafka溝通，或是撈取資料。

Akka Stream的功能還不如此，在資料傳輸過於火爆時，它也可做為緩衝層。他解釋，當系統後端處理資料碰上瓶頸時，Akka Stream會發出請求，要求前端系統放慢傳輸資料的速率，「防止過度負荷，導致系統當機。」

而分散式NoSQL資料庫Cassandra則可以讓使用者根據需求，自訂Data Schema架構。陳煜倫表示，Cassandra不僅和Spark整合完全，它也會儲存完整的Log紀錄，「可以存取任意時間點的資料，就可以解決資料傳輸延遲的問題。」

用Docker快速部署大數據平臺

原本在SMACK架構設計中，使用了Mesos來管理叢集。不過，陳煜倫表示，由於趨勢的大數據平臺得部署於企業客戶端的環境，要他們建立一套龐大的運算叢集並非易事。因此他就利用Docker取代Mesos，一舉再把SMACK翻轉為SDACK架構，可以更容易在開發環境、客戶端部署大數據平臺。

在SDACK架構中，所有的元件都具備水平擴充的特性，當某功能的需求突然增加，可以透過Docker Container打包，建立新運算叢集，應付新增的工作流量。

另外，陳煜倫也把相關Docker映像檔都上傳至Docker Hub，方便企業用戶可以直接下載，就地完成部署工作。同時，Docker Compose也利用Yaml文檔，定義應用程式運行需要的元件，「企業用戶可以很快速的建立系統。」

在3度翻新系統架構後，陳煜倫表示，建構大數據平臺並沒有標準答案，「重要的是了解問題的本質，在使用過程中，慢慢地進行調整。」他認為，開發者不應屈就於時間壓力，而胡亂拼湊出解決方案，「這些都將成為技術債，未來要花更多時間解決。」