一、Flume 組成、Put 事務、Take 事務
Taildir Source：斷點續傳、多目錄。Flume1.6 以前需要自己自定義 Source 記錄每次讀取文件位置，實現斷點續傳。
File Channel：數據存儲在磁盤，宕機數據可以保存。但是傳輸速率慢。適合對數據傳輸可靠性要求高的場景，比如，金融行業。
Memory Channel：數據存儲在內存中，宕機數據丟失。傳輸速率快。適合對數據傳輸可靠性要求不高的場景，比如，普通的日誌數據。
Kafka Channel：減少了 Flume 的 Sink 階段，提高了傳輸效率。
Source 到 Channel 是 Put 事務
Channel 到 Sink 是 Take 事務
二、自定義攔截器步驟
1、實現 Interceptor
2、重寫四個方法
(1) initialize 初始化
(2) public Event intercept(Event evrnt) 處理單個 Event
(3) public List intercept(List events) 處理多個 Event，在這個
方法中調用 Event intercept(Event event)
(4) close 方法
3、靜態內部類，實現 Interceptor.Builder
三、Flume Channel 選擇器
四、Flume 監控器
Ganglia
五、Flume 內存
開發中在 flume-env.sh 中設置 JVM heap 爲 4G 或更高，部署在單獨的服務器上(4 核 8 線程 16G 內存)，-Xmx 與 -Xms 最好設置一致，減少內存抖動帶來的性能影響，如果設置不一致容易導致頻繁 fullgc。
六、FileChannel 優化
通過配置 dataDirs 指向多個路徑，每個路徑對應不同的硬盤，增大 Flume 吞吐量。 checkpointDir 和 backupCheckpointDir 也儘量配置在不同硬盤對應的目錄中，保證 checkpoint 壞掉後，可以快速使用 backupCheckpointDir 恢復數據。
七、HDFS Sink 小文件處理
1、HDFS 存入大量小文件，有什麼影響？
元數據層面：每個小文件都有一份元數據，其中包括文件路徑，文件名，所有者，所屬組，權限，創建時間等，這些信息都保存在 Namenode 內存中。所以小文件過多，會佔用 Namenode 服務器大量內存，影響 Namenode 性能和使用壽命。
計算層面：默認情況下 MR 會對每個小文件啓用一個 Map 任務計算，非常影響計算性
能。同時也影響磁盤尋址時間。
2、HDFS 小文件處理
官方默認的這三個參數配置寫入HDFS 後會產生小文件，hdfs.rollInterval、hdfs.rollSize、
hdfs.rollCount
基於以上 hdfs.rollInterval=3600 ， hdfs.rollSize=134217728 ， hdfs.rollCount =0 ，
hdfs.roundValue=3600，hdfs.roundUnit= second 幾個參數綜合作用，效果如下：
A、tmp 文件在達到 128M 時會滾動生成正式文件
B、tmp 文件創建超 3600 秒時會滾動生成正式文件
舉例：在 2018-01-01 05:23 的時侯 sink 接收到數據，那會產生如下 tmp 文件：
/atguigu/20180101/atguigu.201801010520.tmp
即使文件內容沒有達到 128M，也會在 06:23 時滾動生成正式文件