一、簡介

Gobblin是 LinkedIn在2015年2月開源的、為Hadoop提供的一個數據整合框架。
說到將資料匯入到HDFS，此類的框架包括：

1、Apache Sqoop
2、Apache Flume
3、Aegisthus
4、Morphlines
。。。

其中，Sqoop用於在關係型資料庫（RDBMS）和HDFS之間互相傳輸資料，Flume主要用於對日誌檔案的收集，Aegisthus主要用於從Cassandra抽取資料，而Morphlines則類似於Gobblin中的轉換器，作為外掛配合Sqoop和Flume使用。

然而，相對於其他類似框架，Gobblin的設計有3個主要的目標：

1、普遍性
2、可擴充套件性
3、可操作性

Gobblin支援各種各樣的資料來源，例如RDBMS（Oralce、Mysql、SqlServer）， Espresso，Kafka，RocksDB，S3，Salesforce和Google Analytics等。通過使用同一的Gobblin框架，可以很容易的擴充套件這些資料來源而且讓資料收集工作變得更加簡單和易用。

二、Gobblin架構

2.1 Job元件

Gobblin提供了6個不同的元件介面，因此易於擴充套件並進行定製化開發。
這些元件包括：

1、source
2、extractor
3、convertor
4
 
、quality checker
5、writer
6、publisher

（1）Source主要負責將源資料整合到一系列workunits中，並指出對應的extractor是什麼。這有點類似於Hadoop的InputFormat。

（2）Extractor則通過workunit指定資料來源的資訊，例如kafka，指出topic中每個partition的起始offset，用於本次抽取使用。Gobblin使用了watermark的概念，記錄每次抽取的資料的起始位置資訊。

（3）Converter顧名思義是轉換器的意思，即對抽取的資料進行一些過濾、轉換操作，例如將byte arrays 或者JSON格式的資料轉換為需要輸出的格式。轉換操作也可以將一條資料對映成0條或多條資料（類似於flatmap操作）。

（4）Quality Checker即質量檢測器，有2中型別的checker：record-level和task-level的策略。通過手動策略或可選的策略，將被check的資料輸出到外部檔案或者給出warning。

（5）Writer就是把匯出的資料寫出，但是這裡並不是直接寫出到output file，而是寫到一個緩衝路徑（ staging directory）中。當所有的資料被寫完後，才寫到輸出路徑以便被publisher釋出。Sink的路徑可以包括HDFS或者kafka或者S3中，而格式可以是Avro,Parquet,或者CSV格式。同時Writer也可是根據時間戳，將輸出的檔案輸出到按照“小時”或者“天”命名的目錄中。

（6）Publisher就是根據writer寫出的路徑，將資料輸出到最終的路徑。同時其提供2種提交機制：完全提交和部分提交；如果是完全提交，則需要等到task成功後才pub，如果是部分提交模式，則當task失敗時，有部分在staging directory的資料已經被pub到輸出路徑了。

2.2 儲存狀態

Gobblin存在分支的概念，每一次Job的執行都會將結果持久化到檔案（ SequenceFiles）中，以便下一次執行時可以讀到上次執行的位置資訊（例如offset），本次執行可以從上次offset開始執行本次Job。狀態的儲存會被定期清理，以免出現儲存無限增長的情況。

2.3 執行Job

一旦Job被建立後，runtime就根據Job的部署方式進行執行。Runtime負責job/task的定時執行，狀態管理，錯誤處理以及失敗重試，監控和報告等工作。
對於失敗處理，Gobblin提供了多種級別的重試機制。
對於job的排程，Gobblin可以整合Oozie，Azkaban或者 Chronos。Gobblin同時也支援使用Quartz來排程，其中standalone模式預設的排程器便是Quartz。

2.4 度量和監控

Gobblin的特點之一便是一個端到端的度量資訊的收集系統，其度量庫中包含計數、儀表盤資訊、直方圖等資訊，收集用於監控目的。

2.5 精簡

對於Hive和Mapreduce任務，Gobblin提供了兩分法。舉例來說就是每小時產生一個目錄，之後將這些同一天產生的目錄合併到一個新的目錄中，成為一個高層的以天為單位的目錄。

2.6 部署方式

Gobblin提供了3種部署模式：

1、standalone
2、mapreduce
3、mapreduce on yarn

Job部署在yarn上會非常的靈活而高效，可以執行long-running的Job。跑在Yarn上的額Job，設計上由Apache Helix和和Apache ZooKeeper支援。Helix主要管理container上workunits，zookeeper主要負責元資料資訊的維護。

三、Kafka到HDFS整合（流式抽取）在LinkedIn的實現

Gobblin從Kafka抽取資料，替代了原來的 Camus專案。從Kafka定時抽取資料，通過Job執行在Yarn上，Gobblin可以達到執行一個long-running，流處理的模式。

Source：

每個partition中起始offset都通過Source生成到workunit中；同時，從state中獲取上一次抽取結尾的offset資訊，以便判斷本次Job執行的起始offset。

Extractor：

Extractor會逐個抽取partition的資料，抽取完成一個後，會將末尾offset資訊存到狀態儲存中。

Converter：

LinkedIn內部的Kafka叢集主要儲存Avro格式的資料，並對此進行一些過濾和轉換。

Quality Checker：

LinkedIn中資料都會包含一個時間戳，以便決定放到哪個“小時”目錄和“天”目錄。對於沒有時間戳的資料，則會根據record-level的策略將這些資料寫到外部檔案中。

Writer and Publisher：

內部使用基於時間的writer和基於時間的publisher去寫並pub資料。

四、總結

Gobblin是一個通用的資料整合框架，其可以接收多種不同的資料來源（Kafka，Mysql，RocksDB等），並將這些資料定時寫入HDFS中。易於操作和監控，提供流式抽取支援。

本文主要依據LinkedIn在2015年8月發表的Gobblin的論文中的內容作了部分翻譯和自我的理解，之後的文章會陸續介紹如何在standalone和yarn上部署Gobblin的Job。