2012~2013 年，Google 相继发表了 Spanner 和 F1 两套系统的论文，让业界第一次看到了关系模型和 NoSQL 的扩展性在一个大规模生产系统上融合的可能性，这种新型的数据库架构被行业分析师 Matthew Aslett 称为“NewSQL”。

随后的几年里，NewSQL 数据库迎来大爆发，各大云服务厂商都基于 Spanner+F1 论文推出各自的 NewSQL 数据库服务，开源领域也涌现出 CockroachDB 和 TiDB 这样的人气项目。

近日，浪潮宣布开源一款 NewSQL 分布式数据库 ZNBase，引发了社区开发者的关注。据悉，浪潮的 ZNBase 数据库同样参考自谷歌 Spanner+F1 系统的设计思想，具备强一致、高可用分布式架构、分布式水平扩展、高性能、企业级安全等特性。

而作为一款主打 HTAP 混合场景的分布式数据库产品，前有 TiDB 获资本市场青睐并霸榜国产数据库，后有阿里、百度等厂商陆续推出的自家 HTAP 分布式数据库产品，浪潮的 ZNBase 又将凭借哪些优势在国内市场中立足？

什么是 ZNBase ?

据 ZNBase 产品负责人陈磊介绍，ZNBase 是一个 HTAP 分布式数据库，采用云原生分布式架构，Share Nothing 所有节点全部对等，每个节点均是完整功能的数据库节点，每个节点都包括 SQL 层、事务层、副本层和存储层。SQL 层包括协议和语法解析、优化器和执行器，事务层主要负责分布式事务，副本层负责副本调度和使用 Raft 算法保证多副本一致性，存储层采用 KV 存储引擎 RocksDB 负责存储数据。

ZNBase 首先支持 OLTP 场景，产品完整的支持 SQL 与事务，表数据自动的划分多个 Range 分布在不同的数据库节点上。因此使用 ZNBase 数据库再大数据表也不需要人工分库分表，数据库集群会自动处理，应用只需要当作单机库表使用即可。

在 OLAP 场景支持方面，在 SQL 执行方面做很多偏向 OLAP 场景的优化，包括算子并行、异步、矢量计算、RBO优化器等，得益于产品的分布式架构，可以利用多节点的计算能力，产品可以满足业务应用的 AP 需求。

ZNBase 没有类似 TiDB 包含的集群管理模块（Placement Driver ，简称 PD），每个节点就是一个完整的数据库，在每个节点里同时包含 AP 和 TP 的能力，可以完成处理 SQL 请求，进行 SQL 计算，以及数据存储引擎的全部工作。再通过这种分布式的架构把每个节点联系起来，形成 ZNBase 的数据库系统。

取自社区，回馈社区

前文提到，市面上已经有一些比较成熟的分布式数据库解决方案，其中不乏受到资本追捧的优秀开源项目，那么浪潮的技术团队当初决定要重新做 ZNBase 是出于怎样的考虑呢？

据陈磊回忆，ZNBase 的研发团队最开始是浪潮内部的大数据团队，集团内部不同单位之间有很多交流，他们发现其他的单位有很多的大数据量应用。因为浪潮做信息化比较早，最开始集团内部用的是免费的 MySQL，Oracle 单机版，DB2 单机版等。随着数据不断积累，数据量越来越大，团队开始面临一些新的问题：要不要购买这些数据库的升级版本，或者要不要再升级硬件，但这些都不能解决根本问题，到未来数据量发展到一定程度时，还是会出现瓶颈。于是浪潮大数据团队综合多方述求开始探索解决方案。

最初经过调研，团队尝试过使用分布式中间件的方法。但对于其他业务部门来说，他们还是希望解决方案对业务代码本身没有侵入，并且中间件的维护也过于复杂。因为浪潮的业务更多是面向传统企业客户，这与很多在自己的业务中使用分布式中间件的互联网公司不同。“我们的业务以响应客户为优先级，必须为这些客户提供一套完整且易用的解决方案。”

“后来，我们的团队了解到了谷歌发布的 NewSQL 技术路线，觉得这种分布式的关系型数据库还比较适合我们。最初我们是在内部引入 CockroachDB，这是谷歌 NewSQL 产品 Spanner 的开源版本。当时 CockroachDB 刚刚发布不久，我们就一直在关注这个项目，也开始给浪潮内部的一些业务应用推荐这个项目。但刚开始用的时候这些业务部门多多少少会遇到一些问题，于是我们大数据团队就开始给他们做一些技术支持的工作，在这个过程中我们的团队也深入到 CockroachDB 社区参与贡献，并为社区提交代码。”陈磊介绍。

而到了 2019 年初，浪潮大数据团队部分已经加入云服务集团团队，面临各项业务上云的工作。这时云服务团队就希望他们把基于 CockroachDB 的分布式数据库也上云。而此时正好赶上了 CockroachDB 官方为了限制 AWS 等云厂商修改了项目的 License，不能把 CockroachDB 当做云服务提供。

“虽然我们能够理解 CockroachDB Labs 的这种做法，但我们也需要维持自己的业务。”于是团队只能基于 CockroachDB 的非商业限制版本重新分支立项，并投入大量人力来维护和开发，也就成了现在的 ZNBase。“当然，我们在这个过程中也收到了很多用户的反馈，也根据这些反馈做了一些工作，包括 SQL 的分析性能增强和各种语法特性优化等。”

因为 ZNBase 整个分布式数据库系统最初都是基于开源项目研发，所以在开发过程中，浪潮也积极地回馈上游的开源社区。据统计，浪潮的技术团队为 Cockroach DB、RocksDB、kubernetes 等项目社区提交了 commit 80 多个，issue 50 多个，参与代码贡献的开发者有 30 余人。

看好 Rust，考虑替换 Go

由于 ZNBase 是基于 CockroachDB 而来，所以使用的开发语言也是该项目原本的 Go 语言；存储层则是基于 RocksDB 开发，因此使用的也是该项目原本的 C++。

Rust 语言近年来在社区中的声量很高，不少大厂也开始在内部大规模启用 Rust 来替换 C++。被问到 ZNBase 是否考虑过在未来将 C++ 替换为 Rust 时，陈磊表示：“Rust 最近确实很火。我个人其实早在 2016 年，也就是 Rust 的 1.0 版本还没有正式发布的时候就开始关注了，它确实是一门非常有潜力的编程语言，不过我们的工作内容更多的是解决客户的实际问题。但目前也仍然保持对 Rust 的关注。”

陈磊认为，Rust 近年来的火爆，更多的是一些大公司在用这门语言，比如国外的亚马逊、微软、谷歌，国内的阿里、华为等，首先这些大公司自身的软件规模足够庞大，C/C++语言在内存管理方面的问题难以解决，他们就可以引入 Rust 来解决这些内存安全的坑。

事实上，ZNBase 作为一款新的产品，在选择技术路线的时候也确实会需要考虑这种未来的趋势，但目前 ZNBase 团队还没有考虑到用 Rust 完全去重写原本用 C++ 开发的 RocksDB。“RocksDB 本身就是一个 C++ 写的东西，除非我们发现 RocksDB 的哪些特性，或者哪些问题无法满足我们的产品需求时，我们才会去尝试改造它。”

值得一提的是，虽然 ZNBase 团队暂时不会考虑用 Rust 去替换掉 C++，但出于对性能的考虑，他们可能会用 Rust 将 SQL 层的 Go 语言替换掉。“Rust 确实是一门性能很高的语言，从技术规划的角度来说，后边我们是有计划把 Go 语言替换成 Rust 的，因为 Go 的性能确实没有 C/C++ 和 Rust 高，我们可能会用 Rust 替换掉 SQL 层和副本层的 GO 语言。”陈磊说。

浪潮的硬件优势

浪潮在国内市场以服务器硬件方面的技术闻名，那么 ZNBase 团队是否在硬件方面做了特别的工作？

陈磊透露，在硬件这一块他们确实做了一些工作，比如在硬件存储方面，浪潮开发了一种新型 ZNSSD 存储设备，团队也是第一时间拿到这款设备进行了软硬件结合的适配，包括硬件底层与 ZNBase 的交互优化，RDMA 的软硬件融合等一些开发。另外浪潮本身还有 K1 的主机服务器，这部分目前也在与 ZNBase 进行底层的适配，从而提高产品的性能和可用性等。

总的来说，得益于浪潮的硬件优势，在硬件方面的工作 ZNBase 团队做起来还是比较顺利的，这也是浪潮 ZNBase 相对于其他分布式数据库来说的一个优势。

与 TiDB 等分布式数据库的区别

提到 HTAP 分布式数据库，我们不得不提近年来在社区中人气火爆的明星项目 TiDB，以及一些同样主打 HTAP 场景融合特性的数据库产品，比如国外的 Greenplum 、阿里云的 HybridDB for MySQL、百度的 BaikalDB 等。陈磊认为，与这些数据库相比，ZNBase 的优势主要体现在两个方面。

第一是背景不同，其他的产品都是大的互联网公司开发的或面向互联网应用的。浪潮是大型 IT 企业面向政府大数据、大型企业应用而产生的。

第二是架构或技术栈有所区别。虽然大部分分布式数据库采用 KV 存储，但刚谈到 ZNBase 是 ShareNothing 架构的，TiDB 则是共享存储架构。由此，浪潮 ZNBase 的优势是扩展性更好，部署运维更加容易，为用户提供了可直接启动的二进制包；另外基于浪潮所服务的一些客户的使用习惯，ZNBase 会兼容更多的 Oracle、DB2 等传统商业数据库的函数与语法。

在硬件方面，浪潮的技术团队在国产芯片及操作系统兼容和优化方面做的更多些。浪潮有自己的分布式存储、操作系统、云平台研发团队，做了很多底层适配与底层优化的工作，这使得 ZNBase 更加稳定可靠。

详细来说，ZNBase 与同样基于 Spanner+F1 设计理念的 TiDB 在 HTAP 架构上还是比较类似的，就是都会提供一个列存的副本，主打的是 OLTP 使用场景，OLAP 的场景应用性能偏轻量级，同时在不断地增强中。二者的主要区别在于面向的客户群体不同。ZNBase 根据浪潮长期积累的大量政府、金融和传统企业客户的需求，对 Oracle、DB2 等传统商用数据库做了大量的兼容性工作，这对浪潮的客户迁移到 ZNBase 很有帮助；而 TiDB 可能更多是面向互联网行业的客户，更多地兼容 MySQL 的生态。

而国外比较火的 Greenplum 是主打 OLAP 场景的产品，OLTP 方面在不断增强；HybridDB for MySQL 和 BaikalDB 这两款产品实际上与 Greenplum 类似，他们都是有一个独立的列存引擎，也就是在表建立之前就已经定义了是列存表还是行存表。而 ZNBase 和 TiDB 都是既有行存的数据副本，也有列存的数据副本，这个实际上是一个本质的区别。

“所以说目前主流的 HTAP 分布式数据库采用行存和列存副本，对同一份数据采用不同的存储格式，应该是未来的一个方向。”陈磊表示，“不过目前我们暂时没有能提供的具体对比数据，各位技术爱好者如果有兴趣就可以自己拿来进行对比，也可以为我们分享。”

HTAP 大有可为

关于近年来兴起的 HTAP 概念，陈磊结合浪潮客户对数据库产品需求的变迁历史，为我们描述了分布式数据库从 OLTP 场景需求到与 OLAP 场景需求结合的进化过程。

从浪潮一直以来接触的一些客户使用场景来看，目前的传统企业市场需求主要还是以 OLTP 为主。主要体现在这些客户的业务量规模扩大了以后，比如说他们需要增加 10 台服务器，可能同时要维护一个包含上百亿数据量的表，这个时候数据还需要不断往里加。这种场景就是分布式数据库的 OLTP 部分可以满足他们的需求。

在解决 OLTP 需求的基础上，整个数据库系统必然会有一些数据的沉淀，人们就需要从这些数据中挖掘出对自身业务有意义的价值，这就产生了对这些数据进行分析的需求。而分布式数据库承载的数据量通常要比传统数据库大得多，用传统技术进行数据分析就会很痛苦，可能一个查询操作就要等上好几天的时间，甚至无法返回结果。“这就是我们还要在解决 OLTP 的基础上增加 OLAP 功能，做成一个融合二者的 HTAP 数据库的原因。”

HTAP 数据库将两种需求场景合二为一的愿景固然美好，但在实际的开发过程中，要想实现 HTAP 并不容易。陈磊介绍，实现 HTAP 的难点主要有几个方面：

首先需要解决的是数据存储，大家知道列存是可以做这种分析型的运算，研发高性能的列存引擎就是一个难点，当然现在已经有一些优秀的开源列存引擎，开发者可以在此基础上复用。

然后就是行存和列存数据的一致性问题。传统的 HTAP 数据库行存与列存是分开的两张表，行列之间不需要保持数据一致性，但是像 ZNBase 以及 TiDB 这种新型的 HTAP 数据库，同样的数据同时有行存和列存，就需要保证数据的一致性，但解决数据一致性问题也会带来新的问题，比如影响数据写入的性能，如何去解决数据写入性能问题也是一个难点。

还有的话就是数据同时保存在列存和行存中，当一个查询命令过来的时候，应该选择哪一个存储引擎来计算？这个时候给数据库系统的 SQL 层、优化器和执行器带来的挑战也会更加大一些。

数据库与 AI

AI 的高速发展影响着各行各业，如今也有一些数据库厂商尝试在 OLAP 的场景中加入 AI 辅助进行数据分析，那么这种趋势是否会给 ZNBase 的未来发展方向带来一些启示呢？

陈磊告诉我们，目前业内在数据库中引用 AI 辅助的模式主要有两种，一种是 AI for DB，还有一种是 DB for AI。

DB for AI 就是为分布式数据库提供 AI 分析的能力。就像 Greenplum 通过 MADlib 的第三方插件来实现一些机器学习、图计算或者深度学习的一些算法，客户直接使用AI算法对库内的数据进行计算。“这样的工作确实有厂商在做，但我认为还不足以形成一种趋势。”陈磊表示。

另外一种模式就是 AI for DB，这种模式有两种，第一种是一些数据库厂商提供的类似“数据库大脑”或“数据库自动驾驶”的外部工具，它通过分析数据库日志或者一些视图，得出数据库的性能表现，然后去动态地调整数据库参数，来达到优化数据库性能的目的。另外就是在数据库中利用一些 AI 算法来进行优化，包括内核优化、运维优化等。比如在数据库比较核心的执行计划、执行计划生成、优化器等部分加入 AI 算法的能力辅助来实现性能优化，这一块确实是数据库行业目前的趋势，也是陈磊认为最难做的部分。

ZNBase 的团队实际上也在做数据库与 AI 结合的研究，而 AI for DB 是目前主要研究的一个方向。

未来规划

最后，陈磊分别从开源运营角度和产品研发角度介绍了 ZNBase 未来一段时间的发展规划。

首先是开源规划，目前团队暂时只开源了 ZNBase 的 KV 存储部分，他们的计划是争取 6 月底把 ZNBase 的所有代码全部开源，包括 SQL 层和一些上下层封装接口，全部采用 Apache 2.0 协议。

而关于研发的规划，陈磊向我们透露了大致的方向：“目前我们正在研发一个列存引擎，还有前面提到的 AI 方面的优化，以及用 C++ 或 Rust 替代 Go 语言来重写 ZNBase 的 SQL 层，这些工作都在我们的日程中。感谢大家对 ZNBase 的关注，我们也会尽快把所有的代码开源出来，届时欢迎感兴趣的开发者加入到我们的社区中参与贡献。“