新一代实时数仓：阿里云数据库 SelectDB 版--100% 兼容 Apache Doris 的全托管云原生实时数仓

导读阿里云数据库 SelectDB 版是 100% 兼容 Apache Doris 的云原生数仓产品，具有存算分离和实时弹性的核心优势。同时提供离线及实时流式数据同步链路；实时更新和万级 QPS 高并发点查特性。提供基于倒排的文本检索和日志分析能力，同时支持基于 Multi-Catalog 的湖仓一体方案和开放的生态产品协同能力。本文将介绍 SelectDB 产品能力及其所支持的场景，为数仓选型提供参考和借鉴。

主要内容包括以下几大方面：

1. 阿里云 SelectDB 产品产生背景

2. SelectDB 核心能力

3. SelectDB 云原生特性

4. SelectDB 开放生态和产品协同

5. Q&A

分享嘉宾｜艾乐强（凤豪）阿里云产品经理

编辑整理｜张阳

内容校对｜李瑶

出品社区｜DataFun

阿里云 SelectDB 产品产生背景

1. Apache Doris 是全球流行的开源实时数仓产品

SelectDB 是基于 Apache Doris 提供的一个商业化的云原生产品。Apache Doris 是一款国产的开源数据库，专注于实时数仓领域。该项目始于 2013 年，并于 2022 年在 Apache 基金会的支持下成为顶级项目。经过将近 10 年的演进，Apache Doris 的内核已经非常稳定和成熟。现在，该项目在社区中的关注度和活跃度都非常高。

2. Apache Doris 被 4000+ 国内外企业生产系统使用

目前，在国内外使用 Apache Doris 的企业范围非常广泛，遍布各个行业，包括一些行业的头部企业。其成熟度毋庸置疑，已经在客户业务中得到了广泛验证。02

SelectDB 核心能力

SelectDB 是在 Doris 基础上孵化出来的一个商业化的实时数仓，在 Doris 上做了云原生改造，并在阿里云上提供托管服务。接下来将从用户使用实时数仓的整个链路，展示 SelectDB 在各个环节上的产品能力的匹配。

1. 全面数据导入及同步链路

首先来看数据导入层面。对于数仓产品来说，客户最先面临的问题就是如何将数据同步到数仓中，以便向上层业务提供数据服务，包括实时分析等业务构建。在这一层面，SelectDB 是基于 Apache Doris 的，因此具有良好的开放性和生态兼容性。它支持各种数据源，包括流式和批量的大数据链路加速导入。SelectDB 支持的数据类型和数据源非常丰富，如 CSV、MySQL、SQLServer、Oracle 等数据源，能够进行数据类型的转换和导入。对于流式数据，SelectDB 与 Flink、Kafka 等常见链路有完善的对接方式；对于大数据体系如 hive，Hadoop，MC 等，SelectDB 支持通过 DataWorks 和 DataX 等平台及工具，进行批量离线数据的导入。此外，对于数据湖的数据，为了进行数据湖的联邦查询和湖仓统一管理，SelectDB 与 Iceberg、Hudi 有良好的兼容性。这使得在数据湖层面可以进行很好的数据分析，在业务层面可以通过统一的 SelectDB 访问层向上层业务提供数据湖和数仓的统一服务接口。总而言之，SelectDB 在流式数据、离线数据和数据湖数据方面，提供了全面的技术对接，可以帮助我们便捷地将数据导入数仓，解决了数据入仓这一首要问题。

2. 高吞吐数据写入及实时更新

在数据入仓以后，我们面临的第二个问题是数据可能会需要进行更新。数据进入数据仓库以后，例如订单、物流等实时业务的数据需要进行实时状态更新。SelectDB 针对不同场景提供了不同的数据实时更新能力：

对于 TP 库的数据，分析时业务对数据的唯一性要求比较高，SelectDB 提供了主键（Unique）模型，可以保证数据从 TP 到数仓中的数据一致性，支持全列和部分列的更新。同时基于业务场景，提供了两种更新方式：
MoR (Merge On Read)：这种方式适用于人群画像标签导入等涉及低频、大批量数据更新的场景。人群画像有很多标签，离线标签通过 T+1 或小时级别的计算进行批量导入。MOR 方式下，数据能够以更大的吞吐量批量写入，吞吐量可达 100 万每秒。
MoW (Merge On Write)：适用于实时分析场景，极致的时效性和实时性要求。如订单状态变更，需要进行实时更新。这种方式面向高频、小批量更新，在数据进仓时同步更新原有数据，消耗更多 IO 资源，对 IOPS 要求较高。这种模式下，数据写入过程中事务性保证完成一致性处理，查询时直接获取一致性的数据结果，减少查询时数据一致性处理，查询性能相比批量导入方式可提升 5-10 倍。
对于聚合场景，提供了 Agg 聚合引擎类型。此类业务查询多是进行聚合结算结果的查询。如用户积分的写入和更新，新增积分记录会进行存量和新增计费的聚合计算。那么基于聚合引擎和聚合函数就可以完成增量写入过程的的聚合更新。对于聚合表引擎中进行替换更新的列，也支持通过 replace_if_not_null 方式实现部分列的更新操作。

3. 毫秒级实时查询能力

接下来将讨论衡量 OLAP 实时数仓的一个核心指标，即实时查询能力，这里看主要分析场景来进行说明。首先是宽表分析场景，通常涉及到人群画像和 BI 等场景，数据在 ETL 清洗和处理之后形成一张大宽表，对外提供服务。这里主要关注的是单表分析的性能，业界常用的衡量标准之一是 ClickBench 测试。在最新的 ClickBench 测试中，SelectDB 荣登榜首。这充分证明了 SelectDB 在宽表分析场景下的数据分析性能处于在业界领先位置。

4. 万级 QPS 高并发点查能力

另外一种场景是数据详情的查询。比如 Trace 的场景，日志进到数仓以后，查询某个用户具体的行为轨迹，这就需要根据 QueryID 或者 UID 进行精准匹配查询。又如用户画像的数据，经过 ETL 清洗后，可以在数仓中提供一些人群画像的查询分析，但如果要获取某个具体用户的标签，就需要根据用户 ID 去查询对应的标签列，这些情况就是一个点查的详情查询。数据在 OLAP 中默认是列存排序，基于排序结果进行数据块存储。当进行离散的精准 ID 匹配查询时，每次查询命中的数据结果需要在多个数据块中进行大量的 IO 检索，引起 IO 放大，会明显影响查询性能，因此在默认列存模式下，效率是比较低的。SelectDB 的解决方案是提供行存和列存混合存储的方式，在具体业务场景中只需开启行存模式，通过冗余方式行列同时存储并创建索引，提升点查性能。这样在 Data serving 场景下，数仓可以直接对外提供高并发的点查服务。基于测试结果，在 1 亿条记录规模下，用 48 核 BE 资源测试可以支持万级别的点查 QPS，满足了大部分业务场景的高并发查询需求。

5. 高性价比日志分析方案

日志分析是 OLAP 中的一个通用情景。传统用户日志分析使用 Elasticsearch 这种日志检索引擎的较多。但由于 ES 的写入过程索引构建成本高，以及大量依赖内存来支持请求加速，大数据规模下资源用量高且容易发生 OOM，且压缩率较低，造成存储成本高，整体性价比不是很高。SelectDB 提供了倒排索引的能力，允许对文本列进行分词，并在其上创建倒排索引，从而支持关键字的模糊匹配和全文检索。同时对于非文本列，如 Decimal 或 Int 类型的数据，同样可以加速查询，特别是针对非排序列的 Ad-Hoc 查询场景。通过这种方式，SelectDB 在日志分析中能够显著提升写入和查询效率，同时降低资源消耗，有效解决了以往 Elasticsearch 在性能上的瓶颈问题，整体性价比是 ES 的 10 倍以上。

6. 多租户管理和资源隔离

除了完整的数据导入和点查服务，包括聚合分析、日志分析和全文检索等能力，针对具有高合规性要求的金融客户，为满足其数据安全和权限管理方面的特殊需求，SelectDB 提供了兼容 MySQL 协议账号和数据访问安全认证体系，确保可以实现细粒度的资源权限控制，支持库级、行级和列级角色授权及数据权限管理。在数据传输层面，支持 SSL/TLS 安全加密传输，全面保障数据存储和访问安全。在内核层面，实现了基于用户角色的资源隔离和权限限制，有效防止了单一用户或角色在多用户使用集群中对资源的过度使用，从而确保了整个集群的稳定性和实例的资源限制，为合规性和数据安全性提供了全方位保障。

7. 基于 Multi-Catalog 的湖仓一体能力

另外，Lakehouse 成为当前大数据处理的一种流行方式之一。基于 Lakehouse 的方案可以减少数据冗余成本，同时提供一体化的处理处理能力。SelectDB 提供了基于 Multi-Catalog 的湖仓一体能力，可以为各种数据湖和对象存储的数据提供统一管理，实现了实时的元数据结构同步，从而在整个 SelectDB 平台上实现了统一的逻辑层面的数据管理。在引擎层面，实现了数据湖查询的加速处理和数据缓存，利用引擎本身的加速能力优化数据湖的查询。同时，通过联邦查询的能力，可以将数据湖的数据导入到 SelectDB 本地存储引擎上，以加速实时数据分析。这样，通过 SelectDB 统一的 API 接口，业务可以轻松访问数据湖和实时数仓，整个技术栈更加统一，业务开发难度大大降低。03

SelectDB 云原生特性

SelectDB 的云原生特性主要体现在四个方面：

存算分离：即存储和计算可以独立扩展，实现了资源解耦。
实时弹性：资源弹性调整完全实时，无需停机或大量数据迁移。
多计算负载隔离：读写分离，确保不同业务在共享存储后能进行物理隔离。
数据共享：在多集群环境下实现了数据在隔离的同时保持一致性。

接下来将详细分析 SelectDB 在这四个方面的具体实现。

1. 存算分离，独立扩容

SelectDB 整体架构划分为三个层次。首先，我们将计算层拆分为两部分：第一部分是纯粹的计算引擎，另一部分则是在计算引擎层面引入了本地盘，这部分曾在 MPP 架构下用于全量数据存储，现在则退化为缓存作用，利用云盘等进行数据缓存。这两部分构成了计算层的资源，即区分了纯计算能力与缓存能力。而原先在 MPP 架构下全量数据存储层的数据，现在则放置于基于阿里云 OSS 对象存储构建的共享数据存储层。通过这种架构实现了存储和计算的分离。中间的 Cache 用于加速读写操作。这种架构相比于 MPP 架构带来了明显的优势，特别是对于 Doris、StarRocks 相关技术体系，在以前的架构中，数据高可用性主要通过副本实现，每份数据需要在多个节点上存储多个副本以保证服务的连续性和可靠性。而现在，在云原生存算分离架构下，数据的全量存储转移到了基于阿里云的 OSS 对象存储的共享存储上，而阿里云 OSS 对象存储本身就具备容灾备份的能力，所以在数据库引擎层面，数据只需存储一份副本即可，其可靠性完全依赖于存储介质本身。这样对存储资源的使用量就减少到了之前的三分之一。考虑到缓存也会占用一部分存储资源，所以我们根据业务需求设置了缓存命中率，建议从 10% 起步逐步调整缓存分配比例。如果数据分布比较离散，完全可以最大程度地利用整个 Cache 的容量，使其与共享存储所占比例持平。这样做的好处是，一方面可以通过共享存储保证数据的持久可靠性，同时还可以通过 Cache 加速读写能力。即使在这种情况下，我们整体数据的副本数量最多只需做到两副本，相比之前的三副本存储方式可以减少三分之一的存储用量，同时 OSS 的单位存储成本也更具优势。

2. 实时弹性

通过云原生的方式解决了存算分离的问题，使得计算层和存储层能够独立扩展。当需要扩展计算层时，不再需要进行数据的 Reshard 或 Rebalance 操作。相比于传统的 MPP 架构，SelectDB 水平扩展仅进行元数据刷新和主动缓存加载即可完成扩容，不需要复杂的数据迁移过程。因此整体的扩容效率不依赖数据量，可以实时完成扩容。存储层采用 serverless 方式，根据需求灵活使用，业务完全不感知其扩容和缩容的过程。单副本写&读写 Cache 加速性能

在数据存储和查询过程中，缓存起着至关重要的作用。SelectDB 通过在计算层添加缓存来加速读写操作。具体而言，数据写入过程中，首先缓存至存储介质，同时也写入到 OSS 上，确保在缓存和持久化层都有最新写入的热数据，以便查询时能够迅速获取最新结果，保证查询性能。在缓存数据淘汰策略上，SelectDB 采用两级缓存淘汰策略：第一级基于 TTL 策略，定义数据生命周期以防止数据在缓存期间被清除；第二级策略则根据访问热度使用 LRU 算法，优先保留高频访问热数据，从而在保证数据存储效率的同时，有效提升系统查询性能。在性能消耗方面，相较于传统的 MPP 架构，云原生模式下单副本的模式，写入数据处理量减少了 2/3，显著减少了 CPU 资源的消耗。数据的批量写入和 CPU 计算能力的高效利用，使得整体写入效率明显提升，同时保持了数据存储的可靠性和查询的实时性，从而在大数据处理场景下表现出色。

3. 单实例多计算组资源隔离

另外，SelectDB 提供了单实例多计算资源隔离的能力，主要是为了满足多业务隔离需求。通过业务访问隔离和读写分离的设置，确保了高业务负载情况下数据资源的完全隔离，从而保证了数据导入和查询过程中不会出现业务相互干扰的情况。具体做法是在计算层面实现逻辑计算资源的隔离，逻辑资源对应的物理资源也是完全独立的。这样从用户角度来看是不同的计算集群，还基于容器化技术实现了集群的快速部署和释放，有效地保证了强隔离。再结合 Doris 内核在用户级别提供的软负载的隔离，可以满足不同级别的隔离需求。04

SelectDB 开放生态和产品协同

在数仓选型过程中，还需要考虑产品的生态开放性。SelectDB 作为一个基于 Apache Doris 的云原生商业化改造产品，本身就是基于 Apache Doris 内核构建的，因此协议上完全兼容 Apache Doris，避免了技术绑定带来的困扰。SelectDB 提供的是开放的生态系统，允许客户从 Doris 或 StarRocks 技术栈无缝切换到 SelectDB，几乎没有切换成本。SelectDB 兼容 MySQL 协议，这也意味着开发成本较低。它采用标准的 MySQL 语法，允许使用 MySQL 客户端工具（如 Navicat、DBeaver）直接对接，开发者可以按照标准的 MySQL 开发模式进行 SelectDB 开发工作。SelectDB 作为一个开放的生态系统，与 MySQL 以及 Flink、Kafka 等大数据技术栈的兼容性良好，涵盖了离线批处理和实时数据流的接入。并且在云端实现了与整个云生态系统的紧密衔接，通过云控制台进行操作，可以显著减少生态链路构建及运维的成本。此外，SelectDB 支持从 RDS 和 PolarDB、MySQL 等技术栈实时导入数据，并计划在未来推出 Zero-ETL 服务，同时支持与阿里云上下游其他数据库产品的无缝流转，进一步优化数据流动，实现价值放大。对于大数据工具，在云上也提供了良好的对接和支持。以上就是 SelectDB 在数据引入、更新、分析能力、成本和弹性扩容等各方面所提供的核心能力。

目前，我们提供了一个包含 8 核集群和相应存储资源的优惠套餐，感兴趣可以扫描上图中的二维码进行体验。以上就是本次分享的内容，谢谢大家！05

Q&A

Q1：共享存储层是不是也是分布式存储，不然成了单点故障了？A1：对象存储支持本地机房容灾和跨机房方案，确保高可用性和数据冗余。其实现细节通常基于分布式文件系统，是一个高可用的支持异地容灾的存储服务，从用户角度看，其分布式或单点架构是不可见的。Q2：针对 serving 场景为什么 OceanBase 产品不需要行列共存的模式也能够做到点查很高的 QPS？A2：在数据服务场景中，有些 OLAP 产品不需要行列共存的模式却能做到高的点查 QPS。而 Oceanbase 更倾向于行存数据库，不需要进行行列转换，因为它的定位不同于其他产品，类似于 MySQL 支持高并发 IOPS。但对于 SelectDB，提供行列混存是因为数仓中的数据对象不同，数据已在数仓中经过 ETL 清洗和聚合处理，而后要提供点查及聚合分析。在这种情况下，选择将数据导出到其他 TP 引擎进行分析，但这会增加技术栈的复杂性和数据回流的麻烦。相比之下，行列混存的提供可以减少技术栈的依赖，在数据写入过程中直接提供行存模式，有效解决业务问题，简化技术架构，使数据服务场景更加高效。Q3：SelectDB 的资源能否自动识别负载进行扩缩容？A3：目前在 SelectDB 中，没有自动的负载识别和自动扩缩容功能，但我们提供了一种灵活的解决方案。我们可以根据业务需要，通过启停操作来管理资源，特别是在面对突发的高流量时，可以临时创建新的集群来处理。这种方式允许用户根据实际负载情况动态调整计算资源，以支持业务需求。未来的规划包括在 S2 阶段引入 Serverless 计算资源自动扩展功能，以更好地满足不同业务场景的需求。以上就是本次分享的内容，谢谢大家。