从Informatica迁移到国产ETL平台的消息传开时团队里第一反应不是兴奋而是沉默。我们守着一套稳定运行了六年的老平台维护着三百多个定时作业每天处理上千张表的同步和转换业务部门早就习惯了它的存在。真正推动我们下决心的不是“国产化”这个名词本身而是现实账本原厂许可续费逐年上涨新增数据源适配遥遥无期核心开发人员开始流失老平台的维护成本已经高到无法忽略。这篇文章不聊厂商PPT里的宣传口径只讲我们实际踩过的坑、验证过的方法、以及那些只有在切换过程中才会暴露的细节。如果你也在评估或正在经历类似的迁移项目这篇复盘应该能帮你少走几段弯路。1. 迁移决策的算账逻辑到底哪些成本逼我们动了手1.1 许可费用之外的隐性支出很多人首先想到的是License费用。没错Informatica这类商业工具的许可确实不便宜但真正让我们坐不住的是那几个“看不见的账”。首先是适配成本我们近几年接入了不少新型数据源老平台对其中几个非主流数据库的驱动支持始终跟不上每次都要绕道通过文件接口中转开发和维护成本极高。其次是运维门槛老平台的调度监控、日志排查、元数据管理这些模块需要专人来维护离职交接困难新人不愿意学团队的技术栈长期被绑定在一个老框架上。我们做过一次粗略统计连续三年的总拥有成本TCO里许可费用只占四成不到剩下的全是人力、适配、补丁升级和隐性技术债。算完这笔账迁移的优先级一下子就被提到了年度重点项目里。1.2 选型评估时我们重点盯的五件事平台选型没有固定的标准公式但我们可以提供一个自己用下来比较顺的评估框架。我们当时给所有候选平台打分时只盯五件事存量映射的兼容度不用重新写代码就能平移的作业占比越高越好。我们把这个列为第一硬指标因为它直接决定迁移工期。异构数据源的覆盖度常见的Oracle、MySQL、SQL Server、PostgreSQL必须原生支持还要看对国产数据库的驱动适配情况。调度和运维能力能否支持复杂的依赖关系、补数、重跑、告警和可视化监控这决定了上线后运维团队能不能接得住。性能与并发能力特别是大批量数据同步、高并发调度场景下撑不撑得住。扩展性和开放性能不能方便地扩展自定义插件、连接器以及是否提供清晰的数据血缘和元数据管理能力。选型结果不需要在这里公开但可以负责任地说经过两轮POC测试和压力验证我们最终选定了一款界面熟悉度较高、对存量映射兼容性较好的国产平台。无论选哪家POC阶段一定要拿生产环境的热点作业去跑而不是用几个demo作业随便验证一下。1.3 为什么没有选择“全量推翻重写”其实最初内部讨论时有个声音是“干脆全部推翻用新平台的规范重写所有作业”。这听起来很干净但我们对三百多个作业做了初步估算后立刻否掉了这个方案。这批作业里有三分之一左右是直连数据库的简单同步规则简单重写成本不高但还有相当一部分涉及复杂的数据清洗、Lookup关联、多目标分发、异常处理分支。如果全部重写按每个作业2至3人日的开发工作量估算再加上业务验证周期整体工期会超过一年半业务部门根本等不起。所以最终我们把策略定为“能自动平移的自动平移不能平移的针对性重写废弃作业直接下线”用混合策略控制总工期和风险。这个决策在后面被证明是整场迁移中最关键的一步。2. 迁移前的资产盘点最枯燥却最重要的一步2.1 先把存量作业的底牌摸清楚迁移前必须先搞清楚一件事你到底有多少张底牌。很多团队在迁移启动后才发现连生产环境上有多少个作业、用了哪些数据源、哪些作业已经被业务废弃了都没有准确的清单。我们不希望自己也陷入这种混乱于是启动阶段就做了一次彻底的资产盘点。盘点分为三条线并行推进作业清单线从调度平台上导出所有定时作业的配置包括作业名、调度频率、依赖关系、最近运行状态。映射逻辑线从老平台的元数据仓库导出每个作业对应的映射定义重点分析源表、目标表、转换逻辑和数据流向。数据源血缘线梳理所有作业涉及的数据源连接、数据库实例、Schema和表级依赖。盘点结果让我有些意外存量作业数量不是团队觉得的“三百多个”而是四百二十多个其中七十多个已经超过半年没有正常调起。也就是说我们真实需要迁移的作业比想象中少了近五分之一。2.2 作业分级四象限分类法资产盘点完成后我们按迁移策略将所有作业分成四类形成了一个简单但极有效的四象限分类法分类判定标准处理策略占比A类直接平移映射结构简单源和目标类型新平台原生支持无复杂转换尽量自动迁移工具少量手工调整约35%B类需重写涉及复杂转换、存储过程嵌套、多数据源关联、自定义脚本人工重写并安排业务验证约30%C类可借用平台能力优化老平台实现起来很别扭新平台有更简单方案重写时采用新平台原生能力约20%D类废弃下线长期未使用或业务方确认不再需要迁移时直接下线约15%这个分类的价值是双重的。一方面它让我们对工作量有了清晰认知避免了后期无谓的返工另一方面它帮助我们在向管理层汇报时提供了一个可视化的项目全景图让决策层知道风险到底在哪。2.3 作业依赖关系阻止“蝴蝶效应”的关键单看单个作业的复杂度是不够的作业之间的依赖关系才是迁移后最容易出问题的地方。老平台在调度上有自己的一套逻辑同一个业务链路上的多个作业有的按时间触发有的按前置完成事件触发还有的是跨系统文件到达后触发。如果不把依赖关系完整梳理出来就会出现“作业A已经迁移成功但它依赖的作业B还在老平台导致数据没对齐”这种诡异问题。我们当时的做法是先自动导出调度配置再用脚本解析出作业间的上下游关系最后生成一张完整的依赖拓扑图。这张图在后面制定分批迁移顺序时成了我们最重要的参考资料。调度依赖的梳理必须独立于作业映射迁移进行优先级反而要更高。3. 映射迁移的三种做法自动、手工、混合3.1 “自动迁移工具人工修正”到底靠不靠谱市场上不少新平台都提供了存量兼容的迁移工具声称可以实现“一键迁移”。我们要用真实经历给这个说法泼一盆冷水一键指的是工具可以导出模板而不是一键就能上线。我们选用的平台提供了一套存量作业导入功能能识别老平台导出的映射XML自动翻译成新平台的作业定义。但实测下来翻译率能做到70%到80%就不错了。无法自动翻译的主要是这几类情况老平台特有的转换函数比如某些内建字符串处理函数在新平台里没有对应实现复杂表达式中的变量作用域规则不同自定义Java/C代码段无法直接移植某些依赖特殊连接池配置的加载方式差异。所以我们的实践是把自动翻译当作“初稿生成器”翻译完后的作业必须经过人工逐条review重点检查字段映射、转换逻辑和连接配置。虽然人工工作量大但总比从零开发效率高很多总体至少节省了四成工作量。3.2 手工重写的关键场景复杂转换和存储过程对于B类和C类作业我们基本选择了手工重写。创业团队看这里可能觉得工作量太大了但这里有一个重要的思路重写时不追求和老平台逻辑逐字对应而是以业务结果为准。什么意思举个例子老平台里某个转换逻辑由于历史原因是先对字段做拼接、再截取、再转换绕了好几个弯。如果逐字翻译到新平台虽然能保持结果一致但代码非常丑陋后续没人敢动。而如果我们直接看业务需求理解这个字段最终到底要什么格式往往可以用新平台一个函数或一条规则就写清楚代码可读性反而更好。当然这也意味着需要业务方深度参与确认口径。所以我们在迁移项目组里专门设了一个“业务确认岗”每次重写前先出数据映射文档发给业务方确认确认通过后才开始写代码。3.3 一个典型映射的迁移前后对照直接说可能有点抽象我拿一个比较典型的映射来做对照说明。这是一个从Oracle源表读取客户信息、做清洗后写入目标表的作业。老平台的映射逻辑简化版从CUSTOMER表读取数据对PHONE字段做非空判断和去特殊字符处理将STATUS字段从数字码转换为中文描述通过LOOKUP关联REGION表获得区域名称过滤掉创建时间早于2020年的记录全部写入目标表CUSTOMER_CLEAN这个映射在老平台上需要建一个Mapping配置Source Qualifier、Expression、Lookup、Filter、Target这几个组件组件间用连接线串起来。要修改一个字段的逻辑得进到组件配置里一层层找。新平台重写后逻辑完全可以用一段SQL式的映射脚本表达清楚INSERT INTO CUSTOMER_CLEAN ( CUST_ID, CUST_NAME, PHONE_FORMATTED, STATUS_DESC, REGION_NAME, CREATE_TIME ) SELECT CUST_ID, CUST_NAME, REGEXP_REPLACE(PHONE, [^0-9], ) AS PHONE_FORMATTED, CASE WHEN STATUS 1 THEN 有效 WHEN STATUS 0 THEN 无效 ELSE 未知 END AS STATUS_DESC, R.REGION_NAME, CREATE_TIME FROM CUSTOMER C LEFT JOIN REGION R ON C.REGION_ID R.REGION_ID WHERE C.CREATE_TIME DATE 2020-01-01;这段SQL对团队里的开发人员来说几乎不需要学习成本一眼就能看懂。这也是为什么我们后续更倾向于用“SQL式映射”而非“拖拽式组件”的一个主要原因——可读性决定了这个平台后续能不能被团队长期维护下去。业务逻辑复杂的时候拖拽式组件连线一多很少有人愿意再打开去看。4. 数据一致性验证不比对就不敢上线4.1 三档验证策略按作业等级配置数据迁移最大的风险不是“迁移不上”而是“迁移上去了数据结果和老平台不一致”。我们的原则非常明确没有经过验证的作业不允许进入上线清单。验证策略我们设计了三档按作业等级灵活配置Total档源表和目标表的总量与汇总指标比对。适用于简单的全量同步作业只要行数、关键汇总字段对上就行。Summary档在Total基础上增加分组聚合比对按日期、区域、类型等维度分别对比汇总结果。适用于有时间分区或业务维度的作业。Detail档全字段抽样明细比对对随机抽取的样本数据逐字段对比要求完全一致。适用于核心业务方重点盯着的作业。具体实施时我们写了一套数据比对脚本输入源端查询SQL和目标端查询SQL输出不一致清单。这套脚本支撑了整个验证阶段直到迁移结束后还在线上承担日常巡检任务。4.2 增量数据的验证陷阱刚开始做验证时我们犯了一个低级错误直接把源端和目标端的全量数据拿来比对。结果每次都有大量差异后来排查才发现验证期间源端数据还在持续变化并非静态的比对基准。解决方式是全量历史数据比对选择一个源端相对静止的窗口比如业务低峰期或凌晨比对时配上快照读Oracle的闪回查询或MySQL的binlog位点增量数据验证则通过比对源端binlog或日志解析结果和目标端写入结果来实现。这里特别提醒一句不要尝试在业务高峰时段做全量比对。我们第一次就是周五下午开始跑的比对了三个小时还没结束业务侧持续写入差异清单越来越多最后只能全部作废。后来把比对时间统一调整到凌晨低峰期一次性就通过了。4.3 如何搭建一套可信的测试环境迁移测试如果直接在生产环境上做风险太高但要在一套干净的环境里模拟真实数据也不是简单复制几个表的事。我们的做法是搭建了一套“影子环境”结构上完全复制生产环境数据采用生产脱敏样本重点是构造了边界情况——超长字符串、NULL密集字段、特殊编码字符、大数据量分区表等。这些边界样本是验证迁移逻辑是否健壮的最有效手段。同时影子环境里部署了新旧两套平台确保同一个作业在两边可以同时跑然后直接对比结果。这个过程我们内部叫“双跑验证”。双跑验证不只查数据结果还会观察两边作业的运行时间、资源占用、日志输出这些数据后面会用于性能调优。5. 调度切换与上线窗口最容易翻车的环节5.1 为什么先并行跑而不是直接切换切换策略上我们选择了“先并行后割接”的方式。并行期间新平台和旧平台同时跑同样一批作业但新平台写的数据只进影子库不影响生产。这样做的好处是可以持续多天观察新平台的稳定性和数据一致性调度的依赖关系可以在真实运行环境中刷新验证业务方有足够时间在新平台跑出的结果上做业务验证。并行期的长度不能太短。我们原计划跑两周实际跑了三周半。不是新平台问题多而是业务方验证的节奏比预期的慢很多业务口径他们要内部讨论才能确认。5.2 正式割接的六个步骤正式割接时我们按照“先停、再补、后切、观察回退预案待命”的原则把过程拆成了六个步骤停止旧调度通知所有下游系统凌晨0点起旧平台不再启动新作业。全量初始化新平台从源端拉取全量历史数据完成基线数据初始化。增量追平利用新平台日志解析能力追平停旧调度后产生的增量数据。数据核对对核心表做一次快速全量比对重点确认追平后的一致。切换入口把生产下游的数据入口切换到新平台新平台开始承担全部生产调度。观察期连续7x24小时监控运行状态每四小时输出一份运行简报。每一步我们都有对应的回退判断标准。比如第四步数据核对如果发现不一致超过阈值就放弃切换重新评估追平逻辑第五步切换后如果核心作业连续失败超过10次且无法自愈就执行回退预案。5.3 回退预案切换失败怎么快速回到老环境回退预案这个事很多人觉得用不上就不好好写但我们专门花了整整两天把细节补齐了。回退预案的核心不是“切回老平台”而是“如何在最短时间内切回并且保证数据不丢不重”。具体做法是在老平台停调度之前把老平台所有作业的依赖配置和状态做了一次全量备份。如果新平台运行异常我们把下游入口切回老平台并同时启动新平台的停止和追平流程让老平台从上次停调度的位置继续处理保证数据流不中断。这个预案实际没有用到但在割接前给了所有人很强的心理安全感。没有回退预案的割接就像没有备份的数据库升级赌的是运气而不是管理能力。6. 国产平台的一些“性格”适配比想象中更吃细节6.1 SQL方言和函数差异藏在最深处的坑迁移过程中最折磨人的其实是那些看起来不起眼的函数差异。老平台上某个字符串处理函数在源库上跑得欢新平台底层SQL翻译引擎可能用的是另一种方言结果差之毫厘谬以千里。我们遇到过一个典型案例源库是Oracle某个字段的值是“ABC123”老平台的映射里用了一个函数从第4位开始截取3位得到“123”。新平台翻译后由于默认截取语义的不同实际截出来的可能是“C12”。这种问题在测试环境里最容易暴露所以每一条重写的逻辑都必须带边界用例去验证不能只测正常路径。6.2 并发和资源隔离从单机思维到分布式思维老平台在我们这套环境里是集中式调度资源池相对固定。新平台采用的是分布式执行引擎并发度和资源隔离策略都需要重新设置。一开始我们图省事所有作业都用默认并发数结果高峰期下游数据库被打满出现大量锁等待。后来我们根据作业的运行特征划分了三个资源组核心同步组、常规加工组、批量补数组。核心同步组最高优先级限流上限高补数组优先级最低只能在晚上跑。这套资源隔离策略上线后作业之间的“互相踩踏”问题大幅减少。6.3 数据源驱动兼容性不能只看平台自带的连接器国产平台对主流数据库的连接器支持得比较完善但像某些老版本数据库或某些分布式OLAP引擎连接器缺失或者版本不匹配的情况还是存在。我们当时有一类源端数据取自某国产分析型数据库平台自带的连接器版本过旧读取时总报时区错误。解决办法是联系平台方走了一场专门的联调驱动版本升级时区参数手动指定才彻底解决。这里给一个建议项目启动之初就拉一个数据源类型清单提前确认所有连接器版本是否兼容越早暴露问题越好千万不要等到验证阶段才发现连不上。7. 迁移后的运维体系重建从“能跑”到“管得好”7.1 监控告警的阈值不是拍脑袋定的作业迁移成功只是开始运维体系的平滑接管才是“能不能长期运行”的核心。新平台的监控页面再好看不配置合理的告警阈值也是摆设。我们根据并行期积累的运行数据统计了每个作业正常运行的耗时区间和资源消耗再在这个基础上放宽一定比例设定了告警阈值。比如某个作业正常耗时5到8分钟那我们就设成超过15分钟告警低于5分钟可能没跑数据也告警。上下限都要有这在老平台上我们一直没有做得很好新平台反而给了我们一次重新规范的机会。7.2 任务失败的自愈与人工介入规范作业跑挂了事务性的同步任务还好说关键是那些中间状态特别复杂的批处理任务。我们制定了一整套“失败分级响应”规范单次失败自动重试一次间隔5分钟连续两次失败触发告警通知值班人员超过三次失败自动停掉该作业以及下游所有依赖作业防止脏数据扩散。这套规范听起来简单但在实际运行中非常有效。它避免了作业失败后反复空转打爆下游库的问题也把人工介入的边界划得很清楚。7.3 数据血缘的意外收获国产ETL平台普遍比老平台更重视元数据管理和数据血缘展示。迁移后我们第一次能可视化地看到“某个报表字段到底是从哪张源表、经过哪几个作业加工而来的”。这在排查数据问题时帮了大忙过去追一条数据链路可能要翻十几个作业脚本现在点一下就能出全链路。这件事本来根本不在我们的迁移目标里属于“无心插柳”的收益。如果你也在迁移建议尽早把血缘梳理纳入计划哪怕只是把作业间的依赖关系导入血缘模块后面都能省很多查数的时间。8. 复盘后的几张清单给正在迁移的同行的参考8.1 最耗时的不是写代码而是确认业务口径回头看整个项目真正决定进度的不是开发而是业务口径的确认。很多老作业跑了几年已经没人说得清当初为什么这么写。我们前前后后组织了二十多场业务确认会几乎每场都有口径要反复拉扯。建议你务必留足业务确认的时间预算开发时间压一压可能还能挤出来业务确认的时间一旦不够后面只能靠返工来补。8.2 老平台的“地下资产”要提前挖迁移过程中我们意外发现老平台里有一些多年没更新的历史任务但它们对某些月度报表仍然有影响。这些任务虽然不需要随之迁移上线但它们的逻辑必须保留记录否则以后新平台排查月报数据问题时会缺了上下文。简单做法把所有被下线或长期不调度的作业逻辑做一个“逻辑归档”存成文档或导出成静态文件不参与运行但保留可查性。8.3 文档比脚本更重要迁移项目最容易犯的毛病是代码写完了文档没跟上。我们规定每一个重写的作业都必须有配套的数据映射说明文档内容包括源表、目标表、转换逻辑、业务口径确认人、验证结果链接。这给后续的运维交接省了无数口舌。8.4 给团队一个缓冲区最后说个容易被忽略但很重要的点迁移期间团队的工作负载非常高尤其是既要保证老平台平稳运行又要推进新平台迁移的中间阶段很多同学其实是在双线作战。合理调整任务分配、适当增加人手或者延后部分非紧急需求是在为项目成功率买单这笔投入非常值得。回看整个过程最让我感慨的其实不是技术的难度而是决策和执行之间那条长长的沟。选型时对平台的“兼容性”抱有过高期待实施时才明白兼容永远是相对的关键要看存量复杂度与团队的消化能力。好在我们用混合策略和足够的验证周期控制了风险最终平稳落地。如果你手头也有一笔类似的迁移账要算希望这篇复盘能成为你的参考坐标至少在启动之前把“业务口径确认”和“依赖关系梳理”这两件看起来不紧急但真正决定成败的事排在前面。