去年年初接手了一个挺棘手的任务，把集团的数据集成平台从一套用了快十年的国际商业ETL工具，整体迁移到国产ETL平台。以前聊这种迁移，大家第一反应都是“换工具嘛，重新配一下连接、把映射搬过去”，真做起来才发现完全不是这么回事。这个项目跨了三个多月，牵扯几十个核心链路，中间踩了不少坑，也沉淀了一些可复用的方法。现在类似的国产化替代项目越来越多，但完整的实战复盘并不多，我把整个决策过程和关键技术细节整理出来，给正在做或准备做的团队一个参考。
这篇内容适合两类人看：一类是像我一样负责技术选型和落地的负责人，另一类是实际写映射、调调度的数据工程师。前半部分讲迁移前怎么盘点和选路径，后半部分全是怎么转译、怎么调优、怎么排查问题，直接把能用的步骤和参数抛出来，省得你再走一遍弯路。
1. 迁移前先建台账：盘点比想象中重要得多
1.1 盘点生产映射资产，拒绝“大概数”
很多团队在评估迁移工作量的时候，习惯性看平台上注册了多少个映射、多少个会话，报一个总数就完事。但这个数只能用来做PPT，根本不能用来排计划。真正的盘点要细到这几个维度：
- 映射涉及的源表和目标表数量、字段数量
- 映射的调度频率和最近一次实际运行时间
- 是否被下游依赖，以及依赖方是谁
- 最近三个月有没有变更记录
- 当前负责人是谁，文档是否齐全
我们当时把元数据从旧平台上导出来，写脚本统计了每个映射涉及的字段数、使用了哪些转换组件、引用了几张查找表，再按业务域人工圈了一遍“谁在用、用在哪”。这一步看起来费时间，但它是后续所有估算的依据。没有这份台账，后面排迁移优先级、估人力、做双跑比对都会变成拍脑袋。
1.2 依赖分析：不是单个搬，是整链路搬
ETL有个特点，单看一个映射往往不复杂，复杂的是映射之间、任务之间的依赖关系。一个任务的输出往往是另一个任务的输入，一个表可能同时被三四个任务更新。迁移如果只盯着单个映射，很容易出现“搬过去单独跑没问题，整个链路一跑就对不上”的情况。
我建议在盘点阶段就把依赖关系摸清楚：从源系统到贴源层、再到汇总层、再到应用集市，每一层之间的数据流向是什么，谁先跑谁后跑，失败时的重跑机制是什么。老平台大多有自带的调度依赖图和运行日志，可以导出来分析。用不用得上血缘分析都是次要的，关键是让团队每一名成员手里都有一张上下游依赖图。这张图后面做迁移批次切分和切换演练时，直接决定你先动哪条链、后动哪条链。
1.3 迁移分级与砍需求：别把僵尸任务带过去
盘点还有一个特别重要的产出，就是“砍”。老系统里往往会积累大量几年都没跑过的临时映射，或者上游已经下线了还在定时执行的僵尸任务。这些任务如果原封不动迁到新平台，等于把历史包袱原样搬走，既浪费迁移精力，又让新平台的上线治理难度变大。
我们当时把所有任务分了三个优先级：
| 优先级 | 判断标准 | 迁移策略 |
|---|---|---|
| A类 | 核心交易、财务报送、监管相关，延迟会影响业务 | 优先迁移，配置双跑校验，切换窗口内严格验证 |
| B类 | 重要但允许小时级延迟，比如日常分析报表 | 第二批迁移，允许有限的双跑，不要求分钟级切换 |
| C类 | 超过三个月未运行、无下游依赖、或者可手工补数据的临时任务 | 不迁，直接下线或按需重建 |
这一步看着像是在“砍需求”，实际上是在帮业务做减负。很多业务方根本不知道自己有一堆过期接口还在跑，你把运行记录拉出来，他们自己也认。迁移过程中借这个机会把无效链路清掉，新平台上来之后调度负载也更轻，后面优化性能会舒服很多。
1.4 成本评估：不是比价，是比总拥有成本
说到国产化，很多人第一反应是省钱。但真正把账算下来会发现，迁移过程中的隐性成本远高于授权费价差。你要算的不只是两个平台各自多少钱，而是迁移实施期间的人力投入、双轨并行期间多出来的硬件和运维成本、切换失败可能造成的业务损失，以及上线后一段时间内的“学习成本”和“纠错成本”。
我们当时按“三年总拥有成本”做了个对比，把一次性迁移成本、并行期硬件资源成本、日常运维人力差异、风险准备金都放进去。结论是：如果只迁十个八个映射，那新旧差别不大；但如果要迁几十上百条链路，且这些链路每天都要跑批，那国产平台的好处体现在后续扩展性和配置自由度上，而不是单纯价格。这个结论很重要——它决定了你向决策层汇报时应该强调“业务连续性”还是“降本增效”。我的建议是不要用“降价”做主线，用“可控、可持续、不依赖特定厂商”做主线，更容易获得支持。
2. 迁移路径怎么选：三种主策略的取舍
2.1 一次性切换：别在项目中期才决定
所谓一次性切换，就是在一个时间窗口内，把旧平台所有生产任务全部切到新平台，旧平台直接下线。这个策略看着干净利落，好像省掉了并行期的资源消耗，但适用条件非常苛刻：任务总量要小、链路依赖要简单、业务方对切换时间窗口容忍度要高。我们评估过这个方案，发现根本行不通——几十条核心链路每条下游都不止一个系统，一次性切换意味着所有系统要同时验证，一旦某条链路出问题，回退范围就是整个平台，谁也扛不住这种风险。
如果你的平台上有大量存量任务，非常不建议在项目中期才决定搞一次性切换。它更适合从零开始建平台、或者存量任务极少的情况。对大部分迁移项目来说，这个方案只能作为“最终收敛目标”，而不是主要执行路径。
2.2 按业务域分阶段迁移：最稳妥的路径
我们最终采用的是按业务域分批次迁移：先把客户主数据域和财务对账域切过去，跑通之后再做库存和订单域，最后才是报表集市。每个批次独立验证、独立回退，把风险控制在一个业务域范围内。
这里有一个关键细节：切分批次时，不要只按“哪个系统重要”来分，要看“数据依赖的自然边界”。最好把一组强依赖的上游抽取、中间转换、下游分发放在同一个批次里，这样切换后即使要回退，影响的也是一个完整的数据闭环，而不是半条链。我们第一批选的就是依赖关系最简单、但业务价值又足够高的一个域，相当于拿它当“试验田”，把新旧平台的差异全暴露在小范围内。
2.3 双轨并行：要有明确退出条件
双轨并行是迁移中几乎绕不开的步骤，但很多人把它做成了长期状态，导致人力被拖死。双轨并行的原则是“有明确退出时间，而不是永远跑两份”。我们当时定了一个硬性规则：某个批次完成全量验证、且连续稳定运行了一个完整月结周期之后，旧平台对应任务必须下线。月结周期覆盖了月度汇总、跨月对账这类低频但最容易出问题的场景，比只看日批更靠谱。
并行期的验证怎么做也很讲究。最有效的做法是新旧平台同时跑同一批数据，新平台结果写入影子表或影子文件，然后每天用校验脚本对比新旧两个结果集，发现不一致就当天排查。等连续一个周期没有出现任何数据差异，才可以发起切换确认。双轨期的最长时限也要提前设定，我们当时限制在两个月以内，超过时限还没有跑通，说明这条链路的迁移方案有问题，需要回溯而不是继续耗下去。
3. 核心实操：映射转译、调度重构与一致性校验
3.1 表达式与函数转换：先建映射字典，再动手
这是整个迁移中工作量最大、最琐碎的部分。老平台有自己的表达式函数库，比如字符串截取、日期格式化、类型转换、正则匹配等等，新平台不一定有一一对应的同名函数。更麻烦的是，同一个业务逻辑用不同平台表达，语法和边界行为可能完全不同。
我们的做法是先把两边平台的函数手册拉出来，整理出一张函数映射字典。字典里每一项都写清楚：旧平台函数用法、新平台对应函数、差异说明、测试用例。比如旧平台里日期转字符串的格式符是“YYYY/MM/DD”，新平台可能要求“yyyy-MM-dd”，大小写敏感度不同；字符串截取是“1-based”还是“0-based”也要逐项验证。字段截串、字符串拼接、空值处理这类高频函数，我们单独写了一组单元用例，构建了一个小型的测试数据集，逐个跑通再批量套用。
这里想给一个实用建议：如果目标平台的转换逻辑支持直接写SQL表达式，尽量把复杂逻辑改写成标准SQL，而不是继续用平台自带的专有函数。SQL的通用性更强，以后再做平台调整时，重写的成本会低很多。我们后来把一批“用平台组件拼出来”的复杂转换，统一改成SQL关联加子查询，代码量直接降了三分之一，排错也变得更容易。
3.2 目标表写入策略：不要无脑全删全插
老ETL工具里，目标表数据更新一般由session配置决定，常见的是“truncate后全量插入”或“按主键更新”。新平台往往更强调写入模式，比如覆盖写、追加写、主键更新。不同模式对下游数据的影响差别很大。
我们踩过一个典型问题：某个目标表之前用的是“每天全量覆盖”，新平台默认配置下也这么干，结果在切换当天，下游应用在数据写入中间态时读到空表，导致页面查询直接报错。原因就是目标表在“truncate”和“insert完成”之间有一段空窗期，旧平台因为有锁和事务隔离机制，这个空窗对外不可见，而新平台的默认行为下，下游连接恰好看到了。
解决思路是：对下游实时查询的表，一律不要用“先删后插”，改成“主键更新”或“临时表替换”的方式。临时表替换的逻辑是先把数据写到临时表，再通过改名或分区切换的方式一步到位。这样做还有一个好处，回退时只需要把旧分区数据恢复，不需要重跑整条链路。切换前必须逐表确认目标表的更新策略，宁可多花半天，不要图省事用默认配置。
3.3 调度体系重构：全局DAG比单任务更关键
老平台调度往往采用集中式控制，日历、频次、依赖关系都在一个控制台里配好。新平台如果是分布式调度，需要重点关注三个方面：
- 时区与触发语义：任务配置的“每天02:00”是平台服务器时区还是显式时区，要提前明确，否则跨时区跑批会出现“提前一小时”或“延后一小时”的诡异问题。
- 任务依赖：老平台里可能通过“上一个任务成功才触发下一个”的隐式依赖来串联，新平台迁移时要把这些依赖显式化到全局DAG中。我们当时梳理出400多个任务间依赖关系，全部导成DAG配置，才保证了串行顺序和重跑行为一致。
- 重试与告警：旧平台某个任务失败后，默认会重试3次、每次间隔10分钟；新平台可能默认不重试，或者重试间隔不同。这些参数都要整理成一张配置对照表，迁移一个任务就核对一个任务。
调度重构中还容易忽略“人工干预”操作。老平台里常有“强制跑成功”“跳过某天数据”这类手工操作记录，新平台不一定支持同样的操作语义。遇到这种任务，需要和业务方确认：这个操作以后还要不要？如果要，新平台有没有替代方案？我们有一个对账任务就曾依赖“手动置成功”的机制，切到新平台后该机制不可用，只好改造任务逻辑，增加一个跳过标记位，才算彻底解决。
3.4 数据一致性校验：不能只对行数
双跑校验做得认真不认真，直接决定切换你敢不敢拍板。很多人校验就比对两个表的总行数，但行数相同不代表数据一样。我们当时的校验分三层：
第一层是主键集合比对：用全外连接查新旧两边的主键集合，找出哪边多了、哪边少了。第二层是字段级内容比对：对每行做哈希，比较哈希值。要么把两边的关键字段拼成字符串后算哈希再比对，要么用SQL的聚合函数对关键字段做求和、求平均值，重点核对金额类、数量类字段。第三层是业务汇总比对：按日期、机构等维度做汇总，核对汇总数是否一致。
这里分享一个有用的SQL校验例子，主键集合比对可以用类似下面的逻辑：
select coalesce(a.id, b.id) as id, case when a.id is null then 'new_missing' when b.id is null then 'old_missing' else 'both_exist' end as diff_type from new_table a full outer join old_table b on a.id = b.id where a.id is null or b.id is null;字段哈希比对的思路类似，把需要校验的字段用concat拼起来，再算哈希值，然后比对两边的哈希集合。如果字段值里包含大文本，建议在哈希前先做长度截断或分段哈希，避免性能问题。校验一定要提前写好模板，做成可重复执行的脚本，每天双跑结束自动触发，不要靠人工去跑临时SQL。
4. 性能调优：别一上来就拉高并行度
4.1 先定位瓶颈，再动手调参
从旧平台切到新平台，最先感受到的问题基本都是“变慢了”。但很多人的第一反应是错误的——直接调大并行度、加内存、增加并发数，结果源端数据库被压垮，任务失败率反而上升。
慢的原因要拆开看。我们采取的排查方式是在任务里分段加耗时记录，把整个ETL分成三段时间：读取源数据耗时、转换计算耗时、目标端写入耗时。日志一出来，瓶颈往往立刻现形。有一类典型的慢是源端查询走了低效执行计划，新平台默认的查询条件下推做得不够好，导致源端全表扫描，数据库CPU飙高，这种情况再怎么增加平台并行度都没用，正确做法是优化源查询的过滤条件，把分区字段条件下推到源端SQL里。
目标端写入也很常见。旧平台可能自带批量提交策略，新平台默认一次提交一条，跑大批量数据就会奇慢无比。这种情况就要显式开启批量写入，调整批次大小，但批次不是越大越好，过大会导致目标端锁竞争和内存溢出，一般从1000开始往上调，压测后找到稳定值。
4.2 一个日批任务从40分钟压到12分钟的调优实录
拿我们后续遇到的一个具体任务举例：每天早上跑的一条核心汇总链路，切换后耗时从旧平台的20分钟涨到40分钟，眼看要影响下游8点前的报表展示。我们按上面说的分段排查，很快发现问题出在读取环节——源端是一张上亿行的业务流水表，新平台的默认查询一次性读取全表，没有把时间过滤条件下推，导致每次处理的数据量是实际需要的三倍多。
调整方案分三步。第一步，在映射的源查询里显式加上时间分区条件，只提取前一天的数据，这一项直接把读取数据量降为原来的三分之一。第二步，开启目标端批量提交，批次值设为5000，同时把源端读取的每次抓取行数从默认值调到合适范围，减少往复交互次数。第三步，把转换环节里的一个查找表改成哈希关联，减少逐行查询带来的开销。三步做完，整个过程从40分钟降到了12分钟，比旧平台还快些。
这条调优记录说明一件事：性能问题大多不在平台本身，而在映射的写法还停留在旧平台习惯上。迁移之后花一周时间专门做性能回归测试，非常值得。
4.3 新旧平台性能对比：要同场景、同数据、同并发
很多项目喜欢搞“新旧平台性能PK”，但如果没有控制变量，这种对比很容易变成一场秀。我们当时的办法是：选三条代表性链路，分别代表大表聚合、多表关联、文件读写三种典型场景，用同一份数据、同一个并发数、同一时间段，分别在两个平台上各跑三遍，取中位数做对比。
对比结果当然有意义，但要清醒看待。旧平台跑了几年的任务，SQL和查询都是经过多轮优化的；新平台刚迁过去，映射写法还带着“翻译腔”，性能暂时落后不奇怪。对比的真正价值是找出“哪些环节新平台有代差”，比如某些情况下分布式并行能力更优、某些场景下资源占用更小。而不是为了证明谁比谁强，做一个“我们胜了”的结论。我把对比表放在项目周报里，也注明了优化空间，这样管理层对整个进度有合理预期。
5. 迁移中踩过的坑与排查思路
5.1 中文乱码：问题不在平台，在连接串参数
第一批双跑的时候，我们发现有一张表的中文备注字段在新平台侧有一半变成了乱码。第一反应是新平台编码问题，查了半天，最后定位到是数据库连接串里的字符集参数没配。旧平台连接配置里显式指定了数据库侧的字符集，新平台新建连接时我们没有逐项核对，用了默认UTF-8，但源库的字符集实际是GBK，数据读进来自然就乱了。
这个教训的核心是：迁移不是把“连接串复制过来”就行，而是要逐个参数比对，包括字符集、fetch size、事务隔离级别、连接超时时间。少一个参数，可能在日常运行时看不出来，但数据一多、并发一高，问题就集中爆出来。我们后来做了一个“连接配置核对表”，把源库类型、版本、字符集、驱动参数、连接池大小全部列出来，逐条确认后才能建正式连接。
5.2 时间字段精度不一致：报表对不上账
我们遇到过一种更难查的问题：新旧两边看起来数据一致，但下游报表个别记录对不上。后来排查发现，时间字段精度不同导致的。旧平台里日期类型精度只到秒，新平台默认存了毫秒甚至微秒，同一个时间值两边显示时，个别记录会出现秒以下数值的差异。下游报表如果按时间字符串精确匹配，就会莫名少几条。
解决方法是统一时间处理规范：所有源端时间字段在映射层统一格式化成业务需要的精度，前端展示需要“YYYY-MM-DD HH:MM:SS”，就在转换里做好格式化，不能依赖数据库隐式转换或平台默认行为。这类问题靠行数校验发现不了，只有字段级校验才能揪出来。
5.3 错误处理机制差异：坏数据让任务悄悄失败
老平台常见的错误处理方式是“遇到错误行，把它写进错误表，任务继续跑完”。新平台默认的是“遇到错误行，任务失败退出”。这两种策略本身没有绝对优劣，但迁移时如果不改配置，会导致同一个数据源里有几条脏数据，旧平台能正常跑完，新平台却天天凌晨告警失败。
处理思路是显式配置错误容忍策略：定义允许的最大坏行数、错误行输出到专门的拒绝表中、以及达到阈值后的告警级别。不能把所有脏数据都无条件吞掉，也不能一条坏数据就让全链路崩溃。我们当时按任务类型区分：财务类任务坏行阈值设成0，有坏行立即失败告警；日志分析类任务允许少量坏行跳过，但每一跳过的行都会记录原因，方便后续治理源端数据质量。
5.4 常用问题速查表
把迁移过程中常见的问题和排查思路整理成一个表，可以直接贴在项目群里当速查手册：
| 症状 | 可能原因 | 解决思路 |
|---|---|---|
| 任务整体变慢 | 映射写法未适配，查询未下推 | 分段记录耗时，分别优化读取、转换、写入 |
| 目标表出现重复数据 | 主键或更新键没有显式配置 | 确认目标表主键，写入模式改成主键更新 |
| 调度延迟 | 任务依赖关系不完整 | 核对DAG依赖，确认上游成功才触发下游 |
| 中文乱码 | 连接串字符集不一致 | 逐项核对连接参数，统一声明字符集 |
| 明细对不上、汇总对得上 | 字符集、精度、时区差异 | 对关键字段做哈希级校验，定位具体差异值 |
| 大批量更新锁等待 | 批次提交过大、并发过高 | 调小批次，增加任务分片，错峰执行 |
| 偶发失败、重跑成功 | 重试参数、资源竞争 | 检查重试与告警配置，调整超时和并发 |
5.5 两条保命原则
第一，任何映射迁移前，先把旧平台的映射定义、参数配置文件、最近运行日志完整备份下来。不要觉得迁完就万事大吉，后面排查差异、回退旧任务都需要这些原始资产。第二，先挑一条简单的链路跑通端到端，再做批量迁移。我们第一个试点链路虽然只涉及三张表，但它把“连接配置、映射转译、双跑校验、调度配置”四个环节完整串了一遍，后面所有迁移都拿这套流程套用，省了很多试错时间。
迁移过程中还有一个容易被忽视的隐性成本：团队对两个平台的熟悉程度差异。即便新平台功能再强，工程师也要一段时间适应。我们的做法是每天安排半小时内部共享，把新平台的使用技巧和踩坑记录发在公共文档里，谁遇到问题就顺手记一笔，两周之后，这个文档成了团队最值钱的操作手册。这种组织上的配合，往往比技术方案更能决定迁移项目能不能顺利落地。
最后讲一点个人体会：这种迁移项目做到最后，最大的收获不是“国产平台到底行不行”这个结论，而是逼着我们把运行了十年的旧数据资产完整梳理了一遍。如果你现在也接到类似任务，先别急着讨论工具好坏，把台账盘清楚，把依赖图画明白，把校验脚本写好，这三件事做到位，项目就已经成功了一大半。
