文章目錄
– HDFS Sink如何避免生成大量小文件
- 官方默認的這三個參數配置寫入HDFS後是會產生小文件的，需要修改配置項：hdfs.rollInterval、hdfs.rollSize、hdfs.rollCount
- 基於以上hdfs.rollInterval=600，hdfs.rollSize=134217728，hdfs.rollCount =0，幾個參數綜合作用，效果如下：
（1）hdfs.rollSize=134217728表示tmp文件在達到128M時會滾動生成正式文件
（2）hdfs.rollInterval=600tmp表示hdfs sink間隔超10分鐘將創建的臨時文件滾動成最終目標文件。
（3）hdfs.rollCount =0表示不按照事務的數量來進行滾動生成文件 - 舉例：在2018-01-01 05:23的時侯sink接收到數據，那會產生如下tmp文件：
/atguigu/20180101/atguigu.201801010520.tmp
即使文件內容沒有達到128M，也會在05:33時滾動生成正式文件
/atguigu/20180101/atguigu.201801010520
– file channel /memory channel/kafka channel的區別及如何選擇
一、區別
（1）file channel
- 數據存儲於磁盤，宕機數據可以保存。
- 優勢：可靠性高；劣勢：傳輸速度低
- 默認容量：100萬event
- 注意：
FileChannel可以通過配置dataDirs指向多個路徑，每個路徑對應不同的硬盤，增大Flume吞吐量。
（2）memory channel
- 數據存儲於內存，宕機數據丟失
- 優勢：傳輸速度快；劣勢：可靠性差
- 默認容量：100個event
（3）kafka channel
- 數據存儲於Kafka，
基於磁盤，有副本機制，可靠性高； 傳輸速度極快：kafka channel > memory channel + kafka sink- 速度大於memory channel的主要原因:省去了sink階段
二、生產環境如何選擇
- 如果下一級是kafka,優先選擇kafka channel
- 如果是金融、對錢要求準確的公司，對數據傳輸可靠性要求高的場景，選擇file channel
- 如果就是普通的日誌數據，通常可以選擇memory channel，要求速度足夠快，對安全性要求不是特別高。雖然安全性得不到保障，但是每天丟幾百萬數據又怎樣，PB級億萬富翁，掉1塊錢會撿？
– Flume組成、每個組件的常用類型及其特點
一、Source
- Taildir Source：斷點續傳、多目錄。Flume1.6以前沒有，需要自己自定義Source記錄每次讀取文件位置，實現斷點續傳。
- Avro Source：Avro端口監聽並接收來自外部的Avro客戶流的事件。
- Exec Source：Exec Source的配置就是設定一個Unix(linux)命令，然後通過這個命令不斷輸出數據。如果進程退出，Exec Source也一起退出，不會產生進一步的數據。
- Spooling Directory Source：Spooling Directory Source監測配置的目錄下新增的文件，並將文件中的數據讀取出來。
二、Channel
- File Channel：數據存儲在磁盤，宕機數據可以保存。但是傳輸速率慢。適合對數據傳輸可靠性要求高的場景，比如，金融行業。
- Memory Channel：數據存儲在內存中，宕機數據丟失。傳輸速率快。適合對數據傳輸可靠性要求不高的場景，比如，普通的日誌數據。
- Kafka Channel：減少了Flume的Sink階段，提高了傳輸效率。
三、Sink
- HDFS Sink：當需要將事件消息寫入到Hadoop分佈式文件系統（HDFS）時，可以使用HDFS Sink。
- Avro Sink：和 Avro Source一起工作，用於構建Flume分層收集數據消息結構。
- Kafka Sink：通過該Sink可將事件消息數據發佈到Kafka topic 上。其目標是將Flume與Kafka集成，以便基於拉式的處理系統可以處理來自各種Flume Source的數據。 目前支持Kafka 0.9.x以上系列版本。
– 關於Taildir source
（1）有哪些特點？
- 斷點續傳、多目錄
（2）哪個flume版本產生的？
- Apache1.7、CDH1.6
（3）沒有斷點續傳功能時怎麼做的？
- 通過自定義Source實現
（4）taildir掛了怎麼辦？
- 掛掉了也沒事，掛掉期間繼續往文件裏追加的內容會等flume恢復後從斷點處繼續上傳，但是可能因爲斷點未及時記錄而產生重複數據
（5）怎麼處理重複數據？
- 不處理：生產環境通常不在flume端處理，因爲在Flume中處理效率很低，會嚴重影響傳輸效率
- 處理
方式一：自身處理：在taildirsource裏面增加自定義事務
方式二：找兄弟：下一級處理（hive dwd sparkstreaming flink布隆）、去重手段（groupby、開窗取窗口第一條、redis）
（6）taildir source 是否支持遞歸遍歷文件夾讀取文件？
- 不支持，需要自定義Source，遞歸遍歷文件夾 +讀取文件
– 關於Flume流式處理事務流程
- 事務：ACID 主要是A：原子性，共進退
- Source到Channel是Put事務
- Channel到Sink是Take事務
- putList是阻塞式隊列，能緩存多少可以通過transactionCapacity設置，如果Channel內存隊列空間不足Source就不拉數據了。
- Sink並沒有把這些Event數據拉出來，只是引用到Sink而已，如果輸出成功doCommit會把Channel中相應數據銷燬。sink提交失敗數據歸還到Channel裏，其實只是把數據的引用銷燬。
- Flume1.7有個Bug，會導致Sink拉數據進入死循環，導致CPU佔滿。
- 其中回滾的動作可以理解爲就是等待，也可能是把數據歸還給上級。
– Flume Agent內部原理
- ChannelSelector的作用就是選出Event將要被髮往哪個Channel。其共有兩種類型，分別是Replicating（複製）和Multiplexing（多路複用），ReplicatingSelector會將同一個Event發往所有的Channel，Multiplexing會根據相應的原則（根據
header中value值的不同進行分流），將不同的Event發往不同的Channel，需配合攔截器使用。 - SinkProcessor共有三種類型，分別是：
DefaultSinkProcessor：默認Channel和Sink是一對一的關係。
LoadBalancingSinkProcessor：可以實現負載均衡的功能，但是一個Sink組只能消費Channel中每個Event一次，也就是說每一個Event只能被一個Sink拉走，Channel和Sink只能是一對多的關係。
FailoverSinkProcessor：有點HA的意思，故障轉移，Active掛了小弟開始頂替就完事，FailoverSinkProcessor對應的也是Sink Group，FailoverSinkProcessor可以錯誤恢復的功能（涉及退避算法，如果一個sink掛掉了，會等1s，2s，4s，8s看是否起來，上限是30s，等待時間上限可以通過processor.selector.maxTimeOut配置 ）