DataX在数据迁移中的应用

简介:DataX在数据迁移中的应用

image.png

1. DataX定义

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

2. 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,来做分析和对照测试;
测试结果如下图所示。

image.png
图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在数据同步实战中的应用

该案例是客户两朵云之间的数据迁移,客户新建了一朵云,需要把前一朵云上的数据迁移过去;
方案如下:

image.png
图2:方案

2.2 部署方式

Datax本身无自动集群化部署,需要逐台手工部署;
15台v2的物理机,空余内存均在150G左右。(因为V2集群即将下线,上述产品无业务,所以利用了闲置的物理机,在物理条件不具备时,可以采用ecs或其他虚拟机。)
机器要求:同步任务启动会占用较多内存,测试平均1个任务占用10G内存(大表);
单台150G内存可以支持15个并发任务;

2.3 同步方式
2.3.1 数据特点
分类项目数总数据量
1T以上project7个97T
1T以下project77个15T
  • 历史记录表:历史数据,项目数不多,但占用了80%以上的空间;
  • 维表+临时表:项目数多,表较小,占用空间占比小;
  • 数据特点:客户几十个部门分析报表,小表分区比较多,大表相对少一些;
2.3.2 同步顺序

先同步大表,然后再同步小表;
业务没有同步顺序要求,小表易变,大表稳定,因此优先同步大表;
大表同步需要的手动配置少,也适合前期做好调试;(正式启动同步前的测试不要选太大的表,建议10G-50G,可以测出效率和压力。)

  • 优点:机器多,并发高,可以快速压到瓶颈,提升整体同步效率;
  • 缺点:Datax为原生的迁移工具,不具备自动化能力,需要人工大量的配置同步任务;

注:建议预留几台机器专门用于多分区小表的同步,剩余其他机器同步大表。

2.4 总结

综上所述,Datax的优势非常明显:

  • 首先,部署非常简单,无论是在物理机上或者虚拟机上,只要网络通畅,便可进行数据同步,给实施人员带来了极大的便利,不受标准数据同步产品部署的条框限制;
  • 再者,它是开源产品,几乎没有成本;

但是,它的缺点也是显而易见的:

  • 开源工具更多的是提供基础能力,并不具备任务管理,进度跟踪、校验等等一系列的功能,只能使用者自己通过脚本或者表格记录,目前暂无白屏;因此注定了它只能作为临时性质的数据同步工具去使用;

所以,业务上有一些规范化管理或者标准化运维的需求时,或者有频繁的、持续的使用数据同步调度的需求时,安全生产是非常重要的,还是推荐大家使用阿里云官方的产品。

3. 写在最后

本期给大家介绍了Datax的相关概念,分享了两个案例供大家参考,但是在实际的数据同步过程中仍有非常多的困难和问题,需要对整个数据传输的链路做分析和优化,操作较为繁杂。后续会给大家介绍案例二中的性能瓶颈分析和优化。

所以,下一期见咯。

参考文档

[1] Datax的git地址:https://github.com/alibaba/DataX/

我们是阿里云智能全球技术服务-SRE团队,我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队;提供专业、体系化的SRE服务,帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统,提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云,让客户云上业务运行更加稳定可靠的技术。

原文链接:https://developer.aliyun.com/article/781761?

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值