大數據面試題知識點分析（十一）之Flume面試真題及答案

一般情況下面試大數據崗位的時候都會問到flume，我們之前也對flume進行過總結，不過時間太快了，轉眼到了2020年。下面根據本人最新的flume相關面試並總結最準確的答案如下：

友情提示：本專欄涉及大數據面試題及相關知識點不同於大多數的網絡複製文，是博主精心準備和總結的最新的面試及知識點，喜歡就訂閱噢，後續還會進行flink源碼解析，spark源碼解析，歡迎關注博客，大家一起討論學習！

專欄：點擊打開鏈接
博客：點擊打開鏈接

一、Flume的Source，Sink，Channel的作用？你們Source是什麼類型？

1.1、首先各組件的作用

1. Source組件是專門用來收集數據的，可以處理各種類型、各種格式的日誌數據，包括avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、legacy

2. Channel組件對採集到的數據進行緩存，可以存放在Memory或File中。

3. Sink組件是用於把數據發送（下沉）到目的地的組件，目的地包括Hdfs、Logger、avro、thrift、ipc、file、Hbase、solr、自定義。

1.2、實際生產常用的Source類型爲：

1. 監控後臺日誌：exec 監控tail -F /dir；
2. 監控後臺產生日誌的端口：netcat，exec， spooldir；
3. 我們還自定義了mysqlSource用來監控mysql。

二、你對Flume的Channel Selectors瞭解多少？

Channel Selectors主要功能是可以讓不同的項目日誌通過不同的channel流到不同的sink裏去。Channel Selectors有兩種類型：默認的Replicating Channel Selector和Multiplexing Channel Selector。

這兩種selector的區別是：Replicating 會將source過來的events發往所有channel，但是Multiplexing可以選擇該發往哪些Channel。

三、講一講你們之前怎麼對flume調優的？

flume調優主要根據三個組件分爲以下三個方面：

3.1、Source調優

**增加Source個數（使用Tair Dir這類Source時可增加FileGroups個數）可以增大Source的讀取數據的能力。**例如：當某一個目錄產生的文件過多時需要將這個文件目錄拆分成多個文件目錄，同時配置好多個Source 以保證Source有足夠的能力獲取到新產生的數據。

batchSize參數決定Source一次批量運輸到Channel的event條數，適當調大這個參數可以提高Source搬運Event到Channel時的性能。

3.2、Channel調優

雖然channel的type選擇memory時Channel的性能最好，但是如果Flume進程意外掛掉可能會丟失數據。type選擇file時Channel的容錯性更好，但是性能上會比memory channel差。

使用file Channel時dataDirs配置多個不同盤下的目錄可以提高性能。

checkpointDir 和 backupCheckpointDir 也儘量配置在不同硬盤對應的目錄中，保證 checkpoint 壞掉後，可以快速使用backupCheckpointDir 恢復數據

Capacity 參數決定Channel可容納最大的event條數。transactionCapacity 參數決定每次Source往channel裏面寫的最大event條數和每次Sink從channel裏面讀的最大event條數。transactionCapacity需要大於Source和Sink的batchSize參數。**

3.3、Sink調優

增加Sink的個數可以增加Sink消費event的能力。Sink也不是越多越好夠用就行，過多的Sink會佔用系統資源，造成系統資源不必要的浪費。

batchSize參數決定Sink一次批量從Channel讀取的event條數，適當調大這個參數可以提高Sink從Channel搬出event的性能。

四、你熟悉flume的事務機制嗎？

Flume的事務機制（類似數據庫的事務機制）：Flume使用兩個獨立的事務（flume ng開始，也就是1.X版本）分別負責從Soucrce到Channel，以及從Channel到Sink的事件傳遞。Source 到 Channel 是 Put 事務，Channel 到 Sink 是 Take 事務，比如spooling directory類型的source 爲文件的每一行創建一個事件，一旦事務中所有的事件全部傳遞到Channel且提交成功，那麼Soucrce就將該文件標記爲完成。同理，事務以類似的方式處理從Channel到Sink的傳遞過程，如果因爲某種原因使得事件無法記錄，那麼事務將會回滾。且所有的事件都會保持到Channel中，等待重新傳遞。

五、你們用Flume採集數據有丟失數據嗎？

沒有丟失，Channel存儲可以存儲在File中，數據傳輸自身有事務，只會出現很低的重複，不會有丟失。

六、追問，你怎麼確定沒有丟失數據呢？

主要考察怎麼監控的flume，有兩種回答方式：

• 如果是cdh集羣，就是cdh監控來看，沒有缺失。
• 如果是原生大數據集羣環境，一般是使用的第三方監控框架Ganglia實時監控的flume。

七、你瞭解flume攔截器嗎？有自定義過嗎？

我們之前部署的flume有ETL攔截器和類型區分攔截器。 採用這兩個攔截器主要是爲了模塊化開發和提高可移植性；但是性能會低一些。

自定義flume攔截器步驟如下：

1. 實現Interceptor接口
2. 重寫如下四個方法:
   1. Initialize 初始化
   2. public Event intercept(Event event)處理單個Event
   3. public List intercept(List events) 處理多個 Event，在這個 方法中調用 Event intercept(Event event)
   4. close 方法
3. 靜態內部類實現Interceptor.Builder

八、你們flume sink數據到hdfs後，有沒有出現大量小文件的情況？怎麼處理的？

一般剛設計好，沒有考慮完善的時候都是出現過的，可以從大量小文件對hdfs的影響入手，然後再講解決方案。如下：

8.1、hdfs存入大量小文件，會帶來的影響

1. 元數據層面：每個小文件都有一份元數據，其中包括文件路徑，文件名，所有者，所屬 組，權限，創建時間等，這些信息都保存在 Namenode 內存中。所以小文件過多，會佔用 Namenode 服務器大量內存，影響 Namenode 性能和使用壽命；
2. 計算層面：默認情況下MR會對每個小文件啓用一個Map任務計算，非常影響計算性能，同時也影響磁盤尋址時間。

8.2、sink進hdfs大量小文件主要是如下原因造成的：

1. 官方默認的這三個參數配置寫入 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 秒時會滾動生成正式文件
   3. 舉例：在 2020-04-03 06:26 的時侯 sink 接收到數據，那會產生如下 tmp 文件： /rople/20200403/file.202004030626.tmp 即使文件內容沒有達到 128M，也會在07:26時滾動生成正式文件。

8.3、解決這個問題的方案

1. 去掉round時間系列參數，並將rollSize和rollCount置0，表示不根據臨時文件大小和event數量來滾動文件（滾動文件即指將HDFS上生成的以.tmp結尾的臨時文件轉換爲實際存儲文件）。當然，也可以調大rollSize參數（如調至100000000,表示100MB滾動文件，單位是bytes）。
2. 設置a1.sinks.k1.hdfs.minBlockReplicas=1，這樣文件會因爲所在塊的複製而滾動文件。