去年年初接手了一个挺棘手的任务把集团的数据集成平台从一套用了快十年的国际商业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 两条保命原则第一任何映射迁移前先把旧平台的映射定义、参数配置文件、最近运行日志完整备份下来。不要觉得迁完就万事大吉后面排查差异、回退旧任务都需要这些原始资产。第二先挑一条简单的链路跑通端到端再做批量迁移。我们第一个试点链路虽然只涉及三张表但它把“连接配置、映射转译、双跑校验、调度配置”四个环节完整串了一遍后面所有迁移都拿这套流程套用省了很多试错时间。迁移过程中还有一个容易被忽视的隐性成本团队对两个平台的熟悉程度差异。即便新平台功能再强工程师也要一段时间适应。我们的做法是每天安排半小时内部共享把新平台的使用技巧和踩坑记录发在公共文档里谁遇到问题就顺手记一笔两周之后这个文档成了团队最值钱的操作手册。这种组织上的配合往往比技术方案更能决定迁移项目能不能顺利落地。最后讲一点个人体会这种迁移项目做到最后最大的收获不是“国产平台到底行不行”这个结论而是逼着我们把运行了十年的旧数据资产完整梳理了一遍。如果你现在也接到类似任务先别急着讨论工具好坏把台账盘清楚把依赖图画明白把校验脚本写好这三件事做到位项目就已经成功了一大半。