初賽

在構(gòu)建大數(shù)據(jù)管道時，我們需要考慮如何吸收出現(xiàn)在通常是Hadoop生態(tài)系統(tǒng)大門口的數(shù)據(jù)量，多樣性和速度。 在決定采用哪種工具來滿足我們的要求時，諸如可伸縮性，可靠性，適應(yīng)性，開發(fā)時間成本等方面的初步考慮都將發(fā)揮作用。 在這篇文章中。 我們將簡要介紹三個Apache提取工具： Flume ， Kafka和NiFi 。 所有這三種產(chǎn)品均具有出色的性能，可以水平縮放，并提供一種插件架構(gòu)，可以通過自定義組件擴(kuò)展功能。

阿帕奇水槽

Flume部署由一個或多個配置了拓?fù)涞拇斫M成。 Flume Agent是一個JVM進(jìn)程，它承載Flume拓?fù)涞幕緲?gòu)建塊，即源，通道和接收器。 Flume客戶端將事件發(fā)送到源，源將這些事件成批放置到稱為通道的臨時緩沖區(qū)中，然后數(shù)據(jù)從那里流到連接到數(shù)據(jù)最終目標(biāo)的接收器。 接收器也可以是其他Flume代理的后續(xù)數(shù)據(jù)源。 代理可以鏈接起來，并且每個都有多個源，通道和接收器。

Flume是一個分布式系統(tǒng)，可用于收集，聚合流事件并將其傳輸?shù)紿adoop中。 它帶有許多內(nèi)置源，通道和接收器，例如Kafka Channel和Avro接收器。 Flume基于配置，并具有攔截器 ，可對運(yùn)行中的數(shù)據(jù)執(zhí)行簡單的轉(zhuǎn)換。

如果不小心，很容易使用Flume丟失數(shù)據(jù)。 例如，選擇內(nèi)存通道以實現(xiàn)高吞吐量具有不利的一面，即當(dāng)代理程序節(jié)點發(fā)生故障時，數(shù)據(jù)將丟失。 文件通道將以增加延遲為代價提供持久性。 即使這樣，由于數(shù)據(jù)不會復(fù)制到其他節(jié)點，因此File通道僅與基礎(chǔ)磁盤一樣可靠。 Flume確實通過多跳/扇入扇出流提供了可伸縮性。 對于高可用性（HA），可以水平縮放代理。

阿帕奇·卡夫卡

Kafka是一種分布式的高吞吐量消息總線，可將數(shù)據(jù)生產(chǎn)者與消費(fèi)者分離 。 消息按主題進(jìn)行組織，主題被劃分為多個分區(qū)，并且跨集群中的節(jié)點（稱為代理）復(fù)制分區(qū)。 與Flume相比，Kafka具有更好的可伸縮性和消息持久性。 Kafka現(xiàn)在有兩種形式：“經(jīng)典”生產(chǎn)者/消費(fèi)者模型，以及新的Kafka-Connect ，它提供了到外部數(shù)據(jù)存儲的可配置連接器（源/接收器）。

Kafka可用于事件處理以及大型軟件系統(tǒng)的組件之間的集成。 開箱即用地處理數(shù)據(jù)峰值和背壓 （快速生產(chǎn)，緩慢消費(fèi)）。 此外，Kafka附帶有Kafka Streams ，可以將其用于簡單的流處理，而無需像Apache Spark或Apache Flink那樣需要單獨(dú)的集群。

由于消息在磁盤上持久保存并在群集中復(fù)制，因此數(shù)據(jù)丟失的情況比Flume少見。 也就是說，使用Kafka客戶端或通過Connect API，生產(chǎn)者/源和消費(fèi)者/接收者通常需要自定義編碼。 與Flume一樣，郵件大小也有限制。 最后，為了能夠進(jìn)行通信，Kafka的生產(chǎn)者和消費(fèi)者都必須就協(xié)議，格式和模式達(dá)成共識，這在某些情況下可能會出現(xiàn)問題。

Apache NiFi

NiFl與Flume和Kafka不同。 可以處理任意大小的消息。 NiFi在基于Web的拖放式UI的背后，在群集中運(yùn)行，并提供實時控制，可輕松管理任何源與任何目標(biāo)之間的數(shù)據(jù)移動。 它支持格式，架構(gòu)，協(xié)議，速度和大小不同的分散源。

NiFi可以用于具有嚴(yán)格安全性和合規(guī)性要求的關(guān)鍵任務(wù)數(shù)據(jù)流，我們可以在其中可視化整個過程并立即進(jìn)行實時更改。 在撰寫本文時，它具有近200個開箱即用的處理器（包括Flume和Kafka處理器），可以立即拖放，配置和投入使用。 NiFi的一些關(guān)鍵功能是優(yōu)先排序隊列，數(shù)據(jù)可追溯性和每個連接的背壓閾值配置。

盡管NiFi用來創(chuàng)建容錯生產(chǎn)流水線，但它尚未像Kafka一樣復(fù)制數(shù)據(jù)。 如果某個節(jié)點發(fā)生故障，則可以將流定向到另一個節(jié)點，但是排隊到故障節(jié)點的數(shù)據(jù)將不得不等待，直到該節(jié)點恢復(fù)正常。 NiFi并不是成熟的ETL工具，也不是復(fù)雜計算和事件處理（ CEP ）的理想選擇。 為此，它應(yīng)該連接到Apache Flink，Spark Streaming或Storm之類的流框架。

組合方式

沒有一個可以同時完成所有任務(wù)并滿足您所有需求的單一工具。 結(jié)合使用以更好的方式完成不同任務(wù)的工具，可以增強(qiáng)功能，并在處理更多場景時增加靈活性。 根據(jù)您的需求，NiFi和Flume都可以充當(dāng)Kafka的生產(chǎn)者和/或消費(fèi)者。

Flume-Kafka集成非常流行，它有自己的名字： Flafka （我沒有做這個）。 Flafka包括一個Kafka源，Kafka頻道和Kafka水槽。 將Flume和Kafka結(jié)合使用可使Kafka避免自定義編碼，并利用Flume經(jīng)過實戰(zhàn)檢驗的源和接收器，而通過Kafka渠道存儲的Flume事件將在Kafka經(jīng)紀(jì)人之間存儲和復(fù)制，以實現(xiàn)彈性。

組合工具可能看起來很浪費(fèi)，因為它似乎在功能上造成了一些重疊。 對于 ? 例如，NiFi和Kafka都提供經(jīng)紀(jì)人來聯(lián)系生產(chǎn)者和消費(fèi)者。 但是，它們的做法有所不同：在NiFi中，大部分?jǐn)?shù)據(jù)流邏輯不是位于生產(chǎn)者/消費(fèi)者內(nèi)部，而是位于代理中，從而可以進(jìn)行集中控制。 NiFi的創(chuàng)建是為了做好一件重要的事情： 數(shù)據(jù)流管理 。 結(jié)合使用這兩種工具，NiFi可以利用Kafka可靠的流數(shù)據(jù)存儲，同時解決Kafka并非旨在解決的數(shù)據(jù)流挑戰(zhàn)。

結(jié)論

總結(jié)：

還有更多要討論的內(nèi)容，但這將是書的主題而不是文章。 另外，由于此處提到的工具正在Swift發(fā)展，因此與所有其他有關(guān)新興技術(shù)的簡短分析一樣，遲早也必將過時。

翻譯自: https://www.javacodegeeks.com/2017/07/big-data-ingestion-flume-kafka-nifi.html

總結(jié)

以上是生活随笔為你收集整理的大数据摄取：Flume，Kafka和NiFi的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。