在實際生產中，當我們用Flume採集日誌時，由於數據源的多樣性，則往往需要配置多個Flume進行採集，如果只是使用單層Flume的話，那麼往往會產生很多個文件夾，單個文件夾也只是來自同一個節點的數據組成的。而實際開發中，爲了減少HDFS的壓力，同時提高後續MR的處理效率。往往會將同一組多個節點的數據匯聚到同一個文件中，這樣同時也較少了數據從生產到分析的時間。
如下圖，第一次agent負責採集原始數據，第二層agent負責對第一層數據進行匯聚。這種多層代理的方式尤其適合source源數據量龐大的時候，效率會高很多。
注意：1.如果要構建分層的代理結構，必然牽扯到數據的網絡傳輸和分發問題。所以第一層代理需要某種特殊的sink來進行網絡發送事件，再加上相應的source來接受這些事件。Avro sink 通過Avro RPC將事件發送給運行在另一個Flume代理上的其他Avro。事實上Avro的sink和source不提供寫入和讀取Avro文件的能力，它們僅用於代理層是事件分發，並且爲了做到這一點，它們需要通過Avro RPC來進行通信。這裏要區別Avro文件，如果想將事件寫入到Avro文件，則可以使用HDFS sink實現。
2.如果第二層的agent停止運行，那麼事件將被保存到第一層agent的channel中，等到第二層agent的重新啓動。但是channel的存儲是由限制的，如果第一層agent的channel已經填滿數據時，第二層agent還沒啓動恢復運行，那麼任何新採集的事件都會丟失。默認情況下，file channel能夠恢復的事件數量不超過100萬條（可以通過capacity屬性來設置，實際要設置的大一些）,此外，當檢查點checkpointdir的可用磁盤空間小於500M時(minimumRequiredSpace屬性設置)，也將停止接收事件，造成新事件的丟失。
3.不管第一層某個代理還是第二層某個代理一旦有停止運行或者失敗的情況出現，都會出現Flume丟失數據的情況發生。這也是常見開發中，或者面試中常問的Flume數據丟失問題，如果防止丟失？對於這個問題如果是第一層某個代理失敗，那麼可以考慮由第一層的其他節點來接管故障節點。如果是第二層代理停止運行，則爲了防止數據丟失，只能讓每一個第一層代理具有多個冗餘的Avro sink，然後把這些sink安排到同一個sink組中，如果第二層代理中的某個代理出現問題，則該事件會被傳遞給該層sink組的其他代理來完成，以此來實現故障轉移和負載均衡。下面博客繼續sink組的實現。
多層代理的實現：
