自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

大數(shù)據(jù)流處理:Flume、Kafka和NiFi對(duì)比

新聞 大數(shù)據(jù) Kafka
在構(gòu)建大數(shù)據(jù)流水線時(shí),我們需要考慮處理數(shù)據(jù)的數(shù)量,種類和速度,這些數(shù)據(jù)通常出現(xiàn)在Hadoop生態(tài)系統(tǒng)的入口。

在構(gòu)建大數(shù)據(jù)流水線時(shí),我們需要考慮處理數(shù)據(jù)的數(shù)量,種類和速度,這些數(shù)據(jù)通常出現(xiàn)在Hadoop生態(tài)系統(tǒng)的入口。在決定采用哪種工具來(lái)滿足我們的要求時(shí),都會(huì)考慮到可擴(kuò)展性、可靠性、適應(yīng)性、開(kāi)發(fā)時(shí)間方面的成本等初步因素。在本文中,我們將簡(jiǎn)要介紹三種Apache處理工具:Flume,Kafka和NiFi。這三種產(chǎn)品都具有出色的性能,可以橫向擴(kuò)展,并提供插件機(jī)制,可通過(guò)自定義組件擴(kuò)展功能。

Apache Flume

Flume部署由一個(gè)或多個(gè)使用拓?fù)渑渲玫拇斫M成。Flume代理是一個(gè)JVM進(jìn)程,它承載Flume拓?fù)涞幕緲?gòu)建塊,即源、通道和接收器。Flume客戶機(jī)將事件發(fā)送到源,該源將這些事件成批放置到名為channel的臨時(shí)緩沖區(qū)中,然后從該緩沖區(qū)中數(shù)據(jù)流到連接到數(shù)據(jù)最終目的地的接收器。接收器也可以是其他Flume代理的后續(xù)數(shù)據(jù)源。代理可以被鏈接,并且每個(gè)代理都有多個(gè)源、通道和接收器。

大數(shù)據(jù)流處理:Flume、Kafka和NiFi對(duì)比

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

如果不小心,使用Flume很容易丟失數(shù)據(jù)。例如,為高吞吐量選擇內(nèi)存通道有一個(gè)缺點(diǎn),即當(dāng)代理節(jié)點(diǎn)關(guān)閉時(shí),數(shù)據(jù)將丟失。文件通道將以增加延遲為代價(jià)提供持久性。即使如此,由于數(shù)據(jù)沒(méi)有復(fù)制到其他節(jié)點(diǎn),因此文件通道僅與底層磁盤一樣的可靠性。Flume通過(guò)多跳/扇入扇出流提供了可伸縮性。對(duì)于高可用性(HA),可以水平擴(kuò)展代理。

Apache Kafka

Kafka是一種分布式、高吞吐量的消息總線,它將數(shù)據(jù)生產(chǎn)者與消費(fèi)者分離開(kāi)來(lái)。消息被組織成主題,主題被拆分成分區(qū),分區(qū)被跨集群中的節(jié)點(diǎn)(稱為代理)復(fù)制。與Flume相比,Kafka具有更好的可擴(kuò)展性和消息持久性。Kafka現(xiàn)在有兩種風(fēng)格:一種是“經(jīng)典”的生產(chǎn)者/消費(fèi)者模型,另一種是新的Kafka-Connect,它為外部數(shù)據(jù)存儲(chǔ)提供可配置的連接器(源/接收器)。

大數(shù)據(jù)流處理:Flume、Kafka和NiFi對(duì)比

Kafka可用于大型軟件系統(tǒng)組件之間的事件處理和集成。此外,Kafka附帶了Kafka流,它可以用于簡(jiǎn)單的流處理,而不需要像Apache Spark或Apache Flink那樣的單獨(dú)集群。

由于消息被持久化在磁盤上,并且在集群中被復(fù)制,因此數(shù)據(jù)丟失情況不像Flume那樣常見(jiàn)。也就是說(shuō),無(wú)論是使用Kafka客戶端還是通過(guò)Connect API,生產(chǎn)者/來(lái)源和消費(fèi)者/接收器通常都需要自定義編碼。與Flume一樣,消息大小也有限制。最后,為了能夠進(jìn)行通信,Kafka的生產(chǎn)者和消費(fèi)者必須就協(xié)議、格式和架構(gòu)達(dá)成一致,這在某些情況下可能會(huì)有問(wèn)題。

Apache NiFi

與Flume和Kafka不同,NiFi可以處理任意大小的消息。在基于Web的拖放式用戶界面后面,NiFi在集群中運(yùn)行,并提供實(shí)時(shí)控制,使您可以輕松管理任何源和任何目標(biāo)之間的數(shù)據(jù)移動(dòng)。它支持不同格式、模式、協(xié)議、速度和大小的分散和分布式源。

NiFi可以用于具有嚴(yán)格安全性和合規(guī)性要求的關(guān)鍵任務(wù)數(shù)據(jù)流中,在那里我們可以可視化整個(gè)過(guò)程并實(shí)時(shí)進(jìn)行更改。在撰寫本文時(shí),它有近200個(gè)隨時(shí)可用的處理器(包括Flume和Kafka處理器),可以進(jìn)行拖放、配置和立即投入使用。NiFi的一些關(guān)鍵特性是優(yōu)先級(jí)排隊(duì)、數(shù)據(jù)跟蹤和每個(gè)連接的背壓閾值配置。 

盡管NiFi用于創(chuàng)建容錯(cuò)生產(chǎn)管道,但它還沒(méi)有像Kafka那樣復(fù)制數(shù)據(jù)。如果一個(gè)節(jié)點(diǎn)發(fā)生故障,那么可以將流定向到另一個(gè)節(jié)點(diǎn),但是排隊(duì)等待故障節(jié)點(diǎn)的數(shù)據(jù)必須等待該節(jié)點(diǎn)恢復(fù)。NiFi不是一個(gè)成熟的ETL工具,也不是復(fù)雜計(jì)算和事件處理(CEP)的理想選擇。為此,它應(yīng)該連接到Apache Flink,Spark Streaming或Storm等流式傳輸框架。

組合

沒(méi)有哪個(gè)工具滿足您的所有要求。組合以更好方式執(zhí)行不同操作的工具可以實(shí)現(xiàn)功能的增強(qiáng),并提高處理更多場(chǎng)景的靈活性。根據(jù)您的需求,NiFi和Flume都可以充當(dāng)Kafka生產(chǎn)者或消費(fèi)者。

Flume-Kafka集成非常受歡迎,它有自己的名字:Flafka(我不是這樣做的)。Flafka包括Kafka源,Kafka通道和Kafka池。結(jié)合Flume和Kafka,Kafka可以避免自定義編碼并利用Flume經(jīng)過(guò)實(shí)戰(zhàn)考驗(yàn)的資源和接收器,通過(guò)Kafka通道的Flume事件將在Kafka代理中進(jìn)行存儲(chǔ)和復(fù)制,以實(shí)現(xiàn)彈性。

組合工具可能看起來(lái)很浪費(fèi),因?yàn)樗坪踉诠δ鼙容^重疊。例如,NiFi和Kafka都提供了代理來(lái)連接生產(chǎn)者和消費(fèi)者。但是,它們的做法不同:在NiFi中,大部分?jǐn)?shù)據(jù)流邏輯不在生產(chǎn)者/消費(fèi)者內(nèi)部,而是在代理中,允許集中控制。NiFi的構(gòu)建是為了做一件重要的事情:數(shù)據(jù)流管理。通過(guò)兩種工具的結(jié)合,NiFi可以充分利用Kafka可靠的流數(shù)據(jù)存儲(chǔ),同時(shí)解決Kafka無(wú)法解決的數(shù)據(jù)流挑戰(zhàn)。

END

總結(jié):

大數(shù)據(jù)流處理:Flume、Kafka和NiFi對(duì)比
責(zé)任編輯:張燕妮 來(lái)源: 大數(shù)據(jù)云技術(shù)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)