飞行中换发动机 （二） ：数仓脚本迁移方法及自动化

前不久，我们在文《飞行中换发动机——金融数据仓库架构转型的最佳实践》中介绍了 Kyligence 金融数据仓库迁移的整体方法论以及在某国有大行项目的最佳实践。

本篇将对数据仓库迁移方法论中最为核心的脚本迁移过程进行深入剖析，从血缘分析、数据库对象迁移、ETL 脚本迁移和数据验证等具体环节详细介绍数仓迁移过程中的落地方法以及迁移自动化的挑战及实现，并结合某国有大行数仓迁移项目的实施过程进行解读。

迁移挑战

脚本（主要包括数据库对象和 ETL 脚本）是数据仓库的核心内容，数据仓库的日常运行和有机生长都是依托脚本来实现的。

因此，脚本迁移方案是数据仓库整体迁移方案的重中之重，如何保障脚本本身以及脚本所内含的数据加工逻辑能够被正确、高效的迁移，是整个迁移项目最有挑战的地方，其难度主要体现在几个方面：

• 金融数仓的脚本数量众多，通常以万为单位，多的可能有数十万。比如某国有大行数仓，有着上万个数据库对象（表及视图），数十万的 ETL 脚本。

• 金融行业业务种类多，业务内部关联性强，数据加工逻辑复杂，任务间存在着千丝万缕的关系。

• 海量的脚本和繁杂的加工逻辑，使得数仓迁移难以靠人海战术来实现，自动化是提升迁移效率的必然之路，也是能够大规模迁移的底气所在，否则就是现代版的愚公移山了。这就好比飞行中给飞机换发动机一样，不能指望飞行员从机舱里爬出来手动切换，只有实现了自动化才敢于在飞行中换发动机。

迁移方案

常规的数仓迁移方案有三种，分别是：自下而上、自上而下、部分到整体。下图里我们分别对比分析了这三种方案的优缺点：

（三种迁移方案）

前一篇文章我们已经论述过，庞大的金融数据仓库迁移，无论是系统复杂度还是项目风险，都决定了这件事是无法一蹴而就的，必须分而治之。

在某国有大行数据仓库迁移中，为了控制迁移风险，保证迁移质量，经过 Kyligence 团队和行方的多轮论证，最终确定采用“至上而下”和“部分到整体”相结合的迁移方案（见下图）。

根据数据仓库迁移方案，我们将具体迁移项目的实施步骤从逻辑上划分为以下六个步骤，并会在下文与大家重点分享前面的四个步骤的实现方式。

（迁移实施步骤）

Step1：数据血缘分析

数据血缘分析的重要性

血缘分析，简单的说就是数据之间的上下游来源去向关系，数据从哪里来到哪里去。数据血缘分析是指对数据在流动、处理、融合等实现过程的可追溯，用于对数据处理过程的全面追踪，从而找到以某个数据对象为起点的所有相关元数据对象以及这些元数据对象之间的关系。

在数据仓库迁移项目中，数据血缘分析意义重大，是数据链路分析、影响性分析、问题定位、数据评估、指标波动等一系列分析的基础。

数据血缘分析的实现

数据血缘分析通常通过元数据管理平台来实现（如下图所示）。元数据管理平台不仅是 IT 人员管理数据仓库的重要工具，对业务用户的帮助也非常大。业务用户通过元数据管控平台访问数据血缘关系，可以快速了解数据的来龙去脉，为业务对数据的理解、使用提供参考，进一步拉近了数据平台与业务之间的距离。

金融数据仓库有数十万的脚本，上亿行的代码，所以想通过人工对脚本进行分析是天方夜谭，但血缘性分析重复性工作比较多，所以是自动化迁移工具大显身手的最佳机会。

在迁移项目中，数据血缘分析工作分三步，分别是：血缘关系构建、数据血缘分析、项目迁移设计。

（数据血缘分析步骤，点击可放大）

在某国有大行数仓的初期迁移项目中，基于行里数据仓库的元数据管理平台和 Kyligence 的辅助工具，我们实现了数据血缘关系构建和分析的 100% 全自动化，能够在确定迁移目标后快速进行迁移范围的确定和影响性分析，为迁移项目的具体设计提供了强有力的支撑。

数据血缘分析的案例

在一个以应用 ETL 效率为优化目标的迁移项目中，借助数据血缘分析工具，基于血缘关系模型，从项目结果表切入，通过数据流程可视化页面，Kyligence 迁移团队发现超过 76.4% 的交易数据统计都需要与几个超大表关联。再结合调度监控发现这些处理不仅消耗大量集群资源，而且处理时间、处理链路较长。

迁移团队经过细致分析，结合 Hadoop 平台特性，优化数据处理流程，减少大表的访问，降低复杂统计，增加作业并发，优化后的作业处理耗时基本都控制在 3-6 分钟，性能提升超 60%。

Step2：数据库对象迁移

数据库对象迁移内容

从数据库对象迁移技术细节来看，金融数据仓库需要迁移的数据库对象内容通常比较好确定，主要是 Schema、数据库表、视图、函数、权限等数据库内部的对象组件。

但在做数据库对象迁移时，通常有人会纠结是不是在迁移数据库对象时考虑连数据一起迁移呢？

基于我们的众多实战经验和最佳实践，建议在实际数据仓库迁移过程中，不要过早考虑数据迁移，一定要在脚本迁移完成并且数据验证都通过之后再单独进行历史数据的迁移。

主要原因包括：

• 原有数仓通常包含海量历史数据，数据迁移需要很长时间，前期就开始进行数据迁移，会严重影响项目进度和脚本的验证工作的开展。

• 脚本迁移是个复杂、反复的过程，脚本迁移过程中大概率会导致某些数据库对象不得不做一些调整，会使得历史数据需要被重复迁移。

• 数仓迁移过程中难免会有新需求，新需求、脚本优化等可能会导致设计变更，前期数据迁移将增加后续工作的负担。

数据库对象迁移实现

数据库对象是静态的，不同平台之间的数据库对象大同小异，所以迁移起来难度不大。虽说数据库对象迁移从技术上说复杂度不高，但数据库对象的量非常大，即使每一个对象的迁移都可以快速完成，但量变引发质变，像银行业数仓迁移这样数十万数据库对象的数仓，用手工迁移是不能被接受的，是自动化工具闪亮登场的时刻。

在通过自动化工具正式迁移之前，我们首先需要先梳理新老技术平台数据库对象之间的差异和迁移规范，主要的内容包括：

除了上面列出的迁移规范之外，在某国有大行项目中，由于是从 MPP 数据往 Hadoop 平台进行迁移，除了常规的数据库差异，还有着其他架构层面的差异需要着重考虑，比如，基于 MPP 的数据仓库通常会设计很多拉链表（维度建模 SCD2 的具体实现），在迁移到 Hadoop 之后，由于技术上的差异，大部分拉链表会被改成分区表。

如果说字段类型转换、函数替换通过简单配置就能够支持，那对于拉链表转分区表，库表 DDL 的迁移就需要进行定制以重点解决下面几个问题：

• 表名维护：新分区表 DDL 命名变更，按分区表的命名规则更改新表名。

• 字段维护：新分区表 DDL 新增分区字段，删除拉链表特有字段。

• 清单维护：梳理需改造的拉链表，支持批量导入、删除，单表添加、删除等功能。

在某国有大行项目中，我们通过对原有自动化迁移工具的二次升级，可以通过配置的方式来实现拉链表到分区表的自动 DDL 转换，实现了建行数据仓库数据库对象从 GP 到 Hive 的 100% 自动化迁移，大大减少了手工迁移的工作量，降低了迁移的风险。

Step 3: ETL 脚本迁移

ETL 脚本迁移方案

ETL 脚本迁移是数据仓库迁移的核心工作，同时也是数据仓库迁移最复杂、最费人力、最费时间的工作，迁移的脚本质量直接决定了数据仓库迁移的成败。

金融数据仓库监本迁移难度很高，尽管我们希望实现 100% 的全自动，但是因为种种困难，总会存在一些自动化的困难，需要人工介入，比如：脚本优化。 在某国有大行的项目里，根据对数据仓库迁移的难点评估，迁移项目组最终做出脚本迁移工作以工具迁移与人工迁移相结合的方式迁移方案。

• 工具迁移，承担近 90% 的脚本迁移工作，主要负责 ETL 脚本的平迁和固定规则的改造。

• 人工迁移，承担近 10% 的脚本迁移工作，主要负责优化及新需求实现。

ETL 脚本迁移实现

• 脚本平迁

由于 ETL 脚本数量非常多，所以脚本平迁的工作量非常大。但因为新老平台的 ETL 脚本都是以标准 SQL 作为基础，得益于 SQL 的广泛流行和较高的标准化程度，近 90% 的 ETL 脚本都是可以由迁移工具自动完成的，那么迁移工具是如何实现自动化的呢？ 脚本迁移工具的核心步骤分三步：读取脚本、生成抽象语法树、拼装脚本。

（脚本迁移工具步骤，点击可放大）

当然，由于 MPP 与 H adoop 的架构差异，在 ETL 的一些处理方式上仍然存在众多差异，比如 Update 操作、拉链表改成分区表后 ETL 加工逻辑的变更等等。这些差异对 ETL 脚本拼装影响比较大，而且涉及的 ETL 脚本量比较多，但是在针对这些差异的改写方案进行深入研究之后，我们可以发现改造前后脚本都是有着一定规律可循的，因此，我们最终通过优化自动化迁移工具实现了这些关键加工逻辑的自动改造。

• 脚本优化

脚本优化工作大部分是需要人工参与的，虽然需要优化的脚本数不是很多，但是因为各个脚本的差异比较大，所以人工优化的累积成本投入比较高。

在某国有大行项目里，项目组借助数据流程图、作业调度对批量时效进行综合评估，发现 80% 的时效问题集中在 20% 的脚本中。在快速锁定需要优化的 ETL 脚本后，迁移团队按照业务重要性和影响范围明确优先级，再安排人工逐一优化，以达到 20% 的人力投入解决 80% 的性能问题“二八原则”。

• 新需求承接

所有人都希望迁移过程中，老数仓是个静态的系统，可以让我们从容改造，就好像让飞机停下来换发动机。但现实里，新需求是数据仓库迁移过程不得不面对的问题，并且需要我们以积极的心态去面对新需求。业务之所以将新需求提给新平台，至少说明业务对新平台报以很大的希望。新需求的承接，不仅会增加业务对新平台的粘性，而且是引导业务参与数据平台迁移的一条捷径。

对于新需求的实施，迁移团队需要分析新需求和现有迁移项目的交集，统筹考虑实施方案，甚至会将现有迁移项目中的部分内容提高优先级，与新需求整合后同步实施，这部分内容只能是通过手工实现了。

ETL 脚本迁移案例分享

• 拉链表 ETL 脚本自动转化

基于 MPP 架构的数据仓库，大部分模型都是拉链表的设计，虽然 Hadoop 平台不太推荐使用拉链表，但是又不能完全禁用拉链表，所以拉链表迁移是数据仓库迁移 Hadoop 平台的拦路虎。

对拉链表的迁移方案不仅需要考虑 Hadoop 平台特性，而且要顾及数据特征和数据应用场景，同时还要考虑自动迁移的难度及后续运维的成本。

综合考虑 Hadoop 架构特性和拉链算法特性，Hadoop 平台的拉链表采用分区设计，分别存储开链、闭链数据。每次更新时，将闭链数据插入闭链分区，再全量更新开链数据，这样不仅拉链算法稳定，适合工具批量迁移，同时还提高了数据仓库 ETL 从拉链表访问最新数据的性能。

通过以上分析可以看出，在拉链表迁移过程中，ETL 脚本的改造是有着明显规律的，自动化工具可以大显身手。由于金融数仓中，拉链表在所有数据库对象的占比非常高，通常超过 50%甚至更多，通过自动化迁移不仅提高了拉链表脚本的迁移效率，而且与数据库对象迁移无缝对接，大大降低了迁移风险。

• 拉链表 ETL 脚本自动转化

Update 操作在 MPP 架构的数据仓库是比较常见的，但是在 Hadoop 架构的数据仓库下就碰壁了，如果自动迁移工具无法支持，将直接挑战自动迁移工具的实用性的底线。

经过我们的研究和反复验证，最终在自动化迁移工具中选择借助元数据信息，使用 Overwrite 改写 Update 的方案。Update 改写属于数据仓库迁移中有规律可循的改写，在对迁移工具进行优化、改进后，可以实现自动转译，从而实现了对脚本中 Update 语句的自动化改造。

Step 4：数据验证

数据验证的意义

作为以数据为核心的数据平台，交付的数据质量是至关重要的，因数据质量问题导致项目被延期、否决的案例屡见不鲜。同时，我们也经常看到严谨的数据验证，不仅保证了数据平台的质量，体现了数据平台的价值，而且有助于树立用户对数据平台的信心。

数据验证的实现

数据验证是整个数仓脚本迁移的把关环节。数据验证通过，才能说明前面的血缘分析、对象迁移和脚本迁移等步骤的正确性。反之，如果数据验证没通过，那无论前面做了多少工作，实现了多少自动化，可能都是竹篮打水一场空，还得返工重来。

所以，数据验证是非常关键的环节，也是很让人揪心的一个环节。设计科学合理的数据验证方法，并且尽量实现数据验证的自动化，是我们一直努力的方向。

数据仓库迁移过程中，数据验证工作量非常大，而且经常需要验证好几轮。在数据仓库迁移项目中，我们将数据验证工作分为两类：

• 数据验证工具自动完成的数据验证：迁移团队将前期数据探索中适合工具自动验证的部分转化成验证规则，借助数据验证工具实现自动数据验证。数据验证的结果分绿、黄、红三个级别，自动推送到订阅人的邮箱。

• 需要人工介入深入分析的数据验证：对数据验证工具发现的问题进行深入分析、判别主要还是以人工为主。

从上图可以看出，对于每一个迁移的数据库表或者视图，我们可以从记录数、关键指标（客户数、账户余额、交易金额）等方面针对性的设计验证目标。通过自动化工具来对新老系统中的同一个表进行迁移后的自动比对。

但是，不得不承认，虽然初始的数据验证可以通过自动化工具进行，但是在实际项目中，数据验证步骤仍然是消耗人力最多，最让人抓狂的一个环节。以某国有大行项目的商户应用为例，迁移后的数据验证工作，自动化工具大约只节约了 35%的人力，剩余 65%工作量依旧需要依赖人力。

为什么会这样呢？这是因为不少数据库表迁移后都会发现数据验证不一致的情况。自动化工具可以发现问题，但是没法定位和解决问题，需要人工去介入。虽然整体来说数据验证人工介入分析的场景并不是很多，但是由于每次分析、定位的问题复杂度很高，所以消耗的人力成本反而是整个迁移步骤里最高的地方。

这里稍微展开谈谈导致数据不一致问题的原因，抛开自动化工具或者手工迁移过程中本身的错误不算，导致数据不一致问题的核心是数据质量问题。

归纳起来主要就下面四点，并且需要手工介入和处理的方式方法又略有不同，因此使得数据验证的环节始终难以实现较高的自动化程度。

以某自助查询案例为例，该案例有一张维表“签约渠道”，存放着银行签约的渠道码值和签约渠道名称。但是随着业务的不断发展，签约渠道也在不断的调整，事实表不定期有新的渠道码值进入，但是维表的调整却一直比较滞后。这类问题是数据仓库比较常见的问题，但对数据质量的影响非常大，也对数仓迁移的数据验证带来了很大的困扰。

由此可见，在数据仓库或者数据集市等数据平台建设过程中，数据质量的把关是个非常关键的环节，不但是数据平台价值的保障，也能为日后的搬家扫除潜在的隐患。

结语

数据平台的迁移和数据平台的建设一样，都是系统化的工程，需要成体系的方法论和一系列配套的自动化工具。某国有大行数据仓库迁移的应用已经顺利完成和上线，我们再次验证了金融数据仓库迁移解决方案的优势，打造了最佳实践，也为后续大规模的迁移积累了可复制的实施工艺和自动化工具。

但是我们并没有停止前行的脚步，在数据血缘分析、ETL 脚本迁移、数据验证等方面我们还有很多事情可以做，自动化工具也还有很多可以持续优化的地方，在数据高速同步等方向上我们也将深入探索。

数据将是未来每个企业的核心资产，数据平台的持续建设和迁移也将是每个企业都需要关注的焦点。后续我们还会陆续发布系列文章，对项目中的经验和最佳实践不断总结，并深入解读每部分内容，更多精彩，尽请关注我们的公众号。

我们一直在路上，期待与您同行。

作者介绍：

张荣钢，Kyligence 交付中心高级架构师，有十多年银行数据平台实施经验，多次参与数据平台的升级、优化，对金融数据平台建设有丰富经验。

本文转载自公众号 Kyligence（ID：Kyligence）。

原文链接：

https://mp.weixin.qq.com/s/8Ym5v6d0jcQSKDIjo-GzQg

相关阅读：

飞行中换发动机：金融数仓架构转型的最佳实践