干货分享 | MatrixOne系统架构

分享嘉宾：金海  矩阵起源研发VP

讲稿整理：张德通DataFun志愿者

导读

本文字数：7400字+

阅读时间：20分钟+

我们期望实现热扩容。但会先支持冷扩容，冷扩容指的是在线的事务先abort，执行扩容，扩容完毕后再重新开启事务。整个过程速度很快，因为只扩容DN节点和对应的Log tail状态机。Log tail存储的数据量少，扩容快。我们计划实现热扩容，可能会以追日志的方式实现热扩容。

元数据存储在HA Keeper。表结构我们成为Catalog。每个表数据索引的位置、数据的多个版本被认为是元数据，也叫做meta。HA Keeper本身存储当前集群是否挂掉，和每个DN分区负责的哈希桶。Catalog表信息存储在可靠存储File Service上，最新的可靠元数据信息是存储在Log Service上。

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节点上有缓存。

DN 在现在的方案内没有副本，意味重启一个 DN 时，需要从 log service 回放日志来恢复 DN 的状态机，此时当前 DN 不可用。我们可以把DN做成主备和三副本的形式，从log service拉取log tail，现在使用的DN没有stand by节点。

TSO有中心节点，HLC每次访问时虽然需要同步时钟，但同步可以发生在节点和节点之间。ClockSI使用本地时钟，延迟低，但节点之间可能存在时钟漂移问题。

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

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

纯列存是磁盘和内存都是列存，查询时候会通过optimizer区分是AP还是TP。

首先是TP和AP之间的资源隔离，TP和AP的CN节点分开。根据AP查询的一致性要求高低决定从CN、DN还是File service服务拉取元数据信息。

其次是租户之间的资源隔离。目前的方案是VIP用户部署单独的一套K8s deployment，普通用户根据schema进行资源隔离。后续可能会实现cgroup类似的方式限制租户隔离。

MatrixOne实现比较偏向NewSQL，DN也是share nothing实现的。我们参考过duckdb，但duckdb的update 和 delete是用version chain方式实现的，0.6版本后我们不再使用这一方案。

MatrixOne现在的方式也是LSM Tree的模式。LSM可以认为是分层的架构，以RokcsDB为例，它一共7层，最底层一定是全序的。MatrixOne为了避免写放大，没有全序的层，每层之间都有overlap。

Copy on write的实现方式存在一些问题，本质上对原有的数据块进行了修改、用新数据块替代了原有数据块，对元数据的修改比较复杂。LSM Tree是append only的，对元数据修改也是append only的，对于过去数据的compaction也是append only解决的。

MatixOne就是delta insert的实现，元数据管理复杂度大大降低。

Iceberg的元数据管理和我们的管理方式没有太多区别，但Iceberg把元数据都存储在S3上，而MatrixOne有DN加log service做元数据缓存，性能更好。

我们认为流是一个常见的后台常驻任务，任务随时根据数据源变化后推送或拉取新的数据执行分布式计算任务。分布式事务需要把流事务处理完才能返回成功，整个链条很长，返回更慢，这里就是一个取舍：流处理保证一致性还是让整个流程更快结束。我这里认为流处理和一致性不需要做强一致性，事务写完成后离开用流处理引起读，此时能拿到最新的数据，处理结束后整个流程结束，把事务分为两步进行。

我们期望MatrixOne能和Clickhouse性能相媲美，但需要看具体场景具体分析。Clickhouse是存储计算不分离的，数据压缩、merge tree全序排列等特性会让Clickhouse更快；但MatrixOne的存算分离，非全序排列等特性也是Clickhouse无法比较的。Clickhouse的delete update是不能立刻可见的，但Matrixone是立刻可见的，这就是全序排列和非全序排列的取舍。存储全序排列主要影响主键，非主键的零散数据对数据压缩影响不大，因此AP计算引擎比较起来要具体场景具体分析，我们会做持续优化。

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上最新的快照元数据的不同也是很小，可以按批取这些数据，能极大地利用网络传输吞吐。

是一样的结构，都是存储成列存格式。

优化器绑定时可以拿到元数据和索引，通过索引构建直方图，能够判定数据分布，判断数据量的大小。 由此判别是TP还是AP查询，随后把请求转发到AP或TP专用的CN节点上进行处理。

针对Streaming我们目前还在规划中。

每次查询都到DN节点上读的方式一定是数据最新鲜的方式，TP数据只要写下去一致性读一定能读到最新数据，AP和TP使用一套列存，不存在数据同步等等延迟问题。

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

只要prepare全部完成，事务的提交已经成功，commit只是修改commit的时间戳。每一个事务参与者拿到事务时间戳有前有后，最后commit的时间戳需要是prepare的时间戳中最大的。这时候异步写不会有问题。

Transaction coordinator记录了事务的参与者，一旦事务中途挂掉，重新启动后会读取transaction coordinator内的log service的数据，这部分数据是可靠的。通过这个数据即可知道事务参与者，并检这些参与者的事务是否提交，没提交的话就把整个事务abort，提交了就不会有任何问题。

Table到column下每个segment其实是一个元数据数，可以理解为元数据存储本身也是一个元数据数据库。目前我们用LSM tree方式实现，内存里有状态机，写的具体内容是每一条元数据的状态机修改的日志。写完后内存的状态机会定期地刷到S3等可靠存储上。

这种实现可以比较方便地做数据的delta，CN来的查询单位一定是有事务构成的snapshot，snapshot是有每个事务的commit构成，每个commit也对应着一个数据元的修改。查询实际上是以snapshot或者commit为单位的，元数据修改所产生的delta可以拿到CN上做回放，CN就能拿到最新元数据。

大的流程都是2PC，细节上区别不少。比如OB时间戳使用TSO，MatrixOne使用的是Clock SI配合HLC方式实现。