【大數據面試寶典】 第七篇 Flume 面試題

走過的最長的套路，就是面試官的套路。

Flume是Cloudera提供的一個高可用的，高可靠的，分佈式的海量日誌採集、聚合和傳輸的系統。Flume基於流式架構，靈活簡單。

Flume 的主主要的作用就是，實時讀取服務器本地磁盤的數據，將數據寫入到 HDFS 。

組成

這是官網給出的Flume的架構圖:

現在我們根據這個架構圖說下Flume裏面的組成。

Source

• Spooling Directory
• Exec
• Syslog
• Avro
• Netcat

Channel

• Channel 是位於 Source 和 Sink 之間的緩衝區；
• Flume 自帶兩種Channel: Memory Channel , File Channel.
• Memory Channel: 基於內存緩存，在不需要關心數據丟失的情景下適用；
• File Channel 是 Flume 的持久化 Channel , 系統宕機不會丟失數據。

Sink

• HDFS
• Kafka
• Logger
• Avro
• File
• 自定義

Put 事物

• doPut: 將批數據寫入到臨時緩衝去putList
• doCommit: 檢查 Channel 內存隊列是都足夠合併
• doRollBack: Channel 內存隊列空間不足，回滾數據

Take 事物

• doTake: 先將數據讀取到緩衝去takeList
• doCommit: 如果數據全部發送成功，則清除緩衝區takeList
• doRollBack: 數據發送過程中如果出現異常，rollBack將臨時緩衝區 takeList 中的數據歸還給內存隊列。

面試中需要答道以下幾點:

• Taildir Source：斷點續傳、多目錄。Flume1.6以前需要自己自定義 Source 記錄每次讀取文件位置，實現斷點續傳。

• File Channel：數據存儲在磁盤，宕機數據可以保存。但是傳輸速率慢。適合對數據傳輸可靠性要求高的場景，比如，金融行業。

• Memory Channel：數據存儲在內存中，宕機數據丟失。傳輸速率快。適合對數據傳輸可靠性要求不高的場景，比如，普通的日誌數據。

• Kafka Channel：減少了 Flume 的 Sink 階段，提高了傳輸效率。

• Source 到 Channel 是 Put 事務

• Channel 到 Sink 是 Take 事務

Flume 攔截器

攔截器可以分爲兩種，ETL攔截器（做清洗數據） 和 類型攔截器（區分類型）
使用兩個攔截器的目的在於解耦，便於模塊話開發和可移植性高，當然，兩個攔截器會對性能造成影響。

自定義攔截器的步驟

• 實現 Interceptor
• 重寫 4 個方法:
• • initialize: 初始化
• • public Event intercept(Event event) 處理單個 Event
• • public List<Event> intercept(List<Event> events) 處理多個 Event
• • close
• 靜態內部類，實現 Interceptor.Builder

Flume 的Channel 的選擇器

所謂的 Channel Selectors 其實就是讓不同項目日誌通過不同的 Channel 到達不同的 Sink 中去。官方提供了兩種 Channel Selectors:

• Replicating Channel Selector: 將 Source 過來的所有的 Events 發往所有的 Sink;
• Multiplexing Channel Selector: 將 Source 過來的 Events 選擇性的發往不同的 Sink.

Flume 的監控器

• Ganglia
• 自定義監控器

Flume的數據丟失

看使用的Channel是什麼類型的Channel.

• Memory Channel: 速度塊，但是是基於內存的，容易造成數據丟失；
• File Channel: 數據可以保存在 File 裏面，數據傳輸本身就具備事物性，不會造成數據的丟失。

Flume 內存

• 開發中在flume-env.sh中設置JVM heap爲4G或更高，部署在單獨的服務器上（4核8線程16G內存）
• -Xmx與-Xms最好設置一致，減少內存抖動帶來的性能影響，如果設置不一致容易導致頻繁fullgc。

FileChannel 的優化

• 通過配置dataDirs指向多個路徑，每個路徑對應不同的硬盤，增大Flume吞吐量。
  這個官網有說明:
  Comma separated list of directories for storing log files. Using multiple directories on separate disks can improve file channel peformance
• checkpointDir 和 backupCheckpointDir 也儘量配置在不同硬盤對應的目錄中，保證checkpoint壞掉後，可以快速使用backupCheckpointDir恢復數據

HDFS Sink 小文件的處理

HDFS存入大量小文件，有什麼影響

元數據層

每個小文件都有一份元數據，其中包括文件路徑，文件名，所有者，所屬組，權限，創建時間等，這些信息都保存 Namenode 內存中。所以小文件過多，會佔用 Namenode 服務器大量內存，影響 Namenode 性能和使用壽命.

計算層面

默認情況下MR會對每個小文件啓用一個Map任務計算，非常影響計算性能。同時也影響磁盤尋址時間。

小文件的處理

官方默認的這三個參數配置寫入HDFS後會產生小文件，hdfs.rollInterval、hdfs.rollSize、hdfs.rollCount
基於以上hdfs.rollInterval=3600，hdfs.rollSize=134217728，hdfs.rollCount =0，hdfs.roundValue=3600，hdfs.roundUnit= second幾個參數綜合作用，效果如下：
（1）tmp文件在達到128M時會滾動生成正式文件
（2）tmp文件創建超3600秒時會滾動生成正式文件
舉例：在2018-01-01 05:23的時侯sink接收到數據，那會產生如下tmp文件：
/flume/20180101/flume.201801010520.tmp
即使文件內容沒有達到128M，也會在06:23時滾動生成正式文件