OceanBase 实时数仓关键技术解读

企业级应用的业务场景通常可以分为两个类别：联机交易和在线分析，我们通常称为 OLTP 和 OLAP 的业务应用。企业往往会选择多款数据库产品分别支持 OLTP 和 OLAP 类的应用场景。这种组合式的解决方案需要数据在不同系统间进行流转，数据同步的过程会带来时间延迟和数据不一致的风险；同时，多套不同的系统也会产生冗余数据，增加存储成本。

OceanBase 基于无共享的 MPP 架构，辅以向量化引擎以及强大的优化器调优能力，可以实现在一套数据库引擎中同时支撑在线交易和实时统计分析，同时提供很好的资源隔离机制，保证各种业务负载性能稳定；交易数据原地分析，无需繁琐的ETL过程，数据最大程度保鲜，省去了很多业务场景中实时数仓的构建工作，帮助客户实现业务价值。

点击查看 实时分析解决方案的更多信息 >>

相关案例

跨越速运

翼鸥教育 Classin

OceanBase 实时数仓关键技术介绍

读写分离策略

数据库的读写分离策略是一种将数据库的查询操作和写入操作分离的方案，目的是降低读写操作的相互影响并提升资源利用率。在 HTAP 数据库中，读写分离的应用场景非常普及，只读的业务场景主要包括 BI 查询业务、大数据 ETL 取数、缓存的拉取等。两种类型的业务同时跑在一套数据库集群上，这对数据库的配置等要求就相对较高，因此我们一般会采用读写分离的方式，将一部分的读请求，路由到 Follower 副本上，从而降低复杂分析计算对资源的侵占，影响在线业务的响应延迟。

OceanBase 数据库天然支持读写分离的功能，即通过 OBProxy 代理服务和修改 OBServer 的配置即可实现业务的读写分离策略。

OceanBase 数据库在读取数据时，提供了两种一致性级别：强一致性和弱一致性。强一致性是指请求路由给主副本读取最新数据；弱一致性是指请求优先路由给备副本，不要求读取最新数据。

OceanBase 通过应用侧为执行的 SQL 添加 SQL Hint 来显性开启弱一致性读就可以实现基于注释的读写分离功能，同时也衍生出如下三种常用的读写分离策略，用户还可以根据实际情况，对读写分离策略进行灵活的配置：

备优先读

1. 默认情况下，强一致性读以及增删改的 SQL，会访问 Leader 副本。
2. 可以通过修改 OBproxy 的路由策略为 follower_first ，将业务读流量指定到该 OBProxy 从而保证读请求优先访问 follower 副本，对应 OBProxy 默认会将请求路由到本地 Follower 副本。如果本地该数据的副本为 Leader 副本，则会自动路由到同 Region 中其他 IDC 的 Follower 副本。

优点：配置相对简单，只修改 OBProxy 配置，无需修改 OBserver 配置；读流量均摊到全部 follower 副本上。

缺点：如果本地副本是 Leader 副本，读请求则会跨 IDC（zone） 访问；在不调整副本 leader 的情况下，同 zone 或同 server 下不同副本的 leader 和 follower 可能共存，不能完全实现 zone 级别或者 server 级别的读写隔离。

只读 zone

路由策略：

1. 设置 Primary Zone为 zone1,zone2;zone3，注意这里 zone1 和 zone2 之间是逗号，zone2 和 zone3 之间是分号，表示 zone1 和 zone2 会被设置为 primary zone，因此所有的 Leader 副本都被迁移到了 zone1 和 zone2 中，zone3 默认情况下都为 Follower 副本，那么 zone3 的副本就可以只给弱一致性读的分析计算类SQL提供服务。
2. 需要弱一致性读的 SQL，连接设置了弱读的 OBProxy；其余 SQL 连接正常 OBProxy。
3. 通过连接弱读的 OBProxy 的所有 SQL，会基于 LDC 路由策略，以及 FOLLOWER_FIRST 策略，自动访问本地的 Follower 副本。

优点：通过设置只读 zone 实现了 zone 级别隔离读写请求，隔离性相比备优先读的方案更高。

缺点：需要人工设置 Primary Zone，写流量会被集中打到 zone1 和 zone2。

适用场景：读写比较均衡，存在少量分析的场景。

只读副本

OceanBase 中除了默认的全功能性副本之外，还有一种只读型副本，只读型副本的名称为 READONLY，简称 R，区别于全功能副本，只读副本提供读的能力，不提供写的能力，只能作为日志流的 Follower 副本，不参与选举及日志的投票，不能当选为日志流的 Leader 副本。利用只读副本，我们就可以专门再配置一个zone，只放只读型副本，专门提供给OLAP分析计算类请求，并且只读副本出现故障，并不会影响主集群服务。

路由策略：

1. 主集群正常提供服务。
2. AP 类请求走独立的OBProxy，访问只读型副本。

优点：OLAP 与 OLTP 的请求可以做到完全隔离，互相不受任何影响。

缺点：需要为只读型副本提供更多资源。

适用场景：业务读请求远大于写请求，且大部分读请求对实时性要求不高，或者有大量的 AP 分析场景。

资源隔离能力

资源隔离并不是一个新概念，传统方式下不共享物理资源，可以理解为物理资源隔离方案。这种方案下不同租户或同一租户内 OLAP 和 OLTP 使用不同的副本，只读副本服务 OLAP，全功能副本服务 OLTP，两种业务不共享物理资源。如果不考虑成本，物理资源隔离无疑是更好的选择。

但现实中，大部分客户都会考虑硬件成本及其资源利用率。一方面，数据库硬件的购买和维护成本高昂，而所有硬件都需要定期换新；另一方面，数据库硬件在进行单项业务处理时，平均占用率水平较低。如果不能充分利用硬件资源，无疑会造成巨大的资源浪费。

而要充分利用硬件资源，不同租户或同一租户内 OLAP 和 OLTP 共享物理资源的逻辑资源隔离方案，自然脱颖而出。实际上，物理资源隔离和逻辑资源隔离不是二选一，而是互为补充的关系。理想的资源隔离方案是在完全物理隔离和逻辑隔离中找到平衡点，OceanBase 会给用户更多自由，帮助用户在面对各类场景下都可以做出最合适的选择。

资源隔离的种类

资源按照使用情况有刚性和弹性的区别，资源隔离的对象通常是弹性资源。刚性资源是保障程序完成功能必须的资源，一旦被占用，短时间内也难以释放。刚性资源的典型是磁盘空间和内存空间，连接数等，这类资源做好静态规划后，每个组可以使用的资源数量就会固定下来。弹性资源是指和程序功能无关，但是和性能有关的资源，比如 IOPS、CPU 时间、网络带宽等，这类资源一般可以抢占或被迅速释放，因此资源调度策略可以介入，实现闲时共享，忙时隔离。刚性资源比较重要的是内存和磁盘空间，弹性资源比较重要的是 CPU 时间，IOPS 和网络带宽，OceanBase 对以上资源均支持资源隔离。

除此以外，OceanBase 也提供了 SQL 级的资源隔离。通常适用的场景是，业务中存在多个账号，处理一个账号的一个订单时，会开启一个事务，然后执行一批与该账号相关的 SQL （通常是在 WHERE 条件中指定账号的值）。账号中同时存在大账号（数据量较大）和小账号（数据量较小），为了避免大账号把 CPU 资源用完导致小账号的订单无法得到处理，可以将处理不同订单的 SQL 绑定到不同的资源组，绑定后不同订单的 SQL 就会使用不同资源组的资源。

配置资源隔离的步骤

在 OceanBase 中进行 HTAP 资源隔离分为以下两个步骤：

• 定义资源组以及资源组的 QoS，对数据库来说租户就是最常见的资源组，另外 AP 和 TP 也可以是两个不同的资源组。
• 按定义好的 QoS 制定实施资源隔离的策略。

定义资源组

OceanBase 通过 unit config 描述租户的资源要求，比如创建一个租户之前要创建 resource pool（资源池） 、resource pool 的规格描述里就指定了各种资源的限制，详见：《租户的资源管理》。

create resource unit box1
max_cpu 4, max_memory 21474836480, max_iops 128, max_disk_size '5G',
max_session_num 64, min_cpu=4, min_memory=21474836480, min_iops=128; 

制定 OLTP 和 OLAP 资源规划

怎样管理租户内 OLTP 和 OLAP 的资源使用计划？OceanBase 参考了 Oracle 经典的 Resource Manager 系统包提供的管理接口。我们观察到，很多客户的跑批业务会安排在业务低峰期，如午夜或者凌晨，此时不用过于担心 OLAP 会影响到 OLTP 类业务，我们可以把集群绝大部分资源分配给 OLAP 类业务，给 OLTP 留下最小资源保证即可。在白天的业务高峰期，通过调整资源隔离方案，可以确保 OLTP 业务资源充足，同时按照预设资源满足基本的 AP 类查询。在 OceanBase 里，我们只需要预设两套资源管理计划，白天激活 DAYTIME 计划，夜间激活 NIGHT 计划，就可以实现满足基本的隔离需求的同时实现资源利用率的最大化。

比如我们可以通过 DBMS_RESOURCE_MANAGER 系统包来定义一个白天资源使用计划（resource plan)，并且制定了此计划下 OLTP (interactive_group）和 OLAP (batch_group) 的资源百分比。80% 的资源用于 TP，剩下 20% 资源用于 AP。

// 定义 DAYTIME 资源使用计划
DBMS_RESOURCE_MANAGER.CREATE_PLAN(
  PLAN    => 'DAYTIME',
  COMMENT => 'More resources for OLTP applications');
  
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
  PLAN             => 'DAYTIME',
  GROUP_OR_SUBPLAN => 'interactive_group',
  COMMENT          => 'OLTP group',
  MGMT_P1          => 80,
  UTILIZATION_LIMIT => 100);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
  PLAN             => 'DAYTIME',
  GROUP_OR_SUBPLAN => 'batch_group',
  COMMENT          => 'OLAP group',
  MGMT_P1          => 20,
  UTILIZATION_LIMIT => 20);

// 激活 DAYTIME 资源使用计划
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'DAYTIME';

按照类似的方式，我们可以定义夜晚的资源使用计划，并在业务低峰期激活它。假设这个业务白天的时候 TP 负载高，AP 集中在晚上。因此我们为白天和晚上设置两个不同的资源使用计划，白天的时候我们希望 80% 的资源用于 TP，剩下 20% 资源用于 AP，夜晚的时候希望 50% 的资源用于 TP，剩下 50% 资源用于 TP。

我们按照上面的描述进行从白天计划切换到夜晚计划的测试。从下图可以看出，切换为夜晚计划后，AP 的 CPU 资源占比变大后，AP 的 QPS 明显变高，而 TP 的 QPS 则会降低。下图中 AP 和 TP 的 QPS 发生变化的点（15:32:30）就是切换资源使用计划的时间。

看起来 TP 的 QPS 降低比较少，和 AP 的 QPS 变化比起来不明显。这里要注意，按理想情况来算，TP 的 QPS 变化本来就要比 AP 的变化小，因为 AP 是从 0.3 到 0.5，增加了 66.7%, TP 从 0.7 到 0.5，降了 28.5%。我们算一下，TP 下降了 24.7%(19000 到 14300)，和理论上的数值实际差距并不大。

配置 QoS 的资源隔离语义 min/max/weight

QoS（Quality of Service，服务质量）作为一种安全机制，可以在资源过载时保障关键进程的平稳运行。以下我们通过权重分配、资源上限和保留资源来描述 QoS。

在不同的时间段，业务的流量会有波动，所以 QoS 描述需要有一定的弹性，如果像公有云上的 ECS 一样指定一个固定的 CPU 核数和 IO 带宽，在业务高峰的时候容易出现数据库容量不够而导致的故障。

我们假设这样一个场景：总带宽是 100M，由租户 A 和租户 B 共同使用，基于资源的闲时共享和忙时隔离原则，我们尝试让租户 A 和租户 B 互不干扰地共同使用总带宽。

如果两者的重要程度不同，怎样保证重要进程的优先运行？此时我们可以每个租户的重要程度分配使用资源的比例，如给租户 A 和租户 B 分配 1:3 的权重比，当这两个租户都需要 CPU 时，A 将得到 1 份 CPU 时间，B 将得到 3 份 CPU 时间。这一操作我们称为权重分配，或<weight>。

有时候物理资源较为充裕，低权重租户可能会占用大量并不需要的资源，如何限制它的使用呢？我们可以在权重分配的基础上给不同的租户定义资源上限 <max>，如租户 A 按照权重比 1/4 时，能使用的带宽最多为 25M，当给它设置资源上限参数 20M 后，它最多能使用 20M 的带宽。

租户数量增减会引发权重配比改变，如何直观判断各租户最低资源需求的满足情况？此时我们可以给各租户设置保留资源 <min>，这样不仅可以保证所有租户基本功能的运行，也能直观清晰地描述 QoS。

资源隔离效果测试

接下来我们用单元测试对 OceanBase 的磁盘 IO 隔离能力进行了一项仿真实验：

• 设置 4 个租户，每个租户启动 64 个线程发送 IO 请求，IO 请求固定为 16KB 随机读。
• 租户 1、2、4 的负载持续 20 秒。
• 租户 3 的负载从第 10 秒开始，持续 10 秒。
• 实验磁盘 IOPS 上限大概在 6w，如果不加限制，任意一个租户单独都可以打满磁盘。

组户间的资源隔离

首先验证租户间磁盘 IO 隔离，各租户通过 DBMS_RESOURCE_MANAGER 进行如下配置：

实验结果如下表所示：

可以看到：

• 在第 10 秒磁盘已经打满时，新加入的租户 3 依然拥有 1 万 IOPS，因为其通过 MIN_IOPS 预留了 1 万；
• 租户 4 的 IOPS 没有超过 5 千，因为其通过 MAX_IOPS 设置了资源上限；
• 无论负载如何变化，租户 1 和租户 2 的 IOPS 比值大概为 2:1，正如权重比例要求。

组户内的资源隔离

接下来，我们将验证租户内负载的隔离。我们在租户 2 内设置了 4 个类别的负载，各负载的配置如下表所示：

实验结果如下表所示：

可以看到租户 2 的 4 类负载：

• B 负载稳定在近 2000 IOPS，哪怕其权重为 0，因为 B 负载通过 MIN_PERCENT 预留了租户 MIN_IOPS 97% 的资源；
• A 负载稳定在 1000 IOPS 左右，因为其 MAX_PERCENT 为 1，最多只能使用租户 MAX_IOPS 1% 的资源；
• C、D 负载的 IOPS 比例始终保持大约 2:1，因为其权重为 50:25。

从上述实验可以看出，OceanBase 在支持租户间资源隔离的同时，还支持租户内负载间的资源隔离，且都满足 QoS 的 reservation（MIN），limitation（MAX），proportion（WEIGHT）三种隔离语义。

大查询队列

对于数据库来说，相比于单条复杂大查询，让大量的 DML 和短查询尽快返回更有意义。为了避免一条大查询阻塞大量简单请求而导致系统吞吐量暴跌，当大查询和短请求同时争抢 CPU 时，OceanBase 会限制大查询的 CPU 使用。当一个线程执行的 SQL 查询耗时太长，这条查询就会被判定为大查询，一旦判定为大查询，就会进入大查询队列，然后执行大查询的线程会等在一个 Pthread Condition 上，为其它的租户工作线程让出 CPU 资源。

配置大查询的参数为 large_query_threshold，执行时间超过这个参数设置的阈值，则认为是大查询。

如果系统中同时运行着大查询和小查询，OceanBase 数据库会将一部分 CPU 资源分配给大查询，并通过配置参数 large_query_worker_percentage（默认值为 30%）来限制执行大查询最多可以使用的租户活跃工作线程数。

OceanBase 数据库通过限制大查询能使用的租户活跃工作线程数来约束大查询最多能够使用的 CPU 资源，以此来保证系统还会有足够的 CPU 资源来执行 OLTP（例如交易型的小事务）负载，通过这样的方式来保证对响应时间比较敏感的 OLTP 负载能够得到足够多的 CPU 资源尽快地被执行。