带你读《升舱 - 数据仓库升级交付标准白皮书》——3.1 实施标准路径（上） https://developer.aliyun.com/article/1242483
阶段一：调研与设计
该阶段需要实施厂商对原系统上下游做详实调研，需现有数据仓库平台和业务系统进行充分的信息收集，最后迭代输出调研分析报告，并与企业业务方做深入讨论与修正。
调研内容覆盖如下方面：
（1）原数仓系统架构
（2）原数仓数据交互流程
（3）原系统资源盘点
（4）原数仓库表统计
由于数据仓库数据体量一般较大、数据特征复杂，在调研初期需要合理运用技术手段，采集分析现有数据仓库平台数据对象特征、采集分析业务 SQL、关键特性等，并设计合理而科学的迁移实施方案。
阶段二：测试迁移
该阶段主要围绕典型场景验证展开，对现有数据仓库平台涉及的 ETL 作业任务、表 /视图结构、模型、数据、用户权限等进行迁移的论证工作，通过典型场景验证期望暴露更多技术性问题（如 SQL 兼容性、SQL 复杂度、作业复杂度等），用于正式实施阶段更为准确评估迁移工作量；测试迁移阶段涵盖的主要验证范围如下：
（1）数据源迁移
（2）数仓模型迁移
（3）作业调度迁移
（4）数据迁移
（5）新老数仓系统数据比对
（6）下游系统对接
阶段三：生产迁移
通过测试迁移阶段对潜在风险点、卡点性问题逐一排除后，生产迁移过程压力就会随之降低很多，该阶段依托构建的知识库记录详细的操作流程进行评审和实施，确保正式迁移中操作质量和效率；生产迁移阶段主要包括数据迁移、模型迁移和调度迁移三大块。
（1）数据迁移阶段，涉及表众多且数据量大，迁移步骤涉及建表、数据导出、数据文件传输、数据导入等多个步骤，此过程会占用大量的时间和人员，而且每次操作失误可能都需要重来。因此有必要通过标准数据迁移工具实施迁移，工具是实现上要求基于配置的元数据信息，自动生成建表脚本、数据导出脚本、入库脚本，从而大大减轻人力投入，缩短时间成本。本阶段工作的人力投入主要侧重于脚本的执行调度、执行结果的监控和问题的排查处理。
（2）模型迁移阶段，代码量大，全部由人工改写工作量非常大，且不能保证改写的逻辑一致性；针对传统数仓的模型迁移，需要通过模型迁移工具辅助完成绝大部分程序的改写工作，对于特定语法无法改写的还需要输出专门的错误报告供开发人员针对性重构。
（3）调度迁移阶段，数据仓库平台上的一个重要工作是每天定时执行调度任务，各个任务之间还相互依赖；如果基于新数仓平台的调度工具无法和原有调度工具有效兼容，
将会涉及到原有调度任务元数据重新配置问题，将会是项目如期完成的较大变数，这也是前期轻咨询阶段就需要充分考虑验证的问题，再次说明前期轻咨询阶段的重要性。
阶段四：系统并行
一个企业级的数据仓库平台往往需要对接数十上百个上下游系统。出于业务连续性的考虑，升级过程中想要通过“一刀切”的方式将原有上下游系统切换到新的数据仓库平台上几乎是不可能做到的，因此数据仓库平台升级建设进入到投产期将会存在双核心数仓平台并行。为了降低双系统并行带来的额外人力成本，需要关注以下关键点：
（1）变更同步
在新老系统并行阶段业务触发的变更需要新、老系统同步执行，或者有时间计划的异步执行。在有条件的情况下，尽可能的减少业务变更，避免由于作业变更导致的数据不一致，进而导致数据稽核（数据完整性和一致性检查）失败而产生大量的排查工作量，延误项目工期。
（2）数据采集
并行阶段数据采集差异易导致后续数据稽核失败，如两套系统配置各自的数据采集服务，但并行阶段为避免对上游系统产生双倍的压力，将会采用错峰采集的方式，若采集时间发生时间差，都有可能导致采集数据的差异，进而导致数据稽核失败，此类问题难以排查，因此尽可能保证数据采集的一致性十分重要。
阶段五：项目验收
不同于业务系统数据库升级，数据仓库平台升级在项目投产末期无法以数据完全一致作为验收标准的。由于双核心系统并行阶段两边数据库特性或者数据采集等方面的差异，数据不一致的情况无法完全避免，因此需要尽早的与业务方明确切实可行的验收标准，并积极推动验证。
此外、在项目验收阶段还需要逐步建立投产后转入运维的保障机制，确保数据仓库平台升级平稳过渡。
