重写 50 万行代码，从 0 自研的云原生 HSTAP 能否成为数据库的未来？

HTAP，一个为满足实时性业务分析场景而存在的数据库。

从 2005 年被 Gartner 首次提出以来，HTAP 已经历经数十年的发展期。在当下，如果再次提起 HTAP，不免让人觉得它是个既“友好”又“矛盾”的存在。

“友好”在于，HTAP 数据库能够同时支撑业务系统和在离线数据分析系统运行，避免在传统架构中，在线与离线数据库之间大量的数据交互，对简化企业的数据系统的复杂度将起到至关重要的作用；但“矛盾”在于，用户在 AP 场景和 TP 场景负载模型差异很大，对数据库的诉求也完全不同，如何通过技术手段来平衡他们之间的矛盾成为了 HTAP 数据库的核心问题，因此，一定要有东西在这两者之间做桥梁。

至此，问题也就显露出来了。用户如何能在 TP 还是 AP 负载下，随心所欲地去创建各种表，也可以随心所欲地用一个流呢？在超融合趋势的推动之下，HSTAP 的概念呼之欲出，多出来的“S”格外让人好奇到底是不是在造概念。为了深入了解 HSTAP 的技术架构与产品特性，InfoQ 特别采访了矩阵起源技术 VP 秦姝琦。

技术的发展有迹可循，先谈谈为何提出 HSTAP

要知道，一个技术概念之所以被提出，究其根本还是为了解决某一类痛点问题。比如，近几年 IoT 产业以及 AI 行业的兴起，产生了大量的时序数据以及图数据，在底层数据类型愈发多样的前提下，直接催生出了一批时序数据库和图数据库。

那么，HSTAP 为何会被提出呢？若想真正理解 HSTAP 的内核，不妨先看看它到底要解决业界的哪些问题。

拿一个典型的融合型场景为例，一款股票 APP 本身是交易系统，所以它需要一个 OLTP 数据库做支撑，但是用户又希望其提供股市的预测和分析，这里自然就出现了对 OLAP 系统的需求，即在做大规模交易的同时，还需要基于交易数据和用户行为数据进行分析建模。

要想解决上述问题，常规的技术方案是怎样的呢？如下图所示，企业需要用到非常多的中间件来搭建一个复杂的数据系统，其中包括 OLTP 数据库、OLAP 数据库，消息队列、流引擎、ETL 工具等等，这样一来，会导致系统变得非常复杂，难以保证稳定性；其次，数据流转的链路也变得很长，实时性无法保证，数据血缘管理难度很大，这种基于“缝合”方式搭建的系统，在稳定性、实时性以及运维管理成本和开发成本上存在很多痛点。

在刚刚结束的 2022 re:Invent 大会中，亚马逊云科技提出了一个新的名词——“Zero-ETL”，其本质也是识别到了数据流转已经成为企业很大的痛点。不难看出，简化复杂架构，降低运维使用成本的需求正在不断增长。为了让企业只用一款数据库，就能把最基础的业务中台和数据中台以最低的成本建设好，矩阵起源对 HTAP 进行了重新定义，融入了串联 AP 和 TP 的 Streaming 能力。因此，在秦姝琦看来，HSTAP 的出现便是为了简化数据系统的复杂性，提供极简的用户体验，降低数据使用的难度，让企业可以将精力从繁杂的技术细节中释放出来，专注于数据价值的挖掘，最终达到降本增效的目标。

从 0 开始自研，MatrixOne 的架构解析

在数据库的起步阶段，选择一些现成的数据库进行改写往往是一种较为容易的方案，但如果再做深入定制便会比较痛苦。为了避免不受历史包袱的影响，MatrixOne  从设计之初便放弃了一条相对容易的路，选择从 0 开始自研，用时七个月将 Share Nothing 迁移到云原生架构，从 AOE（Append Optimized Engine）存储切换到 TAE（Transactional Analytical Engine），重写了计算引擎（Parser，执行计划，优化器等），并且完成了分布式事务框架和高性能日志服务的研发，累计删除代码 30 万行，新增 20 万行。

这背后的工作量与执行力足以让我们叹为观止，但回忆起 MatrixOne 的起步期，秦姝琦提到：“在真正设计开发这样一款云原生 HSTAP 数据库的时候，我们面临非常多的艰难选择。”

具体来说，用户对于 TP 和 AP 数据库系统的需求基本可以归纳为以下五点：ACID，并发性能，吞吐，成本和数据新鲜度。HSTAP 数据库若想兼容以上能力，实现起来却没那么容易，由于高并发、短时延的 OLTP 负载与带宽密集型、高时延的 OLAP 负载的访问模式不同且它们互相干扰，把他们融合到一个系统里存在很多的冲突点。

谈及如何平衡上述矛盾，秦姝琦以通信领域中两个耳熟能详的概念为例：频分复用和时分复用，即当突破资源粒度划分得足够小，资源隔离做得足够好，调度能力足够强时，就可以把一些看似矛盾的功能平衡起来。“因此，在设计 HSTAP 数据库时，我们不会追求以上提到的五点在同一时间都做到 100 分，而是基于统一存储引擎，对象存储，自适应计算优化，计算存储独立扩缩容，全局的资源调度和资源隔离策略动态平衡这五个看似矛盾的特性，来适应不同的负载场景需求。”

基于这样的设计理念，MatrixOne 引擎的顶层设计架构，可以大致分为三层：计算层、分布式事务层和共享存储层。

其中，计算层是由多组计算资源组成的，其中计算单元我们称之为 CN，每个 CN 可以承担不同的任务，但无论 CN 用于何种用途它本身是不保存任何状态的，以保证计算层是可以任意扩缩容的；再往下面一层是 Transaction Layer，这一层承担了分布式事务处理的相关工作。分布式事务层选择了 share-nothing 的模式，由于每个 DN 之间需要处理的数据范围各不相关，这样做的好处在于，每个 DN 只需要负责自己这部分数据的冲突检测，从设计上简化了 DN 的实现复杂度和扩缩容的难度；再往下是两个服务，一个是 Log service，为 DN 提供高性能的分布式高可用的日志读写服务，它直接决定事务写性能的关键；另外一个是共享存储，这里不仅支持 S3 这类对象存储，还支持 NFS 以及 HDFS。

此外，为了让 MatrixOne 在云上和私有化场景能够保持统一的架构和接口，还在底层架构中抽象了一层 fileservice 接口，它会将底层不同的共享存储实现细节屏蔽掉。比如，在云上选择 S3 作为底层共享存储，那么在私有化场景不一定有 S3，客户如果能提供 HDFS 集群，就可以通过 fileservice 在保持引擎接口一致的前提下，支持多种的共享存储。

除此之外，MatrixOneGA 版本将会有一个重要的特性——实现了 Streaming 的方案，即 HSTAP 中的“S”。秦姝琦坦言，目前的 Streaming 还处于早期阶段，团队关注的核心问题还是 framework 的设计、有界数据和无界数据的处理以及增量计算的优化等等。

MatrixOne 上云的价值与实现路径

有了上述方案以后，MatrixOne 是否就可以为用户带来简单、易用的最终体验呢？显然还不够，一个普遍的现象是，当云逐渐变成新的基础设施以后，开发者几乎不会触碰到云服务下层的基础设施，这对于数据库厂商而言，也需要思考如何利用云服务作为底座来构建数据库。因此，在此基础上，MatrixOne 也计划上线全托管 MatrixOne 服务 -MO Cloud，目前已经处于开发阶段，目标支持多个国内外公有云如 AWS、GCP、华为云、阿里云等等，其具备的主要特点是 SaaS 化的使用体验，免部署、自动化运维、按量计费、成本低。

为了实现自动化运维的特性，MO Cloud 也选择拥抱了 Kubernetes 生态，然而 MatrixOne 作为一个有状态的系统，它具有自己独有的状态编排的领域知识，如果 Kubernetes 没有这些领域知识，便无法很好地对 MatrixOne 进行编排和调度。因此，MatirxOne 还上线了专属的 MO-Operator，它封装了编排调度 MatrixOne 所需要的全部领域知识，再利用 Kubernetes API 添加自定义 API 类型的能力，来保证运行中的集群状态永远向用户定义的期望状态转移。目前，MO-Operator 已经实现了创建集群、资源伸缩调度，故障转移，滚动更新等功能。“MO-Operator 就像一个经验丰富的运维同学时刻监控 MatrixOne 集群的状态，而且一切按规则执行永不休息。” 秦姝琦比喻道。

实际上，上述所提到的 MO-Operator 只是 MOCloud 的冰山一角，下图展示了 MOCloud 的架构图，包含平台（Platform）和编排（ COS） 两套系统以及旁路观测系统。架构图的上半部分是 MOCloud 的控制面，Platform 包含了一组微服务，比如用户管理，集群管理，计费等，是整个 MOCloud 中唯一需要跟用户进行交互的部分，中间的 Global API Server 是 COS 的核心，也是 Platform 跟 COS 之间的纽带，架构图的下半部分是 MOCloud 的数据面，也就是真正运行工作负载的地方。

值得一提的是，自 Serverless 被认为是新一代云计算发展方向以来，业内就开始关注、推进 Serverless 化，试图从资源视角转换为服务视角。在今年的阿里云栖大会上，阿里云宣布将坚定推进核心产品全面 Serverless 化；在 2022 re: Invent 大会上，亚马逊云科技宣布将数据分析服务全面 Serverless 化. MOCloud 也开始了对于 Serverless 的探索。

秦姝琦认为实现 Serverless 化有两方面好处：一方面，Serverless 对于很多中小型企业很友好，注册即可使用，无需关心任何底层资源，当企业不使用数据库时，也不用付出任何成本；另一方面，站在数据库厂商的角度来看，虽然 Serverless 在前期的投入成本相对较高，但后期可以带来更大的商业回报，是提升收益的一种技术手段。

尽管 Serverless 对于供需双方的价值已经趋向清晰，但是数据库 Serverless 化的实现难度却很高，在秦姝琦看来，主要技术挑战大致可以分为三个部分：第一是安全性，即多租户的资源隔离；第二点资源调度，如何让系统负载达到最优；第三点是整个系统的弹性、高可用。

在采访过程中，秦姝琦主要为我们介绍了 MOCloud 在资源隔离方面的实现进展。在数据的可见性上，MOCloud 可以保证逻辑上的隔离，一个 Session 只能看到这个租户权限范围内的数据，在资源隔离上，还计划用 Proxy+rule engine+CN 来完成一个全局的流控和资源调度，CN 支持独占 Set 来满足更多元化的要求。此外，针对大家关注的安全问题，MOCloud 也会保证持久化的数据是加密的，未来将支持“ bring your own key”的模式，支持租户维度的数据加密。

未来发展方向

数据库从来都不会单独被使用，尤其对于初创的数据库厂商而言，完善生态也是非常重要的工作。秦姝琦透露，在更完整的生态对接方面，MatirxOne 将在明年陆续在开源项目上开展对接，还计划针对制造业、能源、新兴互联网等行业，制定相应的解决方案，为此也会在 MatirxOne 中接入相应的生态。

与此同时，她还介绍了 MatirxOne 在未来的产品规划。预计在明年，MatirxOne 将会推出第一个 GA 版本，接下来还将继续融入流的能力，力争通过一个 HSTAP 数据库满足通用场景的需求。虽然实现起来还需要一定的开发周期，但我们也很乐于看到，未来有更多的数据库厂商能够通过创新的架构实践、极简的设计理念，来不断降低企业使用数据系统的复杂度和门槛。