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

日誌採集系統flume和kafka區別及聯繫:

https://blog.csdn.net/helloxiaozhe/article/details/79481319

 

日誌採集系統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：

1. Kafka是pull based, 若是你有不少下游的Data Consumer，用Kafka；

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

3. 須要更好的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就沒必要多說了，生產者消費者模型，看你怎麼去構建日誌消費的下游了。有了消息隊列做爲中間件，消費的下游和上游能夠完美的解耦。