歷經3度翻修後,趨勢科技資深軟體工程師陳煜倫終於找到目前最適合趨勢的大數據分析架構SDACK。

圖片來源: 

趨勢科技

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


Advertisement

更多 iThome相關內容