共计 5797 个字符，预计需要花费 15 分钟才能阅读完成。
导读
最近的几年中，HTAP 数据库成为了一个时尚词汇，言必称 HTAP 也成了很多数据库畛域从业者的风潮。如何打造一款 HTAP 数据库，从架构层面登程，去应答将来的变动，拥抱变动，也是很多数据库公司所始终在摸索的。
MatrixOne 是矩阵起源（MatrixOrigin）开源的一款超交融 HTAP 云原生数据库，与业内诸多数据库产品十分不同的点是，MatrixOne 的自研之路是从第一行代码开始的。MO 的指标是打造一款极简、高扩展性、高灵活性、高性价比的全新数据库。
在过来的两年里，MatrixOne 经验了一次架构的演进，更具备试验性质的旧架构到面向未来的新架构，成为了诸多数据库开发工程师与运维工程师的关注点，他们经验怎么的架构演进，这两头又有哪些值得借鉴的内容，将在本文中为大家一一揭晓。
上面是本文目录概览：
1. 晚期架构的千层糕
2. 三座大山，推倒重来
3. 新生后的 MatrixOne
4. 积跬步以至千里
5. 复盘播种
6. 总结
Part 1 晚期架构的千层糕
MatrixOne 作为一款开源分布式架构的数据库，已有靠近 2 年的生命历程。我置信有很多社区老用户，会对晚期架构时 SSB 测试的高性能留有印象。而到了 0.5 版本公布之后，性能忽然就大幅下滑。过后就有敌人问我，怎么还越做越回去了？我对他说，有个大动作，整个架构做了一个大规模的降级。
此时此刻，我觉得很有必要，对整个架构的演进降级，做一个残缺的论述。
如何界定 MatrixOne 的晚期架构？明确地说，是指 MatrixOne 从 0.1 到 0.4 版本的架构，也是在 2022 年上半年之前，在各类推送中呈现的那个架构。与其说这是一个架构，更不如说，这是一场试验，通过一个架构，去摸索出各种架构的有余，找到真正适宜于与原生的 HTAP 分布式架构。
这个试验的旧架构，有两个显著的特色：NewSQL 与 MPP。前者是基于 Google 当年的几篇经典论文所衍生出的，也是明天很多数据库产品的总思路。后者 MPP，顾名思义，大规模并行处理，并行计算是它们的显著特点。落地到 MatrixOne 的晚期架构，又有了更具体的含意。
NewSQL
- 分布式架构：多节点的分布式数据库服务器，每一台服务器既蕴含了计算资源，又有各自的存储节点，解决了传统单机数据库伸缩性和高可用问题。
- 多引擎：数据库服务器中可能存在多个存储引擎，不同的引擎个性不同，负责不同的场景。
MPP
- 并行计算：将工作并行地扩散到多个服务器和节点上，在每个节点上计算实现后，将各自局部的后果汇总在一起失去最终的后果。
1.1 晚期架构详解
进一步拆解，将视角拉到 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 引擎中，提供了全局的元数据的保留与读取，是一个频繁应用的模块。
1.2 晚期架构，何以有余？
作为一个晚期的架构，更多的是承载了研发团队晚期的摸索和钻研，通过试验架构，逐渐摸索出一条面向未来的架构。随着开发进度的一直推动，毫无意外地，旧架构的问题开始凸显进去，并且随着性能与性能的晋升，愈发成为后续倒退的枷锁，集中在三个方面暴发：
拓展性
- Share nothing 架构，每扩大 1 单位节点，需同时扩大存算资源;
- 每份数据至多要保留 3 正本，从扩大节点到实现，工夫更久.
性能
- Raft 协定所蕴含的 leader 角色，容易造成热点；
- 在性能较差的存储下，数据库整体性能降落会超过预期；
- 多种引擎各自用处不同，性能各异，无奈有效应对 HTAP 场景。
老本
- 数据保留 3 正本，随节点规模，老本一直攀升，云上版本更甚；
- 只有高配存储能力施展数据库的预期性能。
这三大难题不得不令 MatrixOne 团队去思考，到底什么样的架构能力满足将来 HTAP 的需要，让云用户与私有化客户，获得最佳产品体验与最佳实际。如同很多破而后立的故事的开始，此时此刻恰如彼时彼刻，由 CTO 田丰博士引领，MatrixOne 团队开始了架构的降级之路。
Part 2 三座大山，推倒重来
三大难题是旧的试验架构的表象，如果仅仅依据表象去解决问题，无疑只能做到知其然而不知其所以然。更深层次的起因，依然须要去被开掘与确认，通过 MatirxOne 研发团队的重复的假如与论证后，旧架构有余的根因，归结为三个大问题，这是压在 MatrixOne 之上的三座大山，如同幽灵个别，在每个 MOer 的头上回旋
2.1 分布式框架
MatrixCube 作为过后的分布式框架，提供了多正本存储模式，每一份数据都保留 3 正本并且以分片（shard）模式保留，使得存储的老本飙升。
而基于 Raft 选举的 Leader 节点，频繁成为了热点，各类操作都须要通过 Leader 节点进行散发，在极其业务场景下，Leader 节点的负载会数倍于一般节点
2.2 引擎泛滥
晚期的 MatrixOne 内置了三种存储引擎，三个引擎之间代码复用率较低，使得对性能的保护须要投入更多人力。
而基于因子化算法的 Plan 构建形式过于激进和形象，在计算组外部对其齐全了解的程序员数量无限，往往增加性能时仍旧须要主开一人实现，新性能增加迟缓。
2.3 资源分配
旧架构采纳了存算不拆散的架构，这个架构导致了扩展性较差。每扩大一个单位的计算节点必须同步扩大存储资源。
因为存储采纳了 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 三座大山，推倒重来
回顾历时数月的架构降级之路，充斥了各种辛酸和苦楚。无论思考的如许充沛，在理论开发中，总会遇到各种各样意想不到的问题呈现，尤其是在一些关键问题上的艰难，让研发团队从开始的束手无策，到偶然的灵光乍现，再到很前面的零之曙光，走向最终的拂晓时刻。个中三昧，显而易见。
这些难题中，次要围绕在存储、事务、负载隔离与资源配比几个方面。
4.1 寻找更适合的存储
在意识到三正本存储带来的问题后，如何寻找一个新的存储适配新架构，成为了过后一大难题，而这个新的存储必须满足两个外围需要，低成本与冷热数据拆散。
在对市面上的诸多存储进行了调研以及试验之后，AWS S3 成为了最终的抉择。繁多正本，自带的冷热数据拆散。
4.2 事务分工的调整
最后的新架构中，计算节点 CN 与数据库节点 DN 之间的分工是 CN 负责计算，计算结果推给 DN，由 DN 实现事务。随着开发进度的一直推动，这个分工开始呈现了问题，DN 对事务的解决能力成为整个零碎的瓶颈。因而，对于 CN 和 DN 的分工，必须做从新定义：
- CN 负责所有的计算以及事务逻辑，DN 负责保留元数据信息、日志信息以及事务裁决，DN 不再成为瓶颈；
- 在日志中引入 Logtail 对象，用于保留最近日志中的关联数据，定期将 Logtail 的数据写入 S3 中，CN 扩容能够实时将 Logtail 数据同步至 Cache，实现了局部数据共享；
- 为事务大小设置阈值，超过阈值下限的事务间接写 S3，日志只保留记录写入记录，未超过阈值的事务持续由 DN 写入，极大减少了吞吐量。
4.3 实现 HTAP 的工作负载隔离
作为 HTAP 数据库，如何实现不同类型的工作负载隔离，是一个必须解决的问题。在实现了对旧的试验架构的灵便解耦之后，工作负载的隔离也得以实现：
- 服务器级别的隔离，硬件资源富余的状况下，各个组件别离在不同的物理机运行，接入同一个对象存储；
- 容器级别的隔离，硬件资源无限的状况下，利用所有节点无状态的个性，以容器作为各个节点的隔离伎俩。
4.4 实现资源配比的灵便调整
作为 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 的引入
▶ 灵便调整节点调配带来的资源隔离