大資料流處理：Flume、Kafka和NiFi對比

在本文中，我們將簡要介紹三種Apache處理工具：Flume、Kafka和Nifi。這三款產品效能優異，可橫向伸縮，並提供外掛機制，可透過定製元件進行擴充套件。

Apache Flume

Flume部署由一個或多個使用拓撲配置的代理組成。Flume代理是一個JVM程式，它承載Flume拓撲的基本構建塊，即源、通道和接收器。Flume客戶機將事件傳送到源，然後將它們成批地放在名為channel的臨時緩衝區中，資料從該緩衝區流向連線到資料最終目的地的接收器。接收器也可以是其他Flume代理程式的後續資料來源。代理可以連結，並且每個代理都有多個源、通道和接收器。

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

如果不小心，使用Flume很容易丟失資料。例如，為高吞吐量選擇記憶體通道有一個缺點，即當代理節點關閉時，資料將丟失。檔案通道將以增加延遲為代價提供永續性。即使如此，由於資料沒有複製到其他節點，因此檔案通道僅與底層磁碟一樣的可靠性。Flume透過多跳/扇入扇出流提供了可伸縮性。對於高可用性（HA），可以水平擴充套件代理。

Apache Kafka

Kafka是一種分散式高吞吐量訊息匯流排，可將資料生成者與消費者分開。訊息按主題組織，主題分為多個分割槽，分割槽在群集中的節點之間複製（稱為代理）。與Flume相比，Kafka具有更好的可擴充套件性和訊息永續性。 Kafka現在有兩種樣式：一種是“經典”生產者/消費者模型，另一種是新的Kafka-Connect，它為外部資料儲存提供可配置的聯結器（源/接收器）。

kafka可以用於大型軟體系統元件之間的事件處理和整合，此外，kafka附帶kafka流，它可以用於簡單的流處理，而不需要單獨的叢集，如apache spark或apacheFlink。

由於訊息被持久化在磁碟上，並且在叢集中被複制，因此資料丟失情況不像Flume那樣常見。也就是說，無論是使用Kafka客戶端還是透過Connect API，生產者/來源和消費者/接收器通常都需要自定義編碼。與Flume一樣，訊息大小也有限制。最後，為了能夠進行通訊，Kafka的生產者和消費者必須就協議、格式和架構達成一致，這在某些情況下可能會有問題。

Apache NiFi

與Flume和Kafka不同，NIFI可以處理任何大小的訊息。在基於Web的拖放使用者介面後面，NIFI在叢集中執行，並提供實時控制，以便您可以輕鬆地管理任何源和任何目標之間的資料移動。它支援不同格式、模式、協議、速度和大小的分散和分散式源。

NiFi可以用於具有嚴格安全性和合規性要求的關鍵任務資料流中，在那裡我們可以視覺化整個過程並實時進行更改。在撰寫本文時，它有近200個隨時可用的處理器（包括Flume和Kafka處理器），可以進行拖放、配置和立即投入使用。NiFi的一些關鍵特性是優先順序排隊、資料跟蹤和每個連線的背壓閾值配置。

雖然NiFi用於建立容錯生產管道，但它不會複製像Kafka這樣的資料。如果節點發生故障，則可以將流定向到另一個節點，但排隊等待故障節點的資料必須等待節點恢復。 NiFi不是一個成熟的ETL工具，不適合複雜的計算和事件處理（CEP）。要做到這一點，它應該連線到流式框架，如Apache Flink，Spark Streaming或Storm。

組合

沒有工具符合您的所有要求。組合以更好的方式執行不同操作的工具可以增強功能並增加處理更多場景的靈活性。根據您的需求，NiFi和Flume可以充當Kafka生產商或消費者。

Flume-Kafka整合非常受歡迎，它有自己的名字：Flafka（我不是這樣做的）。Flafka包括Kafka源，Kafka通道和Kafka池。結合Flume和Kafka，Kafka可以避免自定義編碼並利用Flume經過實戰考驗的資源和接收器，透過Kafka通道的Flume事件將在Kafka代理中進行儲存和複製，以實現彈性。

組合工具可能看起來很浪費，因為它似乎在功能上重疊。例如，NiFi和Kafka都提供代理商來連線生產者和消費者。但是，它們的表現不同：在NiFi中，大多數資料流邏輯不在生產者/消費者中，而是在代理中，允許集中控制。 NiFi是為了做一件重要的事情而構建的：資料流管理。透過兩種工具的結合，NiFi可以充分利用Kafka可靠的流資料儲存，同時解決Kafka無法解決的資料流挑戰。

中安威士 ：保護核心資料，捍衛網路安全

 

來源：網路收集