分享嘉宾：金海 矩阵起源研发VP
讲稿整顿：张德通 DataFun志愿者
导读：
随着数字化转型的深刻，数据价值也愈发凸显，数据技术呈现了交融的趋势，基于客户的实在痛点，矩阵起源推出了超交融MatrixOne HSTAP数据库。MatrixOne使数据数据库同时具备 TP、AP和Streaming三种能力，帮忙客户彻底突破数据孤岛问题，成为企业智能化外围的数据基础设施。
明天的分享将解析新一代超交融异构云原生数据库 MatrixOne刚刚公布的0.5版本和后续版本的架构设计。介绍会围绕上面五点开展：
- 数据存储与解决面临的挑战
- MatrixOne架构，各组件和设计方面的取舍
- MatrixOne事务相干的读写流程
- 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