Apache HBase建置高效能網路流量分析系統 .pdf

File information


Original filename: Apache HBase建置高效能網路流量分析系統.pdf
Author: evans_ye@trend.com.tw

This PDF 1.5 document has been generated by Microsoft® Word 2013, and has been sent on pdf-archive.com on 13/01/2015 at 15:10, from IP address 111.249.x.x. The current document download page has been viewed 1357 times.
File size: 922 KB (15 pages).
Privacy: public file


Download original PDF file


Apache HBase建置高效能網路流量分析系統.pdf (PDF, 922 KB)


Share on social networks



Link to this file download page



Document preview


Communications of the CCISA
Vol. 21 No. 3 Jul. 2014

以巨量資料技術 Apache HBase 建置高效能網路流量分析系統
葉祐欣
趨勢科技股份有限公司
evans_ye@trend.com.tw

摘要
近年來巨量資料與雲端運算的議題相當熱門,而在背後推動相關技術持續演進的關
鍵腳色,就是開放原始碼的巨量資料平台 Apache Hadoop。本文探討在巨量資料的浪潮
下,如何利用相關技術解決網路流量分析在效能方面的問題,並詳細介紹建置於 Hadoop
之上的 NoSQL 資料庫 Apache HBase 其具體的設計哲學與架構,透過深入了解 HBase 運
作模式後,提出一個應用於網路流量的即時分析與搜索系統,除了能夠協助資訊安全分
析師快速進行網路流量分析外,也能透過與其他資訊安全系統整合進行入侵、異常與回
溯式偵測,即時排除組織的資訊安全危害。
關鍵詞:資訊安全、網路流量、巨量資料、NoSQL、Apache HBase

壹、前言
過往案例顯示,許多遭到駭客入侵的組織多半是由於內部員工缺乏資訊安全警覺或
遭受進階持續威脅(Advance Persistent Threats, APT)[24]攻擊而點擊了惡意網站、釣魚
郵件遭植入惡意程式,進而成為了駭客的攻擊跳板。著名案例如 2009 年 Google 遭受的
極光行動攻擊(Auroa attack)[26]、2011 年 RSA Secure ID 攻擊[13]以及 2013 年的黑暗
首爾事件(Dark Seoul)[28]。由於組織對內部的安全控管往往較對外來得寬鬆,即認為
內網是安全的,故一旦某台位於組織內部網路的電腦遭到入侵,駭客往往較容易利用此
電腦向更多組織內部的電腦發起攻擊並散布惡意程式。由於遭到駭客入侵可能造成組織
巨大的資訊財產損害以及嚴重的信譽流失,因此這類入侵偵測與隔離排除的即時性成為
了一個重要課題。
資訊安全部門為了保障組織內部網路不受安全威脅,除了設置防火牆與安裝防毒軟
體達到第一線的入侵防護外,還需建置入侵偵測系統(Intrusion Detection Systems, IDS)
對於任何可疑的連線做進一步分析調查。一般的入侵偵測系統是透過設定一組規則來偵
測可能的入侵,然而由於攻擊手法日新月異,除了倚靠 IDS 的自動化入侵偵測外,資訊
安全分析師還必須針對每一次可能的入侵另做詳細的調查,以免有漏網之魚造成組織潛
在的安全危害。
本文提出一個基於開放原始碼巨量資料技術所打造的即時網路流量分析系統。資訊
安全分析師可以透過此系統快速搜尋歷史網路流量紀錄,針對遭受入侵之電腦的任何連
外紀錄做進一步分析調查,找到其餘潛在遭受入侵感染的電腦,對其實施數位安全鑑識
並排除相關病毒、木馬與後門,有效根除組織內部的資訊安全威脅。

Communications of the CCISA
Vol. 21 No. 3 Jul. 2014

貳、網路流量分析
網路流量分析與入侵偵測(Intrusion Detection)一直是個相當熱門的研究議題,相
關應用有流量異常偵測[10,15,16,20]、payload 分析[23]、worm 及 malware 散佈偵測[8,17,25]
以及 botnet 偵測[12,14,22,27]等,對於使用網路流量於入侵偵測的研究方法,Sperotto 等
人[21]有一個完整的分析與整理。本文對於網路流量(IP Flow)的定義遵循 IETF(Internet
Engineering Task Force)中 IPFIX(IP Flow Information Export)工作小組的定義[7,19]:
網路流量是由一群 IP 封包在一定的時間內通過網路中的一個觀察點所構成,這些網路流
量由一組網路封包中的通用屬性(common properties)所組成。在 IPFIX 的定義中,這
組通用屬性稱之為 flow keys,可表示如下:

IPsrc , IPdst , Port src , Portdst , Pr otocol, Packets, Bytes, Timestamp
上述依序為發送端與目的端 IP、發送端與目的端 port、網路協定、封包數量、傳送 bytes
數以及時間戳記。通常每一筆網路流量只會紀錄上述 metadata,而不對任何 payload 做紀
錄。這樣的網路流量紀錄會在路由器上產生,並透過設定將紀錄轉送至流量搜集器(flow
collector)。
現今關於網路流量的相關研究,大多著重在入侵偵測的演算法開發與模型發展,然
而,對於攻擊手法不斷推陳出新的資訊安全領域,加以企業被入侵後所付出的高昂代價,
由專業資訊安全分析師對任何可疑活動進行進一步的調查與分析勢必在所難免。除此之
外,在入侵偵測領域中,Behavior-based Model[12]雖然能夠偵測到較多的惡意行為(true
positive),卻也容易產生過多的誤報(false positive)[18],因此除了不斷提升演算法的準確
率外,如何支援資訊安全分析師對偵測結果進行分析檢測,在短時間內進行大量歷史資
料的搜索分析,就成為了一個值得關注的議題。

圖一:Behavior-based Model 有較高的 true positive 及 false positive[18]

Communications of the CCISA
Vol. 21 No. 3 Jul. 2014

參、巨量資料相關技術探討
Apache Hadoop
近年來由於分散式運算系統 Apache Hadoop 的快速發展與日趨成熟,巨量資料(Big
Data)相關議題也隨之受到矚目。Hadoop 原是 Nutch 的一環,兩者皆由 Dong Cutting 所
創立。Nutch 原先為了索引大量網頁資料,曾經遭遇到效能與軟體擴展性的難題,在
Google 發佈了 Google File System[11]以及 Mapreduce[9]兩篇論文後,Dong Cutting 參考
此二篇論文改進了 Nutch 的架構,將其成功運行在數十個節點的叢集上。不久之後 Yahoo
對於這樣的分散式運算系統產生了興趣,於是 Dong Cutting 將其自 Nutch 獨立出來,命
名為 Hadoop,並加入 Yahoo 組建的團隊致力於 Hadoop 的開發工作。
Hadoop 在資料儲存方面參考 Google File System 實作了 HDFS (Hadoop Distributed
File System),HDFS 的設計哲學考量了整體叢集的容錯能力。系統預設會建立 3 份資料
備份(replica)
,如此一來當叢集中任意節點發生錯誤即可保障資料不致丟失,另一方面
資料備份也有助於提升 MpaReduce 計算的資料本地性(data locality),減少透過網路將
資料傳輸至運算節點的負擔。
Hadoop 作為一個開放原始碼的開發項目,現已成為 Apache 基金會的 top level
project。由於其對一般商用硬體的友好支援,使得企業導入 Hadoop 作為巨量資料解決方
案的可行性大大提高。加以圍繞在 Hadoop 周邊的軟體生態系蓬勃發展,如 NoSQL 資料
庫 Apache HBase、分散式 log 蒐集系統 Apache Flume、in-memory 計算架構 Apache Spark、
類 SQL 查詢工具 Apache Hive 以及 graph 計算框架 Apache Giraph 等,都令 Hadoop 在解
決各種不同巨量資料問題時,有能力提供對應的解決辦法。
Apache HBase
有鑑於傳統的關聯式資料庫無法良好支援巨量資料下的即時查詢,NoSQL 的概念被
提出。NoSQL 主要指非關聯性、分佈式、不提供 ACID 的資料庫設計模式。HBase 作為
NoSQL 資料庫的一種,提供了持久化的分散式、多維度稀疏儲存模型,並將底層資料儲
存於 Hadoop HDFS 之上。Apache HBase 可以視為是 Google Bigtable[6]的一個開放原始
碼實作。
HBase 在 Eric Brewer 的 CAP 定理[5]中屬於 CP 類型的系統,擁有 strict consistency
以及 partition tolerance 特性。strict consistency 代表任一筆資料的操作是 atomic 的並且能
在瞬間完成,其背後隱含的意義是任何時候用戶端都能查詢到最新的資料,與此相對的
eventual consistency 僅能保證資料的操作最終都能完成,然而用戶端在此期間有可能查詢
到舊的資料。partition tolerance 確保系統在任一節點發生錯誤時不致影響系統繼續運行。
由於任一分散式系統僅能 CAP 定理中的任兩項,故 HBase 在可用性上有其侷限在。
在 HBase 中最基本的儲存單元是一個 column,column family 由一個或多個 column
構成;再由一個或多個 column family 組成一個 row,每一筆 row 由一個唯一的 rowkey

Communications of the CCISA
Vol. 21 No. 3 Jul. 2014

表示,最後由多筆 row 組成一個 HBase table。前述構造可以很容易地與傳統關聯式資料
庫做對照,與其不同的是,HBase 在此之上還增加了時間的維度,可以依據資料寫入的
時間(timestamp)儲存多個 version。

圖二:rowkey 的排序方式
HBase table 中的每一筆 row 會根據 rowkey 做字典排序。在字典排序中每一個 rowkey
的比對是透過二進位的方式,byte 對 byte,由左至右。由圖二可以看到,因為 row-1…小
於 row-2…,故不論 row-1 後面接的字元是什麼,它永遠排序於 row-2 之前。這樣的排序
特性讓 HBase 有類似於 RDBMS 中的 primary key index 的功能,並且有助於 HBase 快速
地進行 rowkey range scan 以及特定 rowkey 的隨機存取。
HBase 在資料儲存架構上引入了 column-oriented 資料庫的概念。column-oriented 資
料庫的概念是將同一欄位的資料作為連續區塊做讀取與寫入,相對於傳統資料庫的
row-oriented 是以整個列為單位做讀寫操作。column-oriented 的一個具體的好處是對於某
些特定的分析查詢,並不是每一個欄位都需要被取出,此時 column-oriented 儲存格式僅
將所需的欄位從硬碟讀出,省去讀取其餘欄位的負擔,此一特性在巨量資料的分析與處
理上對於效能有極大的幫助。HBase 在儲存格式的設計上就是利用這個概念,將可能同
時存取的欄位歸入同一個 column family,不同 column family 實際上對應到不同的儲存檔
案,稱之為 Hfile,因此存取同一 column family 內的值時只會讀取這個 column family 下
的 Hfiles,避免多餘的硬碟讀取。圖三表示傳統的 row 及 column 儲存格式在 HBase 中對
應不同 column family 的儲存方式。

圖三:HBase 底層對應不同 column family 的儲存架構

Communications of the CCISA
Vol. 21 No. 3 Jul. 2014

圖四: HBase timestamp 及 version 的進階查詢
每一個 column 中的值(或稱做 cell),會在寫入當下時由系統自動標記 timestamp,
亦可由使用者自行指定 timestamp 值。如此一來 HBase 便可支援多個 version 的資料存取,
在 scan 或 get 時可以透過指定 time range 或特定 timestamp 值取得某一歷史區間或某特定
時間點的資料。圖四示範將 user_id 為 001 的 row 更新為 011,因為 HBase 支援多 version
儲存模式,因此可以透過指定 time range 以及返回 version 數來查詢更新紀錄。
Apache Flume
Flume 是一個高效能的 log 蒐集與傳遞系統,其設計上提供了高可用性以及分散式的
橫向擴展能力,並在傳遞 log 時透過 transection 機制保障了可靠性。Flume 在 1.x 版為了
簡化原本複雜的架構與提高穩定性進行了大工程的重構[2],新版本 Flume NG(Next
Generation)除了大幅簡化了原本複雜的部署架構外,也減低了使用者的學習負擔。Flume
NG 在使用上僅需一個 agent 的角色即可獨立運作,相對 Flume OG(Old Generation)中
agent、collector、master 的複雜架構來得簡單許多。

圖五:Flume 基本架構示意圖[1]
圖五為一個 Flume 的基本架構,要啟動一個 Flume 的 agent 需要指定一個設定檔,
設定檔定義了 source、channel 以及 sink。source 為資料源,負責產生資料(在 Flume 中
資料的基本單位為 event);channel 是存放 event 的 queue,用來緩衝 source 與 sink 間的
運作;sink 則負責將 event 送達目的地,此三個元件構成 Flume 最基本的資料流。在可
靠性方面,Flume 的 source 會確保 event 成功進入到 channel 後才 commit transaction;sink

Communications of the CCISA
Vol. 21 No. 3 Jul. 2014

也一樣會在 event 成功送達目的地後才 commit transection,因此發生錯誤時尚未 commit
的 event 還是會留在 queue 中並且可以透過重試機制保障資料的完整性。
Flume 提供了許多好用的 source 類型與 sink 類型[1],這對於使用 Flume 來銜接不同
系統並串接資料流有極大的幫助。舉例如 Syslog TCP Source 可以接受透過 Syslog TCP
形式送來的資料、Spooling Directory Source 則可以監控某一特定目錄並將目錄下的檔案
讀出作為資料源;sink 方面則有對 Hadoop 友善的 HDFS Sink 及 HBase Sink,能分別將
資料送上 HDFS 與寫入 HBase。Flume 除了支援多樣化的資料格式外,也預留了使用者
客製化的能力。在任何一款 source 類型下都能透過設定客製的 interceptor 對每一筆流經
的 event 進行過濾或修改;在 sink 端一樣能透過設定客製化的 serializer 對流經的資料做
加 工 處 理 , 要 自 行 撰 寫 這 類 程 式 只 需 繼 承 Flume 的 Interceptor 或 Serializer Java
interface[1]。

肆、系統設計
本文提出一個基於巨量資料技術 Apache HBase 打造的高效能網路流量分析系統,系
統架構如下所示:

圖六:系統架構圖
網路流量資料首先由各個網路骨幹上的 router 產生並送至 flow collector,再透過 Syslog
TCP 轉送到 Flume agent 端。Flume agent 的部署有相當大的彈性,可以根據組織內實際
狀況彈性的調整,本文提出最基本的部署方式為將 Flume agent 部署在 flow collector 下
游,Flume agent 收到 flow collector 轉送的網路流量後,透過客製化的 HBase serializer 將

Communications of the CCISA
Vol. 21 No. 3 Jul. 2014

每一筆網路流量轉換成 HBase 資料儲存格式,再交由 HBase Sink 寫入 HBase,最後由前
端 web server 提供即時的分析查詢。由於本文使用了 HBase 作為資料儲存與查詢的關鍵
技術,HBase 的 key design 對於查詢的效能有至關重要的影響。
HBase Key Design
HBase 作為一個 NoSQL 的資料庫,在資料儲存格式方面的彈性極大,然而由於前文
所述的一些系統特性,使得良好的 key design[3]有助於提升查詢效率,而不良的設計則
有可能導致查詢落入 full table scan,致使查詢速度極慢。前述 HBase 會將所儲存的 rowkey
依照字典順序做排序,因此由左開始擁有相同子字串的 rowkey 會群聚在一個連續區塊,
查詢時可以透過 scan API 給定 startrow 及 stoprow 的方式,將特定字串開頭的 rowkey 全
部取出。了解上述特性後,在設計網路流量的搜尋系統時,應將查詢條件放置於 rowkey
的開頭,例如 source IP 或 destination IP。
透過與資訊安全分析師的訪談可以發現,在所有的分析查詢中,搜尋條件一定會包
含 source IP、destitution IP、或兩者皆有,原因是所有的分析查詢都是為了找出惡意的網
路連線,進而對可能受害的電腦做進一步的安全保障。其餘的搜尋條件如 source port、
destination port、protocol 以及時間區間,除了幫助資訊安全分析師做判斷外,也有助於
在大量的網路流量中過濾出真正感興趣的資料,另外像是 packets 以及 bytes 則主要作為
額外參考資訊。
根據上列描述可以將所有網路流量中的屬性做一分類:
Required search fields:
source IP, destination IP
Optional search fields:
source port, destination port, protocol, timestamp
Additional information:
packets, bytes
當每一筆搜尋都有 required search field 時,便能將 required search field 設計在 rowkey 首
位,由於 required search field 有兩個屬性,在 key design 上可以透過一個分隔符號將其串
接起來,如 source IP#destination IP,搜尋時透過設置 startrow 及 stoprow 將 scan 限定在
rowkey 開頭為 source IP 的範圍內,或完全等於 source IP#destination IP 字串,讓每一筆
搜尋都能快速找到資料並返回。然而,此設計僅可滿足搜尋條件含 source IP 以及搜尋條
件含 source IP 及 destination IP 的兩種狀況,但不能滿足搜尋條件僅含 destination IP 的狀
況。在 HBase 之中要解決這樣的問題可以透過建立 secondary index[4]。事實上 secondary
index 與傳統 RDBMS 建立 index 的方式完全一致,即建立 index 需要額外的硬碟空間,
以及在資料更新時需要同步更新 index,只是傳統 RDBMS 的技術發展相當成熟,僅需透

Communications of the CCISA
Vol. 21 No. 3 Jul. 2014

過設定就能完成一系列的處理,相對 HBase 中 secondary index 的建立與管理就必須由開
發者自行處理。
Proposed System Design
在 HBase secondary index[4]實作類型中,本文使用類似於 dual-write secondary index
的方式。dual-write secondary index 的做法是在資料寫入 data table 的同時一併更新 index
table,然而由於網路流量資料的特性是單筆紀錄資料量小,資料總筆數多,因此設計上
需要考量不同的面向。先從資料量的層面探討,以下列一筆網路流量紀錄為例:

10.1.1.1 ,10.1.1.2 ,8000,80, TCP,20,1024,1404188690000
若以 source IP#destination IP 作為 data table 的 rowkey,則此筆紀錄在 data table 中的 rowkey
為 10.1.1.1#10.1.1.2,index table 為了查詢 data table 中的資料必須記錄 data table 的
rowkey:10.1.1.1#10.1.1.2,此 rowkey 的儲存大小為 8Byte(兩個 IP 各 4Bytes,暫不將
delimiter 計入);data table 中儲存的資料大小總計為 14Bytes(如表一)。
表一:網路流量範例的儲存空間列表
Field

Value

Data Type

Size

Source Port

8000

String

4Bytes

Destination Port

80

String

2Bytes

Protocol

TCP

String

3Bytes

Packets

20

String

2Bytes

Bytes

1024

String

3Bytes

以 index table 的角度來看,儲存 rowkey 與直接儲存整份資料的空間差距並不懸殊,只要
額外花費 0.75 倍(6 bytes)的空間,即可儲存所有資料而不需另外向 data table 查詢。此
處要特別說明的是,所有 field 採用的 data type 是依據 35 億筆網路流量資料所計算的平
均字元數來選擇最適合的儲存格式(表二)

表二:網路流量各欄位平均字元數與最適資料格式列表
Field

Smallest Data Type

Source Port

AVG # of character
3.544037

Destination Port

3.51682

String

Protocol

3.010787

String

Packets

2.994488

String

Bytes

1.105705

String

String

Communications of the CCISA
Vol. 21 No. 3 Jul. 2014

從 搜 尋 效 率 的 層面 來看 , 若 data table 含 三 筆 紀 錄 分 別 為 10.1.1.1#10.1.1.2 、
10.1.1.3#10.1.1.2 以及 10.1.1.4#10.1.1.2,則向 index table 查詢 destination IP 為 10.1.1.2 時,
必須分別以三筆 rowkey 向 data table 進行查詢以取回資料,若在 index table 中直接儲存
資料,則只需一次 scan 就能取回資料,速度相對快上許多。
綜合上述考量,本文選定以 dual-write 的方式同時將資料寫入兩個 data table,分別
為 source table 以及 destination table,其 key design 如下:

圖七:source table key design

圖八:destination table key design
rowkey 部分,兩個 table 分別為 source IP 在前與 destination IP 在前,source table 接受搜
尋條件含 source IP 或含 source IP 及 destination IP 的查詢,而 destination table 則接受搜
尋條件含 destination IP 的查詢,過濾方式以 scan 設定 startrow 及 stoprow 方式進行;在
column family 部分,本設計僅須使用單一 column family(cf1);qualifier 的部分,將所
有 optional search fields 以分隔符號串接為字串儲存,搜尋時透過 HBase 提供的 qualifier
filter 以 regular expression 的方式過濾;value 儲存附加資訊 packets 及 bytes;HBase 的
timestamp 若不特別指定則為資料的寫入時間,本設計以網路流量的 timestamp 作為 HBase
的 timestamp,在 scan 時透過設定 time range 的方式選擇欲查詢的時間區段。
值得注意的是,HBase 預設只會儲存同一個 rowkey 與 qualifier pair 的三筆最新
version(以 timestamp 值判斷),在本設計中 rowkey 與 qualifier 完全相同的網路流量(source
IP, destination IP, source port, destination port 及 protocol 完全相同)可能經常出現,因此必
須將 version 指定為最大值。表三為本設計在建立 HBase table 時的參考指令及 table
schema。
表三:HBase shell 建立 table 指令表
source table
schema

Create ‘src_table',
{NAME => 'cf1', VERSIONS => '2147483647', COMPRESSION =>
'GZ', TTL => '15552000'}

destination table create 'dst_table',
schema
{NAME => 'cf1', VERSIONS => '2147483647', COMPRESSION =>
'GZ', TTL => '15552000'}


Related documents


apache hbase
seminarska nbnpix column family hbase
apache spark scala online course content pdf
resume aman bakshi
orgchartreport 1493689891206 416
resume prasanna pai updated

Link to this page


Permanent link

Use the permanent link to the download page to share your document on Facebook, Twitter, LinkedIn, or directly with a contact by e-Mail, Messenger, Whatsapp, Line..

Short link

Use the short link to share your document on Twitter or by text message (SMS)

HTML Code

Copy the following HTML code to share your document on a Website or Blog

QR Code

QR Code link to PDF file Apache HBase建置高效能網路流量分析系統.pdf