使用datax迁移数据的一些感想

项目背景：

项目上最近经常从gbase8a往mysql抽取数据业务，抽取过程属于离线操作，遇到记录条数最多的业务表有30多亿条记录，磁盘空间占用最大的表有170GB（3亿多条记录），整个过程都还是比较顺利，遇到的主要问题是数据如何均匀切片问题？下面记录一条迁移的思路与思考

系统环境

gbase8a多节点集群
mysql5.6.46

迁移思路

1、按业务表记录数进行排序操作，小表直接批量迁移。
2、大表按时间字段或rowid来进行切片迁移
迁移思路挺简单的，那有没有问题呢，有一句话讲得好理想状态与现实情况存在差异，这个差异就是问题，有问题就需要我们思考与分析，尽最大努力让迁移的过程如丝般顺滑。

迁移思考

1、判断小表的依据呢？为什么要按记录数进行统计呢，而不加上表size来一起来判断这个表是小表呢
2、大表中只有部分记录的时间字段有值，大部分记录的时间字段没有值，这种情况怎么办呢？
3、通过rowid切片来迁移，rowid是gbase8a自带的列，起值为0，每增加一条记录rowid加1，正常情况下最大的rowid+1就是表的记录数，那么一张表在8a集群中rowid 是怎么分布呢，通过rowid来迁移可行吗，在哪些情况下可行，存在什么问题，是不是对所有表都可以按rowid进行切片迁移？，切片切多大合适，大了会对迁移造成什么影响？
4、遇到最大rowid比表记录异常大，怎么处理？遇到最大rowid比表记录异常小怎么处理？

思考答案

1、通过datax迁移时，小表的判断方式是按datax一次默认分配的内存来计算的，但这里判断小表通常通过行数来判断，当前也可以实现基于表大小来估计，但需要对每张表单独评估
（画外音：只有对表的只读权限）
2、遇到不少这样只有部分记录的时间字段有值的大表，这种情况可以基于rowid切片
3、所有的表都可以基于rowid来进行迁移，比较繁琐的事每个大表都需要单独处理，切片大小很难统一

总结

1、数据迁移过程总会遇到很多问题，这里遇到最多的就是内存溢出问题，所以合适的切片大小很重要
2、基于rowid内存溢出后，怎么能接着继续同步，类似断点续传功能，这点脚本没有实现该功能
3、基于rowid切好片后发现某个切片范围有数据，但datax执行到这个切片范围时长时间查询不到数据(单通道执行2020/10/02）。