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

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

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

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

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

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

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

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

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

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

在数据库的起步阶段，选择一些现成的数据库进行改写往往是一种较为容易的方案，但如果再做深入定制便会比较痛苦。为了避免不受历史包袱的影响，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 服务 -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 数据库满足通用场景的需求。虽然实现起来还需要一定的开发周期，但我们也很乐于看到，未来有更多的数据库厂商能够通过创新的架构实践、极简的设计理念，来不断降低企业使用数据系统的复杂度和门槛。