写点什么

Apache Doris 全新分区策略 Auto Partition 应用场景与功能详解

作者:SelectDB
  • 2024-08-06
    北京
  • 本文字数:14875 字

    阅读完需:约 49 分钟

Apache Doris 全新分区策略 Auto Partition 应用场景与功能详解

在当今数据驱动的时代,如何高效、有序地管理数据库中的海量数据成为挑战。为了处理庞大的数据集,分布式数据库引入了类似分区和分桶策略,通过将数据按特定规则划分成较小的单位并分布到不同节点上,利用并行计算能力以提升处理和分析性能,并加强了数据管理的灵活性。


在 Apache Doris 中,数据划分包含分区和分桶两个层级。分区一般按照时间或其他连续值对数据进行划分,在查询时,通过分区裁剪过滤不必要的范围扫描,提升执行效率,同时极大地方便了对分区数据的增删改等管理操作;分桶则是基于某个或某些列的哈希值将数据分配到不同的桶中,从而有效定位数据、避免数据倾斜。


在 2.1 版本以前,Apache Doris 的分区主要依赖手动分区和动态分区功能(Dynamic Partition)自动创建两种方式:


  • 手动创建分区:需要在建表时指定该表包含的分区,或者在使用过程中通过 DDL 语句修改。

  • 动态分区:主要支持按照时间维度分区,以建表时的现实时间为标准来维护一个范围内的分区。


这两种方式都有其不够灵活之处,因此我们在 2.1 版本引入了 自动分区(Auto Partition)来拓展分区功能。自动分区同时支持按时间维度的 Range 分区,和支持多种数据类型的 List 分区,按照导入数据的实际分布创建分区,提供了更为灵活的分区创建手段,相比于动态分区,保证流程自动化的前提下极大提升了分区使用的自由度。

分区策略演进

面对数据分布的设计维度时,我们往往更关注分区的规划,因为分区列和分区间隔的选择与实际的数据分布模式强相关,合理的分区设计能够大幅提升表的查询和存储效率。


在 Doris 中,数据表(Table)按照分区(Partition)和分桶(Bucket)两种方式依次划分,最终同一个分桶中的数据形成数据分片(Tablet,可视作 Bucket)。Tablet 是 Doris 中多副本高可用、集群间数据调度与均衡的最小物理存储单位。图示如下:


01 手动创建分区

最常见也最基本的创建方式是手动创建,Doris 支持 Range 和 List 两种分区创建方式。对于日志、交易记录等基础业务场景,数据的时间维度较为明确,我们一般按照时间维度创建 Range 分区,建表语句示例如下:


-- Range PartitionCREATE TABLE IF NOT EXISTS example_range_tbl(    `user_id` LARGEINT NOT NULL COMMENT "用户id",    `date` DATE NOT NULL COMMENT "数据灌入日期时间",    `timestamp` DATETIME NOT NULL COMMENT "数据灌入的时间戳",    `city` VARCHAR(20) COMMENT "用户所在城市",    `age` SMALLINT COMMENT "用户年龄",    `sex` TINYINT COMMENT "用户性别",    `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "用户最后一次访问时间",    `cost` BIGINT SUM DEFAULT "0" COMMENT "用户总消费",    `max_dwell_time` INT MAX DEFAULT "0" COMMENT "用户最大停留时间",    `min_dwell_time` INT MIN DEFAULT "99999" COMMENT "用户最小停留时间")ENGINE=OLAPAGGREGATE KEY(`user_id`, `date`, `timestamp`, `city`, `age`, `sex`)PARTITION BY RANGE(`date`)(    PARTITION `p201701` VALUES LESS THAN ("2017-02-01"),    PARTITION `p201702` VALUES LESS THAN ("2017-03-01"),    PARTITION `p201703` VALUES LESS THAN ("2017-04-01"),    PARTITION `p2018` VALUES [("2018-01-01"), ("2019-01-01")))DISTRIBUTED BY HASH(`user_id`) BUCKETS 16PROPERTIES(    "replication_num" = "1");
复制代码


该表按照数据导入日期 date 进行分区,并预先创建了 4 个分区。在每个分区下,又根据 user_id 的哈希值划分成 16 个分桶。此时对 2018 年及以后的数据查询时,根据该表的分区设计,实际我们只需要对 p2018 进行扫描,查询语句如下:


mysql> desc select count() from example_range_tbl where date >= '20180101';+--------------------------------------------------------------------------------------+| Explain String(Nereids Planner)                                                      |+--------------------------------------------------------------------------------------+| PLAN FRAGMENT 0                                                                      ||   OUTPUT EXPRS:                                                                      ||     count(*)[#11]                                                                    ||   PARTITION: UNPARTITIONED                                                           ||                                                                                      ||    ......                                                                            ||                                                                                      ||   0:VOlapScanNode(193)                                                               ||      TABLE: test.example_range_tbl(example_range_tbl), PREAGGREGATION: OFF.          ||      PREDICATES: (date[#1] >= '2018-01-01')                                          ||      partitions=1/4 (p2018), tablets=16/16, tabletList=561490,561492,561494 ...      ||      cardinality=0, avgRowSize=0.0, numNodes=1                                       ||      pushAggOp=NONE                                                                  ||                                                                                      |+--------------------------------------------------------------------------------------+
复制代码


即使入库的数据集中在某几个分区内,分桶的哈希运算机制也能根据 user_id 的值对数据进行二次划分,避免在查询和存储时对部分机器造成不合理的负载倾斜。


在数据量较少的情况下,手动分区尚能应对,而在实际业务场景中,一个集群可能有上万张分区表,此时管理难度将呈指数级上升。例如:


CREATE TABLE `DAILY_TRADE_VALUE`(    `TRADE_DATE`              datev2 NOT NULL COMMENT '交易日期',    `TRADE_ID`                varchar(40) NOT NULL COMMENT '交易编号',    ......)UNIQUE KEY(`TRADE_DATE`, `TRADE_ID`)PARTITION BY RANGE(`TRADE_DATE`)(    PARTITION p_200001 VALUES [('2000-01-01'), ('2000-02-01')),    PARTITION p_200002 VALUES [('2000-02-01'), ('2000-03-01')),    PARTITION p_200003 VALUES [('2000-03-01'), ('2000-04-01')),    PARTITION p_200004 VALUES [('2000-04-01'), ('2000-05-01')),    PARTITION p_200005 VALUES [('2000-05-01'), ('2000-06-01')),    PARTITION p_200006 VALUES [('2000-06-01'), ('2000-07-01')),    PARTITION p_200007 VALUES [('2000-07-01'), ('2000-08-01')),    PARTITION p_200008 VALUES [('2000-08-01'), ('2000-09-01')),    PARTITION p_200009 VALUES [('2000-09-01'), ('2000-10-01')),    PARTITION p_200010 VALUES [('2000-10-01'), ('2000-11-01')),    PARTITION p_200011 VALUES [('2000-11-01'), ('2000-12-01')),    PARTITION p_200012 VALUES [('2000-12-01'), ('2001-01-01')),    PARTITION p_200101 VALUES [('2001-01-01'), ('2001-02-01')),    ......)DISTRIBUTED BY HASH(`TRADE_DATE`) BUCKETS 10PROPERTIES (  ......);
复制代码


该表通过手动、逐月的方式创建分区,每个月都需要手动重复增添下一个分区。这不仅需要管理员定期维护表结构变更,在处理实时数据时,可能还需要更频繁地按天、甚至按小时来划分数据分区,给 DBA 带来了沉重负担。

02 动态分区

因此 Doris 引入了动态分区(Dynamic partition)来处理重复性较高的时间分区需求,自动化创建和回收数据分区。通过指定分区单位、历史分区数量和未来分区数量,让 Doris 根据现实时间自动完成分区的创建和回收。


例如按天为单位创建分区,设置 start 为 -7 ,end 为 3:预创建未来 3 天的数据分区,并自动回收距今超过 7 天的历史数据分区。这一功能的实现依赖 FE 端的固定线程,通过不断轮询,检查当前是否需要创建新分区或回收旧分区,从而定期更新数据表的分区结构,建表语句示例如下:


CREATE TABLE `DAILY_TRADE_VALUE`(    `TRADE_DATE`              datev2 NOT NULL COMMENT '交易日期',    `TRADE_ID`                varchar(40) NOT NULL COMMENT '交易编号',    ......)UNIQUE KEY(`TRADE_DATE`, `TRADE_ID`)PARTITION BY RANGE(`TRADE_DATE`) ()DISTRIBUTED BY HASH(`TRADE_DATE`) BUCKETS 10PROPERTIES (    "dynamic_partition.enable" = "true",    "dynamic_partition.time_unit" = "DAY",    "dynamic_partition.start" = "-7",    "dynamic_partition.end" = "3",    "dynamic_partition.prefix" = "p",    "dynamic_partition.buckets" = "10");
复制代码


随时间推移,该表将始终保持 [当前日期-7, 当前日期+3] 范围内的分区。对于实时数据收集场景,例如 ODS 层直接从外部数据源(如 Kafka)接收数据时,动态分区功能尤为适用。


由于 startend 参数限定了分区的固定范围,用户只能在此范围内管理分区,若需要包含更久远的历史数据,不得不将start 值调大,而这会导致集群中元数据的不必要浪费。因此,在使用动态分区功能时,需要权衡实时管理的便利性与元数据管理的效率。

数据库分区管理的设计思考

对于更复杂的业务场景来说,动态分区有着明显的局限性:


  • 仅支持 Range 分区,而无法支持 List 分区

  • 只能应用于现实世界的时间维度,如果数据与现实时间无关则无法使用

  • 只能包含 1 个连续分区段,无法容纳该范围以外的分区


这导致在某些特定场景下,无法仅依靠动态分区实现分区管理,例如:


  • 当分区的时间维度不再和当前现实时间相关,而是对历史数据进行重放计算。例如处理过往某一年的数据,且需要进行天级别的分区。

  • 在当前数据导入过程中,偶尔发生历史数据变更。例如在天级别的分区表中,偶尔导入若干年前的数据,是否需要将动态分区的 start 调整到非常大的级别以容纳这些数据?


基于上述的功能局限,我们开始思考,能否提出一种新的分区方式,进一步提升分区管理的自动化程度、简化数据表的维护工作?分析发现,理想分区的实现是同时满足 2 个条件:


  1. 建表后无需手动调整分区

  2. 所有的入库数据都有对应分区


前者是动态分区已经具备的“自动化”能力,后者是希望拥有一种“更加灵活”的分区创建能力。而这种能力的本质,是要求分区创建与实际数据关联。


因此我们开始思考:分区的创建能否从建表时或者日常轮询,延后到数据到达时?从预先构造分区的分布,转为定义“从数据到分区”的映射规则,等数据入库后等待分区容纳时,再根据规则创建对应的分区。这样,相较于手动分区,整个流程都是自动发生的,不再需要人工维护;相较于动态分区,避免了有而无用和用而没有的分区情况。


让分区的创建与实际数据的分布自动关联, 是我们理想分区方式的核心思想。

更灵活便捷的自动分区创建策略

基于以上思考,我们在 Apache Doris 2.1 版本引入了“自动分区”(Auto Partition)功能,不再预先创建分区,而是在数据导入过程中根据设置的规则为创建对应的分区。负责数据处理、分发的 BE 节点会在执行计划的 DataSink 算子中尝试为每行数据找到它所属的 Partition。在以往分区表中,找不到对应分区的新增导入数据将被过滤或直接报错。而在自动分区表中,我们仅需在建表时定义分区创建规则,就可以随数据导入自动生成对应分区。接下来介绍自动分区的具体使用方式。

01 Range 自动分区

Range 自动分区(Auto Range Partition)提供了时间维度上的更优分区方案,弥补了动态分区在调参方面的局限性。它的语法如下:


-- AUTO RANGE PARTITION 语法AUTO PARTITION BY RANGE (FUNC_CALL_EXPR)()FUNC_CALL_EXPR ::= DATE_TRUNC ( <partition_column>, '<interval>' )
复制代码


其中 <partition_column> 指分区列名,<interval> 指分区单位,也就是希望生成分区的宽度。例如分区列为 k0,按照月级别分区,那么最终的分区描述语句就是 AUTO PARTITION BY RANGE (DATE_TRUNC(k0, 'month'))。此时对于所有导入数据,我们会调用 (DATE_TRUNC(k0, 'month')k0 计算出分区的左端点,再增加一个 interval 得到分区的右端点。通俗来说就是,此处选定的时间单位是“月”,数据导入后自动创建的分区区间是其所属的自然月。


前文动态分区章节中介绍的 DAILY_TRADE_VALUE 表,通过自动分区功能优化如下:


CREATE TABLE DAILY_TRADE_VALUE(    `TRADE_DATE`    DATEV2 NOT NULL COMMENT '交易日期',    `TRADE_ID`      VARCHAR(40) NOT NULL COMMENT '交易编号',    ......)AUTO PARTITION BY RANGE (DATE_TRUNC(`TRADE_DATE`, 'month'))()DISTRIBUTED BY HASH(`TRADE_DATE`) BUCKETS 10PROPERTIES(    ......);
复制代码


导入数据后,分区创建结果如下:


mysql> show partitions from DAILY_TRADE_VALUE;Empty set (0.10 sec)
mysql> insert into DAILY_TRADE_VALUE values ('2015-01-01', 1), ('2020-01-01', 2), ('2024-03-05', 10000), ('2024-03-06', 10001);Query OK, 4 rows affected (0.24 sec){'label':'label_2a7353a3f991400e_ae731988fa2bc568', 'status':'VISIBLE', 'txnId':'85097'}
mysql> show partitions from DAILY_TRADE_VALUE;+-------------+-----------------+----------------+---------------------+--------+--------------+--------------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+| PartitionId | PartitionName | VisibleVersion | VisibleVersionTime | State | PartitionKey | Range | DistributionKey | Buckets | ReplicationNum | StorageMedium | CooldownTime | RemoteStoragePolicy | LastConsistencyCheckTime | DataSize | IsInMemory | ReplicaAllocation | IsMutable | SyncWithBaseTables | UnsyncTables |+-------------+-----------------+----------------+---------------------+--------+--------------+--------------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+| 588395 | p20150101000000 | 2 | 2024-06-01 19:02:40 | NORMAL | TRADE_DATE | [types: [DATEV2]; keys: [2015-01-01]; ..types: [DATEV2]; keys: [2015-02-01]; ) | TRADE_DATE | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL || 588437 | p20200101000000 | 2 | 2024-06-01 19:02:40 | NORMAL | TRADE_DATE | [types: [DATEV2]; keys: [2020-01-01]; ..types: [DATEV2]; keys: [2020-02-01]; ) | TRADE_DATE | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL || 588416 | p20240301000000 | 2 | 2024-06-01 19:02:40 | NORMAL | TRADE_DATE | [types: [DATEV2]; keys: [2024-03-01]; ..types: [DATEV2]; keys: [2024-04-01]; ) | TRADE_DATE | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL |+-------------+-----------------+----------------+---------------------+--------+--------------+--------------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+3 rows in set (0.09 sec)
复制代码


可以看到,该表在导入数据之后自动创建了数据所属的对应分区,而没有数据的分区则不会自动创建。

02 List 自动分区

List 自动分区(Auto List Partition)用来应对实际业务场景中,非时间维度的数据划分需求,例如事件所属的地域、部门等维度。在 Doris 以往的功能中,List 分区不存在一个近似“动态分区”的自动管理机制,自动分区同时补齐了这一短板。它的语法如下:


-- AUTO LIST PARTITION 语法AUTO PARTITION BY LIST (`partition_col`)()
复制代码


例如,使用一张表的 VARCHAR 列作为分区列,实际含义为条目所属的城市:


mysql> CREATE TABLE `str_table` (    ->     `city` VARCHAR NOT NULL,    ->     ......    -> )    -> DUPLICATE KEY(`city`)    -> AUTO PARTITION BY LIST (`city`)    -> ()    -> DISTRIBUTED BY HASH(`city`) BUCKETS 10    -> PROPERTIES (    ->     ......    -> );Query OK, 0 rows affected (0.09 sec)
mysql> insert into str_table values ("Beijing"), ("Shanghai"), ("Los_Angeles");Query OK, 3 rows affected (0.25 sec)
mysql> show partitions from str_table;+-------------+-----------------+----------------+---------------------+--------+--------------+-------------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+| PartitionId | PartitionName | VisibleVersion | VisibleVersionTime | State | PartitionKey | Range | DistributionKey | Buckets | ReplicationNum | StorageMedium | CooldownTime | RemoteStoragePolicy | LastConsistencyCheckTime | DataSize | IsInMemory | ReplicaAllocation | IsMutable | SyncWithBaseTables | UnsyncTables |+-------------+-----------------+----------------+---------------------+--------+--------------+-------------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+| 589685 | pBeijing7 | 2 | 2024-06-01 20:12:37 | NORMAL | city | [types: [VARCHAR]; keys: [Beijing]; ] | city | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL || 589643 | pLos5fAngeles11 | 2 | 2024-06-01 20:12:37 | NORMAL | city | [types: [VARCHAR]; keys: [Los_Angeles]; ] | city | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL || 589664 | pShanghai8 | 2 | 2024-06-01 20:12:37 | NORMAL | city | [types: [VARCHAR]; keys: [Shanghai]; ] | city | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL |+-------------+-----------------+----------------+---------------------+--------+--------------+-------------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+3 rows in set (0.10 sec)
复制代码


可以看到,插入“北京”、“上海”、“洛杉矶”三个城市名后,结果根据城市名划分了对应分区,而以往只能通过手动的 DDL 语句实现。Auto List Partition 功能的引入在很大程度上降低了自定义分区的维护成本,拓宽了 Doris 的使用自由度。

03 使用技巧与注意事项

手动调整历史分区


对于写入最新实时数据和零散历史变更数据的表,由于 Auto Partition 不会自动回收历史分区,我们推荐两种可能的处理方式:


  1. 正常使用自动分区功能,为零散数据自动创建分区。相较于动态分区,避免创建冗余的空置分区,极大地节省了元数据使用量。

  2. 自动分区与手动创建分区相结合,按时间维度创建一个 LESS THAN 分区,容纳历史变更数据,这样可以更清晰地划分历史与实时数据,也为后续的数据管理带来效率上的提升。


mysql> CREATE TABLE DAILY_TRADE_VALUE    -> (    ->     `TRADE_DATE`    DATEV2 NOT NULL COMMENT '交易日期',    ->     `TRADE_ID`      VARCHAR(40) NOT NULL COMMENT '交易编号'    -> )    -> AUTO PARTITION BY RANGE (DATE_TRUNC(`TRADE_DATE`, 'DAY'))    -> (    ->     PARTITION `pHistory` VALUES LESS THAN ("2024-01-01")    -> )    -> DISTRIBUTED BY HASH(`TRADE_DATE`) BUCKETS 10    -> PROPERTIES    -> (    ->     "replication_num" = "1"    -> );Query OK, 0 rows affected (0.11 sec)
mysql> insert into DAILY_TRADE_VALUE values ('2015-01-01', 1), ('2020-01-01', 2), ('2024-03-05', 10000), ('2024-03-06', 10001);Query OK, 4 rows affected (0.25 sec){'label':'label_96dc3d20c6974f4a_946bc1a674d24733', 'status':'VISIBLE', 'txnId':'85092'}
mysql> show partitions from DAILY_TRADE_VALUE;+-------------+-----------------+----------------+---------------------+--------+--------------+--------------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+| PartitionId | PartitionName | VisibleVersion | VisibleVersionTime | State | PartitionKey | Range | DistributionKey | Buckets | ReplicationNum | StorageMedium | CooldownTime | RemoteStoragePolicy | LastConsistencyCheckTime | DataSize | IsInMemory | ReplicaAllocation | IsMutable | SyncWithBaseTables | UnsyncTables |+-------------+-----------------+----------------+---------------------+--------+--------------+--------------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+| 577871 | pHistory | 2 | 2024-06-01 08:53:49 | NORMAL | TRADE_DATE | [types: [DATEV2]; keys: [0000-01-01]; ..types: [DATEV2]; keys: [2024-01-01]; ) | TRADE_DATE | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL || 577940 | p20240305000000 | 2 | 2024-06-01 08:53:49 | NORMAL | TRADE_DATE | [types: [DATEV2]; keys: [2024-03-05]; ..types: [DATEV2]; keys: [2024-03-06]; ) | TRADE_DATE | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL || 577919 | p20240306000000 | 2 | 2024-06-01 08:53:49 | NORMAL | TRADE_DATE | [types: [DATEV2]; keys: [2024-03-06]; ..types: [DATEV2]; keys: [2024-03-07]; ) | TRADE_DATE | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL |+-------------+-----------------+----------------+---------------------+--------+--------------+--------------------------------------------------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+3 rows in set (0.10 sec)
复制代码


NULL 值分区


Doris 支持分区表中存储 NULL 值。对于自动分区功能而言,List 分区表的 NULL 值将会存储在真正的 NULL 分区中,例如:


mysql> CREATE TABLE list_nullable    -> (    ->     `str` varchar NULL    -> )    -> AUTO PARTITION BY LIST (`str`)    -> ()    -> DISTRIBUTED BY HASH(`str`) BUCKETS auto    -> PROPERTIES    -> (    ->     "replication_num" = "1"    -> );Query OK, 0 rows affected (0.10 sec)
mysql> insert into list_nullable values ('123'), (''), (NULL);Query OK, 3 rows affected (0.24 sec){'label':'label_f5489769c2f04f0d_bfb65510f9737fff', 'status':'VISIBLE', 'txnId':'85089'}
mysql> show partitions from list_nullable;+-------------+---------------+----------------+---------------------+--------+--------------+------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+| PartitionId | PartitionName | VisibleVersion | VisibleVersionTime | State | PartitionKey | Range | DistributionKey | Buckets | ReplicationNum | StorageMedium | CooldownTime | RemoteStoragePolicy | LastConsistencyCheckTime | DataSize | IsInMemory | ReplicaAllocation | IsMutable | SyncWithBaseTables | UnsyncTables |+-------------+---------------+----------------+---------------------+--------+--------------+------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+| 577297 | pX | 2 | 2024-06-01 08:19:21 | NORMAL | str | [types: [VARCHAR]; keys: [NULL]; ] | str | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL || 577276 | p0 | 2 | 2024-06-01 08:19:21 | NORMAL | str | [types: [VARCHAR]; keys: []; ] | str | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL || 577255 | p1233 | 2 | 2024-06-01 08:19:21 | NORMAL | str | [types: [VARCHAR]; keys: [123]; ] | str | 10 | 1 | HDD | 9999-12-31 23:59:59 | | NULL | 0.000 | false | tag.location.default: 1 | true | true | NULL |+-------------+---------------+----------------+---------------------+--------+--------------+------------------------------------+-----------------+---------+----------------+---------------+---------------------+---------------------+--------------------------+----------+------------+-------------------------+-----------+--------------------+--------------+3 rows in set (0.11 sec)
复制代码


而 Range 自动分区目前并不支持 NULL 值分区。这是因为在 Doris 中,Range 分区的 NULL 值将会存入最小的 LESS THAN 分区,Auto Partition 难以确定该分区应有的范围。如果按照(-INFINITY, MIN_VALUE)范围创建,则分区有在业务中被误删除的风险。

04 功能总结

自动分区在功能上基本覆盖了动态分区的使用场景,并带来分区规则前置的拓展,大大减轻了 DBA 在管理数据时的工作负担。完成分区规则的定义后,大量的分区创建工作将全部由 Doris 自动完成。在使用自动分区前,我们需要先明确相关限制条件,包括:


  1. LIST 自动分区支持多列分区,每个自动创建的分区仅包含一个分区值,分区名长度不能超过 50。Auto List Partition 中,分区名的创建依赖某种特定的规则,对元数据维护具有特定的含义,长度 50 的分区名,所能包含的数据实际长度可能更短。

  2. RANGE 自动分区支持单个分区列,分区列类型必须为 DATE 或 DATETIME

  3. LIST 自动分区支持 NULLABLE 分区列和实际插入 NULL 值;RANGE 自动分区不支持 NULLABLE 分区列

  4. 自从 Doris 2.1.3 版本开始,自动分区不再支持与动态分区共同使用。动态分区在进行分区回收时,不会考虑分区的创建来源。导致即使是 Auto Partition 自动创建的分区,也有可能被立即回收,导致不易察觉的数据丢失。

性能对比

自动分区和动态分区的功能区别主要体现在创建与删除、支持类型以及性能影响这三个方面。


动态分区通过固定线程创建并定期检查和回收分区,只支持按 RANGE 分区。而自动分区根据特定的分区规则在导入数据时按需创建,在 Range 分区的基础上提供了 LIST 分区支持。总体而言,自动分区在灵活性和节约人力方面都具有显著优势。


在导入数据时,动态分区在导入过程中基本不会影响性能,而自动分区会先检索已有分区,按需自动创建,这中间会存在一定的时间开销。因此我们将在后文展示对于自动分区具体的性能测试结果。


自动分区导入流程详解

接下来,详细介绍 Doris 自动分区导入的技术实现。以 Stream Load 为例,Doris 发起导入时,其中一个 BE 会完成前期的数据处理工作,并将数据发送给对应的 BE。用来处理数据的 BE 被称为 Coordinator,其他 BE 则统称为 Executor。



在 Coordinator 执行流程中,最后一个算子是 Datasink Node。在该算子中,数据需要先确定其对应的分区、分桶以及所在 BE 的位置,才能被成功发送到正确的 BE 节点并存储。为了实现数据传输,Coordinator 与 Executor 之间通过特定的 Channel 建立通信桥梁,发送端称为 Node Channel,与之对应的接收端称为 Tablets Channel。


自动分区主要在寻找数据对应分区这一环节发挥作用,具体工作机制如下:



以往找不到分区时,BE 会累计错误直至报错 DATA_QUALITY_ERROR,而开启了 Auto Partition 的表,则会在此阶段发起一个新建分区的请求给 FE 并创建对应的分区。Coordinator 等待 FE 完成分区创建的回传结果后,打开分区导入的对应通道,即对应的 Node Channel 和 Tablets Channel,继续完成数据的导入。


经过上述步骤,自动分区即可实现用户侧无感知的分区创建,使导入顺利完成。


在实际集群运行环境中,Coordinator 等待 FE 完成创建分区事务往往面临巨大的时间开销成本。原因是 Thrift RPC 过程产生的固有开销,以及高负载情况下 FE 的锁开销。为了提高数据导入的效率,我们在 Auto Partition 场景中进行了攒批操作,从而大幅减少 RPC 调用次数,这一改进显著提升了数据写入性能


需要注意的是,目前 FE Master 在“创建对应分区”环节完成对应分区的创建事务后,分区即刻可见,但如果导入流程最终失败或被取消,所创建的分区不会被自动回收。

自动分区性能表现

我们基于不同场景对自动分区进行了性能和稳定性测试,具体如下:


场景 1: 1FE + 3BE 环境,随机生成数据集,每个数据集 1 亿行数据、涉及 2000 个分区,6 个数据集并行导入 6 张对应表。


结果:对比开启自动分区前后,所有导入事务的耗时都较为平稳,平均性能损耗不足 5%。



场景 2:1FE + 3BE 环境,使用 Flink 数据源每秒采集 100 条数据,通过 Routine Load 进行导入,分别测试在 1、10、20 个事务(表)并发下的导入反压情况。


结果:在以上并发下,开启自动分区前后均能顺利完成数据导入、未出现反压情况,20 个事务并发时 CPU 利用率接近 100%,整体表现极为平稳。



上述测试方法分别对应两个典型场景:


  1. 在贴近生产环境的高负载场景下,检验 Auto Partition 功能面向集群高压力的情况,是否会发生性能劣化;

  2. 在 Routine Load 不同并发压力下,检验 Auto Partition 功能是否存在导入瓶颈、数据积压问题;


通过以上真实场景的模拟测试我们发现,开启 Auto Partition 前后对导入性能影响甚微。不论是简单的数据插入、或是生产环境中常见的 Routine Load 消费 Flink 数据源,Auto Partition 都表现出了优异的导入性能和稳定的系统表现。即使面对高负载、集群压力较大的情况,开启 Auto Partition 的导入性能损失仅有 5% 左右,性能表现依旧出色,足以满足实际生产环境的使用需求。


基于 Doris 的自动分区在性能和稳定性方面的出色表现,用户可以放心使用该功能,替代旧有分区方式,简化数据操作流程。

总结与展望

自 Apache Doris 2.1 版本起,自动分区的出现进一步简化了复杂场景下的 DDL 和分区表的维护工作,在我们已发布的版本中,许多用户已经使用该功能简化了工作流程,并且极大的便利了从其他数据库系统迁移到 Doris 的工作,自动分区已成为处理大规模数据和应对高并发场景的理想选择。


不仅如此,我们还将对自动分区功能展开更深入的拓展,以应对更加复杂的数据模型。


对于 Auto Range Partition:


  • 当前仅支持时间类型上的划分,未来期望支持更丰富的类型,如数值类型等,

  • 通过指定上下界的计算方式,创建对应分区


对于 Auto List Partition:


  • 将多个值按特定规则合并到同一分区


这些都是我们未来会考虑的改进方向,欢迎在分区创建方面有需求的同学积极使用并前往 Doris 问答论坛反馈建议,期待与你共建更好的 Apache Doris 社区。

参考文献

  1. Doris Stream Load 原理解析

  2. 一文教你玩转 Apache Doris 分区分桶新功能|新版本揭秘

发布于: 16 小时前阅读数: 14
用户头像

SelectDB

关注

极速易用 开源开放 2022-04-20 加入

SelectDB 是基于 Apache Doris 构建的现代化数据仓库,支持大规模实时数据上的极速查询分析。

评论

发布
暂无评论
Apache Doris 全新分区策略 Auto Partition 应用场景与功能详解_数据库_SelectDB_InfoQ写作社区