2023年年初，曾垄断半个银行业数据仓库的TERADATA突然宣布退出中国，各大银行纷纷发起数据仓库的替代项目，但是一个企业级的数据仓库建成并非一朝一夕，通常内含成千上万个脚本、表、依赖关系等，任何一个环节出差错均会导致牵一发而动全身。而当前市面上又没有一款数仓产品或数仓迁移方案得到充分证实，所以行业内针对TERADATA平替或数据仓库迁移整体的方案五花八门。以TERADATA为代表的相关国外数据库技术，长期垄断国内市场，各家同业也在相关技术上积累了较多历史数据包袱，去化工作十分困难。

　　上海农商银行在2022年研判了相关形势，在年中通过了对TERADATA数仓迁移的决策，决定将其搬迁到开源的HADOOP生态体系下。项目于2022年3季度启动，并在2023年10月完成了全部作业的切换工作，已彻底摆脱对国外相关技术依赖，为后续全面信创打下基础。本文通过上海农商银行企业级数据仓库迁移的实践，总结了一套数据仓库迁移的工艺和方法论，希望能为行业提供些许思路。

　　找准核心矛盾，制定合理目标

　　在我行项目开立初期，行内技术专家经过分析认为：一是作为一个企业级数据仓库迁移项目，核心目标就是将其内容搬到一个异构数据库内，所以这是一个科技含量较高、业务含量较低的工作，注定很难得到业务部门的支撑（如业务测试验证），业务部门更关心业务连续性、数据准确性；二是数据仓库系统往往需要频繁承接上下游变动需求，所以也很难有一个需求封版的长时间窗口来支持数据迁移，做到后期需要双线作战。所以我行得出结论，制定一个合理的迁移范围，不要发散，速战速决尤为关键，整个工期一年内为佳。总结如下。

　　首先，通过数据服务或者卸数接口来倒推数据仓库的整体范围，并框定迁移内容，制定方针为“异构搬迁，数据不变”。

　　其次，在迁移前期（迁移项目开始前3~6个月为佳）针对数仓下游系统，如报表、预警系统等进行清理工作。将长期无人使用报表、过期报表、过期预警进行下线，减轻数仓整体负担。

　　最后，切记不要在迁移项目内进行模型优化（即使当下模型在新的数据库或平台上并不适用），因为这会将迁移项目带到非常不确定的一个处境，导致项目无法收尾。

　　定制迁移生命周期，确定迁移顺序

　　我行将数据仓库作业迁移工作划分如下几个阶段：代码移植、数据迁移、测试验证、生产并行、供数切换、持续并行、老版本下线。同时迁移工作会拆分成许多个模块逐步开展，所以在每个模块的迁移过程都要面向上述7个阶段的一个迁移周期管理工作，后续我们要结合下文的分层迁移思路，可以制定一个整体迁移计划。

　　图1 一个标准的数仓迁移过程和各工具对应能力

　　我行企业级数据仓库按主流分层式设计，总的分为四层，包括贴源层、明细层、汇总层、接口层。我们在制定迁移方案时第一个问题就是确定迁移顺序，在项目初期我们共设想过三种方案。

　　一是自下而上逐层迁移。从贴源层到模型层再到接口层逐步迁移，优势是顺序迁移，更贴合“先打地基后造房子”的建设思路，稳定性强，可以做到迁移一层、核对一层；劣势是新老数仓双线维护时间较长，成本偏高。

　　二是自上而下逐层迁移。与上述方案相反，先迁移接口层，模型层数据通过老数仓供给，后续逐层类推。如此迁移完一层即可将其下线一层，新老数仓双线维护时间短，降低维护成本；劣势是容错性较低，一旦下层迁移后无法适配上层数据就涉及下层代码调整，反过来会影响上层已迁移完的作业跟随调整。

　　三是垂直迁移。以业务条线分批次全流程迁移，优势是以业务为导向的迁移能让业务测试人员更好地介入进行测试，也能实现分条线封版；劣势是实施风险较大，在不同的条线间有较多交叉访问或共享底层数据的情况下，要完整切割一条业务线不容易实现；相较于前两个方案，迁移范围会较为混乱。

　　所以综上所述，我行迁移最后使用方案1。方案1虽然在工作量上有所增加，但是逻辑清晰、边界明确、风险可控，在双线维护工作上我们可以依靠一些工具减少复杂度。结合本章开头提到的迁移生命周期和自下而上逐层迁移方法我们可以制定一个比较详全的迁移总体计划（如表所示）。

　　表 迁移计划甘特图

　　善用工具，不搞人海战

　　在迁移实际实践中，我行在前期制定了“多靠工具，少靠人”的方针，根据迁移周期规划了若干工具，并在后续项目中不断迭代，最终形成了迁移核心方法论。方法论可以归纳为六大工具，分别为：自动建表、数据同步、脚本转化、调度转化、数据核验、自动化版本比对。这6大工具是贯穿整体迁移周期的管理及开发手段，我们建议在第一个迁移模块（如贴源层或接口层）的周期内多预留一点时间打磨工具。由于各家银行迁移的情况不尽相同，市面上很少有现成工具适配这6个功能，所谓磨刀不误砍柴工，自主研发工具并多花一点时间留在打磨非常重要。不建议在工具没有成熟的情况下靠人海战（如手工翻译的方法）去盲目开工，首先人工量巨大，临时组建一支稳定高素质的数据团队对一个中等规模的银行来说是比较困难的；其次工具移植往往错误比较容易跟踪定位，手工翻译会由于项目组内手势不同，导致有些错误将比较隐晦难暴露。下文将逐一介绍6大工具的功能定位。

　　1.自动建表工具。将原数据仓库内的DDL语句逐层导出，并批量翻译为目标数据库的DDL语句，此工具所需技术相对较为简单，DDL的格式也较为固定，唯一难点是需要提前考虑2个数据库中部分字段类型的转换，比如关系型数据库中Char和Vachar类型在大数据中往往都是通过String来存储的，这需要迁移项目组提前对数据类型转化进行规划。

　　2.数据同步工具。将原数据仓库内的数据同步至新的数据仓库，在迁移时一般用作同步历史数据，此工具可以在原数据库的官网获取其原生迁移工具，并进行一些二次开发来实现。比如我行需要将TD数据库的内容迁移到大数据集群，TD官网就提供给我们TDCH这样一个工具，我们结合自身情况再将工具进行了包装，实现了可以参数化配置的一键迁移功能、迁移后自动校验功能、动态调整线程的功能。值得一提的是，这个工具会伴随我们整个迁移生命周期，因为后期新数仓的纰漏都可能导致数据有误，需要通过同步老数仓数据来覆盖错误数据，所以可参数化配置的一键同步可以简化后续修数的复杂度。

　　3.脚本转化工具。将原数据仓库内的数据作业脚本转化为新数据仓库的脚本，同时翻译新老数据库的SQL语句，此工具重点难点在SQL语句的转化上，网上有些现成的转化工具，但是我们试用下来都不是特别顺手（一些热门的数据库互相转换工具可能会较成熟）。我们行使用抽象语法树（AST）的方式将SQL语句中的每个元素进行识别再一一转化，这个工具需要打磨的时间较长，建议随项目进度迭代升级工具，目前看来SQL自动化转换依然需要人工介入，依照我们行的迁移经验在项目初期转化失败率基本在30%左右，到了项目后期迭代至10%。这个过程中需要注意的点比较多，比如新数据库缺失函数、隐式转换、随机取数等等问题，需要逐一排查、逐一改进。

　　4.调度转换工具。将原数据仓库的调度程序转化为新数据仓库的调度程序，此工具在实现难度上不大，但是对原数据仓库依赖关系的完整度要求较高。通常由于新老数据库算力不同会导致很多作业批量时序发生变化，部分缺失的依赖在原数据仓库内没有暴露，导致新数据仓库批量时序错误，且错误通常隐蔽不易发现，需要依靠生产并行期数据对比发现。

　　5.数据核验工具。逐层对比新老数据仓库的数据，主要用作测试和生产并行对比使用。跨库对比工具较多，实现方式这边不做赘述，主要提示对比工具使用上不建议抽样对比，尤其是生产并行期。数据仓库一般夜间进行批量，白天有充足的时间窗口可以用作对比数据，目标还是充分发现问题，缩短并行周期。

　　6.自动化版本比对工具。此工具主要在新老数仓并行期对比新老数仓的投产包，确保两边投产版本内容一致，保证数据的可比性，主要对比内容为建表语句、作业版本、调度配置、数据修改项等。除了工具外，严格的项目纪律和版本管理也需要在这个过程中配套定制。

　　管好并行期，项目成败重点

　　上文提到整个数仓迁移工作会存在一个较长的并行期，且没有一个需求封板的窗口期，双线作战会极大加剧迁移隐形成本。若并行期管理不当会导致版本错乱，数据对错无从考证，极大程度上加大了项目的不确定性。而且项目并行期是一个暴露问题的黄金时期，遇到的情况会比测试更加全面，所以一套完善的并行期问题管理方法及优秀严格的项目经理尤为关键。项目管理和问题管理方法本文不做赘述，主要介绍下我行在并行期的问题发现方式。

　　图2 并行期对比方案

　　总体来说并行期的问题发现还是通过新老数据仓库数据逐层、逐表、逐行、逐字段对比来暴露。我行的方式是将老数据仓库的数据每日批量后通过数据同步工具同步到新数据仓库，在新数据仓库完成数据对比，对比差异将记录在问题清单内进行具体分析。当然这个同步及对比工作也需要讲究一些策略，所以上文提及的同步和对比工具都需要具备参数配置的功能来支持我们的对比范围变动。

　　在策略方面我们配套逐层迁移的思路采用了逐层比对方式，这样更契合项目进度，我们定义一个完整的并行期即满足以下两个条件：此表在新老数仓并行执行超过两个月；此表在并行期新老对比一致率超过99.5%。唯有同时满足这两个条件的表即不再进行每日同步对比，视为已通过验收。在实践过程中，即使上层数据通过验收不再对比，而下层对比发现问题，通过具体分析穿透仍然有可能发现上层数据问题，即下层业务逻辑进一步验证上层的数据质量。

　　另外，有种比较棘手的情况是数据核对不上但也无法快速定位修复问题，这里分两类来应对：一是若问题发生在比较上层，错误数据会波及较多其他作业的情形，建议在该作业后添加一个临时数据同步，通过使用老数仓同步数据的方式堵住问题数据的蔓延；二是若问题发生在较下层，波及面不大的情况下，可以先定位问题，再修复脚本后一次性同步老数仓数据覆盖错误数据。

　　以上是我行在历时一年数仓迁移工作后的一些工作方法总结和归纳。数据仓库迁移项目是一个典型的说起来容易、做起来难的工作，每项任务都环环相扣，需要一定前瞻性和统筹性。希望通过我们的经验给予正在迁移和即将迁移的同业一些建设性思考，助力整体行业早日脱困于国外技术依赖。

　　文 / 上海农商银行金融科技部总经理助理 查晓隽

　　上海农商银行金融科技部 程功 焦郁