數據採集框架Gobblin簡介

問題導讀：
Gobblin的架構設計是怎樣的？
Gobblin擁有哪些組建，如何實現可擴展？
Gobblin採集執行流程的過程？

前面咱們介紹Gobblin是用來整合各類數據源的通用型ETL框架，在某種意義上，各類數據均可以在這裏「一站式」的解決ETL整個過程，專爲大數據採集而生，易於操做和監控，提供流式抽取支持。

號稱整合各類數據源「一站式」解決ETL整個過程的架構究竟是怎樣的呢？沒圖說個X。

Gobblin架構圖

從Gobblin的架構圖來看，Gobblin的功能真的是很是的全。底層支持三種部署方式，分別是standalone，mapreduce，mapreduce on yarn。能夠方便快捷的與Hadoop進行集成，上層有運行時任務調度和狀態管理層，能夠與Oozie，Azkaban進行整合，同時也支持使用Quartz來調度（standalone模式默認使用Quartz進行調度）。對於失敗的任務還擁有多種級別的重試機制，能夠充分知足咱們的需求。再上層呢就是由6大組件組成的執行單元了。這6大組件的設計也正是Gobblin高度可擴展的緣由。

Gobblin組件

Gobblin提供了6個不一樣的組件接口，所以易於擴展並進行定製化開發。分別是：

• source
• extractor
• convertor
• quality checker
• writer
• publisher

Source主要負責將源數據整合到一系列workunits中，並指出對應的extractor是什麼。這有點相似於Hadoop的InputFormat。

Extractor則經過workunit指定數據源的信息，例如kafka，指出topic中每一個partition的起始offset，用於本次抽取使用。Gobblin使用了watermark的概念，記錄每次抽取的數據的起始位置信息。

Converter顧名思義是轉換器的意思，即對抽取的數據進行一些過濾、轉換操做，例如將byte arrays 或者JSON格式的數據轉換爲須要輸出的格式。轉換操做也能夠將一條數據映射成0條或多條數據（相似於flatmap操做）。

Quality Checker即質量檢測器，有2中類型的checker：record-level和task-level的策略。經過手動策略或可選的策略，將被check的數據輸出到外部文件或者給出warning。

Writer就是把導出的數據寫出，可是這裏並非直接寫出到output file，而是寫到一個緩衝路徑（ staging directory）中。當全部的數據被寫完後，才寫到輸出路徑以便被publisher發佈。Sink的路徑能夠包括HDFS或者kafka或者S3中，而格式能夠是Avro,Parquet,或者CSV格式。同時Writer也但是根據時間戳，將輸出的文件輸出到按照「小時」或者「天」命名的目錄中。

Publisher就是根據writer寫出的路徑，將數據輸出到最終的路徑。同時其提供2種提交機制：徹底提交和部分提交；若是是徹底提交，則須要等到task成功後才pub，若是是部分提交模式，則當task失敗時，有部分在staging directory的數據已經被pub到輸出路徑了。

Gobblin執行流程

Job被建立後，Runtime就根據Job的部署方式進行執行。Runtime負責job/task的定時執行，狀態管理，錯誤處理以及失敗重試，監控和報告等工做。Gobblin存在分支的概念，從數據源獲取的數據由不一樣的分支進行處理。每一個分支均可以有本身的Converter，Quality Checker，Writer和Publisher。所以各個分支能夠按不一樣的結構發佈到不一樣的目標地址。單個分支任務失敗不會影響其餘分支。 同時每一次Job的執行都會將結果持久化到文件（ SequenceFiles）中，以便下一次執行時能夠讀到上次執行的位置信息（例如offset），本次執行能夠從上次offset開始執行本次Job。狀態的存儲會被按期清理，以避免出現存儲無限增加的狀況。

Kafka to HDFS 示例

Gobblin的官方論文上給了一個Kafka數據抽取到HDFS的示例，經過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數據。

問：新增數據採集如何處理呢？？？
選（kai）擇（fa）對應的六大組件，配置採集配置文件便可。so easy~~（下篇詳解）

歡迎關注我：叄金大數據（不穩定持續更新~~~）