多租户和资源划分

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

    首先先简单介绍一下 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：

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

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

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

      1. create table UserTable
      2. (k1 int, k2 int)
      3. distributed by hash(k1) buckets 1
      4. properties(
      5.     "replication_allocation"
      6.     =
      7.     "tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1"
      8. )

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

      1.  ┌────────────────────────────────────────────────────┐
      2.  │                                                    │
      3.  │         ┌──────────────────┐  ┌──────────────────┐ │
      4.  │         │ host1            │  │ host2            │ │
      5.  │         │  ┌─────────────┐ │  │                  │ │
      6.  │ group_a │  │   replica1  │ │  │                  │ │
      7.  │         │  └─────────────┘ │  │                  │ │
      8.  │         │                  │  │                  │ │
      9.  │         └──────────────────┘  └──────────────────┘ │
      10.  ├────────────────────────────────────────────────────┤
      11.  ├────────────────────────────────────────────────────┤
      12.  │                                                    │
      13.  │         ┌──────────────────┐  ┌──────────────────┐ │
      15.  │         │                  │  │  ┌─────────────┐ │ │
      16.  │ group_b │                  │  │  │   replica2  │ │ │
      17.  │         │                  │  │  └─────────────┘ │ │
      18.  │         │                  │  │                  │ │
      19.  │         └──────────────────┘  └──────────────────┘ │
      20.  │                                                    │
      21.  ├────────────────────────────────────────────────────┤
      22.  ├────────────────────────────────────────────────────┤
      23.  │                                                    │
      24.  │         ┌──────────────────┐  ┌──────────────────┐ │
      25.  │         │ host5            │  │ host6            │ │
      26.  │         │                  │  │  ┌─────────────┐ │ │
      27.  │ group_c │                  │  │  │   replica3  │ │ │
      28.  │         │                  │  │  └─────────────┘ │ │
      29.  │         │                  │  │                  │ │
      30.  │         └──────────────────┘  └──────────────────┘ │
      31.  │                                                    │
      32.  └────────────────────────────────────────────────────┘

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

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

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

    1. 内存限制

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

      1. // 设置会话变量 exec_mem_limit。则之后该会话内（连接内）的所有查询都使用这个内存限制。
      2. set exec_mem_limit=1G;
      3. // 设置全局变量 exec_mem_limit。则之后所有新会话（新连接）的所有查询都使用这个内存限制。
      4. set global exec_mem_limit=1G;
      5. // 在 SQL 中设置变量 exec_mem_limit。则该变量仅影响这个 SQL。

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

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

      1. // 设置会话变量 cpu_resource_limit。则之后该会话内（连接内）的所有查询都使用这个CPU限制。
      2. set cpu_resource_limit = 2
      3. // 设置用户的属性 cpu_resource_limit，则所有该用户的查询情况都使用这个CPU限制。该属性的优先级高于会话变量 cpu_resource_limit
      4. 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 前，先关闭数据修复与均衡逻辑，以保证我们在规划资源时，不会有副本重分布的操作。

    2. 设置 Tag 和表副本分布

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

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

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

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

      1. ADMIN SET FRONTEND CONFIG ("disable_balance" = "false");

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

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

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