翻过三座大山：MatrixOne从 NewSQL 到 HTAP 分布式架构演进
作者：张潇 MO产品架构师
导读
最近的几年中，HTAP数据库成为了一个时髦词汇，言必称HTAP也成了很多数据库领域从业者的风潮。如何打造一款HTAP数据库，从架构层面出发，去应对未来的变化，拥抱变化，也是很多数据库公司所一直在探索的。
MatrixOne 是矩阵起源（MatrixOrigin）开源的一款超融合 HTAP 云原生数据库，与业内诸多数据库产品非常不同的点是，MatrixOne 的自研之路是从第一行代码开始的。MO 的目标是打造一款极简、高扩展性、高灵活性、高性价比的全新数据库。
在过去的两年里，MatrixOne经历了一次架构的演进，更具有实验性质的旧架构到面向未来的新架构，成为了诸多数据库开发工程师与运维工程师的关注点，他们经历怎样的架构演进，这中间又有哪些值得借鉴的内容，将在本文中为大家一一揭晓。
下面是本文目录概览：
1.
早期架构的千层糕
2.
三座大山，推倒重来
3.
重生后的MatrixOne
4.
积跬步以至千里
5.
复盘收获
6.
总结
本文字数：4800字+ 阅读时间：8分钟+
Part 1
早期架构的千层糕
MatrixOne作为一款开源分布式架构的数据库，已有接近2年的生命历程。我相信有很多社区老用户，会对早期架构时SSB测试的高性能留有印象。而到了0.5版本发布之后，性能突然就大幅下滑。当时就有朋友问我，怎么还越做越回去了？我对他说，有个大动作，整个架构做了一个大规模的升级。
此时此刻，我觉得很有必要，对整个架构的演进升级，做一个完整的阐述。
如何界定MatrixOne的早期架构？明确地说，是指MatrixOne从0.1到0.4版本的架构，也是在2022年上半年之前，在各类推送中出现的那个架构。与其说这是一个架构，更不如说，这是一场实验，通过一个架构，去探索出各种架构的不足，找到真正适合于与原生的HTAP分布式架构。
这个实验的旧架构，有两个显著的特征：NewSQL与MPP。前者是基于Google当年的几篇经典论文所衍生出的，也是今天很多数据库产品的总思路。后者MPP，顾名思义，大规模并行处理，并行计算是它们的显著特点。落地到MatrixOne的早期架构，又有了更具体的含义。
NewSQL
分布式架构：多节点的分布式数据库服务器，每一台服务器既包含了计算资源，又有各自的存储节点，解决了传统单机数据库伸缩性和高可用问题。
多引擎：数据库服务器中可能存在多个存储引擎，不同的引擎特性不同，负责不同的场景。
MPP
并行计算：将任务并行地分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果。
早期架构详解
进一步拆解，将视角拉到MatrixOne Server内部，它又有着多个模块，分工协同，完成整个分布式数据库的功能。一共分为5个部分，前端、计算层、分布式框架、存储层、元数据层。五个部分各自的功能与特性又各有不同。
SQL Frontend
亦称SQL前端，是直接处理SQL语句的部分，它提供了如下功能：
提供MySQL兼容协议，确保MySQL的各类协议能够被MatrixOne接收；
兼容MySQL的语法，对接收的SQL做符合MySQL的语法判断。
Query Parser
是MatrixOne中对语法解析的功能模块，它提供了如下功能：
SQL解析，对前端的SQL并转化抽象语法树；
方言支持，提供支持多种SQL方言基础。
MPP SQL Execution
是实现MPP的SQL执行器，它提供了如下功能：
SQL加速，对SQL计算引擎的一些基础操作的向量化加速，部分操作采用汇编改写做加速；
Plan构建，使用独有的因子化加速能力做SQL的Plan构建。
分布式框架
早期MatrixOne的分布式框架叫做MatrixCube，同样是一个开源项目，它具备了如下组件与功能：
提供高可用、多副本、强一致与自动负载均衡；
提供分布式事务的支持能力（WIP）；
提供基于Raft的副本调度机制，该调度器在代码中称为Prophet。
存储层
早期的MatrixOne存储层是一个拥有多个引擎的架构，多种存储引擎互相分工协作，共同完成HTAP数据库功能：
AOE引擎，Append Only Engine，这是一个Append Only的列存引擎，不支持事务；
TPE引擎，Transaction Processing Engine，用于保存元数据Catalog；
TAE引擎，Transactional Analytical Engine，基于列存的HTAP引擎，会提供完整ACID能力及强大的OLAP能力。
元数据层是一个在早期MatrixOne架构中被每个其他模块都频繁调用的内容，保存在TPE引擎中，提供了全局的元数据的保存与读取，是一个频繁使用的模块。
早期架构，何以不足？
作为一个早期的架构，更多的是承载了研发团队早期的探索和研究，通过实验架构，逐步探索出一条面向未来的架构。随着开发进度的不断推进，毫无意外地，旧架构的问题开始凸显出来，并且随着功能与性能的提升，愈发成为后续发展的桎梏，集中在三个方面爆发：
拓展性
Share nothing架构，每扩展1单位节点，需同时扩展存算资源;
每份数据至少要保存3副本，从扩展节点到完成，时间更久.
性能
Raft协议所包含的leader角色，容易造成热点；
在性能较差的存储下，数据库整体性能下降会超过预期；
多种引擎各自用途不同，性能各异，无法有效应对HTAP场景。
成本
数据保存3副本，随节点规模，成本不断攀升，云上版本更甚；
只有高配存储才能发挥数据库的预期性能。
这三大难题不得不令MatrixOne团队去思考，到底什么样的架构才能满足未来HTAP的需求，让云用户与私有化客户，获得最佳产品体验与最佳实践。如同很多破而后立的故事的开端，此时此刻恰如彼时彼刻，由CTO田丰博士引领，MatrixOne团队开始了架构的升级之路。
Part 2
三座大山，推倒重来
三大难题是旧的实验架构的表象，如果仅仅根据表象去解决问题，无疑只能做到知其然而不知其所以然。更深层次的原因，仍然需要去被挖掘与确认，经过MatirxOne研发团队的反复的假设与论证后，旧架构不足的根因，归结为三个大问题，这是压在MatrixOne之上的三座大山，如同幽灵一般，在每个MOer的头上盘旋
分布式框架
MatrixCube作为当时的分布式框架，提供了多副本存储模式，每一份数据都保存3副本并且以分片（shard）形式保存，使得存储的成本飙升。
而基于Raft选举的Leader节点，频繁成为了热点，各类操作都需要通过Leader节点进行分发，在极端业务场景下，Leader节点的负载会数倍于普通节点
引擎众多
早期的MatrixOne内置了三种存储引擎，三个引擎之间代码复用率较低，使得对功能的维护需要投入更多人力。
而基于因子化算法的Plan构建方式过于激进和抽象，在计算组内部对其完全理解的程序员数量有限，往往添加功能时仍旧需要主开一人完成，新功能添加缓慢。
资源分配
旧架构采用了存算不分离的架构，这个架构导致了扩展性较差。每扩展一个单位的计算节点必须同步扩展存储资源。
由于存储采用了shard分片，使得在shard较大时影响了OLTP的性能，在shard较小时，又会影响OLAP性能。
在找到了三座大山之后，接下来要做的事情就是一一扳倒它们，田丰博士结合MatrixOne的产品愿景以及未来的技术趋势，对于实验架构进行了总结，并提出了MatrixOne独有的架构设想，从整个架构的现状来看，要分三步走：
第一步，将旧架构share nothing的框架破除，完成更灵活的解耦；
第二步，将多种引擎合二归一，实现内部引擎的大一统；
第三部，重构计算引擎，留有足够的空间给未来的产品发展。
Part 3
重生后的MatrixOne
新架构通过解耦，最终实现了三个各自独立的层级，每个层级有自己的对象单元与分工，不同类型的节点可以灵活伸缩，不再受到其他层的制约：
计算层 ，以计算节点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内存溢出处理等。
Part 4
三座大山，推倒重来
回顾历时数月的架构升级之路，充满了各种辛酸和痛苦。无论考虑的多么充分，在实际开发中，总会遇到各种各样意想不到的问题出现，尤其是在一些关键问题上的困难，让研发团队从开始的一筹莫展，到偶尔的灵光乍现，再到很后面的零之曙光，走向最终的黎明时刻。个中三昧，不言而喻。
这些难题中，主要围绕在存储、事务、负载隔离与资源配比几个方面。
寻找更合适的存储
在意识到三副本存储带来的问题后，如何寻找一个新的存储适配新架构，成为了当时一大难题，而这个新的存储必须满足两个核心需求，低成本与冷热数据分离。
在对市面上的诸多存储进行了调研以及试验之后，AWS S3成为了最终的选择。单一副本，自带的冷热数据分离。
事务分工的调整
最初的新架构中，计算节点CN与数据库节点DN之间的分工是CN负责计算，计算结果推给DN，由DN完成事务。随着开发进度的不断推进，这个分工开始出现了问题，DN对事务的处理能力成为整个系统的瓶颈。因此，对于CN和DN的分工，必须做重新定义：
CN负责所有的计算以及事务逻辑，DN负责保存元数据信息、日志信息以及事务裁决，DN不再成为瓶颈；
在日志中引入Logtail对象，用于保存最近日志中的关联数据，定期将Logtail的数据写入S3中，CN扩容可以实时将Logtail数据同步至Cache，实现了部分数据共享；
为事务大小设置阈值，超过阈值上限的事务直接写S3，日志只保存记录写入记录，未超过阈值的事务继续由DN写入，极大增加了吞吐量。
实现HTAP的工作负载隔离
作为HTAP数据库，如何实现不同类型的工作负载隔离，是一个必须解决的问题。在完成了对旧的实验架构的灵活解耦之后，工作负载的隔离也得以实现：
服务器级别的隔离，硬件资源充裕的情况下，各个组件分别在不同的物理机运行，接入同一个对象存储；
容器级别的隔离，硬件资源有限的情况下，利用所有节点无状态的特性，以容器作为各个节点的隔离手段。
实现资源配比的灵活调整
作为HTAP数据库，日常业务中，不同业务场景的比例是在动态变化中，对于资源的配比也有着更高的要求，而旧架构下的资源分配模式注定无法实现灵活调整，需要对各个节点实现更加精细化的管理，包含但不限于：
CN节点的分工，允许用户对CN进行划分，用于TP或AP业务，其中某项业务资源出现瓶颈之后，对CN进行水平扩容；
在不类业务的CN组之间，动态判断各组的负载情况，当前两类业务的负载差异较大时，可以自动将闲置资源分配至繁忙组内；
通过租户（account）的逻辑概念，实现逻辑资源的完全隔离，不同的租户可以以独享或共享的方式使用指定的CN资源。
Part 5
复盘收获
在诸多问题得以解决的背后，是众多MOer一次次发起的攻坚，在阵痛之后，也收获了很多过去不曾涉足过的知识与经验。这些不仅仅是解决问题的积累，同样也为今后MatrixOne的开发积累了一比宝贵的财富。
为此我从解耦之后的三层架构角度，对相关几位同事做了访谈，在倾听了他们对问题的回顾与思考之后，做出了如下的反馈：
计算层
理解SQL的执行，通过重构Plan，对于SQL语法的解析、执行计划以及SQL标准语法都有了更多认识；
事务与ACID，专注于单一引擎之后，几乎每一条SQL都要考虑事务与ACID，需要对这些有更深的理解。
事务层
CN与DN的适配，从架构升级开始，CN与DN的分工与适配成为了巨大难题，反复验证中得到了最优解；
部分数据共享，Logtail的引入，实现了某一部分数据在不同CN之间共享。
存储层
使用S3存储，积累了基于S3等对象存储的引擎开发经验，原来对象存储也可以很好地适配数据库；
Fileservice，一种存储服务，去实现不同节点不同底层存储类型的读写，是个极大的挑战。
Part 6
总结
矩阵起源公司成立于2021年，在上海、深圳、北京、硅谷等城市设有分支机构。团队成员由各领域专家组成，在分布式基础架构、数据库、大数据及人工智能领域经验丰富。致力于成为行业领先的数据基础软件公司，帮助所有企业和用户简单、敏捷、高效地拥抱数据价值。
整个MatrixOne的架构升级之路，始于0.4迭代，在0.6迭代初步完成，历时半年多，数十位一线研发与测试工程师投入其中。删掉了关联的几十万行代码，又新增了体量更多的新代码。最终完成了从share nothing的newSQL架构到今天的新分布式HTAP架构，团队与产品共同获得了成长。
最后，让我们总结一下MatrixOne架构升级的关键点：
▶ 从存算一体到计算、事务、存储三层解耦
▶ 从多引擎到单一TAE的HTAP融合引擎
▶ 从因子化算法到DAG的计划构建
▶ 从多副本存储到对象存储与Logtail的引入
▶ 灵活调整节点分配带来的资源隔离
