FROM:http://go-on.iteye.com/blog/1789466
背景
分布式日志方案
作為互聯網公司，每天龐大的日志數據將是一筆寶貴的財富，對大規模日志數據進行采集、追蹤、處理將是非常有收益的。一些開源項目的出現，也極快地促進了這個方面工作的進展。
本文針對據目前流行的日志框架，主要根據互聯網的一些資料，結合自己的一些了解，對一些關鍵因素進行橫向的對比，比便對技術選型提供參考。
關鍵要素
配置（Configuration）
客服端如何發現服務端？（不好的方式：固定配置。好的方式：基於zookeeper的pub-sub） 怎么配置消息路由？（點對點；廣播；通過brokers路由消息（kafka））
容錯（Failure and Recovery）
當集群中的一個節點出錯，系統是如何什么方式進行buffer的？ 系統是否保證數據傳輸過程的高可用，一旦發送，即保證到達。 系統是否支持樹狀集群。
維護管理（Maintenance）
本地的日志是否可以被配置成持久化，都提供了哪些支持？ 如果日志數據被發送，消息是否是有序的？
Kafka
Kafka是一個大型分布式日志框架，實際更是消息中間件（類似RabbitMQ,ActiveMQ,etc）。但是他不同於一般的消息中間件，不遵從消息隊列的協議，一般消息中間件的協議里面消息是不能被消費者刪除掉的（或者標記成刪除）。 體系架構：
Kafka設計的目標：高吞吐量
數據被存儲在OS pagecache，這使得消息的數據存儲不能可能造成out of memory。Kafka
宣稱他們改進了Varnish的pagecache-centric design。消息在brokers上被保存在文件上並建索引。消息根據到達的時間戳是有序的, 不產生二次索引,這樣就可以很容易進行順序文件訪問和高效的磁盤掃描，即便是在數據量很大的情況下。文件通過Java中的 FileChannel.transferTo發送，操作系統層面是sendFile（），這樣避免了額外的數據考慮。這個號稱“Zero-copy”的機制比直接存內存的消息隊列性能好上很多，具體原因可以看主創團隊如何解釋。
消息的狀態維護是消費者自己負責的，通過Zookeeper來協調一致性。負載均衡和分布式消息的分區也是Zookeeper來實現的。這意味着，所有消息隨機的分布在各個broker上，每個broker都注冊到Zooker上。每個消息的生產者可以通過broker列表來選擇一個broker去發送消息。Kafka在producer和broker層都不提供保障機制。消費端負責保存消息狀態。但是Broker可以保留緩存一個固定時間段的消息。比如LinkderIn保留一個星期的數據在每個broker上，這意味着如果消費者fail，那么在一個星期內，這個消費者如果重啟，它能夠銜接上原來的順序接着消費。
Pros
• 支持發布/訂閱機制
• 通過OS pagecache + sendfile()，JVM內存占用低
• 客戶端API支持多語言
• Brokers不保存狀態，有助於吞吐量的提升
• 使用ZooKeeper來做配置管理和容錯
Cons
• 用Scala開發實行，必須跑在JVM上
• 沒有消息可靠性保證，必須自己去監控消息數據丟失
• 沒有像Flume數據流的概念，必須通過訂閱消息的方式
See Also
• Kafka Design Document
• Why is Kafka faster than other Message Queues?
• Really good presentation from LinkedIn on Kafka's architecture.
• Kafka whitepaper
Flume
Flume是一個分布式、可靠、高可用的海量日志聚合系統，支持在系統中定制各類數據發送方，用於收集數據；同時，Flume提供對數據的簡單處理，並寫到各種數據接收方的能力。
Flume 在0.9.x and 1.x之間有較大的架構調整，1.x版本之后的改稱Flume NG，0.9.x的稱為Flume OG。New和Old的分界嶺如下。
體系架構：
Flume NG 體系架構
Flume NG在之前版本的基礎上進行了重構和精簡，去除了Zookeeper對於集中式配置管理、負載均衡和集群管理的支持，而專注於對數據流的采集和傳輸。對於每個服務器Node的配置，都需要自行在Node上配置。沒法說這樣的簡化是好是壞，需求不一樣，評價自然不同。因為Flume OG已經不再進行版本更新，所以后面討論的Flume都是指Flume NG。
Flume Age是一個運行在JVM中的進程，主要任務是把Event（消息）從外部的一個source開始流向到下一個結點。Flune NG 有一個“數據流”的概念。
數據源（source）：消費Events消息，並把消息傳遞出去。比如一個Avro的source能夠接收來自Avro客戶端采集到的或者其他Agent的sink發送過來的Event消息。當source接收到Event，它把消息保存到一個或者多個channel中，直到消費者通過sink來消費Event。sink把消息從channel中移出，並放到外部的存儲（如HDFS，通過HDFS sink）或者是把消息推向另外一個Flume Agent的source。
Flume提供了各種source的實現，包括Avro Source、Exce Source、Spooling Directory Source、NetCat Source、Syslog Source、Syslog TCP Source、Syslog UDP Source、HTTP Source、HDFS Source，etc。
Flume也提供了各種sink的實現，包括HDFS sink、Logger sink、Avro sink、File Roll sink、Null sink、HBase sink，etc。
Flume對於Channel，則提供了Memory Channel、JDBC Chanel、File Channel，etc。
Pros
可靠，多層消息容錯保障機制。
由Cloudera支持，已經有整套的log到HDFS實現
基於配置部署即可，不需要額外的開發工作
source、sink、channel有豐富的協議、門類實現
Cons
Java實現，必須運行在JVM上
如果sink堵塞，會產生大量的備份日志
沒有publish/subscribe機制
Flume已經停止開發，Flume NG的版本正在逐漸穩定中
負載均衡、集群管理、配置管理需要自己集成其他例如Zookeeper等框架實現
See Also
• Flume User Guide.
• Flume Cookbook.
• Issues to be aware of when using Flume in production.
• blog post about production trouble with Flume. (This guy might not know what he was doing though.)
• publish/subscribe upcoming in Flume-NG
Chuwa
Chukwa是Hadoop的一個子項目，致力於大規模日志收集和分析。Chukwa是建立在Hadoop分布式文件系統（HDFS）和MapReduce框架之上，並繼承了Hadoop的可擴展性和魯棒性。Chukwa還包括一個靈活，功能強大的工具包，用於顯示監測和分析結果，以充分利用此收集的數據。
體系架構：
其中主要的部件為: 1. Agent：負責采集最原始的數據,並發送給collectors。Agent添加了“watchdog”機制，一旦agent出現故障，會自動重啟終止的數據采集進程，防止數據源的數據丟失。 2. Adaptor： 直接采集數據的接口和工具，chukwa對以下常見的數據來源包括命令行輸出、log 文件和 httpSender等提供了實現。一個 agent 可以管理多個 adaptor 的數據采集。 3. Collectors：負責收集 agents 收送來的數據,並定時寫入集群中。Collector負責把大量小文件合並成少量大文件，再寫入集群，以發揮hadoop在處理少量大文件上的優勢。Collertor層實現了負載均衡，agent隨機從列表中選擇collertor來發送數據。 4. map/reduce jobs：定時啟動,負責把集群中的數據分類、排序、去重和合並 5. HICC：負責數據的展示。
Pros
hadoop的子項目，有一套統一的大數據支持的生態環境 yahoo推動，版本更新較快 有監測和分析結果顯示的web-portal工具 有對於大量少文件合並成少量大文件的處理，能夠最大化hadoop威力 對於數據分類、排查，去重、合並，現成的方案實現 內置了兩個mapreduce作業，分別用於獲取data和將data轉化為結構化的log。存儲到datastore（可以是數據庫或者HDFS等）中
Conns
數據收集和處理的實時性要求不高 Java實現，運行在JVM上 可供個性化實現的接口不多，除了Storage端 比較重量級的一套方案，適用於大型的集群
See Also
• Hadoop Wiki Chukwa
Scribe
Scribe是facebook開源的日志收集系統，在facebook內部已經得到大量的應用。 Scribe是基於一個使用非阻斷C++服務器的thrift服務的實現。它能夠從各種日志源上收集日志，存儲到 一個中央存儲系統 （可以是NFS，分布式文件系統等）上，以便於進行集中統計分析處理。它為日志的“分布式收集，統一處理”提供了一個可擴展的，高容錯的方案。
體系架構：
Scribe從各種數據源上收集數據，放到一個共享隊列上，然后push到后端的中央存儲系上。當中央存儲系統出現故障時，scribe可以暫時把日志寫到本地文件中，待中央存儲系統恢復性能后，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中）。
Pros
多客戶端語言支持（Thrift提供支持） C++實現 支持日志分類和自動切分（按照文件大小和時間切分） 配置簡單、靈活
Conns
不再是一個活躍項目，Facebook正在逐漸冷落它 有可能會有單點故障（中心服務器、本地服務器、收集日志的客戶端程序） 日志切換可能導致日志丟失
See Also
• Why did Facebook develop a new logging service?.
In particular check out Sam Rash's answer and presentation on Calligraphus and Facebook's data freeway.
• What's Up Scribe? - Otto's blog post on Scribe packaging and summary of Calligraphus.
概括
總的特性比對，可以用一張表概括之。比對表格
國內一些大型的互聯網公司都各自在大數據的采集和分析上開始發力，同時也根據各自的情況“因地制宜”地發展了一些自己的日志系統，其實聲勢較大的首推淘寶的TimeTunnel。 TimeTunnel是一個基於thrift通訊框架搭建的實時數據傳輸平台，具有高性能、實時性、順序性、高可靠性、高可用性、可擴展性等特點。TimeTunnel的設計和Kafka有一些類似，但是在不少地方都進行了改進。TimeTunnel在更新多個版本之后也已經開源，有興趣的可以看看。