日誌採集系統flume和kafka有什麼區別及聯絡？
日誌採集系統flume和kafka有什麼區別及聯絡，它們分別在什麼時候使用，什麼時候又可以結合？
觀點一：
簡言之：這兩個差別很大，使用場景區別也很大。
先說flume：
日誌採集。線上資料一般主要是落地檔案或者通過socket傳輸給另外一個系統。這種情況下，你很難推動線上應用或服務去修改介面，直接向kafka裡寫資料。這時候你可能就需要flume這樣的系統幫你去做傳輸。
對於數量級別，做過單機upd的flume source的配置，100+M/s資料量，10w qps flume就開始大量丟包。因此我們在搭建系統時，拋棄了flume，自己研發了一套傳輸系統。但flume設計的source-channel-sink模式還是比較好的，我們在開發系統時無恥的也抄襲了這種方式。
Kafka：
我個人覺得kafka更應該定位為中介軟體系統。開發這個東西目的也是這個初衷。可以理解為一個cache系統。你甚至可以把它理解為一個廣義意義的資料庫，裡面可以存放一定時間的資料。kafka設計使用了硬碟append方式，獲得了非常好的效果。我覺得這是kafka最大的亮點。不同系統之間融合往往資料生產/消費速率不同，這時候你可以在這些系統之間加上kafka。例如線上資料需要入HDFS，線上資料生產快且具有突發性，如果直接上HDFS（kafka-consumer）可能會使得高峰時間hdfs資料寫失敗，這種情況你可以把資料先寫到kafka，然後從kafka匯入到hdfs上。印象中LinkedIn公司有這麼用。
業界比較典型的一中用法是：
線上資料 -> flume -> kafka -> hdfs -> MR離線計算 或者：
線上資料 -> flume -> kafka -> storm
觀點二：
Flume和Kafka本身是很相似的系統，都能無壓力傳輸很大的資料量。
細節上他們當然有很多不同，但是總結下來，如果你糾結到底是用Kafka還是Flume：
- Kafka是pull based, 如果你有很多下游的Data Consumer，用Kafka；
- Kafka有Replication，Flume沒有，如果要求很高的容錯性(Data High Availability)，選kafka；
- 需要更好的Hadoop類產品介面，例如HDFS，HBase等，用Flume。
當然，這兩個區別就讓人自然而然的想到整合兩者，這樣既可擁有Kafka的容錯能力，和Flume的多種介面，例如：
Events —>Flume —> Kafka —> Flume —> Storage System (Hadoop Cluster)
當然，壞處就是你需要開發維護多個系統…
前一段似乎看到Cloudera提出過一款Flafka的app，說的就是這兩款產品的整合，有興趣可以去搜搜。
觀點三：
我偏愛Flume，因為架構簡單，依賴少。
但是同樣的，功能也簡單，但是夠靈活。
它的定位是資料通道，不是訊息佇列。
Flume和Kafka應該結合來使用，Flume作為日誌收集端，Kafka作為日誌消費端。
flume：日誌採集系統
kafka：訊息中介軟體
也用過樓上說的組合：
log->flume->kafka->hdfs(solr)
Flume的Source-Channel-Sink模型，非常適合作為日誌收集的模型。你可以想一下，如果你來做一個日誌收集的Agent，如果做能儘量保證日誌資料的傳輸成功率，應對服務端的各種異常情況，以及如何靈活的接入各種不同的日誌型別。
Kafka就不必多說了，生產者消費者模型，看你怎麼去構建日誌消費的下游了。有了訊息佇列作為中介軟體，消費的下游和上游可以完美的解耦。
概述：
（1）kafka和flume都是日誌系統。kafka是分散式訊息中介軟體，自帶儲存，提供push和pull存取資料功能。flume分為agent（資料採集器）,collector（資料簡單處理和寫入）,storage（儲存器）三部分，每一部分都是可以定製的。比如agent採用RPC（Thrift-RPC）、text（檔案）等，storage指定用hdfs做。
（2）kafka做日誌快取應該是更為合適的，但是 flume的資料採集部分做的很好，可以定製很多資料來源，減少開發量。所以比較流行flume+kafka模式，如果為了利用flume寫hdfs的能力，也可以採用kafka+flume的方式。
採集層 主要可以使用Flume, Kafka兩種技術。
Flume：Flume 是管道流方式，提供了很多的預設實現，讓使用者通過引數部署，及擴充套件API.
Kafka：Kafka是一個可持久化的分散式的訊息佇列。
Kafka 是一個非常通用的系統。你可以有許多生產者和很多的消費者共享多個主題Topics。相比之下,Flume是一個專用工具被設計為旨在往HDFS,HBase傳送資料。它對HDFS有特殊的優化，並且集成了Hadoop的安全特性。所以，Cloudera 建議如果資料被多個系統消費的話，使用kafka；如果資料被設計給Hadoop使用，使用Flume。
正如你們所知Flume內建很多的source和sink元件。然而，Kafka明顯有一個更小的生產消費者生態系統，並且Kafka的社群支援不好。希望將來這種情況會得到改善，但是目前：使用Kafka意味著你準備好了編寫你自己的生產者和消費者程式碼。如果已經存在的Flume Sources和Sinks滿足你的需求，並且你更喜歡不需要任何開發的系統，請使用Flume。
Flume可以使用攔截器實時處理資料。這些對資料遮蔽或者過量是很有用的。Kafka需要外部的流處理系統才能做到。
Kafka和Flume都是可靠的系統,通過適當的配置能保證零資料丟失。然而，Flume不支援副本事件。於是，如果Flume代理的一個節點奔潰了，即使使用了可靠的檔案管道方式，你也將丟失這些事件直到你恢復這些磁碟。如果你需要一個高可靠行的管道，那麼使用Kafka是個更好的選擇。
Flume和Kafka可以很好地結合起來使用。如果你的設計需要從Kafka到Hadoop的流資料，使用Flume代理並配置Kafka的Source讀取資料也是可行的：你沒有必要實現自己的消費者。你可以直接利用Flume與HDFS及HBase的結合的所有好處。你可以使用Cloudera Manager對消費者的監控，並且你甚至可以新增攔截器進行一些流處理。
Flume和Kafka可以結合起來使用。通常會使用Flume + Kafka的方式。其實如果為了利用Flume已有的寫HDFS功能，也可以使用Kafka + Flume的方式。
其他：
今天開會討論日誌處理為什麼要同時使用Flume和Kafka，是否可以只用Kafka 不使用Flume？當時想到的就只用Flume的介面多，不管是輸入介面(socket 和 檔案)以及輸出介面(Kafka/HDFS/HBase等)。
考慮單一應用場景，從簡化系統的角度考慮，在滿足應用需求的情況下可能只使用一個比較好。但是考慮到現有系統業務發展，為了後面的靈活擴充套件，在先用系統設計時留有一定的擴充套件性感覺更重要，可能使用Flume+kafka架構相對只使用Kafka會多佔用1-2臺機器做Flume日誌採集，但是為了方便以後日誌資料處理方式的擴充套件，可以採用Flume+kafka架構。
Flume ：管道 ----個人認為比較適合有多個生產者場景，或者有寫入Hbase、HDFS和kafka需求的場景。
Kafka ：訊息佇列-----由於Kafka是Pull模式，因此適合有多個消費者的場景。
目前應用場景，一臺日誌轉發機負責產生日誌。後端需要通過Strom消費日誌資訊，建議可以設定成log–>Kafka->storm.如果以後有寫入Hbase或者HDFS的需求可以，在Kafka後面再接上storm，或者在日誌轉發機上直接日誌落地，由Flume去讀取日誌訊息。
Kafka 與 Flume 很多功能確實是重複的。以下是評估兩個系統的一些建議：
Kafka 是一個通用型系統。你可以有許多的生產者和消費者分享多個主題。相反地，Flume 被設計成特定用途的工作，特定地向 HDFS 和 HBase 傳送出去。Flume 為了更好地為 HDFS 服務而做了特定的優化，並且與 Hadoop 的安全體系整合在了一起。基於這樣的結論，Hadoop 開發商 Cloudera 推薦如果資料需要被多個應用程式消費的話，推薦使用 Kafka，如果資料只是面向 Hadoop 的，可以使用 Flume。
Flume 擁有許多配置的來源 (sources) 和儲存池 (sinks)。然後，Kafka 擁有的是非常小的生產者和消費者環境體系，Kafka 社群並不是非常支援這樣。如果你的資料來源已經確定，不需要額外的編碼，那你可以使用 Flume 提供的 sources 和 sinks，反之，如果你需要準備自己的生產者和消費者，那你需要使用 Kafka。
Flume 可以在攔截器裡面實時處理資料。這個特性對於過濾資料非常有用。Kafka 需要一個外部系統幫助處理資料。
無論是 Kafka 或是 Flume，兩個系統都可以保證不丟失資料。然後，Flume 不會複製事件。相應地，即使我們正在使用一個可以信賴的檔案通道，如果 Flume agent 所在的這個節點宕機了，你會失去所有的事件訪問能力直到你修復這個受損的節點。使用 Kafka 的管道特性不會有這樣的問題。
Flume 和 Kafka 可以一起工作的。如果你需要把流式資料從 Kafka 轉移到 Hadoop，可以使用 Flume 代理 (agent)，將 kafka 當作一個來源 (source)，這樣可以從 Kafka 讀取資料到 Hadoop。你不需要去開發自己的消費者，你可以使用 Flume 與 Hadoop、HBase 相結合的特性，使用 Cloudera Manager 平臺監控消費者，並且通過增加過濾器的方式處理資料。