1. MatrixOne 从NewSQL到全新的HTAP分布式 架构演进 张潇

2.

3. 自我介绍 • 2011-2021,10年全职DBA，金融、教育、商业地产行业 • 2021-至今，矩阵起源，担任产品架构师 • 熟悉Oracle/SQL Server/MySQL等主流关系型数据库

4. 目录 • MatrixOne的早期架构与难题 • MatrixOne的升级之路 • 架构升级的困难与收获 • 公司与产品介绍 • 总结

5. MatrixOne 早期的架构与难题

6. MatrixOne的早期架构 NewSQL+MPP NewSQL 提供了从数据标注、模型部署、模型仓库等功 • 分布式架构：多节点的分布式数据库服务 能。且为了使得部署后的模型可以更方便地给 器，解决了传统单机数据库伸缩性和高可 应用调用，支持将算法服务发布成API；也为了 用问题。 使得部署后的模型可以更容易地被调度，支持 • 多引擎：数据库服务器中可能存在多个存 储引擎，不同的引擎负责不同的场景。 将算法服务发布成AI组件，被AI工作室的调度 MP • 引擎进行调度。 并行计算：将任务并行地分散到多个服务 器和节点上，在每个节点上计算完成后， 将各自部分的结果汇总在一起得到最终的 结果。

7. MatrixOne的早期架构 SQL组件 SQL Fronten • 提供MySQL兼容协议 • 兼容MySQL的语法 计算层Query Parse • 解析SQL并转化抽象语法树 • 提供支持多种SQL方言基础 MPP SQL Executio • 针对SQL计算引擎的一些基 础操作的向量化加速 • 部分操作采用了汇编改写做 加速 • 独有的因子化加速能力

8. MatrixOne的早期架构 分布式框架 MatrixCub • 现多台机器的分布式数据存 储的分布式框架 • 提供高可用、多副本、强一 致与自动负载均衡 • 提供分布式事务的支持能力 （WIP） • 提供基于Raft的副本调度机 制，该调度器在代码中称为 Prophet

9. MatrixOne的早期架构 存储层 AOE引擎 • Append Only Engine，这 是一个Append Only的列存 引擎，不支持事务 TPE引擎 • Transaction Processing Engine，用于保存元数据 Catalo TAE引擎 • Transactional Analytical Engine，基于列存的HTAP 引擎，会提供完整ACID能 力及强大的OLAP能力

10. 原有架构的三大难题 成本 性能 扩展性 • Raft协议所包含的leader⻆色，容易 • share nothing架构，每扩展1单 位节点，需同时扩展存算资源 • 每份数据至少要保存3副本，从扩 展节点到完成，时间更久 • 不断攀升，云上版本更甚 造成热点 • 在性能较差的存储下，数据库整体性 能下降会超过预期 • 多种引擎各自用途不同，性能各异， 无法有效应对HTAP场景 数据保存3副本，随节点规模，成本 • 只有高配存储才能发挥数据库的预期 性能

11. MatrixOne 架构升级之路

12. 原架构的三座大山 分布式框架 引擎众多 • 多副本存储—>存储成本飙升 • 多存储引擎—>开发维护成本 • Leader选举—>制造热点 • 因子化算法—>过于激进 资源分配 • 存算不分—>HTAP隔离性差 • share nothing—>扩展性差

13. 架构升级——灵活解耦的整体架构 Compute Layer Execution Service Streaming Service Transaction Layer Transaction Service Log Service Storage Layer S3/NFS/HDFS Cache Service

14. 架构升级——融合存储引擎TAE 一个引擎，承担所有负载 多引擎相互协同 • 列式编码压缩，采用Column Family灵活在行 • AOE，不支持事务与去重，AP性能较好 • TPE，保存catalog中的元数据信息 • TAE，基于列存的HTAP引擎，会提供完整 • 可同时运行TP和AP负载 ACID能力及强大的OLAP能力 • 所有Table均支持SI事务隔离级别 • 支持主键、唯一键排序 存和列存之间切换 冷热&读写分离，精细化管理 多副本与分片 • 每份数据至少保存3副本 • 冷数据保存S3(私有化部署提供S3兼容存储 • 数据以分片（shard）的形式保存 • 热数据作为Cache保存在计算节点 • 利用操作系统自带的Cache • 所有节点无状态，可以任意隔离负载 • 并发访问能力可以通过任意启动计算节点线性 提升

15. 架构升级——高性能计算引擎 多引擎下的匹配计算 • 因子化算法构建执行计划，对复杂查询做 加速，提高AP场景的性能 • 表达式与节点的抽象与表述较为复杂，增 加修改功能难度较高 • 多个引擎之间代码复用度较低 MPP执行引擎 • 基于DAG构建执行计划，自适应 节点内和节点间调度 • 同时满足并发和并行执行 • 完善SQL能力：支持子查询、窗 口函数、CTE、Spill内存溢出处 理等 • 未来的优化空间更大

16. 架构详解：灵活解耦的整体架构设计 计算层和事务处理Serverless化 极致弹性，可以任意重启 Compute Node CN CN CN CN CN Cache Cache Cache Cache Cache 共享日志层基于复制状态机 高可靠，确保弹性强一致 DN Shard2 DN Shard1 事务处理 提供了从数据标注、模型部署、模型仓库等功能。且为了使得部署后的模型可以更方便地给应用调 与元数据 用，支持将算法服务发布成API；也为了使得部署后的模型可以更容易地被调度，支持将算法服务发 布成AI组件，被AI工作室的调度引擎进行调度。 共享日志层仅保存Tail日志 共享日志 LOG LOG LOG LOG LOG LOG 高性价比，降低多副本存储开销 全量数据保存在S3廉价存储 无限伸缩，最大化降低存储成本 File Service S3 S3 S3 S3 S3

17. 架构详解：融合存储引擎TAE (1) Database Compute Node CN CN CN Cache Cache Cache Table Segment Segment Segment … LOG S3 LOG S3 LOG 提供了从数据标注、模型部署、模型仓库等功能。且为了使得部署后的模型可以更方便地给应用调用，支持将算法服 务发布成API；也为了使得部署后的模型可以更容易地被调度，支持将算法服务发布成AI组件，被AI工作室的调度引擎 进行调度。 Column Block Column Block Column Block Column Block Column Block Column Block Column Block Column Block Column Block S3 Sorted AP Column Scan Primary Key Index TP Point Queries File Service Table … DN Shard1 事务处理 与元数据 共享日志 Database …

18. 架构详解：融合存储引擎TAE (2) 一份存储，承担所有负载 • 列式编码压缩，采用Column Family灵活在行 CN CN CN Cache Cache Cache 存和列存之间切换 • 可同时运行TPCC和TPCH负载 • 所有Table均支持SI事务隔离级别 • 支持主键、唯一键排序 Create TP optimized Table (Column Family ={column1,column2,column3}) 冷热&读写分离，精细化管理 • 冷数据保存S3(私有化部署提供S3兼容存储 Create AP optimized Table Default 提供了从数据标注、模型部署、模型仓库等功能。且为了使得部署后的模型可以更方便地给应 Column1 Column2 Column3 Column1 Column2 Column3 用调用，支持将算法服务发布成API；也为了使得部署后的模型可以更容易地被调度，支持将算 法服务发布成AI组件，被AI工作室的调度引擎进行调度。 Store seperatedly Store together(Heap file) • 热数据作为Cache保存在计算节点 • 计算节点无状态，可以任意隔离负载 • 并发访问能力可以通过任意启动计算节点线性 提升 S3 S3 S3

19. 架构详解：高性能计算引擎 MPP执行引擎 CN • MySQL兼容 • 一套融合型计算引擎，可以同时 执行TPCH和TPC • 基于DAG构建执行计划，自适应 节点内和节点间调度 MySQL Parser CN Planner/Optimizer MySQL Parser 口函数、CTE、Spill内存溢出处 理等 MySQL Parser 提供了从数据标注、模型部署、模型仓库等功能。且为了使得部署后的模型可以更方便地给应用调用，支持将算法服 务发布成API；也为了使得部署后的模型可以更容易地被调度，支持将算法服务发布成AI组件，被AI工作室的调度引擎 Pipeline 进行调度。 Planner/Optimizer Planner/Optimizer • 同时满足并发和并行执行 • 完善SQL能力：支持子查询、窗 CN Cache Pipeline Pipeline Cache Cache

20. MatrixOne 架构升级的困难与收获

21. 寻找更高性价比的数据存储 一份存储减少数据冗余 • 单存储引擎，同时支持TP和AP类 工作负载。 • 列式编码压缩，采用Column 更少 冗余 更低 成本 冷热分离更低存储成本 • 冷数据保存在S3廉价存储，最大化 降低存储成本 (私有化提供S3兼容存 储)。 Family灵活在行存和列存之间切 • 热数据作为Cache保存在计算节点 换，灵活保证点查询与批查询的 • 所有节点无状态，可以任意隔离工 性能。 • Zonemap，BloomFilter等多种过 滤索引，有效提升查询效率。 作负载。

22. 事务层的分工与Logtail CN计算&DN事务 引入Logtail CN直接写存储 • CN只负责做计算 • 在日志中保存部分数据logtai • 批量的插入更新删除直接写存储 • DN负责数据的缓存与写入 • logtail定期写入存储中 • 未超过阈值的小事务由DN写存储 • CN负责所有计算与事务逻辑 • DN只保留最近一段时间的数据 DN成为瓶颈 写入无上限 写入更快速

23. 如何实现HTAP的工作负载隔离 容器级别隔离 机器资源有限，在有效隔 OLTP类工作负载 OLAP类工作负载 离的基础上提升性价比 • 计算节点无状态，可以承担任意负载 • 容器之间的负载与数据实现完全隔离 Compute Node Compute Node Compute Node Transaction Node 提供了从数据标注、模型部署、模型仓库等功能。且为了使得部署后的模型可以更方便地给应用调用， 支持将算法服务发布成API；也为了使得部署后的模型可以更容易地被调度，支持将算法服务发布成AI 机器级别隔离 机器资源充裕，实现TP和AP 负载的完全隔离与独立 组件，被AI工作室的调度引擎进行调度。 Log Service • 各组件可独立机器部署，实现不同工作负载的 完全隔离 • 数据新鲜度可配置，按需保障TP和AP互不影响 S3 S3 S3

24. 如何实现资源配比的灵活调整与扩展 灵活调整不同工作负载资源 查询 • 若AP分析需求增大，则可增加Compute CN(AP) Node节点的机器资源配比 • 若TP写入需求增大，则可调整Compute CN(TP) Node、Transaction Node节点的机器资源配 比 自动调整不同工作负载资源 CN(AP) CN(AP) LOG 提供了从数据标注、模型部署、模型仓库等功能。且为了使得部署后的模型可以更方便地给应用调用， 支持将算法服务发布成API；也为了使得部署后的模型可以更容易地被调度，支持将算法服务发布成AI 动态调整 组件，被AI工作室的调度引擎进行调度。 • 根据系统负载情况，自动调整Compute Node节 点内部的计算资源分配 CN(TP) • 根据系统负载情况，自动扩容增加Transaction Node提升集群事务写入能力 • 根据租户负载情况，自动将不同租户写入负载 合并处理，降低集群成本 查询 CN(TP)

25. 架构升级中的难题与收获 理解SQL的执行 通过重构Plan，对于SQL语法的解析、执行计划以及SQL标准语法都有了更多认识 计算层 事务与ACID 专注于单一引擎之后，几乎每一条SQL都要考虑事务与ACID，需要对这些有更深的理 解 inf ras tru c tur e 事务层 CN与DN的适配 从架构升级开始，CN与DN的分工与适配成为了巨大难题，反复验证中得到了最优解 Logtail Logtail的引入，实现了某一部分数据在不同CN之间共享 使用S3存储 存储层 积累了基于S3等对象存储的引擎开发经验，原来对象存储也可以很好地适配数据库 Fileservice 一种存储服务，去实现不同节点不同底层存储类型的读写，是个极大的挑战

26. 公司与产品介绍

27. 物理世界的数字化和智能化无处不在。矩阵起源 （Matrix Origin）致力于建设开放的技术开源社区和 使命 为数字世界提供简捷强大的数据操作系统。 生态系统、打造世界级的团队、并通过业界领先的 技术创新和工程能力，实现数据在数字世界中的任 意存储和任意计算，帮助用户释放数据的潜力和创 新力（Store Anywhere, Compute Anywhere, 愿景 Innovate Anywhere）。 致力于成为行业领先的数据基础软件公司，帮助所 有企业和用户简单、敏捷、高效地拥抱数据价值。 矩阵起源公司成立于2021年，在上海、深圳、北 京、硅谷等城市设有分支机构。团队成员由各领域 专家组成，在分布式基础架构、数据库、大数据及 人工智能领域经验丰富。

28. 数字化加速进程下，数据孤岛问题日益严重 业务变化带来的系统孤岛 资源限制带来的位置孤岛 技术变化带来的时间孤岛 数字化转型的最高目标 BI 从信息化到智能化 ML 智能化的必要前提 公有云2 1PB数据量 公有云1 Dashboards ICD机房 ICD机房2 3 打破数据Silo 1T数据量 ERP Greenplum ICD机房1 App1 Edge Box1 App2 MES 如何才能以最优性价比感知/采集/存储/ 利用不同系统和不同位置的数据？ Hive CRM Edge Box2 1G数据量 MySQL

29. 数据孤岛导致运维、开发和维护愈发困难 数据引擎繁多， 选型、开发、运维成本暴涨 MySQL * 200 MongoDB * 100 Redis * 60 Hadoop * 20 开发损耗大 • 开发体量大：每家中型公司平均数据引擎建设 提供了从数据标注、模型部署、模型仓库等功 现有数据平台&数据库的建设数量 • 我需要几种数据库？ 数量超过5个。 能。且为了使得部署后的模型可以更方便地给 • 开发复杂度高：每个都有自己的API接口、语 应用调用，支持将算法服务发布成API；也为了 一个传统企业服务应用厂商的成本困扰 言和事务模型等。 使得部署后的模型可以更容易地被调度，支持 将算法服务发布成AI组件，被AI工作室的调度 运维成本高 引擎进行调度。 • 运维体量大：每一个数据引擎平均依赖5+个 DB成本 • 装、监控、补丁和升级，每一个数据存储都 需要实现高可用和可恢复。 • 为什么建设和使用数据库的成 60个客户 200个MySQL节点 运维成本高：每一个数据引擎都要各自安 20个客户 100个MongoDB节点 5个客户 40个MySQL节点 60个Redis节点 5个MySQL节点 10个MongoDB节点 20个Hadoop节点 0个DBA人力 1个DBA人力 3个DBA人力 2018 2020 • 如何规划我的数据基础架构？ • 我需要招聘多少个DBA？ 数据平台建设成本的加速上涨 基础组件，存储3+个数据副本。 • 我如何选择最合适的数据库？ 2022 本比收益增⻓快10倍？

30. 数据孤岛导致业务创新严重受限、需求响应缓慢 数据碎片严重， 研发敏捷度和数据新鲜度无法保障 从4个数据库 提取数据 2个数据 工程师 6个 ETL Job 2周的指标生产、开发 和数据校验周期 持续的数据一致性维护 和排查投入 研发效率无法提升 提供了从数据标注、模型部署、模型仓库等功 • 数据加工链路⻓：多条数据管道多份数据 一个品类小时级别售卖报表的需求响应 能。且为了使得部署后的模型可以更方便地给 存储冗余，需要投入大量时间在数据对比 应用调用，支持将算法服务发布成API；也为了 和校验上。 使得部署后的模型可以更容易地被调度，支持 • 问题排查复杂：上下游数据不一致问题频 发，问题定位和诊断复杂。 将算法服务发布成AI组件，被AI工作室的调度 引擎进行调度。 数据无法实时更新 • 数据新鲜度无法提升：增量数据定时任务 同步，数据新鲜度一般到小时级。 • 更新频次不足以支撑业务：无法满足营销 ⻛控、无人驾驶、等实时计算要求高的应 用场景。 一个零售企业数据研发部⻔的效能困扰 • 如何提升数据应用需求的响应 速度，提升研发的敏捷度？ • 如何构建更加实时的数据平台 和分析能力，找到新的创新业 新增一个更加实时的收益报表需求 重新做数据提取 重新做数据报表开发 和数据一致性校验 再次构建新的 中间表 数据实时性无 法进一步提升 持续的数据一致性维护 和排查投入 务模式？

31. 数据孤岛导致IT预算无序增⻓、业务部⻔满意度持续下降 性能隔离和资源利用率无法兼得， 基础设施硬件规模被迫无序增⻓ 硬件资源预算持续上涨 • 硬件负载难调整：TP类应用和AP类应用的 提供了从数据标注、模型部署、模型仓库等功 ERP/CRM等 TP工作负载 峰值硬件需求 时间 发展 BI/Report等 AP工作负载 峰值硬件需求 TP Workload峰值= 200节点, AP Workload峰值 = 200节点，今年IT预算需要采购多少硬件资源？ • 选项A: 200 TP数据库+ 200 AP数据库= 400。 Q1 80节点 50节点 Q2 50节点 150节点 Q3 200节点 100节点 资源利用率最高，但TP/AP工作负载性能可能 Q4 100节点 200节点 互相影响。 最好的性能隔离，但成本高、浪费严重。 • 选项B: Max (TP+AP)=300 HTAP Database。 应用类型负载的波动变化，在 业务发展下数据库建设的硬件预算方案 硬件资源独立维护，无法灵活调整配比。 能。且为了使得部署后的模型可以更方便地给 不影响应用性能的基础上灵活 • 资源利用率难提升：为了确保性能隔离， 应用调用，支持将算法服务发布成API；也为了 使用IT预算？ 将算法服务发布成AI组件，被AI工作室的调度 基础设施割裂维护愈发复杂 • 如何以统一数据架构应对未来 业务发展下多个公有云、私有化的集群维护交错 引擎进行调度。 无法跨云打通：私有化数据集群和公有云 公有云&私有云集群的不断蔓 数据集群之间数据架构和建设方案割裂， 数据迁移成本高。 据库厂商，后续的集群扩容、新组件采购 业务系统 企业上 ERP/CRM 云 IT支持系 统 云厂商 A 部分应用 扩容需求 云数据库/ 数据仓库 选型 分析需求 群规模扩容 发展 既有云厂商的其他 云厂商 云数据库产品采购 绑定 多个数据组件的碎 片化和ETL流转 等都将被既有厂商绑定。 延？ 既有云数据库的集 单一厂商绑定：数据上云一旦选型确定数 • 调整硬件资源配比，高效合理 一个智能制造厂商IT部⻔的发展困扰 需要规划并浪费巨大资源。 使得部署后的模型可以更容易地被调度，支持 • • 如何应对业务发展过程中不同

32. 打破数据Silo，行业十几年不断探索 方案一 数据中台 现有DBMS的扩展 ✓ 整合和集成多个现有成熟数据管 ✓ 以一个DBMS为核心，增加其他 理系统，对用户提供统一的管理 方面的能力，多个系统共用一套 平台 DBM × 缺点： 架构复杂难维护，数据质 方案二 × 缺点： 架构陈旧、负担重转向 量难以保证，运维和开发成本极 难，仅能减少部分数据孤岛，价 高 值有限 方案三 更加融合统一的 新型数据库 ?

33. 深度融合统一，也已成为主流数据库的演进新方向 湖仓一体 分布式云原生 能力融合 流批一体 HTAP 云边协同 边缘异构 云边数据融合

34. MatrixOne Beta Program 用户体验计划 MatrixOne Beta Program 是矩阵起源全新推出的，与客户、用户一起持续提升 MatrixOne 产品和性能体验优化的计划。 新功能内测权益 产品设计参与权益 FEB MAR 开发过程的直接发言权益 新功能本地环境优先测试权益 APR MAY JUN 专家端到端专业支持权益 JUL 三步推荐好友加入 MOE v0.7 MOC Alpha MOE v0.8（Private Beta） MatrixOn MOE v0.9（Public Beta） 产品路线 Beta Program Beta Program 发 布 • Step1: 扫描下方小程序码提交注册 • Step2: MO架构师将会通过邮件的方 式进行初步联系和沟通 Public Beta（公开招 募） Private Beta（仅邀 请） MO GA • Step3: 加入 Beta Program 社区， 开始您和 MatrixOne 的旅程 线上研讨会 2023年活动 线下客户交流沙⻰ 线下客户交流沙⻰ 计划 产品发布会 行业合作伙伴沙⻰ 线下客户交流沙⻰ 行业合作伙伴沙⻰

35. 总结 MatrixOne架构升级的关键点 • 从存算一体到计算、事务、存储三层解耦 • 从多引擎到单一TAE的HTAP融合引擎 • 从因子化算法到DAG的计划构建 • 从多副本存储到对象存储与Logtail的引入 • 灵活调整节点分配带来的资源隔离 扫码关注矩阵起源服务号 回复0318，获取PP Contributing Welcomed !!! https://github.com/matrixorigin/matrixone

36.