关于数据库:干货分享-MatrixOne系统架构

分享嘉宾：金海    矩阵起源研发 VP
讲稿整顿：张德通  DataFun 志愿者

导读：

随着数字化转型的深刻，数据价值也愈发凸显，数据技术呈现了交融的趋势，基于客户的实在痛点，矩阵起源推出了超交融 MatrixOne HSTAP 数据库。MatrixOne 使数据数据库同时具备 TP、AP 和 Streaming 三种能力，帮忙客户彻底突破数据孤岛问题，成为企业智能化外围的数据基础设施。

明天的分享将解析新一代超交融异构云原生数据库 MatrixOne 刚刚公布的 0.5 版本和后续版本的架构设计。介绍会围绕上面五点开展：

1. 数据存储与解决面临的挑战
2. MatrixOne 架构，各组件和设计方面的取舍
3. MatrixOne 事务相干的读写流程
4. MatrixOne 研发路线图

▌Part 1 – 数据存储与解决面临的挑战

1. 企业数字化中台组件泛滥

企业在做数字化转型时，经常会构建技术中台，基于 Hadoop 搭建出一整套数据处理系统。下图展现了 Hadoop 体系内常见的数据组件，如图所示组件泛滥，有版本、兼容性等大量细节问题须要解决，学习老本、保护老本和保护难度高。

构建和保护整个数据中台就像在搭积木，各个模块搭建起来，尽管能够工作，但整个零碎很软弱，可靠性不好。任何一个组件有问题都会导致整个零碎不可用，整个零碎的可维护性差，构建老本高。

2. 数据库

纵观数据库倒退历程，70 年代开始关系型数据库开始呈现，80 年代 OLTP 数据库经验了大规模倒退，呈现了 Oracle、DB2、Sybase、SQL Server；90 年代呈现了 AP 型数据库，2000 年随着互联网倒退，呈现了 NoSQL 数据库，反对更好的横向扩展性。NoSQL 数据库对事务的反对能力不强，但其良好的可扩展性对数据存储十分敌对，2000 年左右呈现了一批反对 KV、文档、JSON 的 NoSQL 数据库。

2000 年开始逐步呈现了以 Hadoop 为代表的大数据系统，其中包含 Hive、Spark 等。同一期间，为解决传统数据库横向扩大能力受限问题呈现了多种解决方案，一种计划是在传统 MySQL 数据库等根底之上做分库分表中间件，在中间件的根底上实现分布式事务能力；另一种计划则是以 Google Spanner 为代表的 NewSQL，此外还包含 OceanBase、TiDB、CockroachDB、YugaByte 等，其特点是底层基于 KV 引擎，下层利用 Raft、Paxos 共识协定保障日志和状态机的牢靠。

从 2010 年开始，云计算失去大规模倒退，数据库自身也面临着上云挑战。第一代数据库上云的问题是如何在云上部署数据库，第二代、第三代云原生数据库则会利用云上的组件，如 S3 等对象存储降低成本晋升可扩展性。云原生数据库中比拟有代表性的 TP 型数据库是 Aurora，AP 型数据库是 Snowflake，架构方面特色是存算拆散，计算节点、存储节点能够独立扩缩容，节俭用户老本，无需部署，运维简略，用户开箱即用。

大数据通过多年倒退，从纯正地用批处理解决问题变为能够用流解决做计算，对实时性要求高的场景反对得更好，与 AP 型数据库交融后大数据系统的剖析能力也能够失去晋升。

数据湖通常用于解决非结构化的数据，能够存储各类型数据，而数据仓库解决的是结构化的数据，两者的联合就是湖仓一体。湖仓一体比拟有代表性的开源零碎是 Hudi、Iceberg，非开源的有 Lakehouse。

由下面的倒退能够看到，交融是大数据系统近年来的发展趋势：TP 和 AP 的交融、湖和仓的交融等等。MarixOne 正是这样的超交融数据库，相似集成了相机、电话、电子书、闹钟等性能的智能手机，具备着应用多种数据库能力实现的能力，能极大地升高数据库运维老本。

▌Part 2 – MatrixOne 架构总览

图中是 MatrixOne 的架构图，自上而下共分为 5 局部。

首先最上层的是计算层，计算层的计算节点咱们称为 CN。计算节点自身能够做剖析、流计算和后台任务解决。用户层面和前台业务是感知不到计算节点的后盾解决工作的。

计算层上面的事务层次要节点是 DN，这些节点自身是 share nothing、可横向扩容的。每个 DN 之间和外部的数据分片是互不相交的。目前的计划是依据数据主键做数据的横向散布扩大。每个 DN 之间解决的数据范畴相互没有交加，不会有冲突检测的须要。

再上层是 Log service 和 File service。DN 节点写入的数据的日志会存在 Log Service 里。Log Service 外部应用 Multi-Raft，构建牢靠的存储状态机。异步的 compaction 工作把写入的日志合并后写入 File Service。File Service 是一个通用的接口，底层可对接本地磁盘、NFS、S3、HDFS 等多种数据存储系统。

HA Keeper 组件不是大数据里罕用的 Zookeeper，而是一个集中式的集群治理组件。目前的实现计划是用单 Raft 组实现。HA Keeper 保护的是计算集群、DN 集群、Log Service 集群的状态和可靠性。HA Keeper 发现集群内节点挂掉后会把节点拉起。

1. File Service

MatrixOne 对本身的预期是可反对云原生和私有化部署，无论云上还是私有化全副应用一套计划进行部署。在私有化环境下，用户的理论存储环境多种多样，用户可能抉择应用 HDFS、Ceph 等等做存储。云原生场景下也有多种抉择，S3 兼容的协定，阿里云 OSS 等。在此背景下咱们对存储进行了通用形象，这一服务即 File Service，作为存储接口提供给 DN 节点和 CN 节点进行数据交互。同时，File Service 自身也承当了数据缓存的工作。

2. Log Service

Log Service 是一个 Multi-Raft 组。因为存储的是 Log tail，数据量不大。但咱们对 Log Service 的吞吐量要求十分高。因而，在部署时候须要给 Log Service 配置更好的硬件设施，如硬盘须要用 SSD 盘。

3. Transaction DN

节点每个 DN 节点是 shared-nothing 的，每个 DN 节点之间相互拜访的数据是不重叠的。目前版本 DN 组件的数据划分应用对主键做哈希的形式实现，不应用 range 的形式实现，因为咱们认为哈希形式会让散布更加平均。DN 节点的横向扩容难度比 CN 节点的横向扩容大，传统的 NewSQL 扩容节点能够利用 Raft 组的个性、加减正本即可实现扩容；但 DN 节点近期几个 Release 版本临时没有打算 DN 的横向扩容，后续版本会减少扩容方面的优化。

4. 计算节点 CN

MatrixOne 是存算拆散的架构，计算节点 CN 节点的横向扩大能力很强，能够任意地扩缩容。CN 节点除了前台查问工作，还解决流工作和后台任务。后台任务包含异步的 Compaction 工作，自身会对数据进行批改，与前台工作数据会发生冲突，这些抵触须要被检测和解决。后台任务计划由 DN 节点发动。DN 节点保护状态机，状态机发现节点后发动异步工作给 CN 节点调起后台任务。这个过程不须要很高可靠性，异步后台任务并不需要很高的实时响应能力和幂等性。

5. HA Keeper

HA Keeper 保护了集群各节点的状态，和集群内各节点放弃心跳，节点挂到后把节点拉起；此外 HA Keeper 还和内部 K8S 资源池交互，把新增节点的上下文建设起来。HA Keeper 是一个单 Raft 组的牢靠集群，自身并发性不高，只能承载不高的心跳频率。

▌Part 3 – MatrixOne 事务相干的读写流程

1. 事务流程

Matrixone 应用的两阶段提交（2PC）实现事务和目前 NewSQL 计划略有区别。具体写入流程如下：

客户端应用 write 接口写入数据，申请达到 CN 节点后在 CN 节点上保留事务的读写空间 workspace。数据只有达到 DN 节点才开始冲突检测。

一个事务从 begin 到 commit 两头产生的数据交互都会存储在 CN 节点的 workspace 上，一旦客户端发动 commit，CN 节点会进行两阶段提交把数据推到 DN 节点。Workspace 数据可能散布在多个 DN 节点上，因而咱们设计了 DN 节点外部两个阶段的解决流程：第一阶段是 prepare，第二阶段 commit。

为了保障两个阶段自身的可靠性，咱们保障多个 DN 节点里选取一个作为 coordinator，在一些零碎中这个角色也被称作 transaction record。第一个 DN 节点咱们会做 transaction commit，并把所有 transaction 参与者都记录在 transaction coordinator 里。

产生事务时，首先要把 prepare log 写入 Log service 进行长久化，包含 transaction 的 commit 信息、DN 上的 prepare 信息等都做长久化存储。prepare 的事务信息会返回给 CN，CN 节点收到事务参与者的 response 即整个事务胜利，随后返回用户提交曾经胜利；或在 rollback 后再返回用户。

两阶段事务是一个异步的过程，DN 节点 commit 过程是与 prepare 后返回给用户提交曾经胜利是异步进行的。两阶段事务具一些特殊性：首先 workspace 存储在 CN 节点上，冲突检测在 DN 节点上进行；第二个特点是分布式事务应用 Clock SI 形式调配 timestamp。

2. 时钟

Clock SI 自身定义如上图红框圈中内容。任何一个事务会开启一个一致性快照，快照的开始工夫是由一个快照工夫戳确定的，在这个工夫戳以前，所有曾经 commit 的事务在这个快照里都可见。提交的工夫戳是全序的。如果产生并发写写抵触，事务会被勾销。

Clock SI 次要解决了没有核心节点状况下的工夫戳散发这一问题，也就是应用每个节点本人的工夫戳。但节点和节点之间存在始终时钟漂移的问题，时钟漂移会面临两个谬误谬误：

第一个谬误是快照不可用问题，左侧 Fig.1 展现了处在不同节点上的 P1、P2 两个事务参与者，他们之间存在时钟漂移，这会导致 P2 达到 t 之前快照不可用的问题。

第二个谬误是 Fig.2 展现的，T2 如果在 T1 提交时候读，拿到的数据须要等到 T1 提交实现后能力读到 T1 提交后的数据，不期待则读不到数据快照。

对于第二个谬误，Clock SI 应用上图中的算法 1 解决这两个问题。当 T.SnapshotTime 超过了以后提交工夫戳能力读到数据，否则进行期待；也就是以后如果有事务在做 prepare 和 commit，须要期待 prepare 和 commit 都实现后才能够进行冲突检测、做提交。

MatrixOne 把 Clocks SI 和 HLC 联合，HLC 是混合逻辑时钟，两个事务参与者产生时钟漂移时应用混合逻辑时钟校准，从而解决第一个谬误。

3. 读

对数据一致性要求较高的读申请，读申请到 CN 节点后须要从 DN 拉取数据的最新散布，DN 把最新的元数据和 meta 都返回给 CN 节点。CN 节点依据这些信息从 File Service 接口拉取到真正的数据。

MatrixOne 应用繁多的列存存储数据，每个 column 的 block 和 segment 的树形构造和 bloom filter、minmax index 等信息都保留在 meta、index zone 里，所有数据写入都是 append only 的，不管更新、插入还是删除都只是减少新文件。查问时用 Merge on read 的形式做合并。

DN 内保留最新的 meta，应用树形构造保留在 DN 内。查问的时候，CN 会问 DN 要以后须要的快照和 Log tail。CN 依据快照里记录的对 SQL 进行裁剪。比方做 SQL 查问时，可用 bloom filter 做 runtime filter。使得，真正须要读取进行计算的数据量比拟小。

此外，DN 节点会返回 Log tail 数据给 CN 节点，这部分日志数据绝对较小，因而问题不大。

对于 TP 类查问，CN 在拿到最新的数据后即可做一致性读。而 AP 类查问对数据一致性要求更低，能够应用 CN 内存储的 meta 读取，对 DN 负载压力较小，能够承载很高吞吐量。

4. 异步 compaction

咱们既能够用 CN 扫描数据决定是否做 compaction，也能够由 DN 节点判断是否进行 compaction。下图展现了应用 DN 做 compaction 的操作流程。

当 DN 节点发现数据删除过多，数据零散，这时会进行数据合并。数据合并时触发一个专用的用来做 compaction 节点跑合并，CN 节点会把要产生 compaction 的数据进行收集，在 CN 节点内合并后提交。

Compaction 会对数据产生产生批改，这个过程自身也是一个事务，会向 DN 提交数据并进行数据检测。

Compaction 过程中批改的数据，前台工作也有可能批改了这部分数据，此时可能产生写写抵触，产生写写抵触时会 abort 后盾 compaction。此时要重跑 compaction，独立的 CN 节点跑 compaction 工作也不会对用户体验造成影响。

5. Streaming 计划实现打算

目前由两种计划做 streaming，一种是数据产生批改，依据上一次产生的 snapshot 和以后的 snapshot 产生的 delta snapshot 推到 CN 节点上，CN 节点自身依据 streaming 工作生成 DAG 图，在 DAG 图上做增量计算。增量计算也会获得上一次查问后果，以此为根据做增量计算。

最终查问后果是上图中的 delta 查问后果和根底查问后果的组合。存储两头后果的局部用推的模式。

另一个形式是定期地、在用户做 streaming 查问时从 CN 节点拉取 base result、拉取 delta snapshot，再做增量查问。查问完结后把最新的 base result 存储到 S3、HDFS 等牢靠存储上，下次做增量计算时能够用到存储的 base result。

▌Part 4 – MatrixOne 研发路线图

刚刚公布的 MatrixOne 0.5 版本实现了列存带事务的剖析引擎，第三季度行将公布的 0.6 版 MatrixOne 将反对分布式事务,TPC- H 和 TPC- C 性能都有大幅晋升。

2022 年底打算公布的 0.7 版本将反对 streaming，也会反对更多高级 SQL、window function 等。0.7 版本 MatrixOne 打算上线云服务。

▌Part 5 – 精彩 Q &A 实录

Q1. 扩容是冷扩容还是热扩容？

A：咱们冀望实现热扩容。但会先反对冷扩容，冷扩容指的是在线的事务先 abort，执行扩容，扩容结束后再从新开启事务。整个过程速度很快，因为只扩容 DN 节点和对应的 Log tail 状态机。Log tail 存储的数据量少，扩容快。咱们打算实现热扩容，可能会以追日志的形式实现热扩容。

Q2. 元数据没有存 Zookeeper？

A：元数据存储在 HA Keeper。表构造咱们成为 Catalog。每个表数据索引的地位、数据的多个版本被认为是元数据，也叫做 meta。HA Keeper 自身存储以后集群是否挂掉，和每个 DN 分区负责的哈希桶。Catalog 表信息存储在牢靠存储 File Service 上，最新的牢靠元数据信息是存储在 Log Service 上。

Q3. CN 层和存储层是 Share Disk 架构吗，这样是否在扫描数据的时候影响性能？

A：File Service 存储数据，拜访数据也是 CN 节点通过 File Service 拉取数据，DN 节点解决数据只做事务的冲突检测。DN 节点冲突检测时拜访数据无限，会先过滤，不会全量拜访数据。且冲突检测通常只存在于一两个分片上。CN 在进行 Scan 时也会对谓词做下推，Join 时用 Key 决定拜访数据范畴，没有 where 条件的 select * from table 的申请对数据库性能影响很大。CN 节点对 Scan 类查问做谓词下推，最初 CN 节点真正要拜访的数据范畴无限，应用 zone map 过滤后确定局部数据。Join 时维度表绝对事实表更小，对性能影响不大；事实表通过维度表构建好 Hash Table，依据 hash key 建设 block、再下到事实表，用 bloom filter 过滤。最终拜访的数据块也很小，减小数据拜访的范畴。元数据、zone map、bloom filter 这类索引信息都会在 CN 节点上有缓存。

Q4. DN 外部的正本复制也用 raft 吗？

A: DN 在当初的计划内没有正本，象征重启一个 DN 时，须要从 log service 回放日志来复原 DN 的状态机，此时以后 DN 不可用。咱们能够把 DN 做成主备和三正本的模式，从 log service 拉取 log tail，当初应用的 DN 没有 stand by 节点。

Q5. Clock SI 里时钟计划相比 HLC 和 TSO 的劣势是？

A: TSO 有核心节点，HLC 每次拜访时尽管须要同步时钟，但同步能够产生在节点和节点之间。ClockSI 应用本地时钟，提早低，但节点之间可能存在时钟漂移问题。

Q6. 读取会不会随着 del 和 update 增多性能降落，会有异步的合并吗？

A: MatrixOne 是后台任务异步合并，而大量 delete 和 update 带来的垃圾数据多问题，会通过后盾合并工作 merge 掉这部分数据而失去解决。

Q7. 纯列存是指内存和磁盘都是列存吗？查问时会辨别 TP 类查问还是 ap 类查问吗？

A: 纯列存是磁盘和内存都是列存，查问时候会通过 optimizer 辨别是 AP 还是 TP。

Q8. 资源隔离有什么思考?

A: 首先是 TP 和 AP 之间的资源隔离，TP 和 AP 的 CN 节点离开。依据 AP 查问的一致性要求高下决定从 CN、DN 还是 File service 服务拉取元数据信息。其次是租户之间的资源隔离。目前的计划是 VIP 用户部署独自的一套 K8s deployment，普通用户依据 schema 进行资源隔离。后续可能会实现 cgroup 相似的形式限度租户隔离。

Q9. DN 有开源的原型吗?

A: MatrixOne 实现比拟偏差 NewSQL，DN 也是 share nothing 实现的。咱们参考过 duckdb，但 duckdb 的 update 和 delete 是用 version chain 形式实现的，0.6 版本后咱们不再应用这一计划。

Q10. 有思考过不基于相似 lsm 的思维做存储层，而是采纳 copy on write 或者相似 kudu 的 delta store 又或者 adb 采纳的 delta and insert 计划吗？

A: MatrixOne 当初的形式也是 LSM Tree 的模式。LSM 能够认为是分层的架构，以 RokcsDB 为例，它一共 7 层，最底层肯定是全序的。MatrixOne 为了防止写放大，没有全序的层，每层之间都有 overlap。Copy on write 的实现形式存在一些问题，实质上对原有的数据块进行了批改、用新数据块代替了原有数据块，对元数据的批改比较复杂。LSM Tree 是 append only 的，对元数据批改也是 append only 的，对于过来数据的 compaction 也是 append only 解决的。MatixOne 就是 delta insert 的实现，元数据管理复杂度大大降低。

Q11. 流解决和分布式事务处理的联合，是否思考过采纳相似 iceberg 的元数据管理的思维？

A: Iceberg 的元数据管理和咱们的治理形式没有太多区别，但 Iceberg 把元数据都存储在 S3 上，而 MatrixOne 有 DN 加 log service 做元数据缓存，性能更好。咱们认为流是一个常见的后盾常驻工作，工作随时依据数据源变动后推送或拉取新的数据执行分布式计算工作。分布式事务须要把流事务处理完能力返回胜利，整个链条很长，返回更慢，这里就是一个取舍：流解决保障一致性还是让整个流程更快完结。我这里认为流解决和一致性不须要做强一致性，事务写实现后来到用流解决引起读，此时能拿到最新的数据，解决完结后整个流程完结，把事务分为两步进行。

Q12. AP 相比支流的 OLAP 引擎，如 Clickhouse，性能如何？

A: 咱们冀望 MatrixOne 能和 Clickhouse 性能相媲美，但须要看具体场景具体分析。Clickhouse 是存储计算不拆散的，数据压缩、merge tree 全序排列等个性会让 Clickhouse 更快；但 MatrixOne 的存算拆散，非全序排列等个性也是 Clickhouse 无奈比拟的。Clickhouse 的 delete update 是不能立即可见的，但 Matrixone 是立即可见的，这就是全序排列和非全序排列的取舍。存储全序排列次要影响主键，非主键的零散数据对数据压缩影响不大，因而 AP 计算引擎比拟起来要具体场景具体分析，咱们会做继续优化。

Q13. 性能怎么同时兼容 AP 的大数据量和 TP 的高并发实时更新的？

A: AP 和 TP 是用不同计算引擎做的。AP 是的大数据量通常是查问的数据量大、不是写入的数据量大。为例反对 AP 的大查问量，数据写道 S3 上后最终提交时只由 CN 节点提交一次数据到 DN 上，DN 上加载数据做冲突检测。CN 上加载数据时曾经做过一部分冲突检测，在对从 S3 上加载来的数据和 logtail 之间做检测。这个实现能够反对大批量加载。TP 高并发和 AP 大读数据量能够兼容。如果不须要一致性读 AP 能够 CN 间接读 S3，不会影响 TP 性能；而须要一致性读的状况下，须要从 DN 读数据，DN 上是高并发的实时更新的数据，此时 DN 会成为瓶颈，须要扩容 DN 节点。DN 上拿到的是 logtail 和最新的元数据，CN 上已有的快照元数据和 DN 上最新的快照元数据的不同也是很小，能够按批取这些数据，能极大地利用网络传输吞吐。

Q14. AP 和 TP 底层是否有不同的存储构造？

A: 是一样的构造，都是存储成列存格局。

Q15. AP、TP 怎么调度？优化器针对 AP，TP，streaming 交融做了什么批改？

A: 优化器绑定时能够拿到元数据和索引，通过索引构建直方图，可能断定数据分布，判断数据量的大小。由此判断是 TP 还是 AP 查问，随后把申请转发到 AP 或 TP 专用的 CN 节点上进行解决。针对 Streaming 咱们目前还在布局中。

Q16. 在数据新鲜度上，HSTAP 采取了哪些措施？

A: 每次查问都到 DN 节点上读的形式肯定是数据最陈腐的形式，TP 数据只有写下去一致性读肯定能读到最新数据，AP 和 TP 应用一套列存，不存在数据同步等等提早问题。

Q17. 流解决如何保障最终一致性？

A: 一旦产生了更新，会把更新的 delta snapshot 推到流数据计算服务上，通过计算产生流处理结果；或是在查问段流数据查问间接查，查到的数据是具备一致性的。

Q18. 写流程中，第 3 步会客户端响应后，第 4 步写 commit log，这是否有问题？

A: 只有 prepare 全副实现，事务的提交曾经胜利，commit 只是批改 commit 的工夫戳。每一个事务参与者拿到事务工夫戳有前有后，最初 commit 的工夫戳须要是 prepare 的工夫戳中最大的。这时候异步写不会有问题。Transaction coordinator 记录了事务的参与者，一旦事务中途挂掉，重新启动后会读取 transaction coordinator 内的 log service 的数据，这部分数据是牢靠的。通过这个数据即可晓得事务参与者，并检这些参与者的事务是否提交，没提交的话就把整个事务 abort，提交了就不会有任何问题。

Q19. DN 上的元数据如何做到？有何优化解决

A: Table 到 column 下每个 segment 其实是一个元数据数，能够了解为元数据存储自身也是一个元数据数据库。目前咱们用 LSM tree 形式实现，内存里有状态机，写的具体内容是每一条元数据的状态机批改的日志。写完后内存的状态机会定期地刷到 S3 等牢靠存储上。这种实现能够比拟不便地做数据的 delta，CN 来的查问单位肯定是有事务形成的 snapshot，snapshot 是有每个事务的 commit 形成，每个 commit 也对应着一个数据元的批改。查问实际上是以 snapshot 或者 commit 为单位的，元数据批改所产生的 delta 能够拿到 CN 上做回放，CN 就能拿到最新元数据。

Q20. OB 和 MatrixOne 事务处理机制一样吗？

A: 大的流程都是 2PC，细节上区别不少。比方 OB 工夫戳应用 TSO，MatrixOne 应用的是 Clock SI 配合 HLC 形式实现。

MatrixOne 公司矩阵起源专一于构建超交融异构云原生数据库，为用户提供极简、高效的数据系统工具和服务，让数据利用和运维工作十分简洁的同时保障极值性能。帮忙用户和企业简略、麻利高效地拥抱数据价值，升高企业数字化转型门槛。

矩阵起源全面拥抱开源生态，以开源凋谢的形式摸索数字化路线。矩阵起源有多个行业的数字化转型最佳实际。欢送扫码退出 MatrixOne 社群参加探讨：

MO 社群 ：增加 MO 小助手微信 → ID：MatrixOrigin001，退出 MatrixOne 社群
官网 ：matrixorigin.cn
源码 ：github.com/matrixorigin/matrixone
Slack：matrixoneworkspace.slack.com
知乎 | CSDN | 墨天轮 | OSCHINA | InfoQ：MatrixOrigin