日志收集系統Flume調研筆記第1篇 - Flume簡介
來源：程序員人生 發布時間：2015-05-08 08:31:33 閱讀次數：7900次
用戶行動數據的搜集無疑是構建推薦系統的先決條件，而Apache基金會下的Flume項目正是為散布式的日志搜集量身打造的，本文是Flume調研筆記的第1篇，主要介紹Flume的基本架構，下篇筆記將會以實例說明Flume的部署和使用步驟。
本文所用的Flume版本為目前最新版的ver1.5.2，它屬于Flume-NG，在系統架構上與Flume-OG有所區分，2者的不同可以參考FlumeWiki文檔的說明。
1. Flume是甚么
Flume是Apache基金會下的1個開源項目，它實現了1套散布式的、可靠且高可用系統，用于高效地搜集、聚合或移動來自不同源的大量日志數據（典型如來自多臺WebServer的日志），并支持將這些數據統1寫入通用存儲系統（典型如HDFS）。
2. Flume的適用處景
Flume最典型的利用場景就是聚合來自不同源的日志數據并將這些數據集中寫入統1的存儲系統（如HDFS或Kafka）。在觸及到流式計算的利用中（照實時推薦系統），我們常常會看到Flume的身影。
Flume接受的輸入被稱為"event data"。對Flume來講，"event"就是1堆字節流（To Flume, an event is just a generic blob of bytes. 出自官方文檔Flume
User Guide），所以，除純文本數據外，"event data"還支持2進制數據，如圖片、網絡流（network traffic）等。
但需要注意的是，Flume支持的event數據有大小限制，單個event data不能大于部署Flume系統的機器的內存或磁盤，好在正常模塊產生的單條數據應當不會超過這個物理限制。
根據官方推薦的Flume NG性能測試文檔，單臺機器起多個Flume Agent進程同時向同1個HDFS寫數據，保持event-size=300bytes的發送壓力，在不丟數據的條件下，單機最少可處理4w+
events/sec，上限可達7w+ events/sec。固然，確切的數據與機器硬件配置有關，但我們可以通過該結果評估Flume是不是能滿足實際業務的性能要求。另外，文中的結果表明單機最大吞吐量與Flume Agent的并發數有關，最優的并發數與機器CPU核數1致，細節可以瀏覽源文檔。
總之，在公道配置的情況下，Flume可以適用于有日志搜集和聚合需求的絕大多數散布式利用場合。
3. Flume典型系統架構
根據Flume User Guild文檔的說明，典型的Flume數據流模型以下所示：
上圖中方框圈起來的部份就是Flume的系統架構，被抽象為Agent，它在物理上表現為1個flume-agent進程，該進程實際上是個JVM。
每一個agent由3類組件構成（注意不是3個，比如根據業務需求可以通過Flume的配置文件實現單個agent進程的邏輯拓撲中包括多個sources），下面按數據流從前向后的順序分別進行說明。
3.1 Source
Source負責接收并解析（如反序列化）來自外部源的events數據，并將解析后的數據發送給與它連接的1個或多個channel(s)。
幾點說明以下：
1) 外部源發往Source的數據格式必須與Flume配置文件中指定的Source Type保持1致。比如，若配置Flume的Source類型為thrift，則發來的數據必須按thrift協議打包。
2) 目前Source支持的接收外部源數據的方式包括RPC（如將Source配置為Avro方式時，可通過Avro客戶端以RPC方式向Flume發送數據）、Thrift源、HTTP源、Exec源、JMS源、Seq源（類似于計數生成器，它會延續生成event，主要用于測試），等等。具體支持的Source列表及使用實例，可參考官方文檔Flume
Sources的說明。
3) 在同1個agent進程中，若source配置了多個channels，此時，根據業務需求，可為source配置不同的event路由策略，常見的channel selector包括replicating和multiplexing兩種，其中，前者為默許策略，表示來自source的events會同時發往與它連接的所有channels（明顯這類情況會更耗內存或磁盤）；而后者表示source的events只會發送到特定的channel(s)，具體而言，source通過其配置項selector.header指定路由決策字段的key，通過配置項selector.mapping.<hdr-value>指定與hdr-value匹配的events將要發往的channel，其中，<hdr-value>是與決策字段的key關聯的value。具體實例可參考Flume
Channel Selectors文檔的說明。
4) 可以借助source. Interceptors修改或過濾event，細節可參考文檔Flume Interceptors。
5) 自定義實現的Source也能夠作為plugin集成到Flume中。
3.2 Channel
Channel是個被動的存儲組件，它會保護1個內存隊列或磁盤文件來保存Source發來的event直到該event被Sink消費。也即，它像隊列1樣連接了sources和sinks。
最多見的Channel類型是Memory Channel和File Channel，前者通過在內存隊列中保護events來提高性能，但機器故障或進程退出時會丟失未被Sink消費的數據；而后者通過磁盤文件保護events，可以免意外情況情況下的數據丟失，但明顯性能會打折扣。
除Memory Channel和File Channel外，Flume還支持JBDC Channel及其它的Channel類型，細節可以查看Flume Channels文檔。
幾點說明以下：
1) 在使用memory類型的channel時，要意想到最大容量（capacity）問題，如果source生產events的速度超過sink的消費速度，則可能會致使channel緩沖區打滿從而拋出異常。這類情況下，若向Source寫數據的外部利用程序沒有異常處理邏輯（ExecSource最容易出現這類情況），則數據會丟失。
2) 在使用file類型的channel并配置了多個file channels時，最好為每一個channel明確配置寄存events的、各自獨立的文件路徑，由于若采取默許的配置路徑，則多個channel會競爭同1個文件鎖，終究致使只有1個channel能初始化成功。
3) 可以配置memory和file混合的channel類型Spillable Memory Channel，優缺點可以查看文檔，這里不贅述。
4) 自定義實現的Channel接口可以作為plugin集成到Flume中。
3.3 Sink
Sink負責從channel中消費events，并根據配置的sink類型將數據寫入外部的存儲系統。
常見的sink類型包括HDFS Sink、Logger Sink（輸出到終端以方便調試）、Avro Sink（如Flume級聯的情況）、Thrift Sink、ElasticSearchSink、HBase Sink，等等。另外，從Flume v1.6開始，Flume增加了Kafka Sink。
幾點說明以下：
1) 同1個channel可以連多個sinks，但同1個sink只能從1個channel消費數據。
2) 同1個agent進程可以對sinks做分組，同1個sink group可以根據processor.type配置項實現sink間的failover和load_balance。
3) 自定義實現的Sink接口可以作為plugin集成到Flume中，另外還可以自定義Sink Processor接口。
4. Flume級聯
除source-channel-sink1對1的對應關系外，Flume還支持其它情勢的系統結構。
1) 多agent級聯
2) 多agent聚合級聯
3) 多路分流
上圖中，source的events可以根據配置分配到不同的channel中，這類方法在上文介紹source的要點說明中曾描寫過，這里不再贅述。
【參考資料】
1. Apache Flume
2. FlumeWiki -
Getting Started
3. Flume1.5.2 User Guide -
Is Flume a good fit for your problem?
4. Flume NG PerformanceMeasurements
5. Apache Flume -
Architecture of Flume NG
======================== EOF =========================
生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
