在如今这个数据至上的商业环境中，构建一个高效、可靠的数据仓库对企业来说不仅是一项基础性工作，更是推动业务洞察、决策支持和创新的关键，而数据集成技术在此发挥着至关重要的作用，其时效性和准确性直接影响着下游业务的效率和产值。
随着业务需求的不断演化和数据体量的日益增加，挑选一个既能满足当前需求又能适应未来发展的数据集成工具并进行迁移改造变得极为关键。本文主要给大家分享一些通用的数据集成工具迁移经验，以DataX为例，阐述迁移至Apache SeaTunnel的过程和经验，而对于其他数据集成工具，如Sqoop等，此迁移方案同样适用。通过此分享，希望能为社区其他的同行提供参考，帮助那些正在或即将面临类似迁移决策的团队更加顺利地完成转型。
迁移背景
DATAX作为一个稳定且高效的数据同步工具，长期以来服务于我们的数据集成需求。然而，在面对日益增长的数据处理需求时，DATAX在数据源丰富程度、处理能力等的局限性开始显现。
2023年底，我们团队决定从DATAX迁移到Apache SeaTunnel，这是基于对当前市场上主流数据集成技术的深入研究和比较。比较过程中，我们关注了包括但不限于架构设计、引擎性能、社区支持和活跃度、功能的丰富性、处理性能、数据一致性的保障、用户友好度、扩展能力和系统的稳定性等多个维度。Apache SeaTunnel以其卓越的表现在多个方面脱颖而出，特别是在数据源丰富程度、社区活跃度、易用性以及其支持的流批一体处理能力上，为我们的选择提供了坚实的理由。
迁移经验分享
全面的字段类型对比以及特殊字符的转化
在数据迁移过程中，细节决定成败。不少团队在进行数据集成工具迁移时，可能会专注于整体架构和流程的宏观测试，例如确认几个同步任务的顺利运行，就基于此启动迁移工作。
然而，这种方法可能忽略了一些微妙但至关重要的细节，特别是在字段类型的全面测试和特殊字符处理方面。
以字段类型为例， 不同的数据集成工具在处理相同的数据类型时可能会有不同的表现。
- 例如，在处理数组类型数据时，DataX可能返回以逗号分隔的字符串（如"a,b,c"），而Apache SeaTunnel可能返回数组格式的字符串（如"[a,b,c]"）。这种差异可能看似微小，但在数据集成过程中却可能导致重大的数据不一致问题。
此外，对于嵌套数据结构的处理也需要进行详尽的测试。
- 例如，MongoDB中的文档类型可能包含多种基础数据类型的嵌套，这些嵌套的数据类型在迁移前后是否保持一致，也需要进行仔细的比较和测试。我们在初期的测试中，主要关注了一些基础数据类型，而没有对嵌套类型进行足够的比较和分析，这导致了迁移过程中的一些问题。
如下图所示是我们更改的部分源码截图，事实上，仅Mongo一个数据源，我们数据类型处理相关的源码修改就涉及到多达八处。
特殊字符的处理也是一个需要注意的细节。
- 例如，DataX可能会将换行符等特殊字符直接替换为空格，而Seatunnel则保留了这些特殊字符。同步数据到Hive并且目标表为textfile格式时，容易导致数据换行错位问题。
需要注意的是，这种差异不仅是存在于DataX的官方代码与Apache SeaTunnel之间，更可能是存在于经过公司内部定制化修改的版本之间，即便发现某些数据转化逻辑不尽合理，也必须和原有的保持一致，否则会影响业务使用。
总之，通过详尽的比对，包括数字、字符串、日期时间等各种字段类型和特殊符号的正确处理。我们严格把控数据在迁移前后的一致性，任何发现的差异都会被记录并作出调整，直至我们的工具Apache SeaTunnel达到与DATAX一致的效果，确保了数据迁移的准确性。
灰度发布/陪跑方案
关于软件组件的灰度发布，通常指的是在进行版本升级时，只替换一部分服务器的做法，以此来降低全面升级导致的风险。我们在Apache SeaTunnel的组件升级过程中，如从2.3.1版本升级到2.3.2版本时，采取了类似的策略。
但是这样也有一个局限，哪个任务使用新版本是随机的，我们有时可能更希望关键任务使用旧版本，非关键任务使用新版本，这样保障关键任务稳定运行的同时，也能让部分非关键任务体验到新版本的改进。于是我们在通用的同步脚本中，通过一个version参数来控制任务级别的灰度，脚本中非常简单就能控制，一行代码的事：
/home/q/dis/apache-seatunnel-${version}/bin/start-seatunnel-flink-13-connector-v2.sh
主要是结合平台的功能，支持批量勾选任务并填写其使用的版本号。基于变更的风险或影响范围，我们可以灵活选择上述两种灰度方案中的任一种进行实施。
不过，本文重点想叙述的是迁移前期一种针对数据更为精细的发布策略------任务（或称为表）级别的灰度发布，或者称作 "陪跑" 更为准确。在金融领域，数据的精确性和完整性是至关重要的，尤其是当涉及到关键SLA数据表时，容不得半点差错。
由于公司具备双数据中心架构，所有同步任务都是同时运行在双机房的，且备用机房的数据表正常情况下无人使用。因此给我们的灰度操作提供了很好的平台，前期ST运行在备机房，DATAX继续运行在主机房，并行作业达半月时间。在这半月中，我们不断地监控两套组件处理的情况，包括但不限于运行耗时、资源消耗、数据条数、数据值。均符合预期后正式上线到主机房。
对于Apache SeaTunnel的运行效率，我们要求2分钟以上任务,ST处理时间必须100%低于DataX。(为什么要定2分钟呢，因为DataX是本地运行的，少了提交到集群等环节，对于极少数据条数的场景，DataX是必然优于Apache SeaTunnel的) 若SeaTunnel的运行耗时超过DataX，我们会立即着手进行深入的分析，以识别性能瓶颈，并实施相应的优化措施，比如我们优化了MONGO同步的切分算法使得任务耗时降低了20%+。
当然，资源消耗也是同样需要关注的指标，我们允许Apache SeaTunnel一定程度上消耗更多的资源，但从实施来看，基本是同等资源就可以达到时效的提升，最高提升40%。
更为关键的，在数据一致性的验证方面，我们对Hive表中的数据执行了精确的比对工作。此项工作不仅限于数量的比较，更涉及到了数据值的精确校验。我们确保只有在彻底验证两套系统处理的数据在各个维度上完全一致、无任何偏差时，才进行了正式的系统切换。
在这一过程中，数据比对工具的作用不可或缺。鉴于我们的主要目标数据存储平台是Hive，因此我们专门开发了针对Hive表的数据比对工具。该工具不仅能够比对数据记录的数量，还能够逐列比对记录的值，比对结果差异会输出到一个表中便于用户查看。这使得我们能够对半个月的数据，即上亿条记录进行全面比对，有效避免了仅依靠部分数据抽样比对可能导致的疏漏。
主备切换方案
即使有了上面如此严格的灰度发布方案和陪跑方案，我们还是不放心。
面对一项尚不成熟的新技术，而公司内部尚缺乏相应的技术专家时，遇到未预料的技术挑战尤为危险。若Apache SeaTunnel遭遇未知异常，且无法迅速解决，将严重威胁业务决策和数据分析流程，甚至可能导致重大生产事故。鉴于公司对SLA的严格要求，故障发生时，我们几乎没有余地进行深入研究和问题排查。
为应对此类风险，我们又从组件层面，设计了一套主备方案。该方案的核心在于确保，在Apache SeaTunnel遇到故障的情况下，DataX能够迅速、无缝地接管数据同步任务，维持业务连续性。
如下图所示，不论是新表同步任务，还是历史迁移任务，我们都会有两套脚本，无法快速解决问题时先快速切换到另一组件进行同步。
总结
在数据集成工具迁移到Apache SeaTunnel的过程中，我们注重全面细节对比，如字段类型和特殊字符处理等，实施了严格的灰度发布方案、陪跑方案和主备切换方案，以确保数据的时效性、准确性和业务连续性。
总的来看，这次的迁移充分考虑了各种可能的挑战和风险，并且在实施过程中做出了相应的应对措施，体现了数据集成工具迁移的严谨性。
本文由 白鲸开源科技 提供发布支持！