上圖的Flume的Architecture，在Flume中，最重要的抽象是data flow(資料流)，data flow描述了資料從產生，傳輸、處理並最終寫入目標的一條路徑。在上圖中，實線描述了data flow。

其中，Agent用於採集資料，agent是flume中產生資料流的地方，同時，agent會將產生的資料流傳輸到collector。對應的，collector用於對資料進行聚合，往往會產生一個更大的流。

　　Flume提供了從console(控制檯)、RPC(Thrift-RPC)、text(檔案)、tail(UNIX tail)、syslog(syslog日誌系統，支援TCP和UDP等2種模式)，exec(命令執行)等資料來源上收集資料的能力。同時，Flume的資料接受方，可以是console(控制檯)、text(檔案)、dfs(HDFS檔案)、RPC(Thrift-RPC)和syslogTCP(TCP syslog日誌系統)等。

　　其中，收集資料有2種主要工作模式，如下：

　　Push Sources：外部系統會主動地將資料推送到Flume中，如RPC、syslog。

　　Polling Sources：Flume到外部系統中獲取資料，一般使用輪詢的方式，如text和exec。

　　注意，在Flume中，agent和collector對應，而source和sink對應。Source和sink強調發送、接受方的特性(如資料格式、編碼等)，而agent和collector關注功能。

　　Flume Master用於管理資料流的配置，如下圖。

為了保證可擴充套件性，Flume採用了多Master的方式。為了保證配置資料的一致性，Flume引入了ZooKeeper，用於儲存配置資料，ZooKeeper本身可保證配置資料的一致性和高可用，另外，在配置資料發生變化時，ZooKeeper可以通知Flume Master節點。

　　Flume Master間使用gossip協議同步資料。

　　下面簡要分析Flume如何支援Reliability、Scalability、Manageability和Extensibility。

　　Reliability：Flume提供3中資料可靠性選項，包括End-to-end、Store on failure和Best effort。其中End-to-end使用了磁碟日誌和接受端Ack的方式，保證Flume接受到的資料會最終到達目的。Store on failure在目的不可用的時候，資料會保持在本地硬碟。和End-to-end不同的是，如果是程序出現問題，Store on failure可能會丟失部分資料。Best effort不做任何QoS保證。

　　Scalability：Flume的3大元件：collector、master和storage tier都是可伸縮的。需要注意的是，Flume中對事件的處理不需要帶狀態，它的Scalability可以很容易實現。

　　Manageability：Flume利用ZooKeeper和gossip，保證配置資料的一致性、高可用。同時，多Master，保證Master可以管理大量的節點。

　　Extensibility：基於Java，使用者可以為Flume新增各種新的功能，如通過繼承Source，使用者可以實現自己的資料接入方式，實現Sink的子類，使用者可以將資料寫往特定目標，同時，通過SinkDecorator，使用者可以對資料進行一定的預處理。