现如今企业的数据查询需求在不断增多，在共享同一集群时，往往需要同时面对多个业务线或多种分析负载的并发查询。在有限的资源条件下，查询任务间的资源抢占将导致性能下降甚至集群不稳定，因此负载管理的重要性不言而喻。
从业务场景出发，用户负载管理的需求主要来自以下几方面：
在早期版本中，Apache Doris 推出了基于资源标签（Resource Tag）的隔离方案，包括集群内节点级别的资源组划分以及针对单个查询的资源限制，实现了不同用户间的资源物理隔离。而为给用户提供更完善的负载管理方案，Apache Doris自 2.0 版本起，推出了基于 Workload Group 的管理方案， 实现了 CPU 资源的软限，为用户提供较高的资源利用率。 在新发布的 2.1 版本基于 Linux 内核提供的 CGroup 技术，进一步地 实现了对 CPU 资源的硬限，为用户提供更好的查询稳定性。
基于 Resource Tag 的物理隔离方案
在 Apache Doris 中有 FE 和 BE 两类节点，FE 节点负责元数据存储、集群管理、用户请求接入以及查询计划解析等，BE 节点则负责数据的存储和计算。在查询执行过程中涉及资源消耗的主要是 BE 节点，因此 Apache Doris 负载隔离方案都是面向 BE 节点设计。
在 Resource Tag 资源物理隔离方案中，可以对同一个集群内的 BE 节点设置标签，标签相同的 BE 节点会组成一个资源组（Resource Group），可将资源组看作数据存储和计算的一个单元。数据入库时会按照资源组配置将数据的副本写入到不同的资源组中，查询时按照资源组的划分使用对应资源组上的计算资源进行计算。
我们以常见的读写分析场景为例，假设集群中有 3 台 BE，具体使用步骤如下：
Resource Tag 还可以实现多租户的功能。例如有两个用户 UserA 和 UserB，期望创建各自独立的租户以避免相互影响，那么可以把 UserA 的计算和存储资源绑定到名为 UserA 的 Tag 上，把 UserB 的计算和存储资源绑定到名为 UserB 的 Tag 上，那么两个用户在 BE 侧就实现了租户间的资源隔离。
Resource Tag 本质是通过对 BE 节点的分组实现了资源隔离，这个方案的优点是：
基于这个技术，有的用户将不同的资源组放置到不同的物理机房内，实现同城 2 个机房的双活。
但是也存在一定的局限性：
基于 Workload Group 的负载管理方案
为解决上述问题，Apache Doris 推出了基于 Workload Group 的管理方案，支持了更细粒度的资源隔离机制——进程内的资源隔离，这意味着同一个 BE 内多个 Query 间也可以实现一定程度上的隔离，有效避免了进程内的资源竞争，提高资源的利用率。
Workload Group 是通过对工作负载进行分组管理，实现对内存和 CPU 资源的精细化管控。通过将用户执行的 Query 与 Workload Group 相关联，限制单个 Query 在单个 BE 节点上的 CPU 和内存资源的百分比。同时可以配置开启内存资源限制，集群资源紧张时自动终止组内高内存占用查询以缓解压力。资源空闲时，多个 Workload Group 共享空闲资源并自动突破限制，确保查询稳定执行。
CPU 资源的限制可细分为软限和硬限，CPU 软限具备资源利用率更高的特点，允许在资源空闲时候灵活分配资源；而 CPU 硬限则更侧重于性能稳定性的保障，确保各 Group 之间不会因负载变化而相互干扰。
Workload Group 与 Resource Tag 的方案主要有以下不同：
CPU 软限制
CPU 优先级主要通过参数体现，可以将它类比为权重的概念。在相同的时间周期内，权重越高的 Group 可以获得更多的 CPU 时间。
以 Group A 和 Group B 为例，若配置 Group A 的为 1、Group B 的为 9，给定 10s 的时间周期。当两者负载均饱和时，权重更高的Group B 可以获得 CPU 的时间为 9s（所有资源的 90%），Group A 可获得 CPU 时间为 1s（所有资源的 10%）。而在实际使用中，并非所有业务都是满负载运行，若 Group B 的负载较低或无负载，那么 Group A 可以独占 10s 的 CPU 时间。这种方式可以提供更高的资源分配灵活性，从而提高集群 CPU 资源的整体利用率。
CPU 硬限制
使用 CPU 软限时，如果系统负载较高或 CPU 资源紧张时，可能引起查询性能的波动。为满足更用户对查询性能稳定的高要求， Apache Doris 在最新的 2.1 版本中，实现了 Workload Group 的 CPU 硬限制——无论当前物理机整体 CPU 是否空闲，配置了硬限的 Group 最大 CPU 用量不能超过预先配置的限制值。
以 Group A 和 Group B 为例，若配置 Group A 的
cpu_hard_limit=10%
，Group B 的
cpu_hard_limit=90%
。当两者单机 CPU 资源均达到饱和时， Group A 的 CPU 利用率为 10%， Group B 的 CPU 利用率为 90%，这与 CPU 软限是一样的。但是当 Group B 的负载降低或没有负载时，即便 Group A 增加查询负载，其最大 CPU 利用率仍被严格限制在 10%，无法获得更多的资源。虽然这种方式牺牲了资源分配的弹性，但也确保了查询性能的稳定性。
内存资源限制
内存资源限制主要通过参数
memory_limit
来限制（设置可以使用 BE 内存的百分比）。不仅可以设置预配置内存用量，还影响内存过度分配（Overcommit）之后的归还优先级。
在初始状态下，高优先级的资源组会被配置更多的内存、低优先级的资源组被分配较少的内存。为了提升内存的利用率，可以通过
enable_memory_overcommit
开启资源组的内存软限制，如果系统有空闲内存资源时可以超限使用。
为了保证系统稳定运行，当系统整体内存资源不足时，系统将会优先取消占用内存较大的任务，以回收超额分配（Overcommit）的内存资源。在此过程中，系统会尽量保留高优先级的资源组内存资源，低优先级资源组超额内存将被更快收回。
查询排队
当业务负载超过系统可承载上限时，继续提交新的查询不仅无法有效执行，还会对运行中的查询造成影响。为避免该问题出现，Workload Group 支持查询排队功能。当查询达到预设的最大并发时，新提交计划会进入排队逻辑，当队列已满或等待超时，查询会被拒绝，以此来缓解高负载下系统的压力。
查询排队功能主要有三个属性：
Workload Group使用测试
接下来，我们对 Workload Group 的 CPU 软限制和硬限制进行详细测试，以便为用户清晰呈现这两种限制在相同硬件条件下的负载管理效果与性能表现。
CPU 软限测试
启动两个客户端（1、2），分别在未使用/使用 CPU 软限的前提下，测试 CPU 软限制对负载管理的效果。需要注意的是，在该测试中 Page Cache 会影响测试结果，需要关闭 Page Cache 才会达到理想的测试效果。
通过对比分析两次测试中的客户端的吞吐量数据，我们可以得出以下结论：
CPU 硬限测试
由上文介绍可知，CPU 硬限制在负载较高时，可以保证很好的隔离性。因此我们使用硬限限制 CPU 使用率为 50%（
cpu_hard_limit=50%
），并使用同一客户端分别在并发数为 1、2、4 时（模拟不同负载）下执行 q23 查询测试，每次测试运行时间为 5 分钟。
从上方测试结果可知，随着查询并发数的增加，CPU 的利用率的始终稳定在 800% 上下（在一个 16 核的机器上，800% 的意味着使用 8 个核， 实际的 CPU 利用率 为 50% ）。由于 CPU 资源被硬限，因此在并发增加时，tp99 延时增加是符合预期的。
模拟生产环境测试
在实际生产环境中，用户往往更关注查询的延迟性能而非单纯的吞吐量。为了更贴近实际应用场景并准确评估性能，我们选取了一系列延迟约为 1 秒的查询 SQL（包括 CKBench 的 q15、q17、q23 和 TPCH 的 q3、q7、q19），构成一个 SQL 集合。这些查询涵盖了单表聚合和 Join 计算等多种特性，使用的 TPCH 数据集大小为 100G。
我们设计了两组测试，分别模拟了未使用 Workload Group 和使用 Workload Group 的场景。在客户端 1 和客户端 2 上进行了四次测试，重点关注 tp90 和 tp99 的延迟情况。
通过观察上表 4 次测试中查询延迟，可得出以下结论：
结束语
目前 Resource Tag 和 Workload Group 功能已经在多个社区用户的生产业务中上线并得到大规模验证，推荐有资源隔离需求的用户使用。
无论是 Resource Tag 或是 Workload Group，其目标都在于 在资源隔离的独立性和资源的利用率二者之间进行平衡 ，前者采取了更彻底的隔离方案，而后者在保证隔离性的同时实现了资源的充分利用，并通过查询队列和任务排队机制进一步保证了在高工作负载场景下的系统稳定性。
在资源隔离的实际使用过程中，我们建议两种方案可以根据业务场景结合起来应用：
在后续的功能完善上，我们还有很多规划：
致谢
Workload Group 功能是开源社区合作开发的项目，感谢以下同学的贡献：罗甑林（luozenglin），刘立家（liutang123），赵立伟（levy5307）
