日誌採集系統flume和kafka有什麼區別及聯繫，它們分別在什麼時候使用，什麼時候又可以結合？

01-04

很湊巧，都用過這兩個系統。

簡言之：這兩個差別很大，使用場景區別也很大。

先說flume：

日誌採集。線上數據一般主要是落地文件或者通過socket傳輸給另外一個系統。這種情況下，你很難推動線上應用或服務去修改介面，直接向kafka里寫數據。這時候你可能就需要flume這樣的系統幫你去做傳輸。

對於數量級別，做過單機upd的flume source的配置，100+M/s數據量，10w qps flume就開始大量丟包。因此我們在搭建系統時，拋棄了flume，自己研發了一套傳輸系統。但flume設計的source-channel-sink模式還是比較好的，我們在開發系統時無恥的也抄襲了這種方式。

Kafka：

我個人覺得kafka更應該定位為中間件系統。LinkedIn開發這個東西目的也是這個初衷。可以理解為一個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：

1. Kafka是pull based, 如果你有很多下游的Data Consumer，用Kafka；

2. Kafka有Replication，Flume沒有，如果要求很高的容錯性(Data High Availability)，選kafka；

2. 需要更好的Hadoop類產品介面，例如HDFS，HBase等，用Flume。

當然，這兩個區別就會讓人自然而然的想到整合兩者，這樣既可以擁有Kafka的容錯能力，和Flume的多種介面，例如：

Events ---&>Flume ---&> Kafka ---&> Flume ---&> Storage System (Hadoop Cluster)

當然，壞處就是你需要開發維護多個系統...

前一段似乎看到Cloudera提出過一款Flafka的app，說的就是這兩款產品的整合，有興趣可以去搜搜。

我偏愛Flume，因為架構簡單，依賴少。

但是同樣的，功能也簡單，但是夠靈活。

它的定位是數據通道，不是消息隊列。

Flume和Kafka應該結合來使用，Flume作為日誌收集端，Kafka作為日誌消費端。

Flume的Source-Channel-Sink模型，非常適合作為日誌收集的模型。你可以想一下，如果你來做一個日誌收集的Agent，如果做能盡量保證日誌數據的傳輸成功率，應對服務端的各種異常情況，以及如何靈活的接入各種不同的日誌類型。

Kafka就不必多說了，生產者消費者模型，看你怎麼去構建日誌消費的下遊了。有了消息隊列作為中間件，消費的下游和上游可以完美的解耦。

flume：日誌採集系統

kafka：消息中間件

也用過樓上說的組合：

log-&>flume-&>kafka-&>hdfs(solr)

簡單點概括 flume類似於管道，kafka類似於消息隊列。之所以題主覺得類似大概是因為都能用於數據傳輸

這兩個工作中都用過，談談自己的理解吧

kafka:目前項目中主要是用來做消息推送中間件，消息的處理完全由業務方自己定義，請求頻次單機吞吐量輕輕鬆鬆50W+/s，數據在集群不全掛的情況下是不會丟數據，消費也很靈活，可以指定分區和offset，可以當做成一個資料庫

flume:主要是哪來做數據採集和落地，目前使用的是flume-ng，流程是source(kafka)-&>channel-&>hdfs 相比較kafka比較輕量級，就是一個數據的流通管道，當一個flume實例掛了數據會丟失

flume負責保障數據可靠傳輸，kafka做緩衝，及數據多重，兩個結合著用，爽爽的

Flume與Kafka在功能上具有很多的相似性。

1&> Kafka是一個更加通用的系統。用戶可以構造不同的生產者與消費者共享不同的主題；相反，Flume主要是用於向Hadoop或HBase導入數據，因此它對HDFS/HBase具有更好的優化，同時它也集成了Hadoop安全組件。因此，如果數據需要被多個應用程序處理，建議Kafka；如果數據主要是用於Hadoop，建議Flume。

2&> 熟悉Flume的人應該知道，Flume具有很多內置的源與槽。Kafka相比而言，現成生產者與消費者就比較少了，而且Kafka社區對這些生產者/消費者的支持也比較薄弱。因此如果準備自己編寫生產者與消費者，建議Kafka；如果Flume的內置源/槽已經足夠滿足你的需求而又不想編程，建議Fume。

3&> Flume內置了攔截器，可以對流經Flume的數據進行直接處理，因此比較容易實現數據屏蔽與數據過濾。Kafka則需要額外的流處理系統來對數據進行處理。

4&> Kafka與Flume都可以通過配置保證數據不丟失。但是，Flume不會複製消息，因此即使使用可靠的文件渠道，當Flume進程宕機後，你就無法訪問這些消息了（當然Flume進程重啟，從磁碟上恢復之前狀態後，可以繼續對消息進行處理）。因此如果對 HA高可用性具有很高要求，建議Kafka。

值得一提：Flume與Kafka可以很好的集成工作。如果希望將Kafka上的數據導入Hadoop，可以啟動一個內置Kafka源與Hadoop槽的Flume進程。這樣就不需要去實現自定義的消費者，同時還可以得到Flume對HDFS/HBase優化帶來的好處。

Flume/Logstash/Beat 是同一類軟體，如果抽象功能的話可以認為是一個插件執行器，有一些常用的插件（例如日誌採集，Binlog解析，執行腳本等），也可以根據需求將自己的代碼作為插件發布。

Kafka 一般作為Pub-Sub管道，沒有抓取功能。一開始設計的時候主要是Jay Krep覺得Linkedin裡面數據源，消費者之間關係太複雜，如果是N個數據源，M個消費者，需要拉N*M個線，並且介面和協議不同，所以使用了一種消息中間件來解耦數據源和消費者。但Kafka本身也不算消息中間件，中間件一般會有Queue和Topic兩種模型，Kafka主要是Topic類的模型。

對搭建日誌系統而言，也沒什麼新花樣，以下這些依樣畫葫蘆就可以了：

1. 日誌採集（Logstash/Flume，SDK wrapper）

2. 實時消費 (Storm, Flink, Spark Streaming)

3. 離線存儲（HDFS or Object Storage or NoSQL) + 離線分析（Presto，Hive，Hadoop）

4. 有一些場景可能需要搜索，可以加上ES或ELK

Flume和Kafka都是消息系統，但Flume更趨向於消息採集系統，而Kafka更趨向於消息緩存系統。