IN科技数据经典课——2、数据采集

前言

本章是《IN科技数据经典课》第二章，本章主要来讲数据采集流程相关内容。若对本课程不太熟悉的同学，可以先看第一章《IN科技数据经典课——1、大数据整体概述》。

概述

数据的生成，有各种方式，不同的应用，不同的组件，都有一套自己的数据管理规则，和数据产生规则。数据采集的目的，就是将分散在各处的数据，进行统一采集回收，方便数据管理。

数据从哪儿来

数据产生方式多样，无法进行更多业务维度的划分，对于数据处理来讲，只关系两大类数据，流式数据和离线数据。

流式数据，又称实时数据。数据像流水一样，不停的涌过来。很难预测规模，体量，也不知道什么时候结束。只能来一条，处理一条。

离线数据，与流式数据相对，指数据已经完成落地存储，不管是哪个应用生成，又存储在了什么位置。总之，只要知道数据路径，就可以完整的将块状数据进行搬运，进行统一管理。

数据怎么采集

一般来讲，大数据系统中的采集系统，需要有独立的采集机来完成，采集工作相对耗时，尤其针对实时采集，需要建立监控，等待数据进行上 ，此类业务，与业务机应进行区分。

在大数据生态中，针对不同源的数据，都有相应的解决方案。下面，我们来一个个进行展开。

日志采集

假设现在某台服务器上，存在一个.log文件，内容是应用服务每日的ip访问序列。需要将.log文件，同步到数据仓库中。我们应该如何处理。

首先，如果该服务器，以授权采集机通过端口可以直接读取文件目录。那么，我们完全采用wget的方式进行抓取。设置调度，控制采集频度。亦可完成我们的需求。

若不开设固定端口访问，可以使用大数据生态中的日志采集工具，flume，或logstash，通过avro协议进行数据上 。

下面以flume为例，进行简要说明。

flume是Apache开源的日志采集系统，新版本flumeNG，在之前flumeOG基础上，进行了修改，增加了易用性，并且进一步提升了性能。

flumeNG主要分为三部分，source，channel，sink。

source指数据源接入，可以进行日志的tail读取，也可接入kafka等消息队列。或者通过avro协议，接收上层数据。随着版本升级，支持的模块越来越多，可去flume的官 查看最新支持。

channel指通道，目的是在上层数据涌入过量的时候，进行数据缓冲处理，避免了下游拥堵。目前主要使用内存和磁盘两种，memory channel数据较快，但是对系统内存占用较大，而且无法保证数据可靠，一旦机器down机，数据无法进行回收。file channel可将数据以文件的形式持久化到磁盘。会有文件记录数据读取位置，即便down机，依旧可以从节点记录从找到行数，继续读。避免了数据重复和丢失的情况。但是，受磁盘IO限制，数据读取较慢，对于大量数据上 时，容易造成数据积压。

sink指消费端，可以指定下游消费模块，可以直接写入hdfs，也可以通过avro协议，传给另一台服务，也可写入kafka等消息队列。支持模块，参见官 说明。

因为flume支持日志tail，因此，可以在日志写入过程中，进行数据逐行抓取，也可满足实时要求。

良好的flume采集架构，一定是每台机器上进行agent采集，然后多collector进行收集，再进行多sink写入。一方面保障系统稳定，另一方面，又提升了并行度，保障写入速度。

既然日志数据可以这么采，那实时数据，有没有别的方式。当然可以。

以点击流为例，用户进行上 ，数据到nginx，nginx可以直接通过模块接入kafka，之后，在kafka消费端完成数据消费写入。kafka亦可接入storm，spark streaming，flink等进行数据实时计算。

数据库同步

若需要将mysql数据库中的数据，同步到数仓中，会有两种场景。

一种是全量同步，将全库表数据，每天全量同步一遍，这种方式，适用于数据库内容较少的情况下，可以按天创建分区，每天都是全量数据。这种方式，好处是简单，全量导入，不需要对内容进行维护。坏处就是会占用大量空间，而且每次导入全库，时间也会比较长。

第二种是增量导出，设置拉链，标记一条数据生命周期的全状态。因为hdfs在读取的过程中，是以文件IO形式顺序读取，因此，无法对中间内容进行修改。因而，若数据库中内容有更新，需读取当日binlog更新内容，进行记录重写。对该数据标记ACTIVE，对旧数据进行HISTORY标记。通过多dt组合，挂出最新数据内容。这种方式，维护成本较高，规则限定较死，好处是，每日可标记增量文件，无需进行全量导入。

在进行数据库同步时，我们可以使用Sqoop进行数据全量导入，可以使用canal。具体使用方式，可以参照对应的工具文档。

数据采集后，如何存储

数据清洗

原始数据采集上来之后，不能直接导入数据仓库，数据由应用服务生成，可能因为未知原因，产生错误数据。那么，制定清洗规则，先筛掉一部分无效数据，既可以节约存储空间，也减少了后续计算的出错率。

常用的清洗规则，包括重点字段非空、字段格式验证、内容准确性验证、数据源验证等。根据不同的业务，制定不同的验证规则。目的就是为了将错误数据，在入仓之前，清洗掉。

数据存储

目前，多数的数据仓库数据落在hdfs上，使用hive来进行内容管理。

hdfs分布式存储系统，利用分布式服务，进行数据存储。避免了数据单一节点存储容量上限的问题，同时还对数据进行备份，避免了数据因设备故障造成的损失。例如：

一份数据data.log，可被切分为data1.log，data2.log，data3.log，分别存放在server1，server2，server3上，同时，每份数据至少存在两台服务器上，这样，确保了某台server出现down机，依旧可以从余下两台服务器上，获得备份数据，得到data.log完整结果。

hdfs的扩充，也非常方便，只需要将新的节点目录，加载配置当中，即可给到hdfs进行管理。

hive是为了方便开发人员的线性数据库的使用习惯，在hdfs开发的线性库表管理工具。数据存储在hdfs上，元数据及库表基本信息存储在mysql，支持SQL语法，对数据进行检索。

当用户在hive上执行sql时，hive会调用后端执行引擎，转成mr，spark，或tez，进行数据检索。检索速度，取决于表大小，和集群计算引擎执行速度。一般情况下，hive的执行速度，要比mysql慢的多的多。因此，才有了后来的OLAP执行引擎。

关于数据存储的更多内容，会在下一章，数据计算引擎中进行展开。

总结

数据采集是整个数据流转的开始一环，无论是后续数据存储、计算、还是etl处理，数据采集出现故障，都会影响后续结果。因此，数据采集侧的agent监控，预警，容错，都需要非常完善，从而确保数据的不丢失。