flume的基本概念，資料流模型，flume資料流

flume的基本概念，資料流模型，flume資料流
1.flume的基本概念

本文中所有與flume相關術語都採用斜體英文表示，這些術語的含義如下所示。

flume             一個可靠的，分布式的，用於採集，彙總，傳輸海量日誌資料的系統。

Web Server   一個產生 Events 的系統。

Agent            flume 系統中的一個節點，它主要包含三個組件：Source, Channel, Sink。

Event            事件，在 flume-agent 內部傳輸的資料結構。一個 Event 由 Map<String, String>Headers 和 byte[] body 組成，其中 Headers 儲存了 Event 的屬性，body 儲存了 Event 的內容。

Source         Agent Source 用來接收 WebServer 產生的 Events，以及其他 flume-agent 中的 Sink 產生的 Events。

Channel       Source 將 Events 放在 Channel 中儲存，Channel 主要有兩種，是 MemoryChannel 和 FileChannel，分別將 Events 存放在記憶體中和檔案中。

Sink              Sink 用來消費 Channel 內儲存的 Events，然後將 Events 發送出去。

Sinkgroups   將多個 Sink 組合在一起，形成 Sinkgroups。

HDFS           HadoopDistributed File System，它用來儲存日誌資料，也就是 Sinks 發送出來的 Events。

2. flume的資料流模型(1) 單 Agent 資料流模型

如1所示，單個 Agent 主要包括三個組件：Source, Channel, Sink。

  圖1  單Agent的資料流模型

整個資料流如下：

Web Server       產生 Events，並將 Events 發送到 Source 中。

Source              接收 Events，並將 Events 發送到 Channel 中。

Channel            儲存 Events。

Sink                   消費Channel 中儲存的 Events，並將 Events 發送到 HDFS。

HDFS                磁碟儲存 Events。

(2)多  Agent 串列傳輸資料流模型

2所示，兩個 Agent 組成的資料流傳輸模型。

                                                           圖2： 兩個 Agent 串列傳輸資料流模型

整個資料流如下：

Agent foo     Agent foo 中的 Source 接收外部 Events，儲存到 Channel 中，Sink 從 Channel 中擷取 Events，再將 Events 傳輸到 Agent bar 的 Source 中。

Agent bar    Agent bar 中的 Source 接收 Agent foo 的 Sink 發送的 Events，儲存到 bar Channel，再由 bar Sink消費。

整個資料流只做了一件事，就是傳輸資料。

(3)收集資料流模型

3所示，Agent1，Agent2，Agent3負責從不同的 Web Server 中接收 Events，並將 Events 發送到 Agent4，Agent4 再將 Events 發送到 HDFS。

                                                                圖3：收集資料流模型

整個資料流如下：

Agent1      接收 Events，並將 Events 傳輸到Agent4。

Agent2      接收 Events，並將 Events 傳輸到Agent4。

Agent3      接收 Events，並將 Events 傳輸到Agent4。

Agent4      接收 Agent1，Agent2，Agent3 的 Events，然後將 Events 儲存到 HDFS。

整個資料流完成的功能：不同的 Agent 收集不同的 Web Server 產生的日誌資料，並將所有的日誌資料存放區到一個目的地 HDFS。

(4)多路資料流模型

一個 Agent 中可以由一個 Source ，多個 Channels ，多個 Sinks 組成多路資料流，其多路資料流模型如4所示。

一個 Source 接收外部 Events，並將 Events 發送到三路 Channel 中去，然後不同的 Sink 消費不同的 Channel 內的 Events ，再將 Events 進行不同的處理。

Source 如何將 Events 發送到不同的 Channel 中？這裡 flume 採用了兩種不同的策略，是 replicating 和 multiplexing 。

其中 replicating 是 Source 將每個 Event 都發送到 Channel 中，這樣就將 Events 複製成 3 份發到不同的地方去。

其中 multiplexing 是 Source 根據一些映射關係，將不同種類的 Event 發送到不同的 Channel 中去，即將所有 Events 分成3份，分別發送到三個 Channels。

                                                     圖4 多路資料流模型

整個資料流如下：

Agent foo         Source 將接收到的 Events 發送到 Channel1--Sink1--HDFS，Channel2--Sink2--JMS，Channel3--Sink3--Agent bar

Agent bar         Source 接收 Agent foo 中 Sink3 發送的 Events，然後發送到 Channel4--Sink

(5) Sinkgroups資料流模型

現在考慮這樣兩個問題，一是 某 Sink 負責消費某 Channel 中的 Events，那麼如果該 Sink 掛掉之後， 該 Channel 則會堵死。

二是 某 Sink 負責消費某 Channel 中的 Events，那麼如果該 Sink 速度慢，或者該 Sink 的消費能力達不到 Source 的接收能力呢？ 大量的 Events 會在 Channel 中堆積，造成堵塞。

為瞭解決這兩種情況，flume 中存在一種資料流模型，將多個 Sinks 綁定在一起，形成 Sinkgroups，它們共同負責消費某個 Channel 內的 Events。

但是在某個時刻，只有一個 Sink 消費 Channel 內的 Events，於是有兩種策略保證從 Sinkgroups 中選擇出一個 Sink 來消費 Channel 中的 Events。

這兩種策略分別是：failover 和 load_balance。其中 failover 機制，會將所有 Sinks 標識一個優先順序，一個以優先順序為序的 Map 儲存著 活著的 Sink，一個隊列儲存著 失敗的 Sink。

每次都會選擇優先順序最高的活著的 Sink 來消費 Channel 的 Events。每過一段時間就對失敗隊列中的 Sinks 進行檢測，如果變活之後，就將其插進 活著的 Sink Map。

另一種 load_balance機制，在這種機制下，還有兩種不同的策略，分別是 round_robin 和 random。則 round_robin 就是不斷地輪詢 Sinkgroups 內的 Sinks，已保證均衡。

random 則是從 Sinkgroups 中的 Sinks 隨機播放一個。

該資料流模型如5所示。

                                          圖5 Sinkgroups資料流模型

整個資料流如下：

Source          負責接收 Events，並將其發送到 Channel 中。

Channel        負責儲存 Events。

Sinkgroups   負責消費 Channel 中的 Events，並將 Events 發送到 HDFS 儲存。

(6)單  Agent，多條資料流

如6所示，在單個 Agent 中，可以由多個 Sources，Channels，Sinks 組成多條完全不相交的資料流。

                                          圖6 

整個資料流如下：

Source1 Channel1 Sink1 HDFS1  組成資料流1

Source2 Channel2 Sink2 HDFS2 組成資料流2

資料流1和資料流2完全不相關。

(7)各種各樣的資料流模型

從上面介紹的6種不同的資料流模型中，我們可以得知，模型1和模型2相當於程式設計中的順序執行。

模型3中 Agent1，Agent2，Agent3 收集 Events 處於並行狀態，向 Agent4 發送 Events 處於並髮狀態。

模型4 相當於程式設計中的 if--else，選擇模型。

模型5中 三個 Sinks 也相當於處於並髮狀態。

模型6 相當於程式設計中的 並行模型。

則通過這6種不同的資料流模型，我們可以將它們進行不同的組合，形成各種各樣的資料流模型，以應付我們的需求。

3. 解析資料流模型

不同的資料流模型，具有不同的功能，但是這些資料流模型是靠哪些組件，哪些策略來構成的。本節將分析不同的資料流模型在 Agent 內部是如何?的。

(1)   Agent 內部組件架構

如6所示，這是 Agent 內部一個比較完整的架構圖，它不僅僅包含了 Source, Channel, Sink，還包含了 SinkRunner, Interceptor, ChannelSelector, Transaction,

SinkRunner, SinkProcessor, SinkSelector。下面我們將詳細介紹每個組件在 Agent 內部所承擔的責任。

                                                                圖6 Agent 內部組件架構圖

從途中可以看出，將整個資料流分成兩階段，分別是第一階段：Source --> Channel， 第二階段： Channel --> Sink。

下面就從這兩個階段來詳細介紹各個組件在資料流過程中承擔的責任。

(2) 第一階段

圖6既是資料流圖，也是對象結構圖。可以看出，一個 SourceRunner 對象包含一個 Source 對象，一個 Source 對象包含一個 ChannelProcessor對象，

一個 ChannelProcessor 對象包含 多個 Interceptor 對象和一個 ChannelSelector 對象。

首先 SourceRunner 負責啟動 Source， 則 Source 監控是否有 Events 發送過來，如果有，則接收 Events。

其次 Events 被 ChannelProcessor 中的 Interceptor 進行過濾，Interceptor 的功能有三種，分別是 丟棄 Event，修改 Event 再返回，直接返回 Event（不做任何操作）。

舉例：Interceptor 有兩種比較好理解的，分別是 Timestamp Interceptor 和 host Interceptor，Timestamp Interceptor 會對每個 Event 的添加屬性時間戳記， host Interceptor會為

每個 Event 添加屬性 host 。

然後，ChannelSelector 的主要功能是完成上面的多路資料流模型，分別有兩種，replicating 和 multiplexing。也就是說 ChannelSelector 為每個 Event 選擇它所要發送到的 Channel。

在 replicating 模式下，每個 Event 都被發送到 多個 Channel 中；在 multiplexing 模式下，不同的 Events 會被發送到不同的 Channel 中。

最後，Source 與每個 Channel 通過 Transaction 建立串連，將 Events 發送到 Channel 中去。

(3)第二階段

可以看出，一個 SinkRunner 對象包含一個 SinkProcessor 對象，一個 SinkProcessor 對象包含多個 Sinks 和/或 一個 SinkSelector。

首先 SinkRunner 啟動一個 SinkProcessor 對象，SinkProcessor 有三種，分別是 DefaultSinkProcessor，FailoverSinkProcessor，LoadBalancingSinkProcessor。

看到這裡你是不是有點印象了，對，這就是我們上面提到的 Sinkgroups 資料流模型。如果單個 Sink 的話，則使用 DefaultSinkProcessor，它負責啟動 Sink；

如果多個 Sinks 組成一組的話，則可以設定 SinkProcessor 為 failover 或 loadBalance。

其中 FailoverSinkProcessor 會將各個 Sink 設定優先權。儲存了一個 SortedMap<Integer, Sink> liveSinks，活著的 Sinks，一個 Queue<FailedSink> failedSinks，儲存死的 Sinks。

每次會從 liveSinks 中選擇一個優先順序最高的 Sink 來消費 Events。如果某個 Sink 掛掉，則將其放在 failedSinks裡，並且每次都嘗試 failedSinks中的第一個 Sink，如果它能變活，則將其

轉到 liveSinks 中。其中 LoadBalancingSinkProcessor 裡有一個對象 SinkSelector，該 SinkSelector 有兩種，分別是 round_robin 和 random。這裡你又有印象啦。則 SinkSelector 就是在 Sinkgroups 中

選擇某個 Sink 來消費 Events。 round_robin 是輪詢 Sinkgroups 中的所有 Sinks, random 是從 Sinkgroups 中隨機播放 某個 Sink。

其次，SinkProcessor 會選擇某個 Sink，啟動 Sink。

最後，Sink 與 Channel 通過 Transaction 建立串連。消費 Channel 內的 Events。

(16) 資料流圖用於抽象描述一個軟體的邏輯模型，資料流圖由一些特定的圖符構成下列圖符名標識的圖符不屬

（16）[答案]A
[考點]軟體工程基礎
[評析]
資料流圖用於需求分析階段，在此階段我們只考慮大致的資料流流向，而不關心內部具體的處理，以及如何在電腦上實現，不必討論控制流程，我們只關心的：資料流、資料儲存、變換/加工（相當於一個黑盒，不關心內部細節）、外部實體，資料流圖通俗易懂，因為它遠離了電腦，使用者（無需懂編程）和軟體人員都易接受。
比如一個簡單的軟體系統邏輯模型：

輸入資料流和輸出資料流即D中的源和潭
 
1、 什是資料流圖？其作用是什？其中的基本符號各表示什含義？

資料流圖：簡稱DFD，就是採用圖形方式來表達系統的邏輯功能、資料在系統內部的邏輯流向和邏輯變換過程，是結構化系統分析方法的主要表達工具及用於表示軟體模型的一種圖示方法。
　　資料流圖的基本符號的意思：
　　1.矩形表示資料的外部實體；
　　2.圓角的矩形表示變換資料的處理邏輯；
　　3.少右面的邊矩形表示資料的儲存；
　　4.箭頭表示資料流。
　　資料流程圖中有以下幾種主要元素：
　　→：資料流。資料流是資料在系統內傳播的路徑，因此由一組成分固定的資料群組成。如訂票單由旅客姓名、年齡、單位、社會安全號碼、日期、目的地等資料項目組成。由於資料流是流動中的資料，所以必須有流向，除了與資料存放區之間的資料流不用命名外，資料流應該用名詞或名詞短語命名。
　　□：資料來源（終點）。代表系統之外的實體，可以是人、物或其他軟體系統。
　　○：對資料的加工（處理）。加工是對資料進行處理的單元，它接收一定的資料輸入，對其進行處理，併產生輸出。
　　〓：資料存放區。表示資訊的靜態儲存，可以代表檔案、檔案的一部分、資料庫的元素等。