Question

Doris 的多租户和资源隔离方案，主要目的是为了多用户在同一 Doris 集群内进行数据操作时，减少相互之间的干扰，能够将集群资源更合理的分配给各用户。

该方案主要分为两部分，一是集群内节点级别的资源组划分，二是针对单个查询的资源限制。

Doris 中的节点

首先先简单介绍一下 Doris 的节点组成。一个 Doris 集群中有两类节点：Frontend(FE) 和 Backend(BE)。

FE 主要负责元数据管理、集群管理、用户请求的接入和查询计划的解析等工作。

BE 主要负责数据存储、查询计划的执行等工作。

FE 不参与用户数据的处理计算等工作，因此是一个资源消耗较低的节点。而 BE 负责所有的数据计算、任务处理，属于资源消耗型的节点。因此，本文所介绍的资源划分及资源限制方案，都是针对 BE 节点的。FE 节点因为资源消耗相对较低，并且还可以横向扩展，因此通常无需做资源上的隔离和限制，FE 节点由所有用户共享即可。

节点资源划分

节点资源划分，是指将一个 Doris 集群内的 BE 节点设置标签（Tag），标签相同的 BE 节点组成一个资源组（Resource Group）。资源组可以看作是数据存储和计算的一个管理单元。下面我们通过一个具体示例，来介绍资源组的使用方式。

1. 为 BE 节点设置标签

   假设当前 Doris 集群有 6 个 BE 节点。分别为 host[1-6]。在初始情况下，所有节点都属于一个默认资源组（Default）。

   我们可以使用以下命令将这6个节点划分成3个资源组：group_a、group_b、group_c：

    alter system modify backend "host1:9050" set ("tag.location": "group_a");
    alter system modify backend "host2:9050" set ("tag.location": "group_a");
    alter system modify backend "host3:9050" set ("tag.location": "group_b");
    alter system modify backend "host4:9050" set ("tag.location": "group_b");
    alter system modify backend "host5:9050" set ("tag.location": "group_c");
    alter system modify backend "host6:9050" set ("tag.location": "group_c");
   

   这里我们将 host[1-2] 组成资源组 group_a，host[3-4] 组成资源组 group_b，host[5-6] 组成资源组 group_c。

   注：一个 BE 只支持设置一个 Tag。

2. 按照资源组分配数据分布

   资源组划分好后。我们可以将用户数据的不同副本分布在不同资源组内。假设一张用户表 UserTable。我们希望在3个资源组内各存放一个副本，则可以通过如下建表语句实现：

    create table UserTable
    (k1 int, k2 int)
    distributed by hash(k1) buckets 1
    properties(
        "replica_allocation"
        =
        "tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1"
    )
   

   这样一来，表 UserTable 中的数据，将会以3副本的形式，分别存储在资源组 group_a、group_b、group_c所在的节点中。

   下图展示了当前的节点划分和数据分布：

     ┌────────────────────────────────────────────────────┐
     │                                                    │
     │         ┌──────────────────┐  ┌──────────────────┐ │
     │         │ host1            │  │ host2            │ │
     │         │  ┌─────────────┐ │  │                  │ │
     │ group_a │  │   replica1  │ │  │                  │ │
     │         │  └─────────────┘ │  │                  │ │
     │         │                  │  │                  │ │
     │         └──────────────────┘  └──────────────────┘ │
     │                                                    │
     ├────────────────────────────────────────────────────┤
     ├────────────────────────────────────────────────────┤
     │                                                    │
     │         ┌──────────────────┐  ┌──────────────────┐ │
     │         │ host3            │  │ host4            │ │
     │         │                  │  │  ┌─────────────┐ │ │
     │ group_b │                  │  │  │   replica2  │ │ │
     │         │                  │  │  └─────────────┘ │ │
     │         │                  │  │                  │ │
     │         └──────────────────┘  └──────────────────┘ │
     │                                                    │
     ├────────────────────────────────────────────────────┤
     ├────────────────────────────────────────────────────┤
     │                                                    │
     │         ┌──────────────────┐  ┌──────────────────┐ │
     │         │ host5            │  │ host6            │ │
     │         │                  │  │  ┌─────────────┐ │ │
     │ group_c │                  │  │  │   replica3  │ │ │
     │         │                  │  │  └─────────────┘ │ │
     │         │                  │  │                  │ │
     │         └──────────────────┘  └──────────────────┘ │
     │                                                    │
     └────────────────────────────────────────────────────┘
   

3. 使用不同资源组进行数据查询

   在前两步执行完成后，我们就可以通过设置用户的资源使用权限，来限制某一用户的查询，只能使用指定资源组中的节点来执行。

   比如我们可以通过以下语句，限制 user1 只能使用 group_a 资源组中的节点进行数据查询，user2 只能使用 group_b 资源组，而 user3 可以同时使用 3 个资源组：

    set property for 'user1' 'resource_tags.location' : 'group_a';
    set property for 'user2' 'resource_tags.location' : 'group_b';
    set property for 'user3' 'resource_tags.location' : 'group_a, group_b, group_c';
   

   设置完成后，user1 在发起对 UserTable 表的查询时，只会访问 group_a 资源组内节点上的数据副本，并且查询仅会使用 group_a 资源组内的节点计算资源。而 user3 的查询可以使用任意资源组内的副本和计算资源。

   这样，我们通过对节点的划分，以及对用户的资源使用限制，实现了不同用户查询上的物理资源隔离。更进一步，我们可以给不同的业务部门创建不同的用户，并限制每个用户使用不同的资源组。以避免不同业务部分之间使用资源干扰。比如集群内有一张业务表需要共享给所有9个业务部门使用，但是希望能够尽量避免不同部门之间的资源抢占。则我们可以为这张表创建3个副本，分别存储在3个资源组中。接下来，我们为9个业务部门创建9个用户，每3个用户限制使用一个资源组。这样，资源的竞争程度就由9降低到了3。

   另一方面，针对在线和离线任务的隔离。我们可以利用资源组的方式实现。比如我们可以将节点划分为 Online 和 Offline 两个资源组。表数据依然以3副本的方式存储，其中 2 个副本存放在 Online 资源组，1 个副本存放在 Offline 资源组。Online 资源组主要用于高并发低延迟的在线数据服务，而一些大查询或离线ETL操作，则可以使用 Offline 资源组中的节点执行。从而实现在统一集群内同时提供在线和离线服务的能力。

单查询资源限制

前面提到的资源组方法是节点级别的资源隔离和限制。而在资源组内，依然可能发生资源抢占问题。比如前文提到的将3个业务部门安排在同一资源组内。虽然降低了资源竞争程度，但是这3各部门的查询依然有可能相互影响。

因此，除了资源组方案外，Doris 还提供了对单查询的资源限制功能。

目前 Doris 对单查询的资源限制主要分为 CPU 和 内存限制两方面。

1. 内存限制

   Doris 可以限制一个查询被允许使用的最大内存开销。以保证集群的内存资源不会被某一个查询全部占用。我们可以通过以下方式设置内存限制：

    // 设置会话变量 exec_mem_limit。则之后该会话内（连接内）的所有查询都使用这个内存限制。
    set exec_mem_limit=1G;
    // 设置全局变量 exec_mem_limit。则之后所有新会话（新连接）的所有查询都使用这个内存限制。
    set global exec_mem_limit=1G;
    // 在 SQL 中设置变量 exec_mem_limit。则该变量仅影响这个 SQL。
    select /*+ SET_VAR(exec_mem_limit=1G) */ id, name from tbl where xxx;
   

   因为 Doris 的查询引擎是基于全内存的 MPP 查询框架。因此当一个查询的内存使用超过限制后，查询会被终止。因此，当一个查询无法在合理的内存限制下运行时，我们就需要通过一些 SQL 优化手段，或者集群扩容的方式来解决了。

2. CPU 限制

   用户可以通过以下方式限制查询的 CPU 资源：

    // 设置会话变量 cpu_resource_limit。则之后该会话内（连接内）的所有查询都使用这个CPU限制。
    set cpu_resource_limit = 2
    // 设置用户的属性 cpu_resource_limit，则所有该用户的查询情况都使用这个CPU限制。该属性的优先级高于会话变量 cpu_resource_limit
    set property for 'user1' 'cpu_resource_limit' = '3';
   

   cpu_resource_limit 的取值是一个相对值，取值越大则能够使用的 CPU 资源越多。但一个查询能使用的CPU上限也取决于表的分区分桶数。原则上，一个查询的最大 CPU 使用量和查询涉及到的 tablet 数量正相关。极端情况下，假设一个查询仅涉及到一个 tablet，则即使 cpu_resource_limit 设置一个较大值，也仅能使用 1 个 CPU 资源。

通过内存和CPU的资源限制。我们可以在一个资源组内，将用户的查询进行更细粒度的资源划分。比如我们可以让部分时效性要求不高，但是计算量很大的离线任务使用更少的CPU资源和更多的内存资源。而部分延迟敏感的在线任务，使用更多的CPU资源以及合理的内存资源。

最佳实践和向前兼容

Tag 划分和 CPU 限制是 0.15 版本中的新功能。为了保证可以从老版本平滑升级，Doris 做了如下的向前兼容：

1. 每个 BE 节点会有一个默认的 Tag："tag.location": "default"。
2. 通过 alter system add backend 语句新增的 BE 节点也会默认设置 Tag："tag.location": "default"。
3. 所有表的副本分布默认修改为："tag.location.default:xx。其中 xx 为原副本数量。
4. 用户依然可以通过 "replication_num" = "xx" 在建表语句中指定副本数，这种属性将会自动转换成："tag.location.default:xx。从而保证无需修改原建表语句。
5. 默认情况下，单查询的内存限制为单节点2GB，CPU资源无限制，和原有行为保持一致。且用户的 resource_tags.location 属性为空，即默认情况下，用户可以访问任意 Tag 的 BE，和原有行为保持一致。

这里我们给出一个从原集群升级到 0.15 版本后，开始使用资源划分功能的步骤示例：

1. 关闭数据修复与均衡逻辑

   因为升级后，BE的默认Tag为 "tag.location": "default"，而表的默认副本分布为："tag.location.default:xx。所以如果直接修改 BE 的 Tag，系统会自动检测到副本分布的变化，从而开始数据重分布。这可能会占用部分系统资源。所以我们可以在修改 Tag 前，先关闭数据修复与均衡逻辑，以保证我们在规划资源时，不会有副本重分布的操作。

    ADMIN SET FRONTEND CONFIG ("disable_balance" = "true");
    ADMIN SET FRONTEND CONFIG ("disable_tablet_scheduler" = "true");
   

2. 设置 Tag 和表副本分布

   接下来可以通过 alter system modify backend 语句进行 BE 的 Tag 设置。以及通过 alter table 语句修改表的副本分布策略。示例如下：

    alter system modify backend "host1:9050, 1212:9050" set ("tag.location": "group_a");
    alter table my_table modify partition p1 set ("replica_allocation" = "tag.location.group_a:2");
   

3. 开启数据修复与均衡逻辑

   在 Tag 和副本分布都设置完毕后，我们可以开启数据修复与均衡逻辑来触发数据的重分布了。

    ADMIN SET FRONTEND CONFIG ("disable_balance" = "false");
    ADMIN SET FRONTEND CONFIG ("disable_tablet_scheduler" = "false");
   

   该过程根据涉及到的数据量会持续一段时间。并且会导致部分 colocation table 无法进行 colocation 规划（因为副本在迁移中）。可以通过 show proc "/cluster_balance/ 来查看进度。也可以通过 show proc "/statistic" 中 UnhealthyTabletNum 的数量来判断进度。当 UnhealthyTabletNum 降为 0 时，则代表数据重分布完毕。

4. 设置用户的资源标签权限。

   等数据重分布完毕后。我们就可以开始设置用户的资源标签权限了。因为默认情况下，用户的 resource_tags.location 属性为空，即可以访问任意 Tag 的 BE。所以在前面步骤中，不会影响到已有用户的正常查询。当 resource_tags.location 属性非空时，用户将被限制访问指定 Tag 的 BE。

通过以上4步，我们可以较为平滑的在原有集群升级后，使用资源划分功能。