日志采集系統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就不必多說了，生產者消費者模型，看你怎么去構建日志消費的下游了。有了消息隊列作為中間件，消費的下游和上游可以完美的解耦。