作者Tony Siciliani  本文為36大資料獨譯，譯者：隨風

我們在建設一個大資料管道時，需要在Hadoop生態系統前仔細考慮，如何獲取大體量、多樣化以及高速性的資料。在決定採用何種工具以滿足我們的需求時，最初對於擴充套件性、可靠性、容錯性以及成本的考慮便發揮了作用。本文，我們將聚焦於三種Apache獲取工具：Flume, Kafka, and NiFi。這三種工具在橫向比較中都展示出了良好的效能，同時還提供了一種外掛體系結構，在這種結構中可通過定製元件來使功能得到擴充套件。

 Apache Flume

一個Flume部署包括一個或多個配置有拓撲結構的agent。Flume Agent是一個JVM程序用來控制Flume拓撲結構的基本構件，其中包括source, channel 和sink。Flume客戶先把event傳送到source，source再把這些events成批放置到一個叫做channel的暫時緩衝區，然後資料從此流向連線資料終端的sink。一個sink也可以是其它Flume agents的後續資料資源。Agent之間可以被連線，並且含有多個source，channel和sink。

Flume是一個分散式的收集、聚合和將事件流傳輸到Hadoop的系統。它配備有多個內建source、channel和link，比如Kafka Channel and Avro sink。Flume是基於配置的並且含有攔截器以對傳輸中的資料進行簡單轉換。

如果不小心謹慎，使用Flume是很容易把資料丟失掉的。比如，為尋求高吞吐量而選擇memory channel（記憶渠道）的弊端是，當agent節點下降資料就會丟失。File channel（檔案渠道）則以延長潛伏期為代價而提供永續性。即使如此，因為資料並沒有複製到其他節點，所以file channel的可靠性就只能和普通磁碟一樣。Flume 的確通過多跳/扇入扇出流來提供擴充套件性，對於高可用性，agent可以被橫向衡量。

Apache Kafka

Kafka是一種高吞吐量的分散式訊息匯流排，它可以使資料生產者從消費者中分離出來。各種訊息被組織到話題中，然後將話題分成多個分割槽，通過節點再將分割槽成批覆制，這叫做代理。與Flume相比，Kafka有更好的延展性以及資訊永續性。Kafka現有兩種型別：一種是“經典”生產者/消費者模式，另一種是新 Kafka-Connect，它可以給外部資料商店提供可配置聯結器。

Kafka可用於大型軟體系統構件中的事件處理和整合。 資料飆升，背壓可以立即被處理。除此之外，Kafka還配置有Kafka Streams，對於Apache Spark 或 Apache Flink來說，這可以用於簡單的流處理而不需要一個單獨叢集。

因為資訊被留存在磁碟上並且在叢集內被複制，所以資訊丟失的情況就不像Flume那麼普遍。也就是說，生產商/源和消費者/鏈經常需要自定義編碼，要麼使用Kafka客戶端，要麼通過Connect API。 和Flume一樣，它在資訊大小方面也有侷限性。最終，為了能夠交流，Kafka生產商和消費者都不得不同意協議、格式、模式，但這些在某些情況下還是存在問題的。

Apache NiFi

不同於Flume和Kafka，NiFi可以處理任意大小的資訊。在一個基於網站的拖放UI（使用者介面）背後， NiFi可在叢集中進行運作並且提供實時操控，這就使得在任何源和目的地之間，管理資料移動變得更加容易。它支援存在不同格式、模式、協議、速度和大小的分佈源。

NiFi可用於有著嚴格安全要求和達標要求的任務關鍵資料流中，在那裡我們可以看見整個過程並且做出實時改變。在編寫時，有將近200個非傳統的處理器（包括Flume和Kafka處理器），它們可以被拖&放、配置並且立即投入使用。 NiFi的一些關鍵特徵被優先呈現， 比如資料的可追蹤性和每次連線的背壓門限配置。

儘管NiFi被用於製造可容錯生產管線，但它至今仍不能像Kafka一樣複製資料。節點如果下降，那麼資料流就可能被導向另一個節點，但是在失敗節點後排隊的資料就不得不等待直到節點回來。NiFi既不是一個成熟的ETL工具，也不是適合CEP的理想型。為此，NiFi反而應該像Apache Flink, Spark Streaming 或 Storm一樣連線到一個流式框架。

Combinations

這並不是有且只有一個工具，能同樣把所有事情都做好並解決你所有的需求。把能以更好的方式做不同事情的工具結合起來，就會把功能集結起來，同時在處理一大串情況時就會增強靈活性。NiFi和Flume會根據你的需求，也可以做到像Kafka生產商和消費者一樣的。

Flume和Kafka的結合現在非常流行，它有一個專屬名字：Flafka（這並不是編造的）。Flafka包括一個 Kafka source, Kafka channel和Kafka sink。當通過Kafka渠道（channel）時，Flume event就被儲存起來並且為了彈性就通過Kafka代理被複制了下來。把Flume和Kafka結合起來就使得Kafka避免自定義編碼，同時也利用了Flume經檢驗的 source和sink。

結合兩種工具或許顯得很浪費，因為這好像在功能上有些重疊。比如，NiFi和Kafka都能提供代理來連線生產者和消費者。然而，他們所做的卻截然不同：在Nifi中，大多數資料流邏輯並不在生產者/消費者中，而是存在於代理中，這就有利於集中控制。NiFi被建造用於做了一個重要的事情，那就是資料流管理。把兩種工具相結合，NiFi就可以解決Kafka所不能解決的資料流挑戰，同時又利用了Kafka可信賴的流式資料儲存。

總結

仍有很多的內容要談論，但如果那樣的話，這就是一本書的主題了而不只是一篇文章。同時，正如這裡所提及的工具飛速進展一般，這篇簡潔的分析也會像其他人看待新興科技一樣，遲早會過時的。

End.