【FIW2022精彩回顾】数据库领域资深专家韩锋：金融行业数据库自主创新之路

9 月 21—23 日，第一届“金融现代化 IT 基础架构转型论坛（FinTech Infrastructure Wave 2022）”成功举办。该论坛由中国信息通信研究院云计算与大数据研究所、《中国金融电脑》杂志社主办，北京志凌海纳科技有限公司（SmartX）与北京鲲鹏联合创新中心协办。论坛分为三大专场，覆盖银行、保险、证券、基金、期货、信托六大金融细分行业，内容涵盖多云平台建设、核心业务系统自主创新转型、超融合关键场景落地、核心业务 K8s 改造、数据中心零信任安全、基础设施即代码等前沿话题。

数据库领域资深专家韩锋发表了《金融行业数据库自主创新之路》的主题演讲。

文丨韩锋

本文围绕数据库技术发展趋势，结合金融行业特点阐述金融行业数据库自主创新之路。

一、数据库创新驱动因素

金融行业数据库自主创新的驱动因素既有外部因素影响，也与自身发展有着密不可分的关系。总的来说，驱动金融机构进行数据库自主创新的关键因素主要包括以下几个方面。

一是供应链安全。金融行业关系国计民生，其基础软件的安全性至关重要。那么什么是真正的安全？如果项目中使用的是开源产品，又该如何保证供应链安全？笔者认为，保证安全的一个要点就是自主创新，无论是选用商业产品还是开源产品，都必须将核心技术掌握在自己手中，这样才能做到真正的安全。

二是满足金融合规要求。金融业是数据密集型行业，大量业务依赖于数据的产生与流转，对数据的敏感度非常高，同时，金融业的数据通常也具有很高的价值，这些都对数据本身的安全性、稳定性和可靠性提出了非常高的要求。作为国家重点监管的行业，金融业必须满足金融合规要求。

三是业务创新需求。近年来，金融业务正在悄然发生着变化，以银行为例，过去传统的网点人工放贷形式正逐渐被在线银行、手机银行、数字银行等多种线上放贷形式取代，这些新兴业态都对底层的数据基础设施提出了更高要求。

作为基础软件的重要组成部分，数据库被要求承载更多能力，包括分布式、混合负载、多模、智能应用等，这些都是金融业务在金融创新的大背景下对底层数据库提出的新能力要求。

二、数据库的创新改造

笔者认为，数据库的创新改造可分为四个阶段：一是架构选型评估阶段，主要是完成技术栈选型，并开展技术栈培训，完成资源评估。二是研发测试阶段，主要是完成业务系统的改造及测试，也是整个阶段中耗费成本资源较多的一个阶段。三是验证并行阶段，主要是在完成业务系统改造后，对新平台的功能、稳定性、可用性等进行验证，保证后面的替换顺利进行。四是上线支持阶段，主要是在系统经过充分验证后，将业务系统从原技术栈完全迁移至新技术栈，这一阶段的重点工作是提供迁移能力及运维保障。

1.架构选型评估的痛点及其解决方案

（1）技术栈分散

痛点

技术栈分散，尚未形成选型标准，用户选型困难。在生态兼容性上，有兼容 MySQL、PG、Oracle、自有标准等；在架构上，有单机、集中式、分布式等，包括以 NewSQL 为代表的产品；在部署平台上，有私有部署及云端部署（含私有云、公有云）等。

解决方案

解决上述问题的思路是，首先需统一企业内部的数据库生态，明确采用如 MySQL、PG 等为代表的事实标准生态。针对同生态产品（如 MySQL 生态的 TDSQL、GoldenDB、TiDB 等）提供标准能力兼容支持；针对异构生态产品（如 Oracle、DB2）及 MySQL 或 PG 生态，提供等价改写、异常处理（前提是收敛异构间数据库差异，规范标准写法）。

其次需统一企业内部的数据库协议，可通过标准的 MySQL 或 PG 协议访问多种异构数据库。例如通过标准 MySQL 协议接入，底层可对接不同数据源（如 Oracle、DB2）。这种统一接入管理方式，对企业内部数据库管理带来极大便利。

面对企业内部多数据库产品并存的情况，需从全局视角出发拟定数据管理策略。传统竖井式的管理方式在现有碎片化现状下将更加困难，可考虑建立数据标准管理层，将常用的数据管理职能（如访问安全、数据加密）等统一处理。

（2）产品能力层次不齐

痛点

当前，自主创新的数据库产品能力层次不齐，不同产品间功能差异明显，包括内核层面、周边生态层面及管理维护层面等，这使得用户无法使用统一的服务界面。此外，在云产品选择上，用户的自主权不高，存在与原有方式的管理差异。

解决方案

针对以上问题，企业可以增强数据库及周边生态的能力，如针对单机数据库短板，通过引入中间层解决分布式能力，在不改变底层技术栈的情况下，提升数据库的上限能力；加强云适配能力，屏蔽底层变化和管理方式的差异。

2.研发测试的痛点及其解决方案

（1）原系统迁移评估难

痛点

在实际工作中经常会面临一类问题，就是当旧有系统已无人了解或干脆由第三方开发的时候，将会缺乏有效的手段去收集、评估存量业务改造的工作量。

解决方案

这类问题可利用源系统评估工具解决。它不仅能提供数据库评估工具，实现抓取数据库的语句、负载，支持回放能力，同时针对数据库特有的方言、函数等个性化需求改造内容，可生成报告方便工作量评估及改造工作。当然，如果没有工具，通过调研表的方式也可以进行对之前情况的评估。

（2）迁移过程成本高

痛点

很多应用系统严重依赖原有技术栈，如以 Oracle、DB2 为代表大型商业数据库，应用端对商业数据库方言、库内计算（存储过程、触发器、函数等）、生态工具（SQL 优化、数据集成、管控维护）等都存在较重依赖情况，而新技术栈产品差异明显，通过应用研发改造，工作量极大。同时，大量基于商业数据库的开发逻辑需改造迁移，一部分需改造适应新架构数据库，一部分需考虑在异构平台（如大数据平台、缓存平台）或应用层解决。此外，部分改造内容不等价实现，提高了改造难度。

解决方案

为满足在新技术栈下的开发需求，需秉承在架构选型阶段谈到的数据库访问标准层的理念，简化对数据库的使用。对于重度依赖原有系统的，需提供一种方式将旧逻辑向新逻辑转换，这点是比较难的，通常很难做到完全的等价转换。目前，有些工具已经能够实现将复杂的库内计算（如存储过程、触发器等）转化为业务语言（如 Java），可大大加速转化进程。当然，更为重要的还是将两者的差异充分暴露给开发者，让技术人员有的放矢地去改造，明确知道潜在的工作量。此外，可提供一些诸如数据集成、数据管理、SQL 诊断优化的工具，在改造过程中提高开发效率。

还可通过以下两种手段进一步减少改造工作量，一是提升目标平台对源平台的兼容性能力，二是通过中间层实现必要的改写，自动完成不兼容改造。针对第二个方面的诉求，可以通过第三方平台实现，它可兼容新旧平台的语法，同时完成等价转化；针对不能转化的部分，给出异常提示，配合前面的改造改写工具完成内容的修改，不断收敛两者的差异。

（3）迁移结果评估难

痛点

很多新架构产品提供的兼容性能力存疑，仅通过语法层面的兼容或少量改造，很难保证语义上的一致性，这种不确定性会增加系统上线后的风险；同时，缺乏有效的评测手段评估迁移结果，难以有效评估应用迁移前后的语义等价（数据一致性）及性能等。

解决方案

针对上述痛点，可利用迁移结果评估工具，该工具能提供一种验证运行结果的机制，包括但不限于对执行结果一致性的检查、运行效率的检查等，可有效降低系统上线后的风险。

3.验证并行的痛点及其解决方案

系统验证阶段是很多重要系统正式上线前必须经历的阶段。通过上线前的验证，可以大幅降低系统可能存在的技术风险，提高上线成功率。系统验证阶段的痛点主要包括以下几点。

（1）迁移风险高，无法回退

痛点

为了验证系统是否工作正常，一般需要开发大量验证类的代码。这部分工作主要是为了满足系统对新旧技术栈及必要的对比等工作的支持，工作量往往很大，如很多应用常见的数据双发逻辑，通过数据双写同步验证两边执行结果，为满足这一诉求，不得不在原有业务逻辑上开发两套适应不同技术栈的代码。

解决方案

可利用数据双写平台解决上述问题。数据双写平台提供基于中间层的轻量级实现方法，在应用侧无需改动或少量改动代码，即可完成数据的双发写入，满足数据同步写入到异构平台中。为保证数据的一致性，还需提供必要的事务性保证，保证异构数据库间数据的一致性。当一方平台出现异常时，应可自动回退，不影响另一套平台正常使用，能从前端业务自动感知这一变化，可自动适应这一过程，使业务无感，但系统修复后，又可以手工添加回双发状态（需提供异常期间的数据补偿能力）。这一思路的难点在于如何实现在应用代码逻辑不变的情况下支持写入异构库。常见的思路是将数据库的交互语言 SQL 从一种方言翻译成另一种方言，前提是语义等价。此时，就可以参考之前在架构选型阶段谈到的数据库访问标准层，收敛企业内数据库的访问，尽量简化、标准化对数据库的使用，这也是双发验证阶段可执行对比的前提。

（2）迁移验证，无从下手

痛点

在系统验证阶段，还有一个比较难的地方在于如何验证。最好的验证方式是带着真实流量进行验证，但同时还需考虑风险问题，以及如何对业务访问做好精准的控制，按需求进行业务验证，且还需提供必要的回退能力保证安全，如常用的基于读写的分配、基于流量的分发（甚至基于业务特征的分发能力）。

解决方案

可利用流量分发平台解决上述痛点。流量分发平台满足在多平台在线情况下根据策略分配业务访问，可精准地控制其流向，如痛点中提到的读写流量、比例流量抑或是带有业务特征的流量，可感知下方物理拓扑变化（甚至是异构平台间的变化），可对应做流量重分发，不影响业务正常运行。这种方式会为上层应用带来很大的灵活度，可根据需要随时调整验证策略，降低验证期间的风险。

4.上线支持的痛点及其解决方案

（1）迁移窗口短，迁移困难

痛点

在系统上线阶段，迁移窗口期普遍很短，这就需要在较短的时间内完成数据库间（一般是异构）的数据迁移工作，同时还需针对迁移后的数据进行质量对比，以保证迁移数据是正确的。

解决方案

可采用离在线迁移工具解决这一问题。该工具支持异构数据源间的数据离在线迁移，可充分利用物理资源，采用并行处理技术提升迁移效率，满足时间窗口要求。海量数据的迁移通常采用离线与在线相结合的方式，即将静态数据通过离线方式迁移，动态（活跃）数据采取在线方式迁移。此外，还需提供数据对比能力，可根据用户需要进行比对。这存在两个难点：一是如何提升对比效率，满足海量数据对比需求；二是如何实现动态变化的数据对比。针对前者，通常的解决思路是可以让用户选择对比方法（算法），如简单计数、部分采样、统计报表或复杂算法；针对后者，可通过流式窗口比较的方法不断拟合趋近于实时结果。

（2）新上系统不稳定

痛点

新产品、新架构上线后很难保证一定不出问题。虽然可通过充分的测试、并行验证等多种手段尽量减少出现问题的风险，但显然无法完全避免。

解决方案

比较好的方式是提供一种能力，针对可能出现的运行问题，通过一些手段尽量缩小问题的影响范围，恢复业务。可用流量治理平台和系统逃生平台（方案）解决上述问题。

流量治理平台支持数据库流量的统一接入，可通过多种手段（基于标签、SQL 文本、用户名、来源 IP 等）实现对 SQL 流量的精准控制。例如针对低效 SQL，可实现熔断、限流；针对特定 SQL，提供黑白名单；为满足问题排查提供全量 SQL 的审计能力，做到事后追踪等。

系统逃生平台（方案）可提供一种异构“逃生”方案，防止出现系统性风险或全局逻辑性错误。所谓异构，一定是一种有别于现有技术栈的平台或方案，两套平台间的数据是需要做到可控同步的，即可根据需要选择实时同步、延迟同步和人工同步。同时在数据之上，还需提供切换的能力，可满足在异常情况下短时切换需求。

三、数据库改造建议

从过去实践来看，很多业务系统的创新改造比较顺利，但对于数据库的创新改造就比较难。对此，笔者提出以下几点建议。

一是进行前瞻性布局。虽然数据库的技术路线还没有完全成熟定型，但在技术层面要有前瞻性的布局，去选择主流的技术发展路线，采用一些跟随策略，不断在企业内部尝试使用，技术路线都是在企业内部场景中逐步打磨出来的，所以前瞻式的布局很关键。

二是尽量选择和企业内部创建的生态相兼容的标准，这会为企业在后续的调整保留余地。

三是加强自主创新能力建设，要构建自己的核心能力，且保证这种能力自主可控，这样无论下面的数据库如何变化，上层能力都会让企业在做选择时更加从容。

四是广泛合作，无论是引入厂商还是开源项目，通过展开合作，都能快速提升企业的技术能力。

五是做好风险评估，要有预案，能够在整个过程的各个阶段提前预测问题，并提前部署解决方案。

 韩锋，dbaplus社群联合发起人，CCIA（中国计算机协会）常务理事、Oracle ACE，曾担任多家公司首席 DBA、数据库架构师等职务。具有丰富的一线数据库架构、设计、开发经验，精通多种关系型数据库，包括 Oracle、MySQL、GreenPlum、Informix 等，对 NoSQL 及大数据相关技术也有实践经验。著有《SQL 优化最佳实践》《数据库高效优化》等书籍。