共计 2640 个字符，预计需要花费 7 分钟才能阅读完成。
近些年传统企业数字化转型非常的火爆，而传统企业数字化一大的痛点就是各个业务零碎之间“数据不通”。
包含始终以来的数仓、数据湖、湖仓一体，其中的第一步都是数据会集。作为企业数据建设的第一步，这个环节做的好坏，间接影响我的项目的成败，做的少了业务不可用，做的多了白白浪费存储计算成本，以下咱们探讨的就是整个数据集中化过程中的计划，欢送拍砖，微信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
