矩阵起源是一家专注于为企业用户提供简捷强大的数据操作系统的数据基础软件公司。公司创始团队来自腾讯云、Snowflake等国内外一流的互联网企业、软件公司、数字化企业和开源社区，核心团队为产品、研发、解决方案、生态和开源社区等领域的专家，在分布式架构、数据库、云计算、大数据及人工智能等领域积累了丰富经验。

MatrixOne 是矩阵起源（MatrixOrigin）开源的一款超融合 HTAP 云原生数据库，与业内诸多数据库产品非常不同的点是，MatrixOne 的自研之路是从第一行代码开始的。MatrixOne的目标是打造一款极简、高扩展性、高灵活性、高性价比的全新数据库。在过去的两年里，MatrixOne经历了一次架构的演进。MatrixOne 研发团队推翻旧架构三座大山，升级全新架构。

推翻三座大山

分布式框架

MatrixCube作为当时的分布式框架，提供了多副本存储模式，每一份数据都保存3副本并且以分片（shard）形式保存，使得存储的成本飙升。而基于Raft选举的Leader节点，频繁成为了热点，各类操作都需要通过Leader节点进行分发，在极端业务场景下，Leader节点的负载会数倍于普通节点。

引擎众多

早期的MatrixOne内置了三种存储引擎，三个引擎之间代码复用率较低，使得对功能的维护需要投入更多人力。而基于因子化算法的Plan构建方式过于激进和抽象，在计算组内部对其完全理解的程序员数量有限，往往添加功能时仍旧需要主开一人完成，新功能添加缓慢。

资源分配

旧架构采用了存算不分离的架构，这个架构导致了扩展性较差。每扩展一个单位的计算节点必须同步扩展存储资源。由于存储采用了shard分片，使得在shard较大时影响了OLTP的性能，在shard较小时，又会影响OLAP性能。

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

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

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

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

重生后的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内存溢出处理等。

积跬步以至千里

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

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

寻找更合适的存储

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

在对市面上的诸多存储进行了调研以及试验之后，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资源。

写在最后

矩阵起源作为一家数据智能领域的创新企业致力于成为数字世界的核心技术提供者。 矩阵起源专注建设开放的技术开源社区和生态系统、打造世界级的团队、并通过业界领先的技术创新和工程能力，实现数据在数字世界中的任意存储和任意计算，帮助用户释放数据的潜力和创新力（Store Anywhere, Compute Anywhere, Innovate Anywhere）。

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

免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。

责任编辑：kj005