2.3 大数据采集技术

在大数据的生命周期中，数据采集是第一个环节。大数据的采集主要有4种来源：管理信息系统、Web信息系统、物联网系统和科学实验系统。不同的数据集中可能存在不同的数据结构和模式，如文件、XML树、关系表等，表现为数据的异构性。对多个异构的数据集，需要做进一步的集成处理或整合处理，将来自不同数据集的数据收集、整理、清洗、转换后，生成一个新的数据集，为后续查询和分析处理提供统一的数据视图。下面将对Hadoop生态系统中几种比较流行的数据采集技术进行简单介绍。

2.3.1 Apache Sqoop

随着大数据变得越来越重要，数据管理员们面临着不断增长的将数据从源系统转移到大数据分析系统的需求。Apache Sqoop可以辅助进行这种数据迁移。Sqoop是Apache旗下一款“在Hadoop和关系型数据库服务器之间传送数据”的工具。它可以实现将传统数据库中的数据导入基于Hadoop的HDFS、Hive、HBase等数据存储和管理系统，也可以实现从Hadoop文件系统中将数据导出到关系型数据库中。Sqoop的功能如图2-13所示。

Sqoop 类似于其他 ETL 工具，使用元数据模型来判断数据类型，并在数据从数据源转移到Hadoop 时确保类型安全的数据处理。Sqoop 专为大数据批量传输设计，能够分割数据集，并创建Hadoop任务来处理每个区块。Sqoop有一个非常小的命令集，其中包括导入和导出，可列出数据库和表信息，生成Java类来操纵数据，解析SQL命令及其他一些专门的命令。生成Java类的命令对于在Hadoop中编写Java应用进行数据操作特别有用。SQL 解析命令可以显示执行 SQL 语句的结果，这在搜索新数据库或产生复杂逻辑的查询时非常有用。同时，Sqoop提供不同的数据导出模式（全量导出、增量导出、更新导出），为不同的应用场景提供选择模式。

2.3.2 Apache Flume

Flume是Apache基金会的顶级项目，在加入Apache之前由Cloudera公司开发及维护。它是一个可靠的分布式系统，用于有效地从许多不同的源收集、聚合和移动大量日志数据到一个集中式的数据存储区。但Flume的使用不只限于日志数据，因为数据源可以定制，所以Flume可以被用来传输大量事件数据，包括网络通信数据、社交媒体产生的数据、电子邮件信息等。

图2-14为一个Flume数据流模型，将一个Flume事件定义为一个数据流单元。Flume Agent其实是一个JVM进程，该进程中包含完成任务所需要的各个组件，其中最核心的三个组件是Source、Channel及Sink。

Source 消费由外部源传递给它的事件。外部源以一定的格式发送数据给 Flume，这个格式的定义由目标Flume Source来确定。同样，定义一个Thrift Flume Source接收来自Thrift Sink、Flume Thrift RPC客户端或其他任意客户端（该客户端可以使用任何语言编写，只要满足Flume Thrift协议）的事件。Channel可以理解为缓存区，用来保存从Source获取的数据，直到Sink将数据消费掉。Sink从Channel消费完数据后就会将数据从Channel中清除，随后将数据放到外部存储系统（如HDFS）中，或者发送到其他Flume Agent的Source中。不管是Source，还是Sink，都是异步发送和消费数据的。

Flume可以将多个Agent流串联起来，如图2-15所示。

事件被存储在每个Agent的Channel中。随后，这些事件会被发送到流中的下一个Agent 或设备存储（如 HDFS）中。只有事件已经被存储在下一个 Agent 的 Channel中或设备存储中，当前Channel才会清除该事件。这种机制保证了流在端到端的传输中具有可靠性。Flume使用事务方法（Transactional Approach）来保证事件的可靠传输。在Source和Sink中，将事件的存储及恢复作为事务进行封装，存放事件到Channel中及从Channel中拉取事件均是事务性的。这保证了流中的事件在节点之间传输是可靠的。

事件在Channel中进行，该Channel负责保障事件从故障中恢复。Flume支持一个由本地文件系统支持的持久化文件（文件模式：channel.type="file"）Channel。它也支持内存模式（channel.type="memory"），即将事件保存在内存队列中。显然，内存模式的性能会更好，但是当 Agent 进程无法正常运行时，内存模式下存储在 Channel 中的事件将丢失，无法进行恢复。

2.3.3 Gobblin

Gobblin是一套分布式数据集成框架，旨在简化大数据集成工作当中的各类常见任务，具体包括数据流与批量生态系统的提取、复制、组织与生命周期管理，由LinkedIn贡献给Apache基金会。它目前已成为整合各种数据源的通用型ETL框架，各种数据都可以在这里“一站式”解决ETL过程。它专为大数据采集而设计，易于操作和监控，提供流式抽取支持。Gobblin框架如图2-16所示。

Gobblin支持3种部署方式，分别是Standalone、MapReduce和MapReduce on YARN，可以方便快捷地与Hadoop进行集成，运行时有任务调度和状态管理功能，对于失败的任务还提供多种级别的重试机制，可以充分保证数据抽取的可靠性。最上层由6大组件组成执行单元。这6大组件的设计也正是Gobblin高度可扩展的原因。

这6大组件分别是Source、Extractor、Converter、Quality Checker、Writer和Publisher。其中，Source主要负责将源数据整合到一系列Workunit中，并指出对应的Extractor是什么。Extractor则通过Workunit指定数据源的信息，如Kafka，指出Topic中每个Partition的起始Offset，供本次抽取使用。

Gobblin使用了Watermark的概念，记录每次抽取的数据的起始位置信息。Converter是转换器，即对抽取的数据进行一些过滤、转换操作，如将JSON格式的数据转换为需要输出的格式，转换操作也可以将一条数据映射成0条或多条数据。Quality Checker即质量检测器，有两种类型的检测器：Record-level和Task-level。通过手动策略或可选策略，将被检测的数据输出到外部文件或输出路径中给出警告。

Writer 用于把导出的数据写出，但这里并不是直接写到输出路径中，而是写到一个缓冲路径（Staging Directory）中。当所有的数据被写完后，才写到输出路径，以便被Publisher发布。Sink的路径可以包括HDFS、Kafka、S3，而格式可以是Avro、Parquet、CSV格式。同时，Writer可根据时间戳，将文件输出到按照“小时”或“天”命名的目录中。

Publisher根据Writer写出的路径，将数据输出到最终的路径。其提供两种提交机制：完全提交和部分提交。如果是完全提交，则需要等到 Task 成功后才提交数据。如果是部分提交，则当Task失败时，有部分在Staging Directory中的数据已经被提交到输出路径。