数据批量上云方案

近些年传统企业数字化转型十分的火爆，而传统企业数字化一大的痛点就是各个业务系统之间“数据不通”。
包括一直以来的数仓、数据湖、湖仓一体，其中的第一步都是数据汇集。作为企业数据建设的第一步，这个环节做的好坏，直接影响项目的成败，做的少了业务不可用，做的多了白白浪费存储计算成本，以下我们讨论的就是整个数据集中化过程中的方案，欢迎拍砖，微信ukihsoroy。

0x01.上云前准备

一般按照业界通用的做法，数据集中化到数据中心，都会建设一层贴源数据层（与业务系统基本保持一致），该层数据存储时间不用太长一般为（7-15day）为后续数据仓库层建设做数据储备。但考虑每个企业对数据敏感度、安全不一，所以考虑在同步过程可能会考虑一些敏感数据擦除。另外本文重点讨论业务系统数据到ODS（贴源层），数仓建模后面不会再介绍。

1.容量及行数盘点

通过查询数据库information_schema的方式查询，如果DB权限只能手动统计，我们云下数据库是mysql，下面时统计sql样例，替换数据库名字就可以了。

SELECT ISS.SCHEMA_NAME AS 'SCHEMA_NAME',
ITS.TABLE_NAME AS 'TABLE_NAME',
(ITS.DATA_LENGTH / 1024 / 1024) AS 'DATA (MB)',
(ITS.INDEX_LENGTH / 1024 / 1024) AS 'INDEX (MB)',
((ITS.DATA_LENGTH + ITS.INDEX_LENGTH) / 1024 / 1024) AS 'DATA + INDEX (MB)',
ITS.TABLE_ROWS AS 'TOTAL_ROW'
FROM information_schema.`TABLES` ITS
RIGHT JOIN
information_schema.SCHEMATA ISS ON ITS.TABLE_SCHEMA = ISS.SCHEMA_NAME
WHERE ISS.SCHEMA_NAME = ${DATABASE_NAME}
ORDER BY 4 DESC, ISS.SCHEMA_NAME, ITS.TABLE_NAME;

前期统计好需要上云的数据量，才能评估好存储资源需要采购多少，建议按照业务发展1.5-2倍评估存储资源去申请预算（采用云计算的一大优势就是可以随时动态扩容），计算资源可以使用按量付费的方式，后续稳定统一付费。如果需要提前估预算，建议10TB数据，150个Core这样去评估计算资源，给自己留好buffer。

2.统计数据类型

这里可以对全部类型进行测试，确定数据上云后会不会有精度问题，提前预研尽量规避风险，免得后续出现问题反工，我们是通过自动化工具的方式实现的，也可以通过sql去查询information_schema的方式去做。建议预研阶段把数据类型及精度再同步链路、上云后的数据提前测试好，这里我们一开始做的不好，后续出现了大规模反工。

3.统计主键

统计主键主要目的是确定数据上云的切分键，对数据散列均匀避免水桶效应，提高上云效率。起初讨论上云初始阶段不按表粒度区分，就摸底查了客户的数据主键分布情况，客户是老牌保险公司，主键情况很复杂（自增主键、业务主键、联合主键、无主键），后面单独根据每当表选取的切分键。

4.数据脱敏

首先要看是通过直接连业务数据库上云，还是采用ETL以后。这里建议内部先进行ETL，对数据加工后的数据再统一进行同步。

0x02.上云中

1.离线同步

离线同步是一般是通过定时或者手动触发任务的方式同步数据到数据中心。一般分为离线全量、离线增量。

• 离线全量：采用T + n的方式同步一次全量数据，可以删掉历史或者同步到分区中。
• 离线增量：离线全量同步一次以后，后续采用T + n的方式同步增量数据，一般采用入表时间类似字段进行数据筛选同步。
• 数据同步工具方面，基本各大厂商内部都有自己的产品，开源方面可以试试阿里的DataX。

2.实时同步

实时同步是一般采用流或微批（近实时）的方式将数据接入到数据中心。这里把微批的情况也放进实时同步了。

• 流同步：流数据一般采用读取数据库redolog的方式，可以直接通过工具追加到数据中心。
• 微批：微批与流不同的是可以通过设置间隔比较小的方式去查询数据，也可以对接kafka一类的mq，通过Spark streaming将数据写入数据中心。
• 实时链路工具：建议使用kafka作为消息队列，接受数据库数据变化（这方面没有特别成熟的工具，都需要针对性调整）。kafka到数据中心这里，华为使用的是传统的Lambda架构（spark streaming）处理实时部分。而阿里更加倾向使用flink进行批流一体。这方面kapa和lambda都各有优劣，这里就不展开篇幅去讲了，感兴趣可以自行搜索。

3.离线与实时链路衔接

对数据实时性要求比较高的场景，一般涉及离线同步全量，后续数据采用增量的方式汇入。
这种场景一般采用时间字段或者主键的方式去隔离，例如离线同步到今天的凌晨12点，后续的数据采用增量实时接入。也有使用增量同步每一天的数据到实时表中，后续通过离线的方式讲增量数据合入离线同步主表中。

4.同步容错

这部分主要依赖工具及具体任务，如果工具不支持故障重新执行，只能进行手动操作。

离线数据：

• 数据量较少：如果同步任务失败，一般删掉同步表，重新同步。
• 数据量较大：如果是全量同步也只能用上面的本办法，如果离线增量可以删掉增量的数据重新同步。

实时数据：

• 实时数据同步需要保证同步管道容灾，数据消费幂等性，保证数据exactly-once。

5.安全

安全主要关心数据同步链路安全。

• 这里如果对数据敏感度比较高，SSL认证，对数据加密的方式处理。
• 当然，特别敏感的数据建议不上云，或者采用物理移盘的方式。

0x03.上云后

上云后的工作主要有两部分：

• 保证数据同步快速、准确。
• 保证数据同步任务可监控、可回溯。

1.数据同步质量校验

• 对上云总数进行统计比较（需要注意统计的时间窗口）。
• 对上云数据按照类型分组，统计精度是否有问题。
• 这里建议使用工具去进行测试，数据量较大的情况人工会带来比较大的成本。

2.任务运维

• 数据同步任务需要界面去统一管理，方面运维同学进行故障监控，避免产生比较大的生产事故。

0x04.工具

针对这些场景，开发了一个小工具主要包含，上云前的数据盘点，上云后的质量校验，以下是地址：https://github.com/ukihsoroy/Tutorials/tree/master/alibaba/alibaba-data-upload