開源日誌系統比較：scribe、chukwa、kafka、flume
1. 背景介紹
許多公司的平臺每天會產生大量的日誌（一般為流式資料，如，搜尋引擎的pv，查詢等），處理這些日誌需要特定的日誌系統，一般而言，這些系統需要具有以下特徵：
（1） 構建應用系統和分析系統的橋樑，並將它們之間的關聯解耦；
（2） 支援近實時的線上分析系統和類似於Hadoop之類的離線分析系統；
（3） 具有高可擴充套件性。即：當資料量增加時，可以通過增加節點進行水平擴充套件。
本文從設計架構，負載均衡，可擴充套件性和容錯性等方面對比了當今開源的日誌系統，包括facebook的scribe，apache的chukwa，linkedin的kafka和cloudera的flume等。
2. FaceBook的Scribe
Scribe是facebook開源的日誌收集系統，在facebook內部已經得到大量的應用。它能夠從各種日誌源上收集日誌，儲存到一箇中央儲存系統
（可以是NFS，分散式檔案系統等）上，以便於進行集中統計分析處理。它為日誌的“分散式收集，統一處理”提供了一個可擴充套件的，高容錯的方案。
它最重要的特點是容錯性好。當後端的儲存系統crash時，scribe會將資料寫到本地磁碟上，當儲存系統恢復正常後，scribe將日誌重新載入到儲存系統中。
架構：
scribe的架構比較簡單，主要包括三部分，分別為scribe agent， scribe和儲存系統。
(1) scribe agent
scribe agent實際上是一個thrift client。 向scribe傳送資料的唯一方法是使用thrift client， scribe內部定義了一個thrift介面，使用者使用該介面將資料傳送給server。
(2) scribe
scribe接收到thrift client傳送過來的資料，根據配置檔案，將不同topic的資料傳送給不同的物件。scribe提供了各種各樣的store，如 file， HDFS等，scribe可將資料載入到這些store中。
(3) 儲存系統
儲存系統實際上就是scribe中的store，當前scribe支援非常多的store，包括file（檔案），buffer（雙層儲存，一個主儲存，
一個副儲存），network（另一個scribe伺服器），bucket（包含多個
store，通過hash的將資料存到不同store中），null(忽略資料)，thriftfile（寫到一個Thrift
TFileTransport檔案中）和multi（把資料同時存放到不同store中）。
3. Apache的Chukwa
chukwa是一個非常新的開源專案，由於其屬於hadoop系列產品，因而使用了很多hadoop的元件（用HDFS儲存，用mapreduce處理資料），它提供了很多模組以支援hadoop叢集日誌分析。
需求：
(1) 靈活的，動態可控的資料來源
(2) 高效能，高可擴充套件的儲存系統
(3) 合適的框架，用於對收集到的大規模資料進行分析
架構：
Chukwa中主要有3種角色，分別為：adaptor，agent，collector。
(1) Adaptor 資料來源
可封裝其他資料來源，如file，unix命令列工具等
目前可用的資料來源有：hadoop logs，應用程式度量資料，系統引數資料（如linux cpu使用流率）。
(2) HDFS 儲存系統
Chukwa採用了HDFS作為儲存系統。HDFS的設計初衷是支援大檔案儲存和小併發高速寫的應用場景，而日誌系統的特點恰好相反，它需支援高併發低速
率的寫和大量小檔案的儲存。需要注意的是，直接寫到HDFS上的小檔案是不可見的，直到關閉檔案，另外，HDFS不支援檔案重新開啟。
(3) Collector和Agent
為了克服(2)中的問題，增加了agent和collector階段。
Agent的作用：給adaptor提供各種服務，包括：啟動和關閉adaptor，將資料通過HTTP傳遞給Collector；定期記錄adaptor狀態，以便crash後恢復。
Collector的作用：對多個數據源發過來的資料進行合併，然後載入到HDFS中；隱藏HDFS實現的細節，如，HDFS版本更換後，只需修改collector即可。
(4) Demux和achieving
直接支援利用MapReduce處理資料。它內建了兩個mapreduce作業，分別用於獲取data和將data轉化為結構化的log。儲存到data store（可以是資料庫或者HDFS等）中。
4. LinkedIn的Kafka
Kafka是2010年12月份開源的專案，採用scala語言編寫，使用了多種效率優化機制，整體架構比較新穎（push/pull），更適合異構叢集。
設計目標：
(1) 資料在磁碟上的存取代價為O(1)
(2) 高吞吐率，在普通的伺服器上每秒也能處理幾十萬條訊息
(3) 分散式架構，能夠對訊息分割槽
(4) 支援將資料並行的載入到hadoop
架構：
Kafka實際上是一個訊息釋出訂閱系統。producer向某個topic釋出訊息，而consumer訂閱某個topic的訊息，進而一旦有新的關於
某個topic的訊息，broker會傳遞給訂閱它的所有consumer。
在kafka中，訊息是按topic組織的，而每個topic又會分為多個partition，這樣便於管理資料和進行負載均衡。同時，它也使用了
zookeeper進行負載均衡。
Kafka中主要有三種角色，分別為producer，broker和consumer。
(1) Producer
Producer的任務是向broker傳送資料。Kafka提供了兩種producer介面，一種是low_level介面，使用該介面會向特定的
broker的某個topic下的某個partition傳送資料；另一種那個是high
level介面，該介面支援同步/非同步傳送資料，基於zookeeper的broker自動識別和負載均衡（基於Partitioner）。
其中，基於zookeeper的broker自動識別值得一說。producer可以通過zookeeper獲取可用的broker列表，也可以在zookeeper中註冊listener，該listener在以下情況下會被喚醒：
a．新增一個broker
b．刪除一個broker
c．註冊新的topic
d．broker註冊已存在的topic
當producer得知以上時間時，可根據需要採取一定的行動。
(2) Broker
Broker採取了多種策略提高資料處理效率，包括sendfile和zero copy等技術。
(3) Consumer
consumer的作用是將日誌資訊載入到中央儲存系統上。kafka提供了兩種consumer介面，一種是low
level的，它維護到某一個broker的連線，並且這個連線是無狀態的，即，每次從broker上pull資料時，都要告訴broker資料的偏移
量。另一種是high-level
介面，它隱藏了broker的細節，允許consumer從broker上push資料而不必關心網路拓撲結構。更重要的是，對於大部分日誌系統而
言，consumer已經獲取的資料資訊都由broker儲存，而在kafka中，由consumer自己維護所取資料資訊。
5. Cloudera的Flume
Flume是cloudera於2009年7月開源的日誌系統。它內建的各種元件非常齊全，使用者幾乎不必進行任何額外開發即可使用。
設計目標：
(1) 可靠性
當節點出現故障時，日誌能夠被傳送到其他節點上而不會丟失。Flume提供了三種級別的可靠性保障，從強到弱依次分別為：end-to-end（收到資料
agent首先將event寫到磁碟上，當資料傳送成功後，再刪除；如果資料傳送失敗，可以重新發送。），Store on
failure（這也是scribe採用的策略，當資料接收方crash時，將資料寫到本地，待恢復後，繼續傳送），Best
effort（資料傳送到接收方後，不會進行確認）。
(2) 可擴充套件性
Flume採用了三層架構，分別問agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和collector由
master統一管理，這使得系統容易監控和維護，且master允許有多個（使用ZooKeeper進行管理和負載均衡），這就避免了單點故障問題。
(3) 可管理性
所有agent和colletor由master統一管理，這使得系統便於維護。使用者可以在master上檢視各個資料來源或者資料流執行情況，且可以對各
個數據源配置和動態載入。Flume提供了web 和shell script command兩種形式對資料流進行管理。
(4) 功能可擴充套件性
使用者可以根據需要新增自己的agent，colletor或者storage。此外，Flume自帶了很多元件，包括各種agent（file， syslog等），collector和storage（file，HDFS等）。
架構：
正如前面提到的，Flume採用了分層架構，由三層組成，分別為agent，collector和storage。其中，agent和collector均由兩部分組成：source和sink，source是資料來源，sink是資料去向。
(1) agent
agent的作用是將資料來源的資料傳送給collector，Flume自帶了很多直接可用的資料來源（source），如：
text(“filename”)：將檔案filename作為資料來源，按行傳送
tail(“filename”)：探測filename新產生的資料，按行傳送出去
fsyslogTcp(5140)：監聽TCP的5140埠，並且接收到的資料傳送出去
同時提供了很多sink，如：
console[("format")] ：直接將將資料顯示在桌面上
text(“txtfile”)：將資料寫到檔案txtfile中
dfs(“dfsfile”)：將資料寫到HDFS上的dfsfile檔案中
syslogTcp(“host”,port)：將資料通過TCP傳遞給host節點
(2) collector
collector的作用是將多個agent的資料彙總後，載入到storage中。它的source和sink與agent類似。
下面例子中，agent監聽TCP的5140埠接收到的資料，併發送給collector，由collector將資料載入到HDFS上。
- host : syslogTcp(5140) | agentSink("localhost",35853) ;
- collector : collectorSource(35853) | collectorSink("hdfs://namenode/user/flume/ ","syslog");
一個更復雜的例子如下：
有6個agent，3個collector，所有collector均將資料匯入HDFS中。agent A，B將資料傳送給collector
A，agent C，D將資料傳送給collectorB，agent
C，D將資料傳送給collectorB。同時，為每個agent新增end-to-end可靠性保障（Flume的三種可靠性保障分別由
agentE2EChain, agentDFOChain, and agentBEChain實現），如，當collector
A出現故障時，agent A和agent B會將資料分別發給collector B和collector C。
下面是簡寫的配置檔案片段：
- agentA : src | agentE2EChain("collectorA:35853","collectorB:35853");
- agentB : src | agentE2EChain("collectorA:35853","collectorC:35853");
- agentC : src | agentE2EChain("collectorB:35853","collectorA:35853");
- agentD : src | agentE2EChain("collectorB:35853","collectorC:35853");
- agentE : src | agentE2EChain("collectorC:35853","collectorA:35853");
- agentF : src | agentE2EChain("collectorC:35853","collectorB:35853");
- collectorA : collectorSource(35853) | collectorSink("hdfs://...","src");
- collectorB : collectorSource(35853) | collectorSink("hdfs://...","src");
- collectorC : collectorSource(35853) | collectorSink("hdfs://...","src");
此外，使用autoE2EChain，當某個collector 出現故障時，Flume會自動探測一個可用collector，並將資料定向到這個新的可用collector上。
(3) storage
storage是儲存系統，可以是一個普通file，也可以是HDFS，HIVE，HBase等。
6. 總結
根據這四個系統的架構設計，可以總結出典型的日誌系統需具備三個基本元件，分別為agent（封裝資料來源，將資料來源中的資料傳送給
collector），collector（接收多個agent的資料，並進行彙總後匯入後端的store中），store（中央儲存系統，應該具有可擴
展性和可靠性，應該支援當前非常流行的HDFS）。
下面表格對比了這四個系統：
