近日，有幸参加了2023金融业数据库技术大会。本次大会以“数据库赋能数智金融发展”为主题，邀请管理部门、金融机构、科技企业、研究机构等多方，共同对我国金融业数据库技术的研究进展、应用实践、风险挑战、发展趋势等进行了深入探讨与交流。金融业作为数据应用“高地”，一直以来都很重视底层基础平台-数据库的建设。特别是近些年来随着金融业务转型、自主创新需求、新技术架构突破等因素，数据库在金融领域的应用正呈现一些新的变化趋势。下文是我参加会议后的一些感受。
1. 参会有感：技术篇
1).路线之争：分布式与集中式
曾几何时，谈到新型数据库或信创数据库，大家都不约而同认为是分布式数据库。确实，近些年来分布式数据库发展很快，很多国产数据库也采用了分布式架构。同时在金融客户的国产化替代过程中，因为对国产数据库在稳定性、扩展能力、算法优化等方面的担心，用户也愿意去考虑选择分布式架构。但从真实业务系统来看，超过70%、甚至80%以上的业务系统是可以采用集中式架构来解决的，而且其综合成本、运维资源、技术成熟度等更具优势。那么如何看待这一技术路线之争？用户又如何进行两种路线的选择呢？很多乙方厂商，给出的自己的答案。
❖ 集中式分布式一体化
从技术长期发展来看，集中式和分布式不是完全割裂的，而是可以做到统一。采用一套内核代码，使用统一的开发、运维接口，可以在两种架构间平滑过渡。用户不用去纠结选择哪种架构，而是可以根据需要随时切换或升级架构。我们也看到了有厂商提出诸如“单机分布式一体化”的理念，正是基于这一考虑。
❖ 单一平台，多种架构
分布式架构，经常被诟病的是组件众多、使用复杂、成本投入高，特别是对于应用而言，不可避免的需要进行数据分片后的改造。一种新的思路是，基于分布式架构提供多种运行模式，针对数据规模有限、扩展需求不大的场景，可以使用“单分片”架构，这样即可以充分利用分布式带来的收益，保留未来扩展的可能性；又可以减少应用迁移改造的成本，可以快速实现业务平迁。对于数据规模大或有扩展需求的，可直接选择分布式架构。这样实现，一套平台，两种架构，满足不同场景需求。
❖ 充分挖掘单机潜力
随着近年硬件技术的快速发展，单机的能力有了巨大的提升，也就是说硬件上限被提的很高。在单机/集中式架构下，中小规模的应用其综合使用成本是较低的，达到一定规模后会不及分布式架构的成本低；但这一规模已经可以满足绝大部分用户需求。因此，我们也看到近些年诸如“一体机”形态有重新火热，通过极致的硬件组合可以满足大部分需求，且通过一体化管控降低运维压力。
2).产品选型：选路线非选产品
在具体的数据库产品选项上，参会的很多甲方企业经过前些年的实践，已经形成了自己的一套方法论。总结下来，可以大致总结为以下一些原则：
❖ 根据场景，选择产品
面对金融企业复杂、多样的业务场景，很难找到一种“one size fit all”的数据库，之前的一家数据库独大的情况不再会发生。用户可以根据协议、负载、并发、容量、形态等多种因素进行选择。我之前也曾总结过，金融企业需整理自己的数据库应用矩阵，来满足内部的不同需求。
❖ 选择标准，而非产品
这里所说的标准，是指数据库的生态标准。与之前使用国外大型商业数据库不同，国内数据库产品的生态建设相对较晚，还没有形成生态标准。因而在产品构建上大多选择了兼容性，常见如对Oracle、MySQL、PostgreSQL的商业数据库或开源数据库的兼容。后续在设计开发层面，仅需面对生态标准编程即可。因此，在用户选择上选择某种标准是比较好的做法，如选择小众产品又没有兼容生态，则会冒很大的风险。
❖ 选择多家，不依赖绑定
即使是某款产品能很好地满足需要，在选择时也要考虑其他可能，做到可随时替代。一方面是因为厂商本身的不确定性带来的风险，一方面是厂商的供给服务能力存在一定制约，难以满足需要。选择多家，可以有充分的灵活性，同时在采购、续约时也能保有一定话语权。
❖ 不迷信、不盲从，自主测试
目前国产数据库厂商非常大，各家能力也参差不齐，很难通过一两次交流就做出选型。同时，不同机构的业务场景也有其自身特点，很难采用通用的标准进行评测。很多甲方已经总结出符合自己情况的一套测试标准，通常包括有功能、非功能、性能、高可用等测试。通过这种方式，做出自己的选择。
3).扩大场景：HTAP 成为刚需
此次大会上，很多用户与厂商都同时提到了 HTAP 能力。确实，对于金融企业来说，很多场景很难通过简单的OLTP、OLAP 进行划分，混合负载的场景成为常态，这对国产数据库来说提出了更高的要求。其实从本质来说，之前很多国外的商用产品，都是一种 HTAP 架构，也只有这样才能满足金融业务需求。虽然针对 HTAP 这一能力，不同厂商的实现技术差异较大，尚无统一的技术标准，但各家都将这一能力的提升作为产品的核心竞争力之一。相信未来针对这一技术能力，会形成技术共识。
4).降低门槛：全方位多层次兼容
兼容性也是这次大会被提及很多的一个能力，很多产品将兼容性提升到一定高度。从底层硬件适配，到内核层面的SQL 语法、库内计算，到管理、安全、诊断、优化等，再到上层驱动、乃至上游生态如开发工具、BI工具等都希望能支持，进而达到全方位、多层次的兼容。即使无法做到兼容，也通过一系列的工具，来降低改造、迁移的工作量，进而减低迁移的门槛。自己之前也曾对兼容性写过一篇文章，参考《Oracle兼容性面面观》
5).规模供给：云化、容器与多芯
随着国产数据库在金融企业的规模化使用，头部金融用户的使用体量已经达到数千、乃至上万节点数。如何快速实现资源供给，成为制约企业实施的因素。与会的很多甲方用户，特别是头部用户，在数据库落地实践后都纷纷开始提升规模化供给能力。这其中技术能力包括有：
❖ 多芯：X86与国产化
所谓多芯，是指底层平台是可以基于X86构建，也同时需要支持国产非X86的方式。这样一方面可以实现利用全国产化平台来承载业务，真正规避可能的卡脖子风险；另一方面可以充分利用多资源池，实现资源供给的多样性。从乙方厂商来看，一方面需适配国产化平台，另一方面将支持资源混部作为突破点，来解决有效利用资源及规避国产平台稳定性风险作为卖点。
❖ 容器：解决管理痛点
在分布式数据库使用中，通常会面临规模大、节点多、组件多、故障多等问题及现象。如何实现分布式数据库的规模化管理成为用户使用上的普遍痛点。容器方式，通过独有资源编排能力，可在一定程度上解决之一问题。部分头部用户，开始尝试使用容器化来解决这一问题。
❖ 云化：实现规模化
IT 的终极架构在云上，金融企业也不例外，随着国产数据库逐步成熟，通过云实现规模化应用成为必然。很多头部用户在已有多年云平台的基础上，支持国产数据库的服务，并通过“行业云”、“信创云”等实现对外或对内的技术服务。这方面相较于公有云，金融企业自己的云有着独特优势。
2. 参会有感：实践篇
1).数据库迁移规模化成难点
很多企业已经在内部做过了国产数据库迁移，有了一定的经验，但这其中的难点在于规模化问题。企业内不是一两套系统，而是可能有上百套、数百套、乃至上千套的系统。如何在有限的时间内，付出可接受的成本完成迁移任务，同时还需保障业务正常开展是个大问题。信创实施不是做科研项目，不能采用定制化的方式，是需要以工程化（低风险）、可复制（标准化）、可推广（服务化）的方式来完成。很多甲方用户在进行一定体量的改造后，建立了数据库迁移实施的规范标准，形成了“评估-实现-控制-改进”的科学方法论，进而实现迁移可评估、数据有保障、运行可观测、风险可控制的迁移能力。形成了一批包括从系统开发、应用改造、应用测试、数据迁移（同步）、数据校验、流量切换、优化分析等一整套工具或平台。但这里有个较大的问题在于，大型金融企业这么做没有问题，但对于广大中小企业而言，既没有足够的技术积累，也没有充足的财力支持，只能依赖于乙方厂商完成这一过程。因此如何将大型金融机构的成熟能力为其他用户赋能，是个关键问题。
2).数据库稳定运行风险
金融企业最为关注的是数据安全及业务可用性，作为数据的重要载体，数据库承担着至关重要的角色。如何满足金融行业对数据一致性、运行可靠性的要求是进行国产化改造的关键。一方面乙方厂商通过自身技术积累、海量实践磨合、新架构技术突破等手段来解决这一风险；另一方面作为甲方的用户也在通过一系列运营手段来解决这一问题。很多甲方企业已经总结出一整套生产实施工艺，包括从可研评审、开发测试、迁移切换、基线管理、版本升级、配置管理、高可用部署、告警监控、应急处置等多个环节来解决。尽量从流程上去解决引入数据库可能带来的运行风险。
3).实施方式多种路径各异
在具体的实施路径及选择方式上，不同企业差异很大。有的采取了“先核心、后推广”的策略，通过核心系统迁移积累经验、磨合产品、锻炼队伍，为后续的规模化复制做好铺垫。有的则采取“先外围、后核心”的策略，早期通过外围系统选择合适场景进行试点，然后再逐步深入。有的采取“平滑为主、重点突破”，通过将稳定业务优先平迁到国产库，然后再找难点场景完成分布式改造，即先易后难的方式。这些路径及方式的选择，通常是根据企业的自身技术能力、业务特点、财力投入、战略发展等有关，没有标准经验可复用。
3. 参会有感：发展篇
1).成熟度不足，还需验证
随着国产数据库在金融业的规模化应用，特别是分布式数据库的使用，在过程中暴露出国产产品的一些不足。金融行业作为数据库应用“高地”，对海量规模、高并发、高稳定性等方面均提出苛刻的要求。国产数据库产品在高性能、稳定性、可运维性方面普遍存在短板，需进一步提升。
2).专业人才短缺，阻碍发展
国产数据库（含分布式数据库），存在较大的人才缺口，特别是具有实战进行的技术人员。一方面乙方厂商自有人员不足，三方资源培养也处于刚刚起步阶段；另一方面以分布式数据库为代表，技术领域跨度大，专业技术人才的培养较长；第三方面不仅仅在运维侧、针对分布式架构在研发、架构侧同样继续人才，这方面更加匮乏。
3).无标准体系，推广困难
目前缺乏数据库标准体系，需联合行业与产业端，加强数据库金融应用标准规范建设。覆盖从路线、架构、产品选型，到开发、测试、迁移，再到部署、上线、保障全流程的使用体系；进而推动金融行业与数据库产业融合健康发展。
4).开源生态存在安全风险
开源数据库在金融行业已经大规模使用，很多国产数据库也是基于开源基础进行构建的。需充分借鉴、吸收开源技术、融合开源技术生态，走独立自主演进开源技术道路，实现弯道超车。在使用中应加强开源数据库在金融业的管理、合规治理，考虑收敛技术栈，加强开源数据库风险防范并形成机制。
5).加速从“能用”到“好用”转变
希望数据库厂商，加大投入，针对金融行业客户的典型场景，加快产品迭代，不断优化产品。加速产品从“能用”到“好用”的快速转变，扩大、深化国产数据库在金融行业使用。
6).提升服务意识，做好保障
金融行业是涉及国计民生的重要行业，其稳定性、可靠性尤为重要。希望厂商在应用实施过程中，投入更多资源，做好售后技术保障工作，加快响应速度，制定有效的应急手段，提供全面、优质的服务保障体系。毕竟好的产品还需要好的服务配合，才能在用户处发挥更大作用。
