【数据中台建设系列之二】数据中台-数据采集
上篇文章介绍了数据中台的元数据管理，相信大家对元数据模块的设计和开发有了一定的了解，本编文章将介绍数据中台另一个重要的模块—数据采集。
一、什么是数据采集
数据采集简单来说就是从各种数据源中抓取、捕获和传输数据的一个过程。数据采集的质量和效率直接影响到数据的可用性和及时性，进而影响到组织的决策制定和业务运营，因此数据采集是数据中台建设的关键一环，也是数据中台建设不可或缺的一部分。
二、数据采集的基本架构设计
在讨论数据采集模块的架构设计时，我们需要清楚的了解公司的具体业务场景有哪些，数据来源有哪些，对数据的时效性要求有哪些。基于此，构建出来的数据采集架构才能符合每个公司降本增效的目标，毕竟数据采集是数据中台建设中资源开销很大的一块。因此，下图数据采集架构设计是基于本公司的实际生产场景来给大家展现的，供大家参考。
整体数据采集架构有点类Lambda架构，没有把离线和实时同步放在一起，而是单独来处理的。数据主要分为日志数据，埋点数据，业务数据库数据等，我们的数仓采用的是Apache Doris构建的实时数仓。
- 针对日志数据，采用
Flume的方式将数据Sink到Kafka； - 针对埋点和一些其他业务数据，是直接让业务将数据写入到
Kafka中； - 针对业务数据库增量数据，采用的是
Canal和FlinkCDC将数据写入到Kafka中； - 对于同步离线数据库数据，采用的利用
DolphineSchedule里面的Datax来直接抽取，然后写入到Doris中； - 所有实时数据写入到
Kafka以后，通过Flink-ETL来处理数据，最后再采用Doris的StreamLoad将数据写入到Doris中；
看到这问题很多的小明可能会有疑问：
- 为什么用把FlinkCDC采集到的数据写入Kafka中？
其实这样做的目的就是通过Kafka做一层缓冲，Flink消费Kafka中的数据，利用滚动窗口定期攒批，通过StreamLoad将数据写入Doris中。了解Doris的同学可能会知道这是因为Doris数据存储格式类似于LSM Tree结构，如果数据写入过于频繁，可能会引起文件频繁合并，导致机器CPU消耗过高，而通过攒批的方式，可以减少数据导入次数，增大导入条数，对Doris的稳定性有很大的提升。
看到这相信你对这个技术架构已经有了了解了，那整体的功能改怎么设计呢？请继续往下看。
三、基本设计流程
我们既然要设计数据采集模块，那终极目标肯定就是实现零代码入仓。下面就是一个零代码入仓功能设计方案：
-
首先需要创建数据源，这个数据源在元数据管理模块创建，创建完成后，需要手动同步元数据，将元数据中的库表和字段信息全部同步到数据中台侧；
-
新建接入任务时，首先选择数据源，数据库和数据表，选择完整之后再次选择目标数据源，目标数据库和目标数据表；
-
当把源和目标都选择以后，点击表字段映射，字段会通过字段名相等的关系进行映射，如果源字段名和目标表字段名一致，且目标字段的字段长度大于源字段长度时，则会映射成功；如果源字段名和目标字段名不一致，则需要手动指定映射关系。如下图所示，一键映射后，只有
dish_name自动映射成功，其他字段由于字段名不一致，无法成功映射；
-
字段映射完成以后，需要补充一点基本信息，比如子任务的任务名，注释信息，子任务的的Flink的窗口大小，窗口最大条数等，同时可以启动动态清洗功能，需要编辑动态清洗脚本，如下图所示：
-
子任务配置完成以后，可以创建一个组任务，将子任务添加到组任务下面，同时配置组任务中Flink的jobmanager和taskmanager的内存大小。合并任务的目的也是为了提高资源利用率，如下图所示：
-
当组任务创建成功以后，就可以提交任务了，我们采用的是
Flink的Yarn application模式，所有Flink相关的jar包和依赖都放在了HDFS上，当提交任务时，在页面的所有配置信息会生成一个JSON文件，发送给Flink的jar包，Flink在Yarn集群上启动一个任务，开始实时同步任务；
当任务停止后重启时，提供了"根据指定时间启动"和"从上次停止位置启动"两种方式：
- 根据指定时间启动
选择指定时间后，你需要选择一个时间戳，Flink任务将会按照你选定的时间点重新消费Kafka中的数据，这主要是依赖于Flink Source 消费Kafka时，可以指定时间戳的功能来实现的；
- 从上次停止位置启动
该功能依赖于Flink的 savepoint实现。当你上次停止任务时，通过yarncClient接口，获取到Flink任务的一个savepoint地址，下次再重新启动时，将savepoint地址传给Flink任务，Flink会自动从savepoint位置开始重新消费；
四、总结：
本篇文章主要介绍了数据采集功能的架构设计和功能设计，其实在实际开发过程中，远远比当前文档描述的要复杂的多，但大致思路就是这样，希望能够给大家提供一点灵感和思路。
功能的架构设计和功能设计，其实在实际开发过程中，远远比当前文档描述的要复杂的多，但大致思路就是这样，希望能够给大家提供一点灵感和思路。
最后，有兴趣的朋友，欢迎私信交流。
