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

中国建设银行有着将近 20 年的数据仓库建设历史，其技术平台的转型和应用建设过程，既是引领国内各大银行数据仓库建设的标杆和榜样，同时也可以说是国内银行业数仓建设历程的一个缩影。

2000 年初，建行开始启动数据仓库的规划和构建，最早采用了 Teradata 一体机平台，为业务提供了集成、统一的数据仓库平台，但随着数据量和分析应用数量的快速增长，一体机平台成本昂贵、技术封闭等痛点开始显现。

2012 年，建行启动新一代架构建设，在数据线引入基于 X86 架构的 MPP 数据库 Greenplum，取得了软硬件解耦、降低成本的效益。但随着应用场景的深入和数据服务需求的爆发，MPP 平台并发能力差、扩展能力受限的问题开始凸显。

大数据时代，传统数仓面临的挑战

大数据云平台在建设之初选择了对现有数仓应用进行迁移和平台国产化作为目标，已解决现有数据仓库平台迫在眉睫的成本高、效率低、可控弱的痛点。

众所周知，旧屋改造远比建新房要复杂的多。建行数仓历经近20年的建设，已经形成了一个具有数十PB数据量、数十个集群、数万张库表、数十万脚本的巨无霸系统。 迁移如此复杂的系统，引用行领导的一句话： “迁移难度不亚于飞机在空中更换发动机，任何风险都可能导致飞机坠毁。 ”

因此，在技术方案上，需要对每个技术关键点都能考虑周全，深入探索每个技术细节并进行充分的论证和测试；在迁移方法上，需要科学完善的实施方法论，充分考虑迁移项目的工程特点和平滑过渡目标，把迁移风险做到可识别、可分析、可预测、可防范；在实施资源上，不仅需要团队对于新技术具有前瞻性和把控能力，更需要对原有数仓体系的盘根错节有着深入了解，能够在风险发生时从技术、方案、业务等不同层面提出应对方案，及时化解风险。

Kyligence 作为国内大数据技术的领导者和智能数仓建设的专业厂商，依托自身在大数据研发上的深厚技术功底，以及数仓领域丰富的建设交付经验，通过与建行合作，打磨出了一整套行之有效、经过实践检验的技术方案和实施方法论。

下文将结合建行项目从方案设计、ETL 迁移、应用迁移、生产试运行四个方面对迁移项目过程中的关节环节和应对方案进行概述。

Kyligence 迁移实施方法论

技术平台的选型

既然是迁移，技术平台的选择是首先需要考虑的因素。从业内主流方案来看，传统数仓迁移的技术选型方向通常有两种：一是从数据库到数据库（简称 DW on MPP），二是从数据库到大数据平台（简称 DW on Hadoop，此 Hadoop 并不是狭义的 Hadoop 三驾马车，而是指的是以 Hadoop 为基础的大数据技术栈，或者叫广义 Hadoop）。

• DW on MPP 方案因为两套系统都是数据库（并且基本上都是MPP数据库），所以虽然产品不同，但技术路线差异不大，源平台和目标平台的兼容性问题相对较少，技术上的风险也就相对较小。但由于 MPP 数据库的成熟度和扩展性问题，此方案只能算是过渡方案，收益也是相对比较短期的，长期来看必然会碰到上文所提到的建行（Teradata to Greenplum）已经踩过的扩展性、稳定性的坑。而且很多时候，为了技术可控的目标，大多数都是选择从成熟MPP产品迁移到新兴 MPP 产品，当系统体量上去之后，未知的技术风险仍然是很大的。

• DW on Hadoop 方案因为涉及到源平台和目标平台的差异较大，兼容性问题会比较多，技术风险也是相对较大的。 但是 DW on Hadoop 方案本身在互联网行业，无论是数据规模还是技术架构，都已经被证明是经得起考验并且非常成熟的架构，技术的前瞻性、可扩展性和灵活度都要优于 DW on MPP 方案 。只是金融企业的业务复杂性和历史包袱要远高于互联网行业，而金融行业在大数据技术能力方面的储备的又要弱于互联网企业，所以即使知道目标在哪里，但是出于对整个迁移过程的风险没有掌控力和信心，所以此方案在金融企业一直未有成功落地的实践。

对比两种方案的优缺点，考虑到建行的历史和现状以及大数据云平台的长远规划，结合 Kyligence 自身的能力和优势，建行最终选择了 DW on Hadoop 方案作为数仓迁移的目标。

当前，Hadoop 平台分布式架构几乎无限的扩展能力、廉价的存储成本、强大的计算能力已经得到普遍认可，但这只是解决了数据“进”和“存”的问题，所以业内通常也只是把 Hadoop 定位为数据湖或者 ETL 加工平台。

但如果要承担数据仓库应用，如何解决数据的“用”和“出”的问题，为业务应用提供低延迟、高并发的数据服务能力，一直是系统建设的难点。

基于多年对 Apache Kylin 的技术调研以及和 Kyligence 的合作，建行引入了 基于 Apache Kylin 的 Kyligence 增强型分析平台作为大数据云平台之上的智能分析加速引擎，智能提升查询时效和并发能力；再结合现有的前端 BI 工具和数据服务产品，可以在业务无感的情况下做到现有应用的平滑过渡和性能提升，提升业务部门的数据分析体验，并且能够进一步提供海量流水分析、自助分析等新的数据应用方式和分析能力，降低业务的用数门槛，强化科技赋能业务的能力。

迁移方案的制定

建行数仓有着多层的数据架构，数百个分析应用，上万的数据表，几十万的 ETL 任务和依赖关系，如此复杂的系统，从哪里开始切入，采用什么样的迁移方式，如何在工作量、风险和收益之间取得平衡，是一门科学，更是一门艺术。

Kyligence DW on Hadoop 技术方案

一蹴而就的整体迁移听上去很美，但稍微评估一下就知道可操作性几乎为零。因此，基于对建行数仓的深刻理解和需求调研，我们最终采取了“垂直解构、先急后缓、差异覆盖”的小步快跑迁移策略。

垂直解构

既然整体迁移不可落地，那化整为零就是唯一的选择。但具体怎么化整为零，应该水平解构还是垂直解构，又是摆在项目组面前的一个难题。

水平解构就是按照数仓的数据层次进行拆解和迁移，比如先从缓冲层、模型层或者中间层开始，层层迁移。这种方式的优点是复杂度低，容易划分迁移范围，迁移过程的风险相对较低。但缺点也是非常明显的，每个层次的数据加工特点是不同的，各个层次需要面对的技术挑战也是不尽相同，逐层迁移可能每次都无法达到充分“踩坑”和“填坑”的目标，不到最后始终无法评估技术方案的风险可控度。

而且这种方式不到最后，对于项目的最终价值也无法充分体现，如果迁移后的成果没法直接给业务端带来明显的体验改善，项目的价值收益也就无可评估了。

所以，我们最终选择了按照应用主题的方式进行垂直解构和迁移。

先急后缓

既然选择了按照应用的方式进行垂直解构，那该怎么选择具体的应用？在应用选择上，我们首先确定了先急后缓的原则，也就是先选择现有平台上痛点最明显、业务部门抱怨最多的应用进行迁移，这样既能最快的卸载现有平台的负载，快速解决短期痛苦，又能充分体现价值。

差异覆盖

痛点应用太多，但每次的实施时间窗口和资源都是有限的，为了达到小步快跑的目的，每期的迁移应用不能太多才能快速见效。

所以差异覆盖，指的就是在每期应用的选择上，从应用模式和加工流程两个角度，充分考虑不同应用的特点，尽量覆盖不同类型的数据分析应用，以达到尽早踩坑和积累最佳实践的目标。

结合以上的迁移原则和建行的应用调研结果，我们抽象出了三种应用迁移场景：

• 场景一：查询响应慢，业务部门抱怨大，希望能够速提升业务体验的应用，可以直接将加工好的结果数据迁移过来，通过新平台直接提供数据服务，提升查询体验；

项目落地部署方式及原则

ETL架构和脚本迁移

ETL 是数仓的骨骼，因为技术平台的改变，原本 ETL 脚本应该如何改造和迁移，是迁移项目中工作量最大、难度最高的环节。

ETL 引擎的选择并不难，Kyligence 基于自身的经验积累和成功案例，考虑到尽量保障新老平台的兼容性，并且结合 Hadoop 技术栈的发展趋势和成熟度，选择了目前最为流行的 Spark 计算引擎作为大数据云平台的 ETL 引擎，这也是众多互联网 DW on Hadoop 平台的一致选择。

但要把数十万 ETL 脚本从 MPP 数据库迁移到 Spark 引擎，考虑到 MPP 数据库和 Spark 引擎在底层技术架构上的差异，数十万脚本之间复杂的依赖关系，全靠人工来分析和迁移的话，那最终的结果就真的是血肉筑成了。

为此，我们开发了包含数据血缘分析、脚本转换、数据核对等一整套的智能化自动迁移工具，通过对脚本依赖关系进行提取、ETL 脚本自动转换、ETL 数据结果核对的全过程进行自动化操作和监控，来简化 ETL 脚本迁移和数据比对的工作量，确保 ETL 迁移这个项目实施环节中工作量最大、风险点最多的环节得到大大简化和有效控制。

• 血缘分析 ：数据仓库的依赖关系错综复杂，外三层里 N 层，任何一条路径分析错误可能导致整个迁移项目返工，所以需要通过数据血缘分析工具，提取出迁移目标表和作业的属性，包括表的依赖关系、相关脚本范围，字段血缘，作业血缘等，精确分析每条路径的所有依赖关系，确保依赖不丢失、不冗余、不重复；

数据模型的优化

如果说 ETL 是数仓的骨骼，那数据模型无疑是数仓的灵魂。对于金融行业的数仓从业者来说，谈到数仓迁移，通常觉得最困难的、也最关心的都是数据模型的改造。

但对于迁移类项目，模型的迁移原则却是能少动就少动，毕竟灵魂的改造是最难的。系统迁移最大的风险在于迁移过程中的数据不一致会导致原有应用的不可用，影响现有业务，从而没法实现平滑过渡的目标。而模型改造必然会引起后续数据加工逻辑的变化，从而以多米诺骨牌的方式影响到后续一系列数据应用的可用性。

但另一方面，从 MPP 到 Hadoop，技术平台的改变，底层架构的巨大差异（比如数据存储方式的差异、查询优化机制的差异），又不可避免会需要对模型进行改动以适应新的技术特性。

所以，对于数据模型，在迁移项目的初期我们的整体原则是先做平移再做优化，拒绝一步到位的大规模改造，在系统风险最可控的情况下进行定点优化。

当然，具体到实施方法上，我们可以把数仓的模型分为底层的数据整合模型和上层的应用集市模型两部分，结合新老系统的技术差异，两者的设计方法和优化策略也是不同的。

数据整合模型

因为历史原因，国内金融机构的数据整合模型通常都是以FS-LDM 为基础，建行也不例外。FS-LDM 站在企业数据架构的高度，以金融业务视角进行抽象和设计，其普适性和可操作性都得到了实践的检验，有着经久不衰的生命力。

但 FS-LDM 在 MPP 平台上进行物理化时，会优先考虑数据存储成本和扩展灵活性，基本采用范式建模的方式。这种设计方式方便数据进入，但对于后续的数据加工和数据分析，却带来了巨大的关联成本，这在 MPP 平台上一直都不是大问题。但对于 Hadoop 架构，却无疑是一场噩梦，平移后的不少脚本都会出现 ETL 性能下降的情况。所以在数据整合模型层面，我们对于平移后性能下降明显的关键模型，会基于“逻辑模型不动，物理模型优化”的方式，对原有范式模型采取维度建模、逆范式等方式进行优化，依托 Hadoop 的存储成本优势，以空间换时间的方式取得 ETL 性能和灵活性之间的平衡。

应用集市模型

数仓里应用集市模型通常都是维度建模或者大宽表，这种设计方法原本已经比较适合 Hadoop 平台的技术特点。但如上文所述，在整体技术架构上，Hadoop 平台增加了 Kyligence 产品作为数据集市和前端应用之间的数据服务层，以获得比 MPP 平台更加极致的查询性能体验，并且能应对高并发的数据服务需求。数据服务层面向前端应用场景，其模型设计需要充分考虑业务人员的查询使用模式和习惯，如何设计才能在不影响业务原有使用模式下，透明加速整个查询体验，是在迁移过程中对应用集市模型进行优化的主要考量点，比如：

• 库表分区列的选择；

• 维度的设计和Rowkey的排序；

• 维度值的编码方式等；

考虑到建行数仓经过历史的沉淀，每天的查询量有几十万笔，如果对这些查询语句一一进行分析，找出共性和优化的方法，再进行物理模型的设计和优化，将又是一项巨大的工程。Kyligence 产品内置的智能建模功能，可以通过批量的获取和分析历史查询语句、使用频次以及响应时间等行为日志，对数据服务层的多维模型、维度及度量进行智能推荐和优化，从而可以大大节省应用集市模型的优化难度。

Kyligence 智能数仓方案和迁移实施方法论，通过建行一期的信用卡主题、商户主题、对公存款等应用的落地，经受住了海量数据和大规模复杂系统的检验，充分证明了 DW on Hadoop 方案在金融企业数仓建设上的技术可行性，也为建行大数据云平台的建设带来了明显的收益：

• 通过大数据分布式架构的扩展能力，实现了建行数据的统一存储，让数据分析时间跨度可以从 18 个月扩展至 5 年，可以更好的满足精准营销、智能风控等大数据分析应用内的数据需求；

• 通过 Hadoop 强大的并行计算能力，提高 ETL 加工时效，应用迁移到新架构后，ETL 任务的加工时间提升了约 60%~80%，使得数仓的批量数据加工时效 T+1 成为可能；

• 通过“空间换时间”和智能加速技术，迁移应用的查询性能提升了 60~170 倍，并且并发能力提升约 5~10 倍，实现了业务人员在任何时间都可以与数据进行实时交互、随意钻取分析明细数据；

如前所述，系统迁移正如旧屋改造，前难度和复杂度远远高于新修一栋房子，而数仓系统迁移，特别是建行这么大数据量、这么复杂的数仓系统迁移，其复杂度和工作量已经不仅仅是旧屋改造可以比拟的了，甚至可以算的上是城市搬迁了。

Kyligence 有幸能够参与到建行数仓转型和大数据云平台的建设过程中，以上的几个点只是我们在国内金融数仓架构转型过程中对于最佳实践和实施方法论的一些概要介绍，其实除了以上提到的几个点，即使是需求调研、项目管理、人员储备甚至是系统运维这些所有项目都存在的常规环节，都会因为量变而引发质变，从而成为巨大的挑战。

后续我们会陆续发布系列文章，对项目中的经验和最佳实践不断总结，并深入解读每部分内容，更多精彩，尽请关注我们的公众号。

关于作者

吴春贵，Kyligence 交付项目总监，有十多年银行数据仓库项目实施经验，曾经参与多家大型银行数据平台建设，对于企业架构转型有着深刻的理解和丰富的经验。

更多阅读

• 银行数据平台进化的最佳路径是什么？

• 技术引领，数据赋能——建行大数据能力建设之路  

• 从报表到数仓，中国银联如何破解大规模数据分析命题

• 中国大地保险的大数据应用架构演进之路

点

下载 Greenplum 无缝迁移到大数据平台解决方案