（报告出品方/作者：中信证券，杨泽原、丁奇、马庆刘）

报告亮点及创新之处

本报告以市场上核心关注的三个数据库行业问题为抓手，创新性的展开对数据库行业 的讨论与分析，帮助读者重点理解当前数据库行业的核心矛盾，并梳理了对应的参与公司 与建议关注的投资机遇。具体内容如下：

1）OLTP 数据库国产厂商替代能力探究

基于数据库产业发展历史的回顾，明确关系型 OLTP 数据库是目前国产替代的主要对 象，从产品性能、编程方言、应用生态维度梳理海外巨头所具备的优势以及国产厂商面临 的挑战，从性能、生态和市场的角度分别论证数据库国产替代的能力几何。

2）OLAP 数据库的技术复盘与格局推演

我们认为 OLAP 与 OLTP 并行发展是数据库行业重要趋势，并从供需角度分析 OLAP 增长动因。系统梳理 OLAP 领域从数据仓库、数据湖到湖仓一体的技术发展演进，总结各 阶段技术架构与需求痛点。基于 OLAP 需求场景，我们认为 OLAP 数据库正在朝着决策实 时化、场景精细化、产品标准化的方向发展。

3）分析了国产数据库行业的创新发展方向

提出从架构、模型和生态三个维度看待国产数据库未来的创新发展方向。在架构维度， 分布式与云将持续贡献增量；在模型维度，关系型与非关系型将长期共存，多模型兼容能 力者有望胜出；在生态维度，预计国产厂商将积极拥抱开源建设，补充自身技术能力与生 态，同时兼顾自主可控与商业化需求，打开更大市场。

问题一：OLTP 数据库的国产替代能力如何？

核心聚焦：关系型 OLTP 数据库是国产替代的主要对象

产品分类：从需求的角度可将数据库分成以下两种——关系型数据库和非关系型数据 库、OLTP 数据库和 OLAP 数据库。

1） 按数据模型分类：关系型数据库和非关系型数据库

关系型数据库是一种典型的数据库类型，采用关系模型，常用行和列等二维的形式来 存储结构化数据，一系列的行和列被称为表，一组表组成了一个数据库。表的每一行称为 一个元祖（Tuple），代表了一组值之间的联系；每一列称为一个属性（Attribute）或字段 （Field），是对实体的具体描述，每一列的数据类型相同。关系模型凭借原子性、一致性、 隔离性和持久性的 ACID 特性，取代层次、网状模型成为当代主流数据模型。 非关系型数据库是用非关系模型，存储非结构化的如图像、音视频等类型数据的数据 库，分为列存数据库、键值数据库、文档数据库、图数据库等多种类别。随着 web2.0 的 兴起海量半结构化、非结构化数据出现，非关系型数据库应运而生。

2） 按应用类型分类：OLTP 和 OLAP

OLTP（On-Line Transaction Processing，操作型数据库，又称联机事务处理）主 要关注一段时间内的实时数据，基本特征是接收的用户数据可以立即传送到计算中心进行 处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。OLTP 主要 使用关系模型，用户多为一线业务人员，支持高并发、实时快速增删查改，典型应用场景 包括金融交易、互联网电商等。 OLAP（On-Line Analysis Processing，分析型数据库，又称联机分析处理）主要 是分析长期数据的规律走势，多应用于决策。OLAP 使用的数据对象不限于关系模型，用 户多为分析师或管理层，支持对于历史数据的分析操作，典型应用场景包括风险预警、商 业分析、辅助决策等。伴随企业信息系统大量业务数据的产生，从不同类型的数据中提取出对企业决策分析有用的信息这一需求日渐显现。

发展历史：国外数据库厂商相对于国内厂商早起步 20-30 年。国内厂商中，如今占据 国内市场份额较多的达梦数据成立于 2000 年，南大通用成立于 2004 年，而国外的 IT 巨 头早在上个世纪便已经在这一领域进行研究发展，以 Oracle、IBM、微软为代表的海外 IT 巨头的相关产品于 20 世纪 80 年代末开始进入中国。先发优势带来的技术领先和客户粘性 是如今国外厂商仍然占据国内数据库市场主要份额的重要原因。

20 世纪 60-70 年代，关系模型快速发展，关系型数据库可解决数据存储的易用性、 抽象性、独立性等问题，拉开了关系型数据库软件革命的序幕。1970 年，IBM 公司的研 究员埃德加·科德在 Communications of ACM 上发表论文《A Relational Model of Data for Large Shared Data Banks》，在层次模型和网状模型的数据库产品在市场上占主要位置的时代，拉开了关系型数据库软件革命的序幕。 IBM 在 1973 年启动了 System R 项目来研究关系型数据库的实际可行性，各方关系 型模型支持者吸取该项目经验，进行关系型数据库研发。1977 年，Oracle 创始人 Larry Ellison 与 Bob Miner 和 Ed Oates 在硅谷共同创办了一家名为软件开发实验室的计算机公 司（Oracle 前身），开始进行关系型数据库的研发，同时期 Berkeley 大学也在进行关系数 据库系统 Ingres 的开发。IBM 虽然 1973 年就启动了 System R 项目来研究关系型数据库 的实际可行性，但是并没有及时推出这样的产品，因为当时 IBM 的的 IMS（著名的层次型 数据库）市场较好，公司当时认为，如果推出关系型数据库，会是对另一款产品的颠覆。 80-90 年代，大量数据库公司吸取关系模型经验，逐步推出自己的产品。1983 年，IBM 发布商业版数据库 DB2。1984 年，Sybase 公司成立，创始人之一 Bob Epstein 是 Ingres 大学版（与 System R 同时期的关系数据库模型产品）的主要设计人员。1988 年，微软推 出 SQL Server，主要适配自身 Windows 生态，这个时期，Oracle 因为客户需求已经使用 C 语言开发出适用于多个系统版本的数据库产品。90 年代，MySQL、PostgreSQL 等开源 版本数据库陆续发布。

国产替代：重点关注海外 IT 巨头先入为主的关系型 OLTP 数据库的存量市场。外部 确定因素扰动下，安全可控势在必行，数据库国产替代加速开展，以党政为代表的国产替 代先行，并不断向金融、电信等领域拓展。纵观海内外数据库行业近 70 年的发展史，我 国自上世纪 80 年代开始相关技术研发、21 世纪初开始逐步迈入成熟的商业化进程，整体 进度落后于海外巨头 20 余年，导致在传统关系型 OLTP 数据库领域海外巨头占据主要市 场份额。而后较为新兴的非关系型领域、OLAP 领域由于需求的碎片化以及云厂商和独立 厂商的角力，加上国产数据库厂商紧紧跟随行业发展的步伐，海内外新兴数据库市场呈现 出百花齐放的态势，海外厂商在新型数据库领域并不具备绝对的技术迭代优势和市场份额 优势。因此数据库国产替代首先重点关注传统的关系型 OLTP 数据库的存量市场。

替代挑战：海外巨头在产品性能、编程方言、应用生态等维度具备优势

我们认为，海外 IT 巨头在数据库领域能够经久不衰的原因主要体现在优越的产品性 能、独立的编程方言和广泛的应用生态等维度。这亦是数据库国产替代所面临的主要挑战， 是探究国产数据库能否完成替代的重要关切。

1） 技术领先，性能加持

数据库产品最重要的指标之一是性能，以海外数据库龙头 Oracle 为例，其产品在安 全性、可伸缩性和并行性、兼容性、开放性等维度具备出众优势。 安全性方面，Oracle 的安全机制得到 17 家独立安全评估机构的认可，获得最高认证 级别的 ISO 标准认证。Oracle Data Guard 是 Oracle 的高可用性数据库方案，主要功能是 数据保护、数据容灾。Oracle Data Guard 在主节点和备用节点之间通过日志同步来保证 主数据库与备用数据库之间数据的同步，实现数据库的快速切换和故障恢复，最大程度保 护数据库的安全。 可伸缩性和并行性方面，Oracle 的服务器通过使一组结点共享同一簇中的工作来扩展， 提供高可用性和高伸缩性的解决方案；Oracle 产品拥有 RAC 等数据库领域的硬核技术。 Oracle RAC (Real Application Clusters)是 Oracle 的一项支持网格计算环境的关于应用集 群的核心技术。在一个应用环境中，让多个服务器来管理同一个数据库，分散了每一台服 务器的工作量。Oracle RAC 的技术大幅提升架构的可用性、性能、扩展性，即使某些实 例宕机，也能维持系统正常工作；提高集群的事务处理能力，使得多个实例能够并发工作； 能通过增加节点提高数据库的性能。

兼容性方面，Oracle Database 可以在 Windows、Unix、DOS 等多个系统上工作， 没有 SQL Server 只能在 Windows 系统上运行的局限性，同时支持包括 TCP/IP、DECnet 在内的多种协议，可以与多种通讯网络连接。 开放性方面，Oracle 的底层使用 C 语言开发而成，随着不断发展在开发中也加入 Java 语言和技术标准，并支持绝大多数编程语言，相比之下 SAP 等竞争对手均只支持几种编 程语言，与其他技术与平台的兼容度低于 Oracle。

2） 独立编程方言，提升用户粘性

SQL 作为关系型数据库的标准语言，具备移植性强、简洁易用等优势。SQL 全称 Structured Query Language，是用于定义、查询、修改和管理关系型数据库的结构化查询语言。1970 年 IBM 公司研究员埃德加·科德在其发表的论文《A Relational Model of Data for Large Shared Data Banks》中首次描述了关系模型，SQL 是对关系模型的第一个商业 化语言实现，并于 1986 年成为美国国家标准学会（ANSI）的一项标准，在 1987 年成为 国际标准化组织（ISO）标准。作为一种高度非过程化的编程语言，SQL 同时具备扩展型 强和简洁易用的优势，它允许用户在不指定对数据的存放方法和不了解具体数据存放方式 的情况下在高层数据结构上进行工作。

各家数据库产品在落地应用过程中逐渐形成 SQL“方言”，以解决标准语言无法解决 的问题，提高了用户黏性，形成竞争壁垒。在商业实践中，由于各家数据库产品的数据源 不同、应用场景不同、用户需求不同，众多数据库厂商均开始尝试在标准 SQL 基础上提 供自己特有的功能，以提高用户的便捷性。不论是数据库龙头 Oracle、微软 SQL Server、 IBM DB2 还是开源框架 MySQL、PostgreSQL，都逐渐形成了自己的 SQL“方言”，这大 大提高了不同主流数据库产品之间的替换成本。同时，以 Oracle 为代表的全球数据库巨头 不断完善自身产品生态，通过收购 MySQL 等途径提高自身在开源社区的影响力和话语权。 持续提升的用户黏性帮助海外 IT 巨头实现对于传统数据库市场的垄断。

3） 产品快速迭代，完善应用生态

龙头数据库公司对于产品的更新换代较为积极，能够产生较大的用户粘性，使得市场 份额优势持续。以Oracle为例，在 Oracle9i产品中引入网络（Internet）的特性，在 Oracle10g 中加入网格计算（grid）的特性，在 Oracle12c 中引入云（cloud）的概念，不断让产品有 新的突破。而通过每一次更新对于产品的漏洞进行及时修复、推出新的应用、优化产品的 性能，也都会吸引已有的用户持续使用这款产品。数据库的这些特征，使其如同操作系统 一样存在较强的用户粘性，帮助行业龙头厂商迭代已建立的市场份额优势，因此数据库行 业是一个容易形成寡头的行业。

国外数据库公司注重技术创新和边界拓展，不断获得用户黏性。以 Oracle 为例，Oracle 是第一个引入对象概念、多媒体等多种数据格式、并行技术、网格技术的数据库。作为数 据库产品的标杆，Oracle 的 IT 布局十分完备，开发的产品涵盖了行业管理软件、企业管 理软件、中间件、数据库、操作系统、服务器、存储等多个领域。通过向上游基础设施和 下游软件应用延伸产业链，海外 IT 巨头得以进一步完善产品生态布局、提高基础技术实力， 从而持续稳固在数据库领域的龙头地位。

替代能力：国产数据库已具备较强的替代能力

1） 性能为基：传统数据库领域，技术及性能可满足国产替代的要求

从 TPC-C 测试结果来看，OLTP 领域国产数据库在 TPC-C 等国际知名测试中性能已 达到甚至赶超海外巨头水平。TPC 全称 Transaction Processing Performance Council， 中文名称为事务处理性能委员会，是数据库性能测试的国际权威标准组织，目前拥有 20+ 成员公司，包括 Oracle、微软、IBM 等数据库领域 IT 巨头和华为、阿里、浪潮、柏睿数 据等国产厂商。TPC-C 测试是衡量 OLTP 系统的工业标准，是行业中公认的权威和最为复 杂的在线事务处理基准测试。它通过模拟仓库和订单管理系统测试 OLTP 数据库功能，包 括查询、更新和队列式小批量事务，通过每分钟处理任务数（tpmC）衡量数据库性能。2020 年阿里云旗下 OLTP 数据库 OceanBase 以 7.07 亿 tpmC 的成绩登顶 TPC-C 测试历史榜 首并延续至今，打破了 Oracle、IBM 等传统 IT 巨头对头部排名的垄断，反映了国产力量 在 OLTP 领域已经达到较为领先的水平。

国产 OLAP 数据库龙头厂商拳头产品性能已逐渐实现对于海外 IT 巨头的追赶。以达 梦数据库为例，公司招股说明书显示，通过基于记录的多版本并发控制、基于事务锁的行 级并发、日志包分片处理等大量先进性技术，公司产品具备优秀的并发事务处理性能。第 三方软件测评实验室测试，单节点能够支撑数据库并发连接超过 10 万个；TPC-C 测试模 型下，单节点性能可达百万级 tpmC，与海外主流 OLTP 产品 Oracle 11g、IBM DB2 9.5 性能达到同一数量级。

除了关注 OLTP 数据库基本的读写性能之外，国产厂商还高度重视产品可用性、稳定 性、易用性、安全性等维度。人大金仓旗下拳头产品通用型关系型数据库 KingbaseES 实 现对 97%以上 Oracle“方言”的兼容，便于用户实现低成本迁移；同时具备高稳定性、高 可用性，标杆项目国家电网智能电网调度系统已实现 10 余年 7x24 稳定运行；易用性方面， KingbaseES 通过自研数据库辅助调优工具的应用，大大提高了性能诊断、辅助调优、故 障修复等运维业务的效率；此外，KingbaseES 还通过了国家信息安全产品认证、Common Criteria EAL4+安全认证，达到主流产品 Oracle、SQL Server、IBM DB2 的安全级别。

2） 生态为纲：信创加速，国产数据库稳步推进上下游生态的适配

党政信创纵向下沉和行业信创横向拓宽持续利好国产数据库生态构建。信创需求是数 据库国产替代的核心动力，外部环境不确定性提升国内信创产业发展的确定性，紧迫性、 重要性持续获市场更深认知。作为对自主可控和数据安全要求最高的细分市场，党政信创 开启最早，部委、省、市层面包括数据库在内的基础软硬件和 PC、应用推进顺利，信创 产业后续有望从“纵向下沉”和“横向拓宽”两方面继续发展。纵向方面，信创核心品类 预计将进一步向区县层面下沉，各条线工作落地节奏逐步清晰。我们认为当前阶段信创应 用在部委、省、市层面已深入开展，未来有望进一步下沉，实现较第一轮信创三倍体量的 扩展。同时在行业内部，国产化替代主要遵循“外围软件-管理支持-准核心系统-核心系统”的顺序，按四个业务层级逐步深化。横向方面，信创核心品类有望从党政公文向电子政务、 事业单位及其他行业加速渗透，按照“2+8”的自主可控体系由党政机关逐渐拓展至金融、 电信、能源、教育、交通等八大行业，预计有望以 2022H2 为起点逐步进入高速发展期。 信创产业的快速推进将持续利好国产数据库上下游行业生态的构建，不断加强对国产基础 硬件、操作系统、中间件及各类应用的适配能力。

上游生态：数据库软件作为基础软件，其上游主要是 CPU 芯片、服务器主机、存储 设备、操作系统等基础软硬件行业。目前国内市场上除 IBM Power 小型机，以及 Intel、 AMD 等主要国际 PC 服务器生态体系外，众多国产生态体系也走在快速发展的路上。其中 CPU 主要包括飞腾、龙芯、申威、鲲鹏、海光、兆芯等品牌，服务器主要包括浪潮、长城、 曙光、联想等品牌，操作系统则有麒麟软件、统信软件等厂商。以达梦为例，达梦数据库 与相关国内外上游计算生态企业有着良好合作关系，能够提供经过良好兼容优化的各类数 据产品。此外，在上游存储设备领域，达梦也与宏杉、H3C、华为、浪潮、曙光、长城、 联想、EMC 等主流厂商的存储产品具有良好的兼容适配性。

下游生态：数据库软件的下游主要为应用软件开发行业，既包括传统信息化应用，如 电子政务、电子商务、企业 ERP、财务管理、工业生产控制等，也包括新型的应用如大数 据、人工智能、物联网等。数据库软件作为信息化系统中不可或缺的组成部分，广泛覆盖 政府、金融、能源、教育、交通等大多数涉及国计民生的领域。目前我国应用软件产业整 体发展较为成熟，在各行业领域拥有丰富的产品供给，形成了大量行业独立应用软件开发 商（ISV）。ISV 是数据库与用户的重要桥梁，承担着数据库的应用和集成工作。与 ISV 的 合作将是国产数据库公司下游生态建设的持续投入方向。

大型国央企数字化转型和信创需求持续丰富国产数据库下游生态。由于海外数据库龙 头较早进入国内市场打开市场，此前重点行业大型央国企高度依赖海外数据库产品。随着 “十四五”期间数字经济的不断加码和行业信创的稳步推进，大型央国企数据库建设呈现 出“升级改造”和“国产替代”的双重需求，为国产数据库厂商开拓下游用户生态创造了 良好的发展机遇。目前国产数据库厂商在金融、电信、能源、交通等重点行业持续拓展大 型用户，推进国产替代，通过打造标杆性行业用户不断积累行业 know-how，从而快速把 握用户需求实现产品迭代。

3） 市场为证：传统数据库领域国产份额稳步提升，竞争格局逐渐清晰

市场份额：国产厂商在国内传统数据库市场已逐渐与海外龙头分庭抗礼。Gartner 数 据显示，2021 年全球数据库主要市场份额仍被微软、AWS、Oracle 等海外龙头占据。反 观国内传统数据库领域，国产替代已经初具成效。IDC 数据显示，2021 年我国本地部署关 系型数据库市场份额 Top3 分别为 Oracle、华为、达梦，后两者的市场份额超过了微软、 IBM 等海外 IT 巨头，人大金仓、阿里巴巴等国产厂商亦在国内市场有所斩获。

国产企业：传统领域国产数据库竞争格局逐渐清晰。赛迪顾问数据显示，传统领域国产数据库市场 Top5 在过去三年基本没有发生变化，市场格局逐渐趋于稳定。达梦数据库、 人大金仓、优炫软件、南大通用和神州通用作为国内老牌商业数据库厂商，已成为 OLTP 领域国产替代的中坚力量。

问题二：OLAP 数据库的发展到了什么阶段？

并驾齐驱：OLAP 成为继 OLTP 之后数据库的下一发展重心

20 世纪 90 年代以前，早期 OLAP 需求场景尚不成熟，OLAP 和 OLTP 在同一个数 据库产品中实现，主要应用于简单的历史数据查询分析。前文中我们提到，1990s 之前， 以增、删、查、改为核心的 OLTP 需求是数据库领域发展的重心。随着企业数据管理系统 应用的深化，数据量的高速积累、数据应用场景的不断丰富和数据模型的不断完善，分析 师和企业管理层逐渐看到数据分析的价值。 20 世纪末，分析型数据库开始崭露头角，OLAP 技术路线独立，成为继 OLTP 之后 数据库领域的另一发展重心。OLAP（联机分析处理）的概念最早由关系模型之父埃德加·科 德于 1993 年提出。他认为 OLTP 已不能满足终端用户对数据库查询分析的要求，用户需 要对关系型数据库进行大量的计算才能辅助决策分析。OLAP 的技术路线由此独立并得到 蓬勃发展，在传统数据库的基础上逐渐发展出数据仓库的产品形态，主要支持面向分析场 景的应用，提供结构化的、主题化的数据用于业务反馈和辅助决策。

我们认为，OLAP 需求的独立和分析型数据库的爆发是数据库行业发展的必然趋势， 其驱动因素主要包括需求侧和供给侧两个维度：

1） 需求侧：数据量的积累带来数据赋能的潜力，分析处理的应用场景不断丰富

数据治理能够实现对企业各个价值链环节的赋能，提升企业的运营与决策效率。数据 量的积累使得基于历史数据的分析决策成为可能，企业的顶层决策、生产运营、后台研发 等一系列环节将逐步由数字化迈向智能化。我们认为，信息密集型、劳动密集型行业的数 据治理赋能成果更易显现，在业务运营过程中容易产生体量巨大、数据结构不统一的数据。 基于对历史数据的分析可以充分赋能产品研发、营销销售、售后服务等诸多环节。以金融 行业为例，基于个人消费行为数据、征信数据、储户信用报告数据、交易数据的分析可以 帮助企业更高效地开展风险评估以及理财产品的定制化推介营销活动。

2） 供给侧：海内外传统数据库巨头、云厂商、独立厂商百家争鸣，各有千秋

分析型数据库领域由于场景需求碎片化、技术路径多样化，海内外各类厂商呈现出百 花齐放的态势。传统 IT 巨头多在关系模型领域深耕，凭借在 OLTP 领域的先发优势率先进 行探索，整体占据主导地位。但云计算、大数据的快速发展带来了需求的进一步爆发，各 类数据模型、各种应用场景的需求逐渐分化。同时随着开源生态的不断丰富，以 Apache 软件基金会为代表的开源体系也为巨头之外的数据库厂商的发展提供了一片沃土。云计算 巨头、独立数据库公司的数据库产品快速崛起。

传统巨头：在 OLTP 领域起步相对较早具有先发优势，产品具备高稳定性、高安全性 的优势，且具备良好的客户基础，市场份额较高。但技术架构相对传统，需要承担较高的 运维成本和改造成本，在新技术的适配性上存在短板。典型代表包括海外 Oracle、IBM、 Microsoft、SAP 和国内人大金仓、达梦数据库等。 云厂商：对于应用场景（特别是互联网领域）的理解更加深刻，产品矩阵类型丰富。 但相对缺少中立性，销售绑定云服务，降低企业可选择性，同时对于私有化部署相对缺乏 服务能力。典型代表包括海外亚马逊、谷歌和国内阿里、腾讯、华为等。 独立厂商：技术架构先进，能够满足更加多元化的分析需求，各自在自身的强势领域 深耕细作。但商业化验证维度存在欠缺，客户消费意愿、消费能力以及市场空间均有待验 证，财务表现相对较弱。典型代表包括海外 Databricks、Snowflake、MongoDB 和国内星 环科技、PingCAP、偶数科技等公司。

技术复盘：把握数据处理效率、数据完整性两条发展主线

路径回顾：OLAP 先后衍生出数据仓库、数据湖的发展路径，现在正在进行湖仓一体、 智能湖仓的实践尝试。数据仓库聚焦于结构化数据处理能力的问题，由传统 OLTP 数据库 提供底层数据，主流采用 MPP（大规模并行计算）的无共享架构，相较于早期分析型数据 库显著提升了扩展性和对于结构化数据的处理性能，但不支持非结构化、半结构化数据的 存储和分析；数据湖聚焦于数据完整性的实现，支持对于各类半结构化数据（CSV、XML、 日志等）、非结构化数据（文档、图片、音频、视频等）的存储和分析，大大拓展了数据 分析的使用场景和功能，但在结构化数据处理、ACID 特性支持、数据的实时性与可靠性 等维度存在短板。为了兼顾数据分析效率和数据完整性，同时在分析过程中与 AI/ML 更紧 密结合，近年来众多分析型数据库厂商开始进行湖仓一体、智能湖仓的尝试。

1） 数据仓库：基于 MPP 架构实现较大规模结构化数据计算效率优化，但在可用性、 可扩展性和数据模型灵活性上仍存在短板

技术架构：数据仓库的分析对象主要来自 OLTP 数据库的结构化数据，通过预先定义 Schema 的方式，运用 ETL（抽去、转换、加载）操作将数据导入数据仓库后，用户可以 较为便捷地链接 BI 系统和报表系统。由于与 OLTP 数据库高度结合，数据仓库对于元数 据的要求十分严格，很多数据仓库同样满足 ACID 事务能力。早期数据仓库主流采用 MPP （大规模并行处理）架构，通过一定的节点互联网连接多台 SMP 服务器，每个节点之间 采用完全无共享（Shared Nothing）结构，具有独立的 CPU、内存和磁盘资源。在实务过 程中，来自 OLTP 数据库的数据将根据来源场景、应用特点分配到不同的节点上，在每个 处理单元上并行地进行计算分析，最终每个节点计算完成后再统一汇总得到最终结果。

性能分析：基于 MPP 架构的数据仓库在 ACID 事务性支持和中等规模数据分析效率 上具备优势。由于数据源来自高度结构化的 OLTP 系统，数据仓库具有稳定可靠、支持 ACID 事务性和 SQL 兼容的优势，同时多个节点的并行计算也提高了数据仓库所能处理的数据 量水平。但是，基于 MPP 架构的数据仓库在数据模型的灵活性、可用性和扩展性的维度 上仍存在短板。Web2.0 时代的来临使得企业在日常运营过程中积累了大量非结构化、半 结构化数据（如日志、图片、文档、音视频等），需要提前设计 Schema 的数据仓库无法 应对非/半结构化数据的处理需求。此外，由于 MPP 的各个节点并行处理任务，一旦某个 节点出现性能短板或性能故障，将会降低整个系统的处理性能。因此 MPP 架构的可用性 （部分节点发生故障时继续运行的能力）、并发度（单位时间内所能够处理的任务数）仍 然存在缺陷，这也进一步造成了 MPP 数据仓库可扩展性以及扩展成本上的短板，使得数 据仓库无法应对大数据时代 PB 级甚至更高的数据处理需求。

2） 数据湖：以 Hadoop 架构为代表的数据湖提高了可扩展性和数据模型的灵活性， 但牺牲了一定程度数据的实时性和可靠性

技术架构：数据湖的核心是存储业务数据的完整副本（原始数据），包括结构化数据、 非结构化数据以及半结构化数据。Hadoop 是企业数据湖建设的典型架构，以分布式文件 系统 HDFS、分布式计算引擎 MapReduce 为核心组件，将所有机器的存储资源与计算资 源进行分层抽象设计。2003 年前后，Google 连续发表三篇论文，奠定了大数据的框架基 础。此后基于理论又形成了 Hadoop 原始的“3+1”式软件栈：即分布式文件系统 HDFS、 分布式计算引擎 MapReduce、Hbase NoSQL 数据库,以及 YARN 资源调度。Hadoop 定 义了最基础的分布式大数据批处理架构，打破了传统数据库一体化的模式，将计算与存储 分离，聚焦于解决海量数据的低成本存储与规模化处理。Hadoop 在面对上百 PB 数量级 的大数据查询分析时能够极大地提升效率，同时通过使用廉价硬件集群搭建的分布式系统 实现成本效益。

性能分析：基于 Hadoop 架构的数据湖解决了半/非结构化数据的存储问题，同时通过 存算分离的架构设计提高了可扩展性。数据湖中各种类型的数据均按原样存储，在分析时 采用 Schema-on-read 模式，能够满足互联网场景下多种数据类型存储和分析的需求。但 也以牺牲 ACID 事务性作为代价。如果要基于 Hadoop 实现 BI、报表等功能，需要将数据 库的数据经过 ETL 进入数据仓库、在版本控制、数据索引等维度存在短板。

生态演化：核心组件基础之上衍生出庞杂的开源 Hadoop 生态圈。仅有 HDFS、 MapReduce 组件并不能支撑企业级的大数据分析应用，在此基础上衍生出丰富的生态组 件，包括资源管理系统、各类计算引擎、ETL 工具、安装部署工具、数据库/数据仓库产品 等。同时，还出现了 Hadoop 发行版商业公司，通过提供整合、加强后的打包产品和服务， 解决繁杂组件带来的版本管理混乱、部署过程繁琐、升级过程复杂等问题。

3） 湖仓一体和智能湖仓：“仓”“湖”结合，兼顾事务性、扩展性和灵活性，并逐渐 向数据全生命周期管理发展

数据量的爆发增长和应用场景的不断丰富为企业分析型数据库提出了更高的要求。随 着云、5G 基础设施的成熟带动互联网的深入发展，各种应用程序、移动设备、边缘设备、 传感器所产生的数据总量正在以前所未有的速率爆发式增长。IDC 预计 2025 年全球数据 总量将达到 175ZB，其中超过 25%为实时数据。数据仓库在扩展性和数据模型的局限性亟 待突破。此外，企业数据分析的应用场景不断丰富，智能化分析水平不断提高，爱分析调 研显示未来企业存在广阔的 AI/ML 应用空间，企业数据分析智能化需求有望爆发。

基于此，兼具数据仓库和数据湖优势的湖仓一体应运而生。2021 年创新数据系统研 究会议（CIDR）上 Databricks，UC Berkeley 和 Stanford University 联合发布的论文 《Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics》，系统描绘了新一代湖仓一体架构。数据湖仓的核心是将“湖内”和 “仓内”的数据和元数据进行打通，实现自由流动。各类结构化、非/半结构化数据使用标准文件格式（如 Parquet），通过对象存储的方式依然存储在底层的数据湖当中。在数据湖 之上建立的元数据层实现 ACID 事务性、版本控制等数据管理功能。元数据层作为存储层 和计算层之间的中间层，通过缓存、索引、辅助数据和数据布局优化等多种优化手段减少 计算和存储层之间的 I/O 流量，优化 OLAP 工作负载的性能。元数据层之上的各类计算引 擎（包括面向 BI/报表的 SQL 类工作负载和面向数据挖掘的机器学习工作负载）共享统一 的数据存储，可以按需摄取热数据、回注冷数据。 未来“智能湖仓”架构将把湖、仓以及所有其他数据处理服务组成统一且连续的整体。 AWS 提出的智能湖仓架构旨在以数据为中心构建“数据服务环”。数据湖作为数据中央存 储库，围绕数据湖建立包括数据仓库、机器学习、大数据处理、日志分析等一系列专用服 务，各项服务共享同一的数据存储，按需对湖内数据进行摄取和回注，同时彼此之间可以 以低成本、高效率地进行数据交换，最终实现企业数据全生命周期管理。

需求推演：决策实时化、场景精细化、产品标准化

数据库的发展历史是用户数据治理需求的变迁史，需求的演变方向决定技术路线的演 进方向。纵观数据库近 70 年的发展历程，从 1960s 增删查改的事务性需求的出现带来了 OLTP 数据库的兴起，到 1990s 针对历史数据的分析和辅助决策需求推动了 OLAP 数据库 的发展，用户需求的变迁决定了数据库技术的发展重心。分析型数据库的发展脉络，数据 处理效率的更高要求催生了数据仓库，半/非结构化数据的治理需求催生了数据湖，而用户 对于数据分析事务性、扩展性和灵活性的统一追求催生了湖仓一体和智能湖仓。

我们认为，当下分析型数据库正呈现出决策实时化、场景精细化、产品标准化的需求， 这亦是未来 OLAP 数据库的演进方向。

1） 决策实时化：打通 TP/AP 消除 ETL 延时，HTAP 助力实现实时决策

OLAP 与 OLTP 之间的数据传输延时导致在处理实时性极高的分析业务时存在短板。 不论是数据仓库还是数据湖，在进行分析处理时都需要基于事务处理所产生和积累的数据， 必须经过数据提取、转换、加载的 ETL 过程，在此过程中为了保证系统的高可用将会产生大量且分散的副本数据造成数据冗余，最终导致较高的同步难度和运维成本。同时，当用 户面临实时性要求极高的分析业务场景时，OLAP 与 OLTP 之间分钟级甚至小时级的数据 传输延时将难以满足分析需求，数据实时性所蕴含的数据价值也会随着 ETL 的延时而逐渐 消弭。此外，当用户需要调用不同系统之间的数据进行聚合分析时，实时性方面的短板将 被进一步放大。

HTAP 混合事务和分析处理消除了 OLAP 和 OLTP 之间的间隔，可以更好满足实时分 析和决策需求。目前市场上的 HTAP 实现路径主要由三种：第一种在上层应用层实现混合 处理，通过 OLAP/OLTP 的松耦合和底层共享存储缩短数据同步时间，只能在数据库和应 用的整体层面呈现 HTAP 能力；第二种分别运用行存储引擎和列存储引擎进行 OLTP 和 OLAP，存储引擎在物理上进行隔离，通过分布式协议进行实时复制和同步；第三种采用 单一存储引擎，在最底层实现 HTAP，但目前仍处于技术探索阶段。第二种分离存储架构、 同一系统的 HTAP 是目前的主流解决方案。

2） 场景精细化：深耕细分领域积累行业 know-how，应用场景愈加精细化

数据分析与数据管理的应用场景在未来将持续拓展和深化。数据分析的应用将继续向 各行业领域的核心业务渗透，数据的采集、流通、分析、应用的价值闭环将持续完善。由 数据分析需求逐渐衍生出的大数据管理将逐渐改变各行业的各个价值链环节。一方面，基 于历史数据分析的销售预测、趋势分析、营销策略设计、客群画像匹配的优化建议将提高 用户的运营效率和决策效率；另一方面，基于数据分析的如 AI、大数据的应用有望带来新 商业模式、新产品形态、新应用场景的开拓，如无人驾驶、智能安防、智慧物流等。

3） 产品标准化：技术 SaaS 化、解决方案标准化打开长尾下沉市场

分析型数据库产品将逐渐实现标准化，进入下沉市场提高中小企业渗透率。受限于数 据治理需求碎片化、场景理解不够深入等因素，现阶段分析型数据库产品主要集中在大型 企业客户市场，且定制化程度相对较高。未来伴随更多业务场景能力的沉淀，分析型数据 库厂商将不断丰富产品矩阵，完善数据治理服务的深度和广度，通过产品标准化的途径降 低成本，从而提高在长尾下沉市场的渗透率。

问题三：如何看待国产数据库的创新方向？

看架构：分布式成重要趋势，云数据库打开更大市场

按照架构模式进行分类，数据库可以分为分布式数据库和集中式数据库。这种分类方 式的诞生，一方面是由于传统集中式数据库缺乏扩展性，为了实现扩展而出现了分布式数 据库，另一方面，是缘于云技术和网络技术快速发展，推动分布式技术升级，形成新型分 布式数据库。集中式数据库由一个处理器、与它相关联的数据存储设备以及其他外围设备 组成，将数据集中在一台机器上进行处理，被物理地定义到单个位置。典型代表有 Oracle、 DB2、人大金仓、武汉达梦等；分布式数据库采用分布式架构，将数据在网络上分开储存 于多个机器中进行处理。分布式数据库是一个数据集合，这些数据在逻辑上属于同一个系 统，但物理上却分散在计算机网络的若干站点上，并且要求网络的每个站点具有自治的处 理能力，能执行本地的应用。分布式数据库典型代表如谷歌的 Google Spanner、阿里巴 巴的 OceanBase、华为的 GaussDB 等。

硬件架构：数据库硬件架构主要有完全共享、共享内存、共享磁盘和无共享四种。完 全共享（Shared Everything）模式拥有完全透明共享的 CPU、内存和磁盘，属于集中式 数据库的范畴，天然具有较好的 AICD 事务性，但扩展性和并发性较差；共享磁盘（Shared Disk）和共享内存（Shared Memory）模式允许增加内存节点和磁盘节点以提高并行处理 能力，但是随着数据体量的爆发式增长，共享磁盘的接口数量容易达到上限，共享内存的 内存访问和网络带宽之间冲突增强，系统处理速度将会遭遇瓶颈。无共享（Shared Nothing） 模式下每个节点具备独立的 CPU、内存、磁盘，每个处理单元独立运行，各单元之间通过 协议通信。无共享架构具备良好的扩展能力和并行处理能力，从 MPP 数据仓库时代起逐 渐得到广泛应用。随着硬件成本的下降，无共享模式已逐渐成为分布式硬件架构的主流。

主流应用：通过无共享架构实现的分布式架构已成为大数据管理的主流解决方案。数 据量的爆发式增长以及应用负载的快速增加使得传统单一服务器架构的集中式数据库出 现瓶颈，包括传统集中式数据库厂商、新兴厂商在内的各类玩家均开始探索数据功能的分 布式实现。三种分布式架构中，无共享架构凭借高可用性、高扩展性、低带宽要求等优势 已成为分布式架构的主流解决方案。

技术实现：分布式架构的实现方式将逐渐从借助中间件向原生分布式过渡。分布式架 构的实现路径包括借助中间和原生分布式两类，其中原生分布式包括共享存储分布式数据 库、去中心化的分布式数据库，不同技术路线产品各有千秋。分库分表+中间件的模式相 对成熟，但整体依然基于单机数据库的存算性能，依托中间件进行数据分配和任务管理， 在并发性和扩展性上仍有局限。原生分布式实现了存储层、计算层的全面分布式改造，但 目前技术成熟度相对较低。

技术内核：从存算一体到存算解耦，硬件成本的降低和网络带宽的提高保障分布式架 构的实现。20 世纪 80 年代，Oracle 推出了首款数据库产品。彼时服务器硬件成本高昂， 硬件算力、存储、网络带宽都十分有限。因此数据库产品在优化过程中难以依托服务器之 间的信息交换，而是聚焦于在单服务器的 CPU、内存、磁盘固定配置下进行极致优化。因 此在软件架构的设计中，存储与计算高度耦合，其核心思想是通过存算一体实现性能的极 致优化。随着硬件成本的大幅降低和网络带宽的大幅提高，通过集群服务器的硬件设计， 联合多个节点进行协议通信以实现分布式计算成为可能。软件算法的设计无需再基于存储 和计算的深度绑定，存算解耦的思想为分布式的实现提供了更多想象力。

分布式数据库的“资源池化”思想与云计算的“按需服务”理念具有异曲同工之处， 天然满足云原生的需求。分布式数据库迁移到云计算平台后可以轻松实现数据与业务的分 离、存储与计算的分离。云数据库可以相对不受限制地实现基础设施资源的调动，以满足 上层对于高扩展性、高并发、高吞吐量、灵活配置的需求。因此，云数据库在成本、可用 性、易用性、扩展性和并行处理方面较传统数据库有绝对优势。但同时，由于现阶段云数据库产品仍处于相对不成熟阶段，且市场的普遍存在公有云和私有云的混合部署需求，云 数据库在数据迁移、数据质量、性能优化和规范标准方面仍有局限。

在未来，上云需求将持续为数据库市场带来增量。IDC 数据显示，2021 年我国关系 型数据库中，公有云部署的市场规模增速已经超过本地部署的增速，预计从 2022 年开始 二者的增速差将进一步拉大。IDC 预测，未来三年关系型数据库中云数据库的市场规模增 速有望保持在 40%左右，而本地部署模式的规模增速仅为 20%，云数据库的市场份额有 望进一步提高。

看模型：关系型与非关系型长期共存，重视多模型能力构建

数据模型先后经过了层次模型、网状模型和关系模型的变迁，互联网的兴起推动非关 系模型和 NoSQL 数据库登上历史舞台。20 世纪 80 年代以来，结构化的关系模型始终占 据市场主流，随着 Web2.0 的繁荣非结构化和半结构化数据（如日志、图片、文档、音视 频等）出现爆发式增长，面向非关系型数据的 NoSQL 数据库开始走向市场，区别于关系 数据库，它们往往不保证关系数据的 ACID 特性，对于超大规模和高并发数据具有较好的 处理能力。NoSQL 数据库种类繁多，数据之间无关系，容易扩展。NoSQL 数据库具有非 常高的读写性能，尤其在大数据量下，主要在于它的无关系性，数据库的结构简单。目前 对于非关系型数据库主要有四种数据存储类型：键值对存储（key-value），文档存储（document store），基于列的数据库（column-oriented），图形数据库（graph database）。

放眼全球：从市场反馈来看，多模型数据库更受企业青睐，企业用户关注平台的兼容 性与可扩展性。DB-Engines 发布的 2022 年 10 月数据库管理系统流行程度排名显示，排 名前 8 的数据库管理系统均为多模型数据库，支持文档模型，键值模型，图模型等多种数 据模型。而随着排名逐渐靠后，多模型数据库的比重也逐渐下降，排名 11-20 的数据库管 理系统中仅有 5 个多模型数据库。由此可见多模型数据库受企业欢迎的程度更高。国内公 司凭借对于主流数据模型更高的兼容性，有望在非关系型数据库领域与国际厂商同台竞争， 凭借大数据基础平台等核心产品实现国产替代。

聚焦国内：非关系型数据库占比呈现上升趋势，关系型数据库在市场规模和产品数量 上仍占据主流。智研咨询数据显示，2018 年我国关系型数据库市场规模占比高达 85%，但 呈现逐年下降趋势。综合多方关于我国数据库市场规模的数据（中国信通院、IDC、艾瑞咨询），2021 年我国关系型数据库市场规模占比约为 60%。中国信通院数据显示，截至 2021 年 6 月，我国关系型数据库的产品数量占比约为 60%。

我们认为，非关系型数据库与关系型数据库长期共存，具备多模型兼容能力者有望胜 出。根据 IDC、艾瑞咨询、中国信通院对于未来我国数据库市场规模的增速预测，未来关 系型数据库仍将占据主流市场，但非关系型数据库也将成为行业生态中不可或缺的一部分， 二者将长期共存。处理半结构化、非结构化数据的治理水平或将成为未来衡量数据库厂商 能力的重要指标之一，具备多模型兼容能力者有望胜出。

以国产大数据厂商星环科技为例，旗下核心大数据基础平台（TDH）中包含 9 种独立 的存储引擎，支持业界主流的 10 种存储模型。相关核心子产品主要包括关系型分析引擎 Inceptor、宽表数据库 Hyperbase、图数据库 StellarDB、搜索引擎 Scope、时空数据库 Spacture、时序数据库 TimeLyre、键值数据库 KeyByte、事件存储库 Event Store、文档 数据库 DocStore，对于多模型的兼容能力相较于海外主流厂商存在优势。

TDH 的多模型实现路径相较于其他主流产品具备优势。传统的多模型实现路径包括为 每一种新数据模型开发独立完整的存算策略、用单一存储引擎支撑多个存储模型、在多种 独立数据库之上提供统一的用户界面等，这些策略暴露出存算资源消耗过高、存储引擎与 存储策略不匹配、语言不一致提高开发难度等问题。星环 TDH 通过提供统一的 SQL 编 译器层，统一的分布式计算引擎层 ，统一的分布式数据管理系统层以及统一的资源调度 层，将不同的数据库架构在统一多模型数据平台中，跨库的关联分析不需要额外的数据导 出导入过程，避免了数据冗余。同时 TDH 提供 9 种独立的存储引擎子产品，用户可以根 据业务的需要，随时增减不同的存储引擎，做到资源按需分配。

看生态：开源闭源并存发展，共促商业化生态繁荣

开源即开放源代码，用户拥有基于源代码进行修改的权利。虽然源代码一般均免费提 供给使用者，但开源系统的版权依然受到法律保护。开源软件标准权威发布机构 OSI （Open Source Initiative）发布的对于开源的定义及要求主要包括如下三个方面：

内容方面：开放的源软件必须包含源代码，且必须确保源代码可被理解和可被运用； 不得故意混淆源代码；开源代码需以源码或编辑后文件的形式传播。允许用户对开源项目 及其他衍生分支进行修改，且必须允许其按照与初始软件相同的许可证发行。 传播规范方面：开源许可证不能限制开源软件的再传播，不得利用此条件进行收费。 必须允许更改后的源代码所建立的程序发行许可证。当且仅当开源软件配合补丁文件一起 发布时，开源许可证才可以限制源代码以修改后的形式发行。开源许可证不得限制其他铜 许可软件一起发行的其他软件，不得限制特定软件的项目内容。 公平性、中立性准则：开源项目不得歧视任何研究领域、个人或团体。所有获得该项 目的主体拥有所有附加到开源项目上的内容的使用权，无需当事方执行额外许可。开源许 可必须独立于技术，不应指定任何特定的技术或接口。

从数据库厂商的视角来看，积极开源有助于构建服务生态，提高产品迭代速度和适配 能力，及时捕捉用户需求的同时降低开发成本。通过构建开源生态社区，数据库厂商一方 面可以依托广泛的开发者群体提高产品创新效率和迭代速度，节省自身开发成本和下游客 户的 IT 成本，另一方面可以更加敏锐地捕捉新兴需求，并基于此迅速迭代产品抢占市场， 亦可通过开源社区提高品牌影响力和行业话语权。

从用户视角来看，开源不同于免费，选型采购阶段的成本将转移到后续的开发部署和 运维使用阶段。对用户来说，采用开源数据库可以一定程度节约选型采购阶段的 license 费用，但同时对于自身二次开发的能力提出了较高要求，数据库的部署、运维、迁移、配 套升级等环节需要开源厂商提供数据库服务，也需要额外的人力投入和资金投入。此外， 用户由于缺乏相关领域的重复实践经验，在应用场景和性能的扩展能力上可能不及直接采 购商业数据库。因此政务、金融等对于数据安全性、一致性要求更高的场景倾向于使用商 业数据库，越来越多厂商开始尝试“开源+商业”的混合策略。

我们认为，开源与商业并不冲突，未来国内数据库厂商将呈现出开源和商业共同繁荣 的格局，数据库厂商将在积极拥抱开源生态的同时，兼顾自主可控及商业化需求。一方面， 在传统数据库领域，我国相较于海外龙头企业仍有差距，开源生态能够帮助国内厂商更加 快速实现追赶；另一方面，近年来数据库领域持续迸发出新技术、新应用、新模式，参与 开源项目能够帮助企业更快把握技术革新与市场机遇，实现生态构建的正向循环。此外在 信创大背景下，开源生态能够促进国产数据库上下游的适配能力，加快自主可控的步伐。

（本文仅供参考，不代表我们的任何投资建议。如需使用相关信息，请参阅报告原文。）

精选报告来源：【未来智库】。