Flume整體架構是怎么樣的

這篇文章主要為大家展示了“Flume整體架構是怎么樣的”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“Flume整體架構是怎么樣的”這篇文章吧。

1、Flume介紹

Flume是cloudera公司開源的一款分布式、可靠地進行大量日志數(shù)據(jù)采集、聚合和并轉移到存儲中；通過事務機制提供了可靠的消息傳輸支持，自帶負載均衡機制來支撐水平擴展；并且提供了一些默認組件供直接使用。

Flume目前常見的應用場景：日志--->Flume--->實時計算（如Kafka+Storm） 、日志--->Flume--->離線計算（如HDFS、HBase）、日志--->Flume--->ElasticSearch。

2、整體架構

Flume主要分為三個組件：Source、Channel、Sink；數(shù)據(jù)流如下圖所示：

1、Source負責日志流入，比如從文件、網(wǎng)絡、Kafka等數(shù)據(jù)源流入數(shù)據(jù)，數(shù)據(jù)流入的方式有兩種輪訓拉取和事件驅動；

2、Channel負責數(shù)據(jù)聚合/暫存，比如暫存到內存、本地文件、數(shù)據(jù)庫、Kafka等，日志數(shù)據(jù)不會在管道停留很長時間，很快會被Sink消費掉；

3、Sink負責數(shù)據(jù)轉移到存儲，比如從Channel拿到日志后直接存儲到HDFS、HBase、Kafka、ElasticSearch等，然后再有如Hadoop、Storm、ElasticSearch之類的進行數(shù)據(jù)分析或查詢。

一個Agent會同時存在這三個組件，Source和Sink都是異步執(zhí)行的，相互之間不會影響。

假設我們有采集并索引Nginx訪問日志，我們可以按照如下方式部署：

1、Source采集的日志會傳入ChannelProcessor組件，其首先通過Interceptor進行日志過濾，如果接觸過Servlet的話這個概念是類似的，可以參考《Servlet3.1規(guī)范翻譯——過濾器 》 ；過濾器可以過濾掉日志，也可以修改日志內容；

2、過濾完成后接下來會交給ChannelSelector進行處理，默認提供了兩種選擇器：復制或多路復用選擇器；復制即把一個日志復制到多個Channel；而多路復用會根據(jù)配置的選擇器條件，把符合條件的路由到相應的Channel；在寫多個Channel時可能存在存在失敗的情況，對于失敗的處理有兩種：稍后重試或者忽略。重試一般采用指數(shù)級時間進行重試。

我們之前說過Source生產日志給Channel、Sink從Channel消費日志；它倆完全是異步的，因此Sink只需要監(jiān)聽自己關系的Channel變化即可。

到此我們可以對Source日志進行過濾/修改，把一個消息復制/路由到多個Channel，對于Sink的話也應該存在寫失敗的情況，F(xiàn)lume默認提供了如下策略：

Failover策略是給多個Sink定義優(yōu)先級，假設其中一個失敗了，則路由到下一個優(yōu)先級的Sink；Sink只要拋出一次異常就會被認為是失敗了，則從存活Sink中移除，然后指數(shù)級時間等待重試，默認是等待1s開始重試，最大等待重試時間是30s。

Flume也提供了負載均衡策略：

 1、首先是日志采集層，該層的Agent和應用部署在同一臺機器上，負責采集如Nginx訪問日志；然后通過RPC將日志流入到收集/聚合層；在這一層應該快速的采集到日志然后流入到收集/聚合層；

2、收集/聚合層進行日志的收集或聚合，并且可以進行容錯處理，如故障轉移或負載均衡，以提升可靠性；另外可以在該層開啟文件Channel，做數(shù)據(jù)緩沖區(qū)；

3、收集/聚合層對數(shù)據(jù)進行過濾或修改然后進行存儲或處理；比如存儲到HDFS，或者流入Kafka然后通過Storm對數(shù)據(jù)進行實時處理。

以上是“Flume整體架構是怎么樣的”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業(yè)資訊頻道！