简介： DataX在数据迁徙中的利用

  1. DataX定义

===========

首先简略介绍下datax是什么。
DataX是阿里巴巴团体内被宽泛应用的离线数据同步工具/平台，实现包含 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步性能。

  1. 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的劣势非常明显：

  • 首先，部署非常简单，无论是在物理机上或者虚拟机上，只有网络通顺，便可进行数据同步，给施行人员带来了极大的便当，不受规范数据同步产品部署的条框限度；
  • 再者，它是开源产品，简直没有老本；

然而，它的毛病也是不言而喻的：

  • 开源工具更多的是提供根底能力，并不具备工作治理，进度跟踪、校验等等一系列的性能，只能使用者本人通过脚本或者表格记录，目前暂无白屏；因而注定了它只能作为长期性质的数据同步工具去应用；

所以，业务上有一些规范化治理或者标准化运维的需要时，或者有频繁的、继续的应用数据同步调度的需要时，平安生产是十分重要的，还是举荐大家应用阿里云官网的产品。

  1. 写在最初

========

本期给大家介绍了Datax的相干概念，分享了两个案例供大家参考，然而在理论的数据同步过程中仍有十分多的艰难和问题，须要对整个数据传输的链路做剖析和优化，操作较为繁冗。后续会给大家介绍案例二中的性能瓶颈剖析和优化。

作者：陈树昌
原文链接
本文为阿里云原创内容，未经容许不得转载