翻过三座大山：MatrixOne从 NewSQL 到 HTAP 分布式架构演进

这个实验的旧架构，有两个显著的特征：NewSQL与MPP。前者是基于Google当年的几篇经典论文所衍生出的，也是今天很多数据库产品的总思路。后者MPP，顾名思义，大规模并行处理，并行计算是它们的显著特点。落地到MatrixOne的早期架构，又有了更具体的含义。

• 分布式架构：多节点的分布式数据库服务器，每一台服务器既包含了计算资源，又有各自的存储节点，解决了传统单机数据库伸缩性和高可用问题。

• 多引擎：数据库服务器中可能存在多个存储引擎，不同的引擎特性不同，负责不同的场景。

• 并行计算：将任务并行地分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果。

进一步拆解，将视角拉到MatrixOne Server内部，它又有着多个模块，分工协同，完成整个分布式数据库的功能。一共分为5个部分，前端、计算层、分布式框架、存储层、元数据层。五个部分各自的功能与特性又各有不同。

 SQL Frontend 

• 提供MySQL兼容协议，确保MySQL的各类协议能够被MatrixOne接收；

• 兼容MySQL的语法，对接收的SQL做符合MySQL的语法判断。

 Query Parser 

• SQL解析，对前端的SQL并转化抽象语法树；

• 方言支持，提供支持多种SQL方言基础。

 MPP SQL Execution 

• SQL加速，对SQL计算引擎的一些基础操作的向量化加速，部分操作采用汇编改写做加速；

• Plan构建，使用独有的因子化加速能力做SQL的Plan构建。

 分布式框架 

• 提供高可用、多副本、强一致与自动负载均衡；

• 提供分布式事务的支持能力（WIP）；

• 提供基于Raft的副本调度机制，该调度器在代码中称为Prophet。

 存储层 

• AOE引擎，Append Only Engine，这是一个Append Only的列存引擎，不支持事务；

• TPE引擎，Transaction Processing Engine，用于保存元数据Catalog；

• TAE引擎，Transactional Analytical Engine，基于列存的HTAP引擎，会提供完整ACID能力及强大的OLAP能力。

作为一个早期的架构，更多的是承载了研发团队早期的探索和研究，通过实验架构，逐步探索出一条面向未来的架构。随着开发进度的不断推进，毫无意外地，旧架构的问题开始凸显出来，并且随着功能与性能的提升，愈发成为后续发展的桎梏，集中在三个方面爆发：

 拓展性 

• Share nothing架构，每扩展1单位节点，需同时扩展存算资源;

• 每份数据至少要保存3副本，从扩展节点到完成，时间更久.

 性能 

• Raft协议所包含的leader角色，容易造成热点；

• 在性能较差的存储下，数据库整体性能下降会超过预期；

• 多种引擎各自用途不同，性能各异，无法有效应对HTAP场景。

 成本 

• 数据保存3副本，随节点规模，成本不断攀升，云上版本更甚；

• 只有高配存储才能发挥数据库的预期性能。

这三大难题不得不令MatrixOne团队去思考，到底什么样的架构才能满足未来HTAP的需求，让云用户与私有化客户，获得最佳产品体验与最佳实践。如同很多破而后立的故事的开端，此时此刻恰如彼时彼刻，由CTO田丰博士引领，MatrixOne团队开始了架构的升级之路。

MatrixCube作为当时的分布式框架，提供了多副本存储模式，每一份数据都保存3副本并且以分片（shard）形式保存，使得存储的成本飙升。

而基于Raft选举的Leader节点，频繁成为了热点，各类操作都需要通过Leader节点进行分发，在极端业务场景下，Leader节点的负载会数倍于普通节点

在找到了三座大山之后，接下来要做的事情就是一一扳倒它们，田丰博士结合MatrixOne的产品愿景以及未来的技术趋势，对于实验架构进行了总结，并提出了MatrixOne独有的架构设想，从整个架构的现状来看，要分三步走：

• 第一步，将旧架构share nothing的框架破除，完成更灵活的解耦；

• 第二步，将多种引擎合二归一，实现内部引擎的大一统；

• 第三部，重构计算引擎，留有足够的空间给未来的产品发展。

新架构通过解耦，最终实现了三个各自独立的层级，每个层级有自己的对象单元与分工，不同类型的节点可以灵活伸缩，不再受到其他层的制约：

•  计算层 ，以计算节点Compute Node为单位，实现了计算和事务处理的Serverless化，又有自己的Cache，可以实现任意重启与扩缩容；

•  事务层 ，以数据库节点Database Node为与日志节点Log Service为单位，提供完整的日志服务以及元数据信息，内置Logtail用于保存最近数据；

•  存储层 ，全量数据保存在以S3为代表的对象存储中，实现了低成本的无线伸缩存储方式，以File Service命名的统一文件操作服务，实现了不同节点对底层存储的无感知操作。

在确定了以TAE作为唯一存储引擎之后，对融合后的TAE引擎又做了诸多设计上的调整，才有了后来融合后的TAE存储引擎。完成了单一引擎完成所有数据库存储行为的目标，并且具备了如下优势：

•  列存管理 ，统一的列存与压缩，对于OLAP业务有着先天的性能优势；

•  事务处理，共享日志与DN节点共同完成对计算节点的事务支持；

•  冷热分离，使用File Service以S3对象存储作为目标，每个计算节点都有自己的Cache。

多次运行测试，得出置信度较高的结果：

早期的计算引擎中，兼容MySQL的大目标没有变化，但是对于节点调度、执行计划、SQL能力又有着更高的要求。重构后的高性能计算引擎，既具备了实验架构中计算引擎的MPP，又弥补了过去的诸多不足：

•  兼容MySQL，既有对MySQL协议的支持，又包含了对MySQL语法的支持；

•  融合引擎，基于DAG重新构建执行计划，可以同时执行TP和AP；

•  节点调度，未来可支持自适应节点内和节点间调度，同时满足并发和并行执行；

•  完善SQL能力，支持子查询、窗口函数、CTE、Spill内存溢出处理等。

回顾历时数月的架构升级之路，充满了各种辛酸和痛苦。无论考虑的多么充分，在实际开发中，总会遇到各种各样意想不到的问题出现，尤其是在一些关键问题上的困难，让研发团队从开始的一筹莫展，到偶尔的灵光乍现，再到很后面的零之曙光，走向最终的黎明时刻。个中三昧，不言而喻。

这些难题中，主要围绕在存储、事务、负载隔离与资源配比几个方面。

在意识到三副本存储带来的问题后，如何寻找一个新的存储适配新架构，成为了当时一大难题，而这个新的存储必须满足两个核心需求，低成本与冷热数据分离。

在对市面上的诸多存储进行了调研以及试验之后，AWS S3成为了最终的选择。单一副本，自带的冷热数据分离。

最初的新架构中，计算节点CN与数据库节点DN之间的分工是CN负责计算，计算结果推给DN，由DN完成事务。随着开发进度的不断推进，这个分工开始出现了问题，DN对事务的处理能力成为整个系统的瓶颈。因此，对于CN和DN的分工，必须做重新定义：

• CN负责所有的计算以及事务逻辑，DN负责保存元数据信息、日志信息以及事务裁决，DN不再成为瓶颈；

• 在日志中引入Logtail对象，用于保存最近日志中的关联数据，定期将Logtail的数据写入S3中，CN扩容可以实时将Logtail数据同步至Cache，实现了部分数据共享；

• 为事务大小设置阈值，超过阈值上限的事务直接写S3，日志只保存记录写入记录，未超过阈值的事务继续由DN写入，极大增加了吞吐量。

作为HTAP数据库，如何实现不同类型的工作负载隔离，是一个必须解决的问题。在完成了对旧的实验架构的灵活解耦之后，工作负载的隔离也得以实现：

• 服务器级别的隔离，硬件资源充裕的情况下，各个组件分别在不同的物理机运行，接入同一个对象存储；

• 容器级别的隔离，硬件资源有限的情况下，利用所有节点无状态的特性，以容器作为各个节点的隔离手段。

作为HTAP数据库，日常业务中，不同业务场景的比例是在动态变化中，对于资源的配比也有着更高的要求，而旧架构下的资源分配模式注定无法实现灵活调整，需要对各个节点实现更加精细化的管理，包含但不限于：

• CN节点的分工，允许用户对CN进行划分，用于TP或AP业务，其中某项业务资源出现瓶颈之后，对CN进行水平扩容；

• 在不类业务的CN组之间，动态判断各组的负载情况，当前两类业务的负载差异较大时，可以自动将闲置资源分配至繁忙组内；

• 通过租户（account）的逻辑概念，实现逻辑资源的完全隔离，不同的租户可以以独享或共享的方式使用指定的CN资源。

在诸多问题得以解决的背后，是众多MOer一次次发起的攻坚，在阵痛之后，也收获了很多过去不曾涉足过的知识与经验。这些不仅仅是解决问题的积累，同样也为今后MatrixOne的开发积累了一比宝贵的财富。

为此我从解耦之后的三层架构角度，对相关几位同事做了访谈，在倾听了他们对问题的回顾与思考之后，做出了如下的反馈：

 计算层 

• 理解SQL的执行，通过重构Plan，对于SQL语法的解析、执行计划以及SQL标准语法都有了更多认识；

• 事务与ACID，专注于单一引擎之后，几乎每一条SQL都要考虑事务与ACID，需要对这些有更深的理解。

 事务层 

• CN与DN的适配，从架构升级开始，CN与DN的分工与适配成为了巨大难题，反复验证中得到了最优解；

• 部分数据共享，Logtail的引入，实现了某一部分数据在不同CN之间共享。

 存储层 

• 使用S3存储，积累了基于S3等对象存储的引擎开发经验，原来对象存储也可以很好地适配数据库；

• Fileservice，一种存储服务，去实现不同节点不同底层存储类型的读写，是个极大的挑战。

矩阵起源公司成立于2021年，在上海、深圳、北京、硅谷等城市设有分支机构。团队成员由各领域专家组成，在分布式基础架构、数据库、大数据及人工智能领域经验丰富。致力于成为行业领先的数据基础软件公司，帮助所有企业和用户简单、敏捷、高效地拥抱数据价值。

整个MatrixOne的架构升级之路，始于0.4迭代，在0.6迭代初步完成，历时半年多，数十位一线研发与测试工程师投入其中。删掉了关联的几十万行代码，又新增了体量更多的新代码。最终完成了从share nothing的newSQL架构到今天的新分布式HTAP架构，团队与产品共同获得了成长。

最后，让我们总结一下MatrixOne架构升级的关键点：

▶ 从存算一体到计算、事务、存储三层解耦

▶ 从多引擎到单一TAE的HTAP融合引擎

▶ 从因子化算法到DAG的计划构建

▶ 从多副本存储到对象存储与Logtail的引入

▶ 灵活调整节点分配带来的资源隔离