活动回顾 | MatrixOne 在 SaaS 企服领域的应用解读

1.  业务分析一体化场景 ，举个例子，像ERP相关的软件，在发展到一定程度后通常需要结合报表系统或增强报表功能。以前的做法是使用两个数据库来支持，一个用于事务处理（TP数据库），一个用于分析处理（AP数据库），而现在只需使用MatrixOne即可解决这个问题。

2.  时序处理场景，该类场景简单来说，特点就是大量的高并发写入以及实时查询，常见于IoT系统，互联网运维监控/安全类系统，网络情报和爬虫类系统，这些场景都需要大量高频数据的写入和快速的分析，而这正是MatrixOne擅长的领域。

3.  SaaS 应用，下文将会详细地分析 MatrixOne 解决SaaS 应用中的问题。

4.  实时数据仓库，实时数据仓库是OLAP数据库擅长的领域之一。MatrixOne在这个领域中提供了对事务、删除和更新以及高并发的支持，相比传统的OLAP引擎，具有更完整的能力。

5.  轻量级的数据中台，与传统的Hadoop方案对应。有很多传统的小型大数据系统，通常由十几个到二十几个节点的CDH构成，大多数已建立于5-8年前。从现在的视角来看，这些基于Hadoop架构的大数据系统的维护成本和数据处理能力已逐渐落后。如今，在美国几乎没有人再使用Hadoop来处理大数据，而大多数都转向了云原生化的数据平台。

6.  数据智能化应用，近期的热点话题，即基于大模型的数据应用。在这类的数据处理方面，我们也提供了一些解决方案。

首先，来看一下SaaS市场的情况，参考了最新的36氪分析的中美SaaS市场对比报告。报告显示，近几年整个SaaS行业增速非常快，但就渗透率而言，中国的SaaS市场与美国相比仍存在一定差距。

在技术层面上，国内企业与全球化的SaaS企业之间存在一些差距。例如，在数据处理方面，国内许多行业垂直类的SaaS（如制造、能源、交通等实体行业）面临着巨大的数据压力，但目前的处理方案并不能很好地解决它们的问题，只能勉强应对。这实际上也是整个SaaS市场普遍存在的情况。

再来看一下目前非常典型的一个SaaS产品相关的架构。首先，从开发的层面上讲，SaaS软件通常需要每1-2周发布一个版本。因此，现在基本上有非常完善的 CICD 流水线，通过容器化的镜像服务来进行业务部署和应用开发环境。

另外则是支撑整个SaaS运行的技术架构。在前端方面，通常会有CDN、API网关、防火墙等组件。在整个应用层中，目前，大多数都采用了微服务化的方式，利用微服务框架（如Spring Cloud）和Kubernetes进行应用编排和调度管理。接下来是数据层，而这里就涉及到大量数据库组件的应用。首先，为了支持业务应用，通常需要使用MySQL或其他OLTP类数据库。此外，整个SaaS应用还需要专门的系统来管理日志、运维监控、性能分析、统计和计费等。这些系统可能会涉及到Prometheus监控、Elasticsearch日志处理和ClickHouse等OLAP数据库进行报表分析。最后，在SaaS应用中，各种系统模块的数据通常需要汇聚到所谓的数据中台中。目前，构建数据中台的主流方法仍然是传统的Hadoop体系中的组件，包括Hive、Spark和Flink等。另外，从今年开始，市场上出现了许多结合了人工智能的大模型应用，这可能还需要增加向量数据库。

在整个架构中与数据相关的部分占据了很大的比重。实际上，对于任何一家公司来说，处理这样的架构并不是一件容易的事情。在传统的软件开发模式中，通常需要建立一个规模很大的系统才能实现这样的架构。然而，对于SaaS来说，由于其在公网上提供服务，所以更容易在早期阶段就遇到数据压力的瓶颈。

这里有几个常见问题：

第一个问题是关于SaaS面临的挑战，即如何在数据层面实现多租户的隔离。通常来说，有两种核心选择方式：每个租户独占数据库实例，或多租户共享数据库实例，或介于两者之间。

第一种选择是每个租户都有一个专门的数据库实例。例如，如果有100个客户，就需要为每个租户分配一个单独的数据库实例。这种方式确保了很好的隔离性。但问题是，管理这100个数据库实例并不简单。对于每个实例的资源分配、性能监控和维护都需要投入大量的人力和成本。而且，随着租户数量的增加，这个工作会变得越来越困难。

另一种主流的选择是多个租户共享同一个数据库实例。在这种情况下，一个实例可以服务多个租户，通过tenantID将数据区分开。这种方式的管理成本较低，因为只需要一个实例。但是，它也存在一个很大的问题，即负载不均衡。由于租户的负载并不相等，当某个租户执行一个大型查询时，其他租户的查询性能可能会受到影响。因此，在隔离性方面存在一定的问题。

目前，许多用户都采用了一些中间方案，即一部分用户使用独立实例，一部分用户使用共享实例。然而，实质上它并没有根本解决这个问题。

第二个问题是可扩展性。事实上，几乎所有的SaaS公司都可以被视为相对较新的公司，它们的生命周期通常没有超过10年。这是因为云计算的发展时间有限，SaaS行业必然会面临各种问题——从初创阶段到成熟阶段，公司将遇到许多不同的挑战。

从ARR角度来看，一家初创公司一年可能只有数十万元的收入，团队也可能非常小，它可能会逐步成长到年入数十亿的规模，这可能已经是中国SaaS市场的顶峰了。

而在不同的发展阶段来说，数据规模和处理需求将有很大的差异。例如，在最初的SaaS场景中，可能只是一个单体应用程序，只有不到10个客户，因此只需使用一个MySQL主备数据库即可解决问题。

但当公司的规模达到10-100GB，并且客户数量达到10-100个时，情况就不同了。此时可能需要多个应用程序来满足客户需求，因此可能需要多个MySQL主备实例，并且需要进行分库分表。因为数据量已经增加，单个表无法满足要求，必须进行业务拆分以解决这个问题。

再往上发展到更大的，100-500个客户，这个阶段的客户，可以说中国的SaaS绝大多数还是集中在这个阶段，年收入在千万到亿元之间的一个阶段，相对成熟的一个SaaS公司。他们基本上现在业务已经微服务化改造，它现在基本上都要整个数据或者整个系统就要云原生化，云原生化现在第一步就是要买RDS，要把数据从以前自己在虚拟机里装的MySQL，换成一个RDS。相对来说有一定的扩展性，同时也还要做一些分库分表的操作。同时要开始会有一些日志监控甚至像计费相关的一些系统，这里面可能需要一套ES来去专门做这种管理。

再往后就是更大型，处于成熟阶段，拥有十亿以上的收入，实际上它需要增加很多的系统，包括计费、分析、报表一些大数据相关的系统，它的数据栈会变的非常复杂，类似于前面那一套非常完整的架构。ES加一个clickhouse，加一个Hadoop，加一个Spark，加一个Flink，管理难度是相当大的。那能不能有一套东西，从刚刚初创到最后解决这样一些数据架构上面的挑战呢？

第三个问题是实时性，这一点对于SaaS非常关键。就像互联网应用一样，如果实时性达不到要求，可能会导致客户流失并引发赔偿问题。由于SaaS是面向企业用户的应用，通常需要签订SLA协议，如果不能满足协议要求，将会造成严重后果。

实时性方面有两个方面需要考虑。

首先是业务应用的实时性，即对业务的增删改查操作的实时响应能力。这方面最担心的是高并发和大数据量的应用场景。

其次是数据分析的实时性。现在越来越多的SaaS厂商都设有自己的分析系统，比如内部的BI仪表盘，用于监测业务指标、用户数量等。对于内部系统来说，实时性要求并不太高，很多客户可以接受T+1或者T+N的延迟。但是随着SaaS分析能力的发展，解决方案不仅限于内部使用，还要提供给客户或合作伙伴使用。

举个例子，许多SaaS应用服务于电商、跨境电商等行业，比如ERP系统或CRM系统，其中的某些子系统并不仅仅是公司内部使用，而是提供给客户使用的。这意味着数据分析能力是SaaS的一部分，对客户来说，他们需要快速获取实时的分析结果，因为他们需要及时做出决策和运营行动，尤其是在营销和广告等领域。此外，SaaS中的计费、监控和运营模块也是如此。如果实时性不够高，可能会导致客户服务出现问题而未能及时察觉，比如客户已欠费几百或上千元，但平台仍没有终止他们的服务。

最后一个问题是智能化，也是现在最火热的话题。在大模型领域，人们普遍认为交互方式可能会发生一种转变，而对于SaaS来说，这种变化也十分明显。过去，交互是通过工作流和界面上的点击来完成的，而现在则完全基于自然语言进行交互，类似于通过对话框来完成任务。

在北美地区，像Tableau这样的数据分析类SaaS产品已经开始广泛应用与GPT相关的工具链。其中最常见的一种用法是将自有数据进行向量化，然后与大模型结合，通过结合大模型、向量数据库和Langchain等组件来实现。虽然这套技术相对较为成熟，但却增加了一个额外的数据组件，即向量数据库的管理。因此，你可能需要考虑如何将这个新的向量数据库与之前的整体架构进行结合。

首先介绍一下MatrixOne的核心技术架构。MatrixOne是一个完全云原生化的产品，体现在以下3个方面：微服务架构、完全的存算分离、基于云上的成熟组件开发。

MatrixOne构建在两个主流云平台的基础组件之上。第一个是S3，即对象存储。另一个是Kubernetes (K8S)。在MatrixOne中，所有的组件都可以被理解为容器，可以快速地启动和关闭。作为容器，它们拥有强大的扩展能力，可以轻松地从一个容器扩展到多个容器，或者从小容器扩展为大容器。

我们将整个MatrixOne数据库的计算、事务和存储层进行了拆分，实现了一个三层解耦的架构。存储层完全基于S3对象存储，所有的数据都存储在对象存储中。在云计算领域，S3已经成为事实上的标准存储层，它拥有几乎无限的容量和自动扩展性，并且无需担心可靠性问题，AWS的S3可靠性达到了11个9。

在计算层，我们的计算节点称为CN，它是无状态的纯计算容器。可以根据需求轻松地扩展CN的数量，例如一次性扩展10个或100个。

在事务层，我们对Snowflake架构进行了创新改进。相比于Snowflake不支持TP（事务处理），我们的架构实现了事务能力。我们的事务处理组件称为TN，主要负责处理数据写入的仲裁和其他事务相关的处理。

此外，我们还有一个Log Service组件，用于记录最新的数据写入操作。我们会将最新写入的数据记录到Log Service中。当达到一定数据量后，后台会异步压缩数据，并将压缩后的数据写入S3中，这意味着S3中始终保存着完整的数据。

我们的架构采用了多级冷热分离的存储设计，数据从上往下依次为热到冷。在CN节点中，我们设置了两级cache缓存，第一级是内存cache，第二级是本地磁盘cache。最热的数据存放在内存cache中，即最红色的部分；其次是整个disk的cache，它相对较冷，但容量稍微大一些。

第三个存储层是Log Service，即前面提到的日志层，它会少量使用EBS存储。尽管EBS的读取效率不如前两个存储层高，但它具有较高的可靠性和使用简便性，并且作为整个产品一致性的保障，其中包含三副本Raft协议。因此，它需要一定的可靠性来保证数据不会丢失。

最后一个存储层是对象存储的主存储，其容量可以做到无限大，可靠性非常高，达到11个9。然而，它的存取效率相对较低，这是一个缺点。我们将其作为主存储，仅在读取和写入比较大的数据块时直接与其交互，效果还是相当不错的。通过这种多级存储设计，用户需要读取数据时，会依次查看这些数据是否在相对热的存储层中。例如，对于TP数据，很多时候可以在热存储层中非常快速直接返回，这可以弥补云上对象存储存取效率较低的问题。此外，如果需要进行大数据量的写入或查询，可以直接从对象存储中访问，这样整个效率将保持相对平衡的状态。

为了实现HTAP，常见的技术路线有两种。第一种是像TiDB那样，使用两套引擎，一套用于处理事务性处理（TP），一套用于分析性处理（AP）。这种方法需要维护两份数据，并通过RaftLearner架构将TP引擎的数据同步到AP引擎。而我们的实现方式与此不同，它在同一数据引擎中只使用一份存储来实现HTAP。

我们的核心思想是有效拆分读写操作。对于写操作，我们将其处理过程几乎等同于处理TP问题。具体来说，当写入请求到达CN节点时，CN节点会将数据传递给TN节点。TN节点进行事务相关的判断，比如判断多个客户端写入的先后顺序，确定哪些需要等待，哪些可以立即写入。然后TN节点会将这些数据存储在我们的Log Service上，也就是说所有新写入的数据都会保存在这个位置，我们称之为LogTail。这些数据会被重新同步到服务查询的CN节点的内存中。因此，CN节点在处理查询时可以快速从缓存中找到相应的数据。

在查询方面，请求会经过Proxy到达CN节点。如果命中缓存中的数据，如LogTail，就可以在无需经过其他节点的情况下快速返回。缓存是一级一级地寻找的。如果未命中缓存，就会从S3读取数据。这种读取时至少读取一个匹配S3读取效率的数据Size，并将其放入缓存中，下次读取时可以直接从缓存中获取。

可以看出，在MatrixOne中，读和写的链路是完全不同的，并且在一个系统中，它们天生就是分离的。这种隔离性是实现整个HTAP的基础。

MatrixOne还内置了多租户能力，允许在其中创建多个账户（account）。每个账户天然地在数据空间上相互隔离，就像是拥有独立数据实例的数据空间一样。通过前端的代理（proxy）模块，我们可以灵活地自定义账户的资源组。也就是说，当使用accountA或accountB连接到MatrixOne时，它会被路由到相应的计算节点（CN组）。由于CN节点是无状态的纯计算模块，我可以通过打标签的方式，为account1分配一些CN节点，为account2分配另一些CN节点，这样在Kubernetes中可以保证它们的隔离性。

这意味着，如果通过account1进入前端，所有的连接都只会连接到account1对应的CN资源上；而account2则全部连接到account2对应的CN资源上。除此之外，在每个租户中，我们甚至可以进行更细粒度的资源组划分。例如，我们可以将备份负载和业务的增删改查负载进行拆分。实际上，你可以在代理上再设置标签，指定一些CN节点用于备份，另一些CN节点用于处理业务负载。

MatrixOne具备自动扩缩容的功能，可以通过感知负载来实现。MatrixOne内部集成了一套监控系统，用于存储各种运行状态数据。此外，我们还使用了云原生社区中著名的组件KEDA组件。KEDA会调用MO Scaler组件，后者会查询MatrixOne的负载相关指标。如果超过预设阈值，MO Scaler会向CN组发出扩容或缩容指令，实现scale out、scale in甚至scale to zero的操作。

这意味着，当租户完全没有负载时，可以关闭所有CN节点，不提供任何资源，就像关闭了自来水的龙头一样。对于那些对成本非常敏感的客户，比如SaaS场景，他们可以在没有负载时完全不花一分钱。

流计算是MatrixOne数据库中非常重要的内容。它主要解决两个问题。首先，我们需要从各种外部数据源（如其他数据库、日志系统、消息队列等）将数据写入到我们的系统中，这就需要一个流计算框架。通常行业内使用Kafka、FlinkCDC等组件来完成此任务。

我们在设计MatrixOne时，自己开发了一套Connector和流引擎系统，可以方便地接入其他数据库和外部组件（如Kafka），将包括数据库、消息队列和文件等各种外部数据都导入到MatrixOne中。

其次，流计算解决了内部数据处理的问题。也就是说，我们需要将原始数据转换为最终用于serving的数据，其中涉及到许多转换过程，比如聚合表、数据清洗和转化等。对于数据库而言，我们可以使用流计算提供的物化视图功能来解决这个问题。通过使用不同的算子，将数据的聚合和转换过程集成到流计算链路中，并最终生成物化视图。然后，我们可以将这些物化视图作为数据服务给业务应用。这样一来，就避免了许多用户目前所面临的复杂链路问题，即需要将原始数据读出，在外部使用Flink或代码进行处理，然后再写回数据库以供查询。

基于MatrixOne，如果要设计一套新的SaaS架构，可以按照以下方式进行。通常，整个SaaS可以分为用户面和控制面两部分。用户面是面向用户的，而控制面是用于内部管理的模块。

在用户面方面，我们可以有创建多个应用租户，每个应用租户对应一个独立的数据库租户Account，例如Account1、Account2、Account3，这样每个租户的数据空间就天然地被隔离了。同时，我们可以为每个数据库租户配置一个CNGroup资源组，并为其配备自动扩缩容策略。这样，每个租户在使用时不需要担心负载的问题，直接与资源组对应即可。

在控制面方面，我们可以使用另一个租户，即系统租户，用于管理控制界面的相关能力。同样地，我们可以为其设置计算资源的分组，例如为写入负载分配一个资源组，为分析相关任务分配一个资源组，为备份相关任务分配一个资源组。这些资源组可以存在于同一个账户中，意味着在一个用户空间中进行操作。这样的设计使得所有能力都具备可扩展性。如果现在系统租户和这些用户租户之间需要进行交互，例如平台层需要对用户相关数据进行统计或从中提取相关数据，我们可以使用发布-订阅机制，即从一个租户发布数据，另一个租户可以直接接收，因为它们本质上在同一个集群中。

总之，我们提供的这套实践架构实现了超融合的理念，所有的数据处理都集中在一个数据库中解决，而且使用起来与使用MySQL基本没有区别。

有一个典型的多租户问题场景，是一个ERP的SaaS厂商。这个厂商是某个制造领域的IT服务商龙头，目前有近5000个客户。他们目前的架构是通过多租户的形式，使用了十几个MySQL实例来支撑，每个实例大约有300个客户，采用了分库分表的方式进行资源共享和隔离。然而，他们面临着很大的隔离性问题。单个实例中的一些表已经达到了百万级别，而在ERP业务中，经常需要对多个大表进行复杂查询操作。这对整个数据库实例来说是一个巨大的负担，即使一个用户执行这种操作，其他用户也会受到影响。这导致了用户投诉和退款的问题，对业务产生了严重影响。

为了解决这个问题，我们可以将每个租户作为独立的实例部署到MatrixOne上。这样，每个实例之间天然具有隔离性，一个租户出现问题不会影响其他租户。同时，MatrixOne可以自动进行扩缩容，无需手动管理每个实例的资源。此外，如果需要在平台层面对这些用户进行管理和操作，所有实例都位于同一个集群中，可以方便地访问整个集群和其他租户的相关数据。