Gobblin--一个用于Hadoop的统一"数据抽取框架"

一、简介

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主要负责将源数据整合到一系列work units中，并指出对应的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

转：https://blog.csdn.net/lmalds/article/details/53940549