共计 2603 个字符，预计需要花费 7 分钟才能阅读完成。
简介：DataX 在数据迁徙中的利用
- DataX 定义
===========
首先简略介绍下 datax 是什么。
DataX 是阿里巴巴团体内被宽泛应用的离线数据同步工具 / 平台，实现包含 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步性能。
- DataX 商业版本
==============
阿里云 DataWorks 数据集成是 DataX 团队在阿里云上的商业化产品，致力于提供简单网络环境下、丰盛的异构数据源之间高速稳固的数据挪动能力，以及繁冗业务背景下的数据同步解决方案。目前曾经反对云上近 3000 家客户，单日同步数据超过 3 万亿条。DataWorks 数据集成目前反对离线 50+ 种数据源，能够进行整库迁徙、批量上云、增量同步、分库分表等各类同步解决方案。2020 年更新实时同步能力，反对 10+ 种数据源的读写任意组合。提供 MySQL，Oracle 等多种数据源到阿里云 MaxCompute，Hologres 等大数据引擎的一键全增量同步解决方案。
对于 datax 的 git 地址，可参考文后材料理解详情[1]。
2.1 利用案例
接下来介绍下咱们在两个我的项目上的利用案例。
2.1.1 案例一 通过 datax 帮助剖析数据同步链路
客户某 oracle 数据库在迁徙上云过程中，应用了某封装好的产品，然而传输效率始终很低，只有 6M/s。客户始终狐疑是云内 vpc 网络瓶颈或 rds 数据库瓶颈导致，然而实际上，云内网络以及数据库整体处于非常低的负载状态。
因为客户侧的传输工具咱们不不便间接拿来测试，所以在 ecs 上长期部署了 datax，来做剖析和对照测试；
测试后果如下图所示。
图 1：测试后果
罕用的优化参数介绍如下：
1. 通道（channel）– 并发
- 通过测试可知，channel 的设置对传输效率的影响较为显著，上述试验中，所有设置为 1 的，即没有并发的状况下，同步速度均为 8.9M/s；将该设置调高之后，速率显著倍增，但增大到肯定水平后，瓶颈点就转到其余配置了；
2. 切片（splitpk）
Git 官网介绍如下：
- 形容：MysqlReader 进行数据抽取时，如果指定 splitPk，示意用户心愿应用 splitPk 代表的字段进行数据分片，Datax 因而会启动并发工作进行数据同步，这样能够大大提高数据同步的效力。
- 举荐 splitPk 用户应用表主键，因为表主键通常状况下比拟平均，因而切分进去的分片也不容易呈现数据热点。
目前 splitPk 仅反对整形数据切分，不反对浮点、字符串、日期等其余类型。如果用户指定其余非反对类型，MysqlReader 将报错。
如果 splitPk 不填写，包含不提供 splitPk 或者 splitPk 值为空，DataX 视作应用单通道同步该表数据。 - 必选：否
- 默认值：空
实际上，由测试后果可知，切片是要配合 channel 来应用的，如果只开了 splitpk，然而 channel 的配置为 1，同样不会有并发的成果；
3.Batchsize
Git 官网介绍如下：
- 形容：一次性批量提交的记录数大小，该值能够极大缩小 DataX 与 Mysql 的网络交互次数，并晋升整体吞吐量。然而该值设置过大可能会造成 DataX 运行过程 OOM 状况。
- 必选：否
- 默认值：1024
现场的理论测试成果不显著，次要起因是数据量较小，1c1g 配置时，适当进步 batch 能够晋升同步速度。
其余还有很多参数，有待小伙伴们去逐个挖掘，或者下次咱们用到再给大家分享；
由测试后果可知，我的项目应用的工具只能同步 6m 的速率，必定是远远有余的，性能瓶颈既不在网络上，也不在数据库上，咱们只做了局部测试，就发现 4c16g 的数据库轻轻松松就能达到 27M 的同步速率。
2.1.2 案例二 datax 在数据同步实战中的利用
该案例是客户两朵云之间的数据迁徙，客户新建了一朵云，须要把前一朵云上的数据迁徙过来；
计划如下：
图 2：计划
2.2 部署形式
Datax 自身无主动集群化部署，须要逐台手工部署；
15 台 v2 的物理机，空余内存均在 150G 左右。（因为 V2 集群行将下线，上述产品无业务，所以利用了闲置的物理机，在物理条件不具备时，能够采纳 ecs 或其余虚拟机。)
机器要求：同步工作启动会占用较多内存，测试均匀 1 个工作占用 10G 内存（大表）；
单台 150G 内存能够反对 15 个并发工作；
2.3 同步形式
2.3.1 数据特点
分类项目数总数据量 1T 以上 project7 个 97T1T 以下 project77 个 15T
- 历史记录表：历史数据，项目数不多，但占用了 80% 以上的空间；
- 维表 + 长期表：我的项目数多，表较小，占用空间占比小；
- 数据特点：客户几十个部门剖析报表，小表分区比拟多，大表绝对少一些；
2.3.2 同步程序
先同步大表，而后再同步小表；
业务没有同步程序要求，小表易变，大表稳固，因而优先同步大表；
大表同步须要的手动配置少，也适宜后期做好调试；（正式启动同步前的测试不要选太大的表，倡议 10G-50G，能够测出效率和压力。）
- 长处：机器多，并发高，能够疾速压到瓶颈，晋升整体同步效率；
- 毛病：Datax 为原生的迁徙工具，不具备自动化能力，须要人工大量的配置同步工作；
注：倡议预留几台机器专门用于多分区小表的同步，残余其余机器同步大表。
2.4 总结
综上所述，Datax 的劣势非常明显：
- 首先，部署非常简单，无论是在物理机上或者虚拟机上，只有网络通顺，便可进行数据同步，给施行人员带来了极大的便当，不受规范数据同步产品部署的条框限度；
- 再者，它是开源产品，简直没有老本；
然而，它的毛病也是不言而喻的：
- 开源工具更多的是提供根底能力，并不具备工作治理，进度跟踪、校验等等一系列的性能，只能使用者本人通过脚本或者表格记录，目前暂无白屏；因而注定了它只能作为长期性质的数据同步工具去应用；
所以，业务上有一些规范化治理或者标准化运维的需要时，或者有频繁的、继续的应用数据同步调度的需要时，平安生产是十分重要的，还是举荐大家应用阿里云官网的产品。
- 写在最初
========
本期给大家介绍了 Datax 的相干概念，分享了两个案例供大家参考，然而在理论的数据同步过程中仍有十分多的艰难和问题，须要对整个数据传输的链路做剖析和优化，操作较为繁冗。后续会给大家介绍案例二中的性能瓶颈剖析和优化。
作者：陈树昌
原文链接
本文为阿里云原创内容，未经容许不得转载
