深入解析 OceanBase 4.3关键能力

最近的OceanBase开发者大会上，OceanBase 4.3.0 Beta版本正式亮相。新版本中，我们引入了全新的列存存储引擎，构建了一个近PB级别的实时分析数据库，能够提供秒级的实时数据分析能力，从而进一步强化了OceanBase在TP和AP一体化方面的能力。

相继开发者大会 4.3 亮相，OceanBase 4.3.1 Beta 版于 5 月 17 日发布。该版本带来了大量基础性 OLAP 能力的增强，其中包括用户期待已久的全文索引支持、物化视图增强支持实时物化视图和自动 SQL 改写、外表增强支持分区表分目录存储。作为实验性特性功能，增量旁路导入能力可以提升多次导入场景的入库性能。同时，我们对 JSON 进行了进一步增强，支持 JSON 多值索引。另外，在这个版本中，SQL 临时结果落盘时可开启压缩，解决了超大 OLAP 查询导致的磁盘空间问题。

本文将作为发版解读的补充，深入探讨 OceanBase 4.3 版本的核心功能、性能提升、应用场景，以及未来内核层面的发展规划。

一、更完善的 OLTP

在 OceanBase 的发展历程中，从 1.x 版本开始直至当前的 4.3 版本，我们始终将OLTP（联机事务处理）数据库作为关键能力进行强化，这也是我们在上千家客户的关键业务负载上经过广泛验证的能力。在 4.3 版本中，我们进一步完善了 OLTP 的功能，包括租户快速克隆、优化器增强、事务日志优化以及大表 DDL 空间优化等。虽然这只是一些亮点中的一部分，但实际上我们在许多细节上都做了改进。我们持续不断地优化产品，致力于为用户提供更加极致的 OLTP 体验。

在提高 OLTP 易用性方面，我们引入了参数模板、索引使用监控、配置项重置以及客户端本地导入等功能。其中许多功能都是解决用户痛点的设计。例如，以前用户在安装 OceanBase 后，为了在业务场景中获得最佳性能，需要配置大量参数。在电商领域，高并发的简单 OLTP 应用需要怎样的参数设置？在银行业务中，复杂查询场景下需要怎样的参数配置？过去，这一过程需要用户不断试错探索。

在 4.3 版本中，我们提供了一套参数模板，用户只需确定业务类型，就可以直接应用相应的模板，设定初始参数，从而获得良好的体验。同时，索引使用监控也得到了升级。在之前的版本中，用户很难判断哪些索引被利用了，哪些可以删除。而通过索引使用监控，用户可以轻松判断这些情况。

二、全新的 OLAP

早期版本的 OceanBase 就已经提供了一定的 OLAP 能力。2021 年，OceanBase在 TPC-H 基准测试中以 1526 万 QphH@30000GB 登顶榜首。即便如此，OLAP 方面还有很多事情要做。在 4.3 版本，OceanBase 补齐了 OLAP 的重要能力。

在 4.3 版本里，在原有能力的基础上，补齐纯 OLAP 所必须的能力，如列存、物化视图、数据导入、数据加工等，更好地支持 AP 生态。整个 OLAP 能力拼图越来越齐，等我们拥有一个完整的拼图后，开发者基于 OceanBase 做开发时可以更加轻松，对于中小型的业务，一套架构就能应对 OLTP 和 OLAP 需求。

（一）直观呈现 AP 能力：下单模拟场景

OceanBase 团队一直在思考，如何更直观地呈现 AP 能力？所以在今年的开发者大会现场，我们提供了一个小型 demo 演示，这个演示分成两部分：左侧是 APP，模拟手机购物场景；右边是给商店管理人员查看的看板。左侧进行下单操作后，右边的看板数据会在 2 秒内刷新。

那么 2 秒意味着什么呢？在传统的 OLAP 工具里，数据从 TP 到 AP 有一个同步的过程，并且同步需要积累一批数据作为比较大的事务写进 AP 数据库，而攒批意味着会增加系统的延迟。

OceanBase 提供了小事务的支持，即时只有一行数据，也可以立即完成同步写入 AP 库。这个对 OceanBase 来说是很容易的，因为 OceanBase 在 OLTP 领域中已经具备了小事务能力。

为了实时获得看板数据，还需要支持快速扫表。在 demo 演示里，看板查询是硬扫的，并没有进行预聚合。订单表中有约 1.8 亿行数据，在内核里只要 10 毫秒左右就能完成扫描和聚合统计。做到这么快，需要内核提供什么样的支持？

在这个场景下，第一，数据要读得快；第二，要算得快，如聚合计算等要快；第三，同步快，数据从 TP 生产库到 AP 库要快。OceanBase 提供了几个相应的解决方案。

第一，读得快。读得快依赖 4.3 版本推出的列存。OceanBase 的列存功能和市场上大多数 AP 数据库有一点不同：OceanBase 的表不限于列存，还支持列存行存混合。为什么这么做？如果这个表上既有分析查询，同时又有大量高并发的点查，这种模式可以给用户提供最好的体验。当然了，如果没有点查，那就只需要建一个纯列存表，只有下图中左边的部分，存储空间更省。

OceanBase 在表级上给用户提供了非常灵活的选择，可以根据业务的需求建不同的表。此外，我们还支持列存索引。如果业务上已经是行存的表，并且需要列存加速计算，还可以对行存表建列存索引，只对其中的若干列建列存，以实现性能最优和最小的存储空间。

第二，算得快。快速计算依赖 4.3 版本引入最新的向量引擎。OceanBase 的计算引擎已经发布多年，到第四代时，已支持面向列格式的向量化。这意味着 OceanBase 在存储层将数据按列形式读取，在计算层可以直接基于这个列格式做计算，无需做二次转换，从而计算更快。

第三，T+0 的实时能力。T+0 同步快依赖实时写入能力，OceanBase 早已具备多年的实时写入能力，在 AP 场景下可以发挥更大的价值。这可以分解成两部分：

○  实时导入：将数据实时导入 AP 库里，支持非常小的小事务。

○  支持 Flink 生态：支持将 OceanBase 的数据同步给 Flink，或者 Flink 将其他地方的数据实时写入 OceanBase。

在实际业务中，如果数据分布在多个库中，可以基于 Flink 把它们汇集到一个 OceanBase 4.3 AP 库中进行分析。OceanBase 具有高级优化器、向量化引擎、列存表、行存表，具有带主键的点查，支持 Insert or Replace、Insert or Update（UpSert），也支持二级索引，还支持多种 join 算法。从 2.x 版本到 4.x 版本，这些功能已经逐渐成熟，可以很好地应用在 AP 分析中。

（二）物化视图让AP实时分析更快

上文提到的 demo 演示中，计算耗时约为几十毫秒。有没有可能将计算时间耗时缩减至 1 毫秒？答案是肯定的—通过物化视图就可以实现。

通过建物化视图的方式，可以避免重复计算。例如，之前已经对 1.8 亿行数据进行了一次聚合计算，新进数据只需对新增部分再聚合即可，无需重新扫描数据，这就是物化视图提供的能力。

通过实验，首先按照颜色进行聚合并建立物化视图，再基于物化视图做 TOP3 查询和总预定量的查询，就可以将所有查询时间缩减至 1 毫秒。建立物化视图后，该表只包含几十行数据，对于几十行数据表的查询，速度自然非常快。

现在我们来了解下 OceanBase 物化视图的路线图。

在 4.3.0 版本中，我们支持了非实时物化视图，即数据插入源表后，数据不会自动在物化视图上查询到，需要手动刷新才能同步数据。而 4.3.1 版本中，我们支持了实时物化视图，这意味着数据一旦插入源表，下游就可以立即查询到。4.3.1 版本同时支持异步实时物化视图，增量数据写入到一个名为 mlog 的结构中，查询时查基线的物化视图，同时和 mlog 的数据做汇聚运算，得出最终结果。从用户的视角看，获得的就是实时的汇聚结果。

如果用户有需求，未来的版本中，OceanBase 可能会支持同步实时物化视图，即每插一行数据到源表并提交事务后，物化视图层立即进行聚合。如果有这样的需求，请随时反馈给我们。

4.3.1 版本，我们还支持了自动查询改写。也就是说，一旦建立了物化视图，用户查询源表的 query 不用改，当优化器发现这个查询能够用上物化视图，就会自动改写成查询物化视图，让用户无感地实现性能加速。

如果你想给 OceanBase 一个机会，并实际体验一下，第一步是导入数据，将其他数据库或文件里的数据导入到 OceanBase。

导入数据速度越快越好，OceanBase 通过旁路导入的方式，将数据快速导入到  OceanBase 中。以下是我们经过模拟实验得到的真实数据：

○  如果表没有主键，可以实现每秒 100 万行的导入速度；

○  如果表上有主建，由于涉及排序，可以实现每秒50 万导入速度。

三、丰富的 OLAP 场景

在前面我们介绍了 4.3 版本的核心特性，接下来分享一下 4.3 版本的应用场景。

（一）TP 增强场景

希望在 OceanBase 的 TP 库里体验 AP 能力，该怎么办呢？专门搭一个 AP 集群非常麻烦，OceanBase 提供一种方式：对现在的行存建一个索引，将索引的存储格式指定为列存，也就是列存索引，这样就可以在现有集群中获得列存的能力，加速查询。例如，下面的语句为 t1 表的 c2, c3 列创建了列存索引。

create index idx1 on t1(c2,c3) with column group (each column);

此时，行存和列存都在同一个集群里，共享同一套硬件资源。这种情况自然需要资源隔离， OceanBase 在租户内提供了基于 Cgroup 的资源隔离，以及 IOPS 的隔离，可以实现 CPU、I/O 的隔离，确保 AP 和 TP 之间不会相互干扰。

（二）ODS & Serving 场景

在大数据处理场景中，OceanBase 可以用于 ODS 和 Serving 场景：

○   ODS：用户上游的各种数据首先会写到 ODS 层，OceanBase 为什么可以用于 ODS 层？因为我们支持实时写入、批量写入以及部分更新，同时还提供 HBase 模式。很多系统的 ODS 层都是由 HBase 构建的，用户可以用 OceanBase 上的 HBase，也可以直接将数据以表格形式进行存储。将数据写入 ODS 层后，再基于第三方生态进行分析，分析结果放到下游进行实时查询。值得一提的是，早在 3.2 版本中， OceanBase 已经成功应用于头部保险行业数仓 ODS 场景。

○   ADS：OceanBase 也可以用在数仓 ADS 层。由于 ADS 会承担分析和点查流量，并且有高并发的需求，OceanBase 基于行存、列存能力，可以为用户提供出色的 ADS 查询性能。

（三）轻量数仓场景

在数仓场景下，可以通过全面使用 OceanBase 来简化 ETL 流程。在 OceanBase 里建立各种物化视图来实现 ETL，可以简化用户的数仓运维。

（四）轻量实时数仓场景

4.3 版本既支持 Flink-CDC，也支持 Flink Connector，在轻量实时数仓场景下，Flink 既可以把 OceanBase 当成存储来用，也可以把一些查询下压到 OceanBase 层来加速计算。

如图所示，Flink 可以订阅 OceanBase 在 ODS 层的变更日志，实时进行流式计算，最后通过 Flink Connector 将结果写入 ADS 里，以对外提供交互查询、联邦查询、复杂查询、多维查询等服务。

四、AP 实时分析性能

以上简要介绍了 OceanBase 的 OLAP 功能及典型场景。在实际使用中，用户还关注其 AP 实时分析性能表现。

（一）TPC-H 1T 性能提升 25%

OceanBase 4.2 版本已具备一定的数据分析能力，在 1TB 的数据规模下，相比 4.2 版本，OceanBase 4.3 版本在 TPC-H 基准测试中性能提升了 25%。值得注意的是，TPC-H 基准测试模型并不涉及大宽表场景，无法充分发挥列存引擎的优势。因此，在这部分场景下，4.3 版本性能提升没有发生数倍的变化。

（二）TPC-DS 1T 性能提升 112%

下图展示了 TPC-DS 的 100 条 query，每个数据点代表着 4.3 版本相对于 4.2 版本的性能提升。在横轴上，0 表示 4.3 版本的性能与 4.2 版本相同，虚线代表 4.3 版本的性能提升达到或超过 1 倍，而最顶部的线代表在当前查询性能测试中，4.3 版本性能提升达到/超过 10 倍。

以 Q37 查询为例，4.3 版本中的性能提升达到十几倍，这得益于列存、以及优化器、执行能力等方面的改进。

五、内核 Roadmap 及未来展望

📢 Q1（2024 年第 1 季度）：我们已经发布了列存表、列存索引、物化视图、以及全新的向量化引擎，这使得 OceanBase 具备了 AP 实时分析的基础能力。AP 不是一个简单的工程，要真正做好 AP 实时分析工作负载，还有很多工作要做。因此，我们将持续优化 OceanBase 的 AP 实时分析能力，以满足用户不断增长的需求。

📢 Q2 （2024 年第 2 季度）：我们将继续打磨物化视图，以支持实时读取、自动改写等功能。同时，我们深知用户的AP场景不仅限于基础数据类型，还需要处理全文索引等复杂场景，因此我们引入了全文索引能力和JSON 多值索引能力，以满足用户对于更广泛数据处理需求的期待。

📢 Q3 （2024 年第 3 季度）：在接下来的版本中，我们计划引入三项重要的能力：

1）Parquet、ORC：随着数据处理需求的不断演进，数据不仅限于单个数据库里，而是存储数据湖里、S3、OSS 等环境中。为了充分发挥分析能力，OceanBase需要具备和外部环境交互的能力。Parquet、ORC 是两种典型的外部存储格式，我们将以外表的形式支持对 Parquet、ORC 的分析。

2）Bitmap：Bitmap 在人群圈选、实时广告营销等场景中被广泛使用，能够实现相关查询的毫秒级响应。通过引入Bitmap，我们将进一步帮助用户提升查询性能和效率。

3）Vector：支持向量数据库，OceanBase 内核将定义向量的存储格式、向量距离计算函数，向量索引层提供插件式的向量索引。这会使得 OceanBase 有机会提供非常广泛的索引形式支持，为用户提供更灵活的选择。

📢 Q4 （2024 年第 4 季度）：我们将持续关注用户在存储成本方面的需求，支持基于 S3 的存算分离，以进一步降低 TP、AP 的存储成本，从而帮助用户降低运营成本并提升效率。

本文作者：