近期召开的2023 DTC大会，是疫情之后首次线下会议，吸引了众多厂商和观众参与。日前会议相关的材料也分享出来，本文特选取部分内容加以浅析，进而洞悉全行业的变化与趋势。
❖ 架构演进
从数据库架构演进来看，以关系型为例，就走过了从单机、集中式再到分布式的道路。如下图我们可以从业务负载、复杂度、成本等因素，将现有架构产品加以分类。从需求来看，单机及集中式架构仍占主体，但分布式发展不容忽视。当然这其中存在一个误区，就是完全采用分布式产品。有的企业希望通过分布式架构搭建起内部统一数据库服务，可应对不同规格需求；但我仍建议慎重选择分布式产品，只在确定性场景选择并有效评估测试分布式能力后才可上线。
针对这些不同的架构，可以按如下图所示的原则进行对比，按是否共享数据、是否切分数据、是否存算分离等角度进行区分。
不同架构产品各有其特点，需要企业根据自身特点进行选择。因此不存在所谓“银弹”架构，能解决所有问题，其背后对应的应用改造、维护、财力成本是不同的。
❖ 硬件&DB
这些年来，硬件技术发展非常快，出现了硬件与软件发展速度的倒挂，即软件的发展落后于硬件。作为硬件基础，计算单元（CPU多核，GPU、FPGA的引入）、传输单元（高带宽网络）、存储单元（高IO、大吞吐、低时延）等均有突破性的进展，性能有数倍到数百倍的提升。
以NVMe协议的存储为例，其较传统的SCSI接口有了质的飞跃，原来最为头疼的IO性能问题，变的不再重要。这其中蕴含两个问题：一是传统软件架构设计需要更新，基于新型硬件平台设计的数据库会大量涌现（云平台上已经看到了这一趋势）；二是如何利用好新型硬件，整合发挥最大硬件效能成为必然，因而一体机形态产品再次受到关注。
同时，新型硬件还带来了对数据库架构的影响。单机数据库的能力较之以往有了巨大的飞跃，很多原来只能由分布式数据库、大数据平台来承载的业务，可以由单机库来完全承担；而前者（单机架构）在易用性、灵活性、经济性等角度有很具优势。当然分布式架构不仅仅在于容量、性能，其天然还具备其他一些优势，如高可用、弹性等。
❖ 超融合
超融合架构，是尝试解决企业数据分散的一种架构，是数据库之集大成者。相较于传统架构，超融合通过融合更多数据（解决孤岛问题）、融合更多类型（解决多模问题）、融合多种算力（解决访问方式）及标准统一管理（解决管理难题）。这看起来是一种很理想的解决方案，通过一种all in one的方式解决企业数据问题。
如何解决超融合的痛点，有的厂商提出了微内核的概念，为不同场景实现独立内核，内核间实现协同。
并以微内核为核心，下面对接多模存储引擎，上面支持不同计算引擎及计算方式
也有采用全新架构，利用融合型存储引擎及统一计算引擎解决上述问题。
通过对算力、存储、事务三层解耦，实现资源与负载的均衡调度解决冲突问题。
❖ 湖仓一体
数据仓库技术可以说由来已久，从上世纪八十年代独立出单独产品后，不断演进发展，经历了若干发展阶段。最新的以Snowflake为代表的云原生数仓，充分利用云基础设施能力，结合数仓对存储、计算能力要求演变而成。
在其发展的中后期，因数据仓库产品不支持非结构化数据、成本高、不灵活等局限不能满足需求而诞生出一种新技术产品-数据湖，后者可提供更为灵活、低成本的存储计算，但其也面临查询性能低下、实时性、可靠性差的问题。近年来以两者融合的技术方案-湖仓一体，逐步发展起来，其融合两种方案的优点。
在具体技术实现上，如何充分利用云端资源构建新兴数仓也受到关注。例如使用云端场景的低成本对象存储、可弹性扩展的计算资源等。在资源调度上采用更为细粒度的、更贴近工作负载的方式。
❖ AI&DB
从人工智能和数据库结合角度看，下图以具体产品openGauss为例，说明其内置的两种能力。
从运维角度来看，其内置的自治系统提供从采集、诊断、优化、实施全流程，实现了闭环控制。进而达到业务无感下的一键式优化。
除了在数据库中内置这一能力，也可将其外置。如阿里云最早提出的DAS（数据库智能驾驶）以及白鳝老师带来的工具，在实现对数据库的可观测之外，针对指标的加工进而通过知识图谱进行自动化诊断。
❖ HTAP
HTAP是近些年来大家很关注的一个技术方向，很多产品也主打此场景。在这里存在一些技术难点，包括资源隔离、TP/AP场景的定向优化等。例如下图是PolarDB在原有很强的TP能力基础上，又增强了AP方面的能力。
又如GoldenDB的最新版本，也是利用主备库行列缓存、向量计算等实现HTAP能力。
再如 TDSQL-PG，在HTAP的做法通过行列混存、向量化计算引擎、CGROUP资源隔离等技术实现。
❖ Serverless
Serverless 技术，是云数据库近期发展的热点，也成为云产品发展的主流趋势。以AWS、Aliyun为代表的云厂商均提出了全线产品的Serverless化。这一将成为下一步云产品的核心竞争力之一。其重要是为了满足如下图所示的业务不确定性带来的成本问题。
不同的业务工作负载，对资源的供给要求不同，传统方式、云传统方式、Serverless方式存在明显差异。不难看出Serverless更为顺滑，整体资源成本也最低。个人觉得，Serverless的发展趋势还是要看场景需要，仅从目前而言需要的场景相对有限，大面积推广使用尚待时日。
❖ DBaaS
数据库云服务化，正成为未来的趋势。从近期趋势分析来看，云将在不久的将来成为主要交付方式。从当前头部的数据库厂商变为AWS、Azure等也可见一斑。下图则是对比了这两种方式的差异，除了在安全私密、极致性能、综合成本等方面，私有化部署尚可能有部分优势外，其他云均占优。
❖ DaaS
Data as a Service，是近年一种新提法，将数据服务作为对象整体提供，而不是仅作为数据抽取由后端自行消费。
与传统的数据集成对比，DaaS 有以下区别
数据库运维从发展来看，走过了从手动人工、到脚本工具、再到智能挖掘阶段。其表现是人均可运维资源的数量大大增加、整体可用性指标有所提升，运维方式也从被动式、演变为主动式甚至前瞻式。技术特点上也呈现平台化、智能化等特点。
❖ 平台化
平台化是数据库运维的一大趋势，随着信创改造的需求，这一点尤为重要。企业内部往往存在多种数据库，对数据库的管理运维诉求也是繁杂的，通过统一平台提供从安装部署、容量规划、告警巡检、性能优化、备份恢复乃至高可用的全管理流程覆盖的平台将对用户很有吸引力。可以说一个数据库是否能够使用好，一套好的平台也很关键，解决不仅要选好，还要用好的问题。
❖ 智能化
运维智能化发展，以AI4DB和DB4AI为主要发展方向。特别是前者，通过人工智能技术简化数据库在管理与使用上的问题。这其中最早是以Oracle提出的自治数据库为代表，提供了诸如索引推荐等功能。之后很多厂商产品在这里领域也有所实践。随之智能化应用的逐步积累，已开始在部分领域初见成果，可在一定程度降低数据库运维成本并降低整体运行风险。
从发展阶段来说，目前尚处于智能化的早期阶段，大多提供的还是建议类。就如同汽车智能驾驶能力，还多处于L1、L2阶段，距离真正的自动驾驶L3、L4还有不小的距离。在具体能力构建上，后面的技术篇还会谈到。
从智能化能力的构建方面，一般是遵循下面的方式，即基于指标数据做智能分析，提供优化、诊断建议给到运维侧，并通过前端进行展示。在上述过程中，难点是在于智能算法与数据库运维的结合部分。除了利用机器学习的方式积累外，也有通过人工标注的方式将专家经验注入系统之中。
信创，可以说是本次大会的一个热点，很多企业正在规划或已经处于信创改造的进程中。
❖ 信创背景
信创工作已经进入"深水区"，本人也接触很多企业，确实进入到信创关键阶段。下图提出了一个很有意思的观点，在信创改造过程中用户往往存在两类诉求，第一是在现阶段满足政治诉求，实现国产化的替代；第二是在未来阶段的效益诉求，实现集约化即提高单位效益。后面在产品设计阶段，也将面对这两类诉求设计自己的产品。
从市场空间来看，有一个明显的冰山现象。即在现有可统计的新增业务系统市场外，还存在一个不可见但更加庞大的市场。这主要是来自于大量存量市场及盗版化带来的隐藏市场。这个暗市场的规模更为客观。
关于这部分市场空间的测算上，可参考数据表明空间上限可突破千亿级别。
从信创应用场景来看，主要是为了满足下面四类诉求。
❖ 痛点&难点
来自信创改造的最大痛点，就是对新生事物的“未知”。过去传统企业对数据库的使用相对简单，只需要从几个厂商产品选择其一即可，而选择的产品也都具备较为完善的生态，很容易快速搭建企业架构。但对于信创改造则不同，一方面数据库自身技术架构众多，实现方式多元，交付方式多变；一方面对企业架构也提供出新要求，如何实现多层次、多组件流转打造以数据为中心的服务能力成为要点。这些对于其他来说有太多未知...
信创替换带来的挑战是多方位的，面对纷繁复杂的信创技术栈，对企业的架构、研发、运维等都需要应对这些挑战。先从运维侧来看，对数据库的管理带来的挑战是很明确的，就是“碎片化”导致的管理复杂、安全稳定问题。
此外，信创替换涉及到方方面面，对承担数据基础的载体-数据库而言，需要适配完成上下游的完整生态。其上下游包括有哪些呢，可从下图窥知一二。
❖ 替换过程
在整体信创工作中，除选择一款国产数据库产品外，替换过程也非常重要。如何实现有计划、平滑的、低风险、可回退的替换成为核心。看看关基领域用户关心的问题（如下图），不难发现用户对安全问题的关注。
如何完成替换过程，很多企业做了实践。这涉及到一系列方法论，从前期准备、调研、选型、出方案；到中期的改造开发、测试验证、模拟演练；到后期的试运行及正式上线。这里面涉及的诸多环节，都需要逐一解决难点。
在每个关键步骤都需要重新构建能力，特别是选用新架构的产品，需要评估的内容更多。
针对这些内容是需要一整套完备的能力（工具或平台）来辅助支持，需要解决数据库侧及应用侧在迁移中的诸多问题。很多公司也都纷纷推出了各种工具或平台来支持。如这样
如这样
如这样
再如这样
在上述诸多能力中，尤为关注的是关于双轨并行问题，这是有效解决新系统验证的难点。很多厂商产品也提出了对应的方案，但多数还是通过数据复制技术实现，还存在一定瑕疵，无法满足数据强一致及实时性的问题。因而也有很多公司针对核心系统，采取应用改造方式去解决，但这种需要花费相对较多的资源。
此外，在信创替换过程中，数据库的兼容能力也非常关键。很多用户在选型时会将数据库兼容能力作为首选要素，毕竟存量系统大量依赖于数据库的能力。如何做到多方位的兼容，不仅仅包括语法兼容，还包括性能兼容及操作习惯的兼容。后两者是是很多在兼容性问题考虑时往往被忽略的情况。
❖ 产品演进（技术-功能-场景-价值）
作为一个产品经理，经常需要思考的问题就是如何定义产品。这里存在一个闭环逻辑，即从核心技术能力，到形成产品功能，主打某一场景，解决客户问题，实现产品价值；再到确定适用人群，进而圈定销售目标。反之从客户侧确定痛点，明确功能价值进而驱动产品研发工作。下图就是TiDB的一个实践，可以很清晰地看到这一过程。
没有完美的产品，只有适用的场景。如何找准符合自己产品的定位很关键。正所谓从客户中来，回到客户中去。在产品摸索推广中，圈行业、找业务、定场景、推功能，如此往复。下图就是TiDB在金融行业，大型银行下在多个业务条线的多场景下的定位。
进而在这个定位下，其产品的最佳实践是什么。
同样问题，我们看看来自虚谷伟业的做法。其产品定位于信创替换场景，通过将信创需求分解，将政治诉求和效益诉求的需求细分，按不同目的圈定功能范围。前者重点解决高并发、高扩展问题，后者重点解决兼容性及基本性能问题，以此来满足用户对现状替换及长久发展诉求。
❖ 开源&数据库
开源，是越来越多软件产品采取的策略，在国家层面也非常鼓励。开源会大大加速企业选择、使用软件的过程，并通过积极参与来贡献并自建技术能力。国内的很多数据库产品都采取了开源策略。
但在全面使用开源产品时，还是有许多因素需要关注，这些也妨碍了很多企业选择开源。如何破解这一问题，一方面有些行业、组织正在通过标准工作，建立使用开源规范，方便企业使用；另一方面，很多厂商也提供的开源商业支持或基于开源之上的商业版本，方便用户选择。用户可根据企业自身情况，选择使用开源策略。
韩锋频道：
关注技术、管理、随想。
长按扫码可关注
