甲殼蟲1

Flume和Kafka有一部分功能是相同的，但是整體來看，兩者的差別還是很大的；它們使用的場景有所不同，但是可以相互配合使用。

Flume

簡單的說，Flume是分佈式日誌收集系統，它把各個服務器上的日誌收集起來，傳送到制定的地方，比如傳送到HDFS中。

Kafka

Kafka的定位是分佈式消息中間件，自帶存儲，提供push和pull存取數據功能。

使用場景

在實際應用中，系統實時產生的日誌需要最後進入HDFS，但是生產上的日誌數量會有波動，比如由於訪問量的增加，導致突然之間產生大量的日誌，這時候可能會導致日誌寫入HDFS失敗，所以這時候可以先把日誌數據寫入到Kafka中，再由Kafka導入到HDFS中。

總結：在日誌採集系統中，把Kafka當做日誌緩存更加合適，Flume做數據採集，因為它可以定製很多數據源，減少開發量，所以Flume和Kafka可以配合起來一起工作。

整體的流程是這樣的:

服務器上的日誌Kafka-->HDFS-->離線計算

服務器上的日誌Kafka-->Storm

希望我的回答能夠幫助到你！

會點代碼的大叔

Flume

Flume是一個分佈式系統，可用於收集、聚合流事件並將其傳輸到Hadoop中。它有許多內置的源、通道和接收器，例如Kafka通道和Avro接收器。Flume是基於配置的，它有攔截器來對通道中的數據執行簡單的轉換。

Kafka

Kafka是一種分佈式、高吞吐量的消息總線，它將數據生產者與消費者分離開來。消息被組織成主題，主題被拆分成分區，分區被跨集群中的節點（稱為代理）複製。

與Flume相比，Kafka具有更好的可擴展性和消息持久性。

由於消息被持久化在磁盤上，並且在集群中被複制，因此數據丟失情況不像Flume那樣常見。也就是說，無論是使用Kafka客戶端還是通過Connect API，生產者/來源和消費者/接收器通常都需要自定義編碼。與Flume一樣，消息大小也有限制。

加米穀大數據培訓，大數據開發0基礎班、提高班，成都小班面授！

相關：

大數據流處理：Flume、Kafka和NiFi對比

https://www.toutiao.com/i6711502507501158926/

加米穀大數據

做大數據有一段時間了，這兩個大數據組件都有使用研究，非常榮幸一起來交流這個問題。

首先肯定的是兩者有一些類似，但也僅僅是一點點

兩者都是從A端得到數據，給B端用

但兩者的區別是很大的

1. 首先兩者是兩個領域的東西

flume是數據採集測的組件，採集日誌信息、socket信息、命令輸出信息等

kafka從當前功能上更偏向於消息隊列，但不同於JMS，是分佈式消息隊列

2. 是否是分佈式

flume 是非分佈式組件，只是多個節點可以前後拼接起來

kafka是分佈式流式消息組件，使用zookeeper實現分佈式框架

3. 末端接收不同

flume的sink端是主動的將數據寫入或推送到墓地裡

kafka需要其他程序使用consumer來從kafka broker拉取數據

4.數據存儲

flume只臨時的保存少量數據在內存中作為緩存

kafka則可以在硬盤中分佈式、可備份的保存默認七天的數據，供多個消費者隨時、重複的消費數據

5.計算能力

flume不具備計算能力

kafka以後的定位是流式一站式處理組件,kafka Streaming 具備流式處理數據的能力，ksql也在研究中

總之：flume是數據採集組件，kafka則是大數據流式處理框架，兩者是沒有太多可比性的。

上述就是我對flume和kafka的一點拙見，歡迎大家進行評論指教，也麻煩大家關注、點贊。

學習是人充實，祝大家出任CTO、迎娶白富美 ！！！O(∩_∩)O

數據程序媛

我自己有寫過一份flume+kafka的日誌採集系統，flume我採用的是監聽端口，應用使用AOP面向切面進入監聽日誌，把有用的日誌向指定端口發送。flume監聽這個端口消息，一旦有消息，把消息寫入到kafka。kafka進行數據臨時存儲和傳輸到監控系統中做實時預警（Web頁面或短信預警）。對於標題所說的區別與聯繫，我找了一篇他人的文章做介紹，大家一起了解。

1 .背景

flume是由cloudera軟件公司產出的可分佈式日誌收集系統，後與2009年被捐贈了apache軟件基金會，為hadoop相關組件之一。尤其近幾年隨著flume的不斷被完善以及升級版本的逐一推出，特別是flume-ng;同時flume內部的各種組件不斷豐富，用戶在開發的過程中使用的便利性得到很大的改善，現已成為apache top項目之一.

2 .概述

1. 什麼是flume?

apache Flume 是一個從可以收集例如日誌，事件等數據資源，並將這些數量龐大的數據從各項數據資源中集中起來存儲的工具/服務，或者數集中機制。flume具有高可用，分佈式，配置工具，其設計的原理也是基於將數據流，如日誌數據從各種網站服務器上彙集起來存儲到HDFS，HBase等集中存儲器中。其結構如下圖所示：

2.應用場景

比如我們在做一個電子商務網站，然後我們想從消費用戶中訪問點特定的節點區域來分析消費者的行為或者購買意圖. 這樣我們就可以更加快速的將他想要的推送到界面上，實現這一點，我們需要將獲取到的她訪問的頁面以及點擊的產品數據等日誌數據信息收集並移交給Hadoop平臺上去分析.而Flume正是幫我們做到這一點。現在流行的內容推送，比如廣告定點投放以及新聞私人定製也是基於次，不過不一定是使用FLume,畢竟優秀的產品很多，比如facebook的Scribe，還有Apache新出的另一個明星項目chukwa，還有淘寶Time Tunnel。

3.Flume的優勢

1. Flume可以將應用產生的數據存儲到任何集中存儲器中，比如HDFS,HBase

2. 當收集數據的速度超過將寫入數據的時候，也就是當收集信息遇到峰值時，這時候收集的信息非常大，甚至超過了系統的寫入數據能力，這時候，Flume會在數據生產者和數據收容器間做出調整，保證其能夠在兩者之間提供一共平穩的數據.

3. 提供上下文路由特徵

4. Flume的管道是基於事務，保證了數據在傳送和接收時的一致性.

5. Flume是可靠的，容錯性高的，可升級的，易管理的,並且可定製的。

4. Flume具有的特徵：

1. Flume可以高效率的將多個網站服務器中收集的日誌信息存入HDFS/HBase中

2. 使用Flume，我們可以將從多個服務器中獲取的數據迅速的移交給Hadoop中

3. 除了日誌信息，Flume同時也可以用來接入收集規模宏大的社交網絡節點事件數據，比如facebook,twitter,電商網站如亞馬遜，flipkart等

4. 支持各種接入資源數據的類型以及接出數據類型

5. 支持多路徑流量，多管道接入流量，多管道接出流量，上下文路由等

6. 可以被水平擴展

3. Flume的結構

1. flume的外部結構：

如上圖所示，數據發生器（如：facebook,twitter）產生的數據被被單個的運行在數據發生器所在服務器上的agent所收集，之後數據收容器從各個agent上彙集數據並將採集到的數據存入到HDFS或者HBase中

2. Flume 事件

事件作為Flume內部數據傳輸的最基本單元.它是由一個轉載數據的字節數組(該數據組是從數據源接入點傳入，並傳輸給傳輸器，也就是HDFS/HBase)和一個可選頭部構成.

典型的Flume 事件如下面結構所示：

我們在將event在私人定製插件時比如：flume-hbase-sink插件是，獲取的就是event然後對其解析，並依據情況做過濾等，然後在傳輸給HBase或者HDFS.

3.Flume Agent

我們在瞭解了Flume的外部結構之後,知道了Flume內部有一個或者多個Agent,然而對於每一個Agent來說,它就是一共獨立的守護進程(JVM),它從客戶端哪兒接收收集,或者從其他的 Agent哪兒接收,然後迅速的將獲取的數據傳給下一個目的節點sink,或者agent. 如下圖所示flume的基本模型

Agent主要由:source,channel,sink三個組件組成.

Source:

從數據發生器接收數據,並將接收的數據以Flume的event格式傳遞給一個或者多個通道channal,Flume提供多種數據接收的方式,比如Avro,Thrift,twitter1%等

Channel:

channal是一種短暫的存儲容器,它將從source處接收到的event格式的數據緩存起來,直到它們被sinks消費掉,它在source和sink間起著一共橋樑的作用,channal是一個完整的事務,這一點保證了數據在收發的時候的一致性. 並且它可以和任意數量的source和sink鏈接. 支持的類型有: JDBC channel , File System channel , Memort channel等.

sink:

sink將數據存儲到集中存儲器比如Hbase和HDFS,它從channals消費數據(events)並將其傳遞給目標地. 目標地可能是另一個sink,也可能HDFS,HBase.

它的組合形式舉例:

以上介紹的flume的主要組件,下面介紹一下Flume插件:

1. Interceptors攔截器

用於source和channel之間,用來更改或者檢查Flume的events數據

2. 管道選擇器 channels Selectors

在多管道是被用來選擇使用那一條管道來傳遞數據(events). 管道選擇器又分為如下兩種:

默認管道選擇器: 每一個管道傳遞的都是相同的events

多路複用通道選擇器: 依據每一個event的頭部header的地址選擇管道.

3.sink線程

用於激活被選擇的sinks群中特定的sink,用於負載均衡.

4.Flume與Kafka對比

kafka和flume都是日誌系統，kafka是分佈式消息中間件，自帶存儲，提供push和pull存取數據功能。flume分為agent（數據採集器）,collector（數據簡單處理和寫入）,storage（存儲器）三部分，每一部分都是可以定製的。比如agent採用RPC（Thrift-RPC）、text（文件）等，storage指定用hdfs做。

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的方式。

IT追夢—廈門站

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

關鍵字: 科技 互聯網 傳送