Resource Group的问题

Question

参照

官网文档： https://doris.apache.org/zh-CN/docs/admin-manual/resource-admin/multi-tenant

业务操作过程

本次的业务目的是将服务器分成两个组，一组用来离线计算，一组用来提供在线服务，原始的tag是default, 同样的,所有的表初始参数tag也是default.

对服务器进行分组

alter system modify backend "host_01:9050" set ("tag.location" = "group_interface");
alter system modify backend "host_02:9050" set ("tag.location" = "group_interface");
alter system modify backend "host_03:9050" set ("tag.location" = "group_interface");
alter system modify backend "host_04:9050" set ("tag.location" = "group_etl");
alter system modify backend "host_05:9050" set ("tag.location" = "group_etl");
alter system modify backend "host_06:9050" set ("tag.location" = "group_etl");

业务中断

查询中断

1：没有对用户分配资源组，执行分配资源

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';

2：需要重连jdbc.
以上两步执行完成后，查询恢复了。

写入中断

1：在jdbc重连之前，好像是所有的表都会写入中断（需要验证）。
2：自动分区的表因为有BUG（后续流程会有用例），无法修改现有表的tag, 导致写入一直失败，解决办法是重建表。拉数据到新表后重命名。

总结

把所有的服务器都打tag之后，导致原有的default tag没有了。然后就造成了业务写入和查询的中断问题。

#####################################################################

非自动分区表

DDL

-- 这是一个非自动分区表
CREATE TABLE `ods_sms_detail_all_dt_temp_02` (
  `id` VARCHAR(192) NULL COMMENT '',
  `create_date` DATE NULL COMMENT '',
  `seq_index` INT NULL COMMENT '',
  `template_code` VARCHAR(96) NULL COMMENT '',
  `app_code` VARCHAR(96) NULL COMMENT '',
  `app_sms_id` VARCHAR(192) NULL COMMENT '',
  `seq_no` INT NULL COMMENT '',
  `org_code` VARCHAR(60) NULL COMMENT '',
  `sms_status` INT NULL COMMENT '',
  `error_code` INT NULL COMMENT '',
  `error_msg` VARCHAR(120) NULL COMMENT '',
  `detail_error_code` VARCHAR(60) NULL COMMENT '',
  `detail_error_msg` VARCHAR(120) NULL COMMENT '',
  `calling_no` VARCHAR(300) NULL COMMENT '',
  `sp_code` VARCHAR(96) NULL COMMENT '',
  `sp_service_code` VARCHAR(96) NULL COMMENT '',
  `send_time` DATETIME NULL COMMENT '',
  `sp_notify_time` DATETIME NULL COMMENT '',
  `app_notify_status` VARCHAR(60) NULL COMMENT '',
  `app_notify_time` DATETIME NULL COMMENT '',
  `create_time` DATETIME NULL COMMENT '',
  `update_time` DATETIME NULL COMMENT '',
  `sub_code` VARCHAR(60) NULL COMMENT '',
  `ext_col` VARCHAR(192) NULL COMMENT ''
) ENGINE=OLAP
UNIQUE KEY(`id`, `create_date`, `seq_index`)
COMMENT ''
PARTITION BY RANGE(`create_date`)()
DISTRIBUTED BY HASH(`id`, `create_date`, `seq_index`) BUCKETS AUTO
PROPERTIES (
	"replication_allocation" = "tag.location.default: 2",
	"min_load_replica_num" = "-1",
	"is_being_synced" = "false",
	"dynamic_partition.enable" = "true",
	"dynamic_partition.time_unit" = "DAY",
	"dynamic_partition.time_zone" = "Asia/Shanghai",
	"dynamic_partition.start" = "-365",
	"dynamic_partition.end" = "3",
	"dynamic_partition.prefix" = "p",
	"dynamic_partition.replication_allocation" = "tag.location.default: 2",
	"dynamic_partition.buckets" = "10",
	"dynamic_partition.create_history_partition" = "true",
	"dynamic_partition.history_partition_num" = "-1",
	"dynamic_partition.hot_partition_num" = "0",
	"dynamic_partition.reserved_history_periods" = "NULL",
	"dynamic_partition.storage_policy" = "",
	"storage_format" = "V2",
	"inverted_index_storage_format" = "DEFAULT",
	"enable_unique_key_merge_on_write" = "false",
	"light_schema_change" = "true",
	"disable_auto_compaction" = "false",
	"enable_single_replica_compaction" = "false",
	"group_commit_interval_ms" = "10000",
	"group_commit_data_bytes" = "134217728"
);

操作

修改表Resource Group Tag,预期想让表分布在指定的服务器组中。

--  ############################语法1 ######################################### 
alter table ods_sms_detail_all_dt_temp_02 set ("dynamic_partition.replication_allocation" = "tag.location.group_interface:2")

-- 该语法可以执行成功。 查看表的DDL语句
SHOW CREATE TABLE ods_sms_detail_all_dt_temp_02;

-- tag相关表参数结果如下
PROPERTIES (
-- #####replication_allocation参数还是原来的default tag
"replication_allocation" = "tag.location.default: 2",
-- ##### dynamic_partition.replication_allocation参数的tag变成了预期的修改后的。
"dynamic_partition.replication_allocation" = "tag.location.group_interface: 2",
);

-- 查看数据分布，发现历史的数据没有按设置后的重分布到group_interface
show tablets from ods_sms_detail_all_dt_temp_02 

-- 但最新分区的数据按规则落到了指定的group tag对应的服务器
SHOW REPLICA DISTRIBUTION FROM ods_sms_detail_all_dt_temp_02 PARTITION(p20241213);

-- 希望历史数据也可以重分布到指定的tag






-- ############################语法2 ######################################### 
-- 直接修改"replication_allocation属性， 会报错。 
alter table ods_sms_detail_all_dt_temp_02 set ("replication_allocation" = "tag.location.group_interface: 2")




  
  
-- ############################语法3 ######################################### 
-- 这两个都会执行成功，但没有任何效果。 ddl语句不会有任何变动。
-- replication_allocation和dynamic_partition.replication_allocation都不会变动。
Alter table ods_sms_detail_all_dt_temp_02 modify partition(*) set ("replication_allocation"="tag.location.group_interface: 2");

Alter table ods_sms_detail_all_dt_temp_02 modify partition(*) set ("dynamic_partition.replication_allocation"="tag.location.group_interface: 2");




-- 总结
-- 1： 只有alter table ods_sms_detail_all_dt_temp_02 set ("dynamic_partition.replication_allocation" = "tag.location.group_interface:2")有效，且只能影响dynamic_partition.replication_allocation表参数。
-- 2： 就算dynamic_partition.replication_allocation修改成功了之后，历史数据也不会重新分布。但最新分区的数据，会按照最新的group tag分。 
-- 3： 希望历史数据也可以实现业务无感的重分布。

自动分区表

DDL

-- 这是一个自动分区的表
CREATE TABLE `ods_sms_detail_all_dt_temp_03` (
  `id` VARCHAR(192) NULL COMMENT '',
  `create_date` DATE NOT NULL COMMENT '',
  `seq_index` INT NULL COMMENT '',
  `template_code` VARCHAR(96) NULL COMMENT '',
  `app_code` VARCHAR(96) NULL COMMENT '',
  `app_sms_id` VARCHAR(192) NULL COMMENT '',
  `seq_no` INT NULL COMMENT '',
  `org_code` VARCHAR(60) NULL COMMENT '',
  `sms_status` INT NULL COMMENT '',
  `error_code` INT NULL COMMENT '',
  `error_msg` VARCHAR(120) NULL COMMENT '',
  `detail_error_code` VARCHAR(60) NULL COMMENT '',
  `detail_error_msg` VARCHAR(120) NULL COMMENT '',
  `calling_no` VARCHAR(300) NULL COMMENT '',
  `sp_code` VARCHAR(96) NULL COMMENT '',
  `sp_service_code` VARCHAR(96) NULL COMMENT '',
  `send_time` DATETIME NULL COMMENT '',
  `sp_notify_time` DATETIME NULL COMMENT '',
  `app_notify_status` VARCHAR(60) NULL COMMENT '',
  `app_notify_time` DATETIME NULL COMMENT '',
  `create_time` DATETIME NULL COMMENT '',
  `update_time` DATETIME NULL COMMENT '',
  `sub_code` VARCHAR(60) NULL COMMENT '',
  `ext_col` VARCHAR(192) NULL COMMENT ''
) ENGINE=OLAP
UNIQUE KEY(`id`, `create_date`, `seq_index`)
AUTO PARTITION BY RANGE (create_date)()
DISTRIBUTED BY HASH(`id`, `create_date`, `seq_index`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 2",
"min_load_replica_num" = "-1",
"is_being_synced" = "false",
"storage_medium" = "hdd",
"storage_format" = "V2",
"inverted_index_storage_format" = "V1",
"enable_unique_key_merge_on_write" = "false",
"light_schema_change" = "true",
"disable_auto_compaction" = "false",
"enable_single_replica_compaction" = "false",
"group_commit_interval_ms" = "10000",
"group_commit_data_bytes" = "134217728"
);

操作

以下的4种语法操作都会报错，也就是自动分区的情况下，不能进行表 group tag的修改。这是一个bug

alter table ods_sms_detail_all_dt_temp_03 set ("dynamic_partition.replication_allocation" = "tag.location.group_interface:2")
alter table ods_sms_detail_all_dt_temp_03 set ("replication_allocation" = "tag.location.group_interface: 2")
alter table ods_sms_detail_all_dt_temp_03 modify partition(*) set ("replication_allocation"="tag.location.group_interface: 2");
alter table ods_sms_detail_all_dt_temp_03 modify partition(*) set ("dynamic_partition.replication_allocation"="tag.location.group_interface: 2");

非分区表

DDL

CREATE TABLE `ods_sms_detail_all_dt_temp_04` (
  `id` VARCHAR(192) NULL COMMENT '',
  `create_date` DATE NOT NULL COMMENT '',
  `seq_index` INT NULL COMMENT '',
  `template_code` VARCHAR(96) NULL COMMENT '',
  `app_code` VARCHAR(96) NULL COMMENT '',
  `app_sms_id` VARCHAR(192) NULL COMMENT '',
  `seq_no` INT NULL COMMENT '',
  `org_code` VARCHAR(60) NULL COMMENT '',
  `sms_status` INT NULL COMMENT '',
  `error_code` INT NULL COMMENT '',
  `error_msg` VARCHAR(120) NULL COMMENT '',
  `detail_error_code` VARCHAR(60) NULL COMMENT '',
  `detail_error_msg` VARCHAR(120) NULL COMMENT '',
  `calling_no` VARCHAR(300) NULL COMMENT '',
  `sp_code` VARCHAR(96) NULL COMMENT '',
  `sp_service_code` VARCHAR(96) NULL COMMENT '',
  `send_time` DATETIME NULL COMMENT '',
  `sp_notify_time` DATETIME NULL COMMENT '',
  `app_notify_status` VARCHAR(60) NULL COMMENT '',
  `app_notify_time` DATETIME NULL COMMENT '',
  `create_time` DATETIME NULL COMMENT '',
  `update_time` DATETIME NULL COMMENT '',
  `sub_code` VARCHAR(60) NULL COMMENT '',
  `ext_col` VARCHAR(192) NULL COMMENT ''
) ENGINE=OLAP
UNIQUE KEY(`id`, `create_date`, `seq_index`)
DISTRIBUTED BY HASH(`id`, `create_date`, `seq_index`) BUCKETS 1
PROPERTIES (
	"replication_allocation" = "tag.location.default: 3",
	"min_load_replica_num" = "-1",
	"is_being_synced" = "false",
	"storage_medium" = "hdd",
	"storage_format" = "V2",
	"inverted_index_storage_format" = "DEFAULT",
	"enable_unique_key_merge_on_write" = "true",
	"light_schema_change" = "true",
	"disable_auto_compaction" = "false",
	"enable_single_replica_compaction" = "false",
	"group_commit_interval_ms" = "10000",
	"group_commit_data_bytes" = "134217728",
	"enable_mow_light_delete" = "false"
);

操作

-- 非分区表的语法简单，并可以执行成功
alter table ods_sms_detail_all_dt_temp_04  set ("replication_allocation" = "tag.location.group_interface:2");


-- 但是没有效果
show tablets from ods_sms_detail_all_dt_temp_04 
-- 数据没有重分布到指定的tag

总结

因为非分区表的tablet数据分布没有最新数据的概念，可以认为没有起到作用。

最终总结

1：一个BE标签只能有一个group tag感觉是不合理的。假如说一个BE两个标签，可以在更改tag的时候保留default tag, 在轮流改表tag的过程中，也有个缓冲空间，不至于造成业务中断。
2：自动分区表完全没有考虑修改tag的情况。这是一个明确的bug.
3: 建议在进行BE设置tag时做个校验，对数据库中全部表的tag及副本做个校验，如果变动后的结果会导致现有表数据【无家（tag）可归】，可以中断这个变更操作，并给出明确报错信息。防止业务中断。
4：经过测试发现，重新重新设置表参数后表数据没有重分布到指标的group tag上。希望设置后可以像扩容缩容那样平滑且对上层业务无感。对于分区表，只会影响最新分区，非分区表完全无效。只有重新建新group tag的表，拉取到新表中，这样才会实现数据的完全分布到新tag上。官网上的描述是可以重分布的。

王卫光 · Answer

Doris v2.1.x版本基本上都通过Workload Group来进行资源的软硬隔离，基本上不用Resource Group来限制不同用户的资源

阿渊@SelectDB · Answer

回复：

这里第一点，主要是对 default group 的兼容，这块我记录了需求，看下有没有办法能降低业务的影响。但是一个BE 两个tag 感觉是背离了资源隔离的概念，至于如何优化需要内核评估。
auto partition 问题，2.1.7 版本正常，应该是已经fix过了，本地测试OK，可以在新版本上测试一把。
表数据无家可归这里，每张表都需要有对应的 tag 组，这里指的应该和第一点类似，主要是对于 default 组，如果BE节点上没有 default组的话，读写可能会有问题，所以，一般建议搞了运维窗口，写个脚本一次性将所有表都调整完。
动态分区表和非分区表已经一起拉会议测试，修改 tag 后，数据正常迁移。

补充：其实这里的测试场景并不是很贴切于业务。这种resource group ,资源组的变更，是属于大规模元数据变更的，因为涉及到了元数据的重写和tablet的迁移，所以这里咋样都需要一个窗口期的。如果没有窗口期，就会出现你说的这种情况。同时 tag能打到分区级别，一个集群有多少表，一个表有多少分区，FE editlog的压力也是非常大的。
但是建议这种操作，最好空一个运维窗口期去做，从1.0到现在，其实线上大规模改tag的场景不是很多，同时一般我们也会建议要有一个窗口期的。

wangbo · Answer

目前的resource tag的功能还是比较简单的，只是能做到把查询，机器和副本绑定到指定的tag上，你说的这些属于体验提升的部分，目前确实做不到自动化的这么丝滑，运维的成本暂时是需要用户人工处理的