Flume_Sink

概述

從Flume Agent移除數據並寫入到另一個Agent或數據存儲或一些其他存儲系統的組件被稱爲sink。Sink不斷的輪詢channel中的事件且批量的移除它們。這些事件批量寫入到存儲或索引系統，或者被髮送到另一個Flume Agent。Sink是完全事務性的。在從channel批量移除數據之前，每個sink用channel啓動一個事務。批量事件一旦成功寫出到存儲系統或下一個Flume Agent，sink就利用channel提交事務。事務一旦被提交，該channel從自己的內部緩衝區刪除事件。
sink的生命週期

·每個sink至少有一個正確配置的channel連接它
·每個sink有一個定義的type參數
·sink是在Agent中sink活躍列表中的
Flume可以聚合線程到sink組，每個sink組可以包含一個或多個sink。如果一個sink沒有定義分組，那麼該sink可以被認爲是在一個組內，且該sink是組內的唯一成員。
每個sink運行器運行一個sink組，sink運行器是一個針對sink組循環調用process方法的線程，依次轉發調用到組裏其中一個sink的process方法。
類似於其他所有的組件（除了Memory Channel），當Flume被重新配置，sink的實例是不會被重用的。因此，sink不應該緩衝任何已被讀取和提交的事件。這是因爲提交事務表明channel可以刪除在事務的上下文中讀取的事件。
優化sink的性能

當個別sink比寫入到指定channel的速率要慢很多時，那就值得添加更多sink用來寫入到相同目的地和從相同channel讀取事件。當增加sink數量來提升性能時，必須確保的一點是資源不會因過度使用而結束，創建有太多上下文切換或網絡的情況下將導致阻塞。
HDFS Sink

可以基於事件的報頭、事件的時間戳等配置寫入到不同的目錄。HDFS Sink支持Hadoop1和Hadoop2,但是代碼必須針對Hadoop的相關版本進行特定的編譯，這是因爲在Hadoop1和Hadoop2之間二進制不兼容性變化。

HDFS Sink將數據寫到HDFS的bucket。實際上，一個bucket就是一個目錄。一個HDFS Sink可以同時將數據寫到多個bucket中，但是一個事件將只進入到一個bucket中。無論任何時候每個bucket最多隻有一個文件打開，但每個sink在不同的bucket裏可以打開若干文件。Flume允許用戶基於配置文件中不同指定參數動態創建bucket。HDFS Sink批量處理事件，在一個批處理中刷新所有的事件到HDFS中。如果一個事件再次被寫入到同一個bucket，那麼sink將會創建一個新的文件。
理解bucket

HDFS Sink使用幾個參數創建bucket路徑。爲了動態創建這些路徑，配置文件必須指明路徑爲hdfs.path參數。該路徑可以指定一個或多個sink將取代的轉義序列，用來構造寫事件的真實路徑。

當HDFS Sink從channel讀取一個事件，它讀取主體報頭的值，並利用配置參數，將路徑的轉義序列替換爲指定主體報頭的值。HDFS Sink提供了很強大的時間戳的轉義。它支持幾個使用時間戳事件報頭值的轉移序列。多個轉移序列可以在相同的路徑中使用：

這個例子對於每一個主題，將把所有時間戳爲相同小時的事件寫到相同目錄內。

使用該配置，用戶可以每10分鐘就有一個bucket
使用序列化器控制數據格式

序列化類必須實現EventSerrializer接口。
Flume內置了三類序列化器：TEXT序列化器、HEADER_AND_TEXT序列化器、AVRO_EVENT序列化器。
TEXT序列化器以事件主體本身寫入到文件，可以根據需要在事件之間插入新的一行。
HEADER_AND_TEXT序列化器也做相同的事情，但也包括“key=value”格式的事件報頭。默認會在事件之間插入新的一行。這可以通過將appendNewline的值設置爲false來禁用：

AVRO_EVENT序列化器使用下面所示的模式，將事件寫出爲Avro container文件：
HBase Sink

Flume有兩類HBase Sink：HBase Sink和Async HBase Sink。HBase客戶端API是阻塞的，所以HBase Sink逐個向HBase集羣發送事件。Async HBase API是非阻塞的且使用多線程寫數據到HBase。所以，大多數情況下，Async HBase Sink有可能給出更好的性能。但是HBase Sink支持安全HBase，Async HBase不支持。這兩個HBase sink都是批量寫事件
RPC Sink

如果從一個Flume Agent發送數據到另一個Agent，那麼要使用RPC Sink。RPC Sink和對應的RPC Source使用相同的RPC協議。Flume支持兩種RPC系統：Avro和Thrift，Avro被認爲是Flume主要的RPC格式。
Avro Sink使用Avro的Netty-based RPC協議發送數據到Avro Source。Avro Sink可以批量發送事件到Avro Source。
Thrift Sink可以用來在FlumeAgent之間使用Thrift RPC進行通信。Thrift Sink跟Avro Sink很像，但它缺少壓縮和SSL功能。在Flume Agent之間推薦使用Avro RPC通信。
Morphline Solr Sink

Morphlines是一個高度可擴展的ETL框架，幾個命令可以連在一起，且使一個命令的輸出作爲下一個命令的輸入，來執行數據的重量級轉換。Morphline Solr Sink整合Morphline框架和提供Sink的Flume，可以從Flume管道傳輸數據到Morphline，最終加載事件到Solr索引。
Morphline庫提供了一個稱爲loadSolr的命令，可以加載記錄到solr。
Elastic Search Sink

Flume可以使用Elastic Search Sink實時加載數據到Elastic Search來創建索引。
其他sink

①Null Sink
用於從channel讀取事件並刪除它們。這類sink的目的是檢測其餘agent的功能和特性。Null Sink批量地從channel移除事件並更新日誌文件。

②Rolling File Sink
Rolling File Sink寫事件到本地文件系統。

③Logger Sink
Logger Sink記錄到log4j.properties文件中配置的Flume Agent的log4j日誌文件。該Sink所有的配置都從log4j.properties文件中獲取，且它不需要任何其他的參數。
編寫自定義Sink

自定義Sink必須實現Sink接口，如果Sink需要接受來自配置系統的配置，那麼可以選擇實現Configurable接口。爲了更好地理解如何編寫一個Sink，很重的是要理解Flume框架如何與Sink交互。

當Agent 啓動時，框架檢查來確保每個Sink 有一個指定的type，且有一Channel 參數的值代表了Agent 中已經存在的配置合適的Channel.然後Sink 被實例化且配置傳遞給它的configure方法。如果configure方法失敗且拋出異常，那麼該Sink 會從Agent 中移除且刪除它的實例。一且Sink 成功配置，它就連接到應該從其中讀取事件的Channel.

從那時起，Sink由一個Sink 運行器管理。Sink 運行器只是一個負責運行該Sink的線程。框架通過調用start方法來啓動Sink。如果start失敗，該框架將反覆重試啓動Sink.

一旦Sink 啓動，Sink運行器線程就循環調用process 方法。該方法負責從Channel 讀取數據並寫出到下一階段或最終目的地。每個process 調用必須處理整個事務——啓動事務，從Channel讀取事件，提交或回滾事務，並最終關閉事務。如果Channel 不包含任何Sink可以移除的事件，process方法必須返回Status.BACKOFF,這使得Sink 運行器只在一個時間間隔後重試。如果Sink 成功，它必須返同Status.READY狀態，且運行器將立即再次調用process 方法。

當從Channel讀取數據或寫入到目的地時，如果遇到一些異常，sink 必須返同status.BACKOFF狀態或拋出異常以報告失敗。這使Sink 運行器減慢速度，如果不能消除下流Agent或最終目的地的數據，這也是避免發送數據到下一階段的調節機制。在Flume框架中，爲了正確地運行，process方法必須是線程安全的。