Schema Change

用户可以通过 Schema Change 操作来修改已存在表的 Schema。目前 Doris 支持以下几种修改:

  • 增加、删除列
  • 修改列类型
  • 调整列顺序
  • 增加、修改 Bloom Filter
  • 增加、删除 bitmap index

本文档主要介绍如何创建 Schema Change 作业,以及进行 Schema Change 的一些注意事项和常见问题。

名词解释

  • Base Table:基表。每一个表被创建时,都对应一个基表。
  • Rollup:基于基表或者其他 Rollup 创建出来的上卷表。
  • Index:物化索引。Rollup 或 Base Table 都被称为物化索引。
  • Transaction:事务。每一个导入任务都是一个事务,每个事务有一个唯一递增的 Transaction ID。

原理介绍

执行 Schema Change 的基本过程,是通过原 Index 的数据,生成一份新 Schema 的 Index 的数据。其中主要需要进行两部分数据转换,一是已存在的历史数据的转换,二是在 Schema Change 执行过程中,新到达的导入数据的转换。

1. +----------+
2. | Load Job |
3. +----+-----+
4. |
5. | Load job generates both origin and new index data
6. |
7. |      +------------------+ +---------------+
8. |      | Origin Index     | | Origin Index  |
9. +------> New Incoming Data| | History Data  |
10. |      +------------------+ +------+--------+
11. |                                  |
12. |                                  | Convert history data
13. |                                  |
14. |      +------------------+ +------v--------+
15. |      | New Index        | | New Index     |
16. +------> New Incoming Data| | History Data  |
17. +------------------+ +---------------+

在开始转换历史数据之前,Doris 会获取一个最新的 Transaction ID。并等待这个 Transaction ID 之前的所有导入事务完成。这个 Transaction ID 成为分水岭。意思是,Doris 保证在分水岭之后的所有导入任务,都会同时为原 Index 和新 Index 生成数据。这样当历史数据转换完成后,可以保证新的 Index 中的数据是完整的。

创建作业

创建 Schema Change 的具体语法可以查看帮助 HELP ALTER TABLE 中 Schema Change 部分的说明。

Schema Change 的创建是一个异步过程,作业提交成功后,用户需要通过 SHOW ALTER TABLE COLUMN 命令来查看作业进度。

查看作业

SHOW ALTER TABLE COLUMN 可以查看当前正在执行或已经完成的 Schema Change 作业。当一次 Schema Change 作业涉及到多个 Index 时,该命令会显示多行,每行对应一个 Index。举例如下:

1. JobId: 20021
2. TableName: tbl1
3. CreateTime: 2019-08-05 23:03:13
4. FinishTime: 2019-08-05 23:03:42
5. IndexName: tbl1
6. IndexId: 20022
7. OriginIndexId: 20017
8. SchemaVersion: 2:792557838
9. TransactionId: 10023
10. State: FINISHED
11. Msg:
12. Progress: N/A
13. Timeout: 86400
  • JobId:每个 Schema Change 作业的唯一 ID。
  • TableName:Schema Change 对应的基表的表名。
  • CreateTime:作业创建时间。
  • FinishedTime:作业结束时间。如未结束,则显示 “N/A”。
  • IndexName: 本次修改所涉及的某一个 Index 的名称。
  • IndexId:新的 Index 的唯一 ID。
  • OriginIndexId:旧的 Index 的唯一 ID。
  • SchemaVersion:以 M:N 的格式展示。其中 M 表示本次 Schema Change 变更的版本,N 表示对应的 Hash 值。每次 Schema Change,版本都会递增。
  • TransactionId:转换历史数据的分水岭 transaction ID。
  • State:作业所在阶段。
  • PENDING:作业在队列中等待被调度。
  • WAITING_TXN:等待分水岭 transaction ID 之前的导入任务完成。
  • RUNNING:历史数据转换中。
  • FINISHED:作业成功。
  • CANCELLED:作业失败。
  • Msg:如果作业失败,这里会显示失败信息。
  • Progress:作业进度。只有在 RUNNING 状态才会显示进度。进度是以 M/N 的形式显示。其中 N 为 Schema Change 涉及的总副本数。M 为已完成历史数据转换的副本数。
  • Timeout:作业超时时间。单位秒。

取消作业

在作业状态不为 FINISHED 或 CANCELLED 的情况下,可以通过以下命令取消 Schema Change 作业:

CANCEL ALTER TABLE COLUMN FROM tbl_name;

最佳实践

Schema Change 可以在一个作业中,对多个 Index 进行不同的修改。举例如下:

源 Schema:

1. +-----------+-------+------+------+------+---------+-------+
2. | IndexName | Field | Type | Null | Key  | Default | Extra |
3. +-----------+-------+------+------+------+---------+-------+
4. | tbl1      | k1    | INT  | No   | true | N/A     |       |
5. |           | k2    | INT  | No   | true | N/A     |       |
6. |           | k3    | INT  | No   | true | N/A     |       |
7. |           |       |      |      |      |         |       |
8. | rollup2   | k2    | INT  | No   | true | N/A     |       |
9. |           |       |      |      |      |         |       |
10. | rollup1   | k1    | INT  | No   | true | N/A     |       |
11. |           | k2    | INT  | No   | true | N/A     |       |
12. +-----------+-------+------+------+------+---------+-------+

可以通过以下命令给 rollup1 和 rollup2 都加入一列 k4,并且再给 rollup2 加入一列 k5:

1. ALTER TABLE tbl1
2. ADD COLUMN k4 INT default "1" to rollup1,
3. ADD COLUMN k4 INT default "1" to rollup2,
4. ADD COLUMN k5 INT default "1" to rollup2;

完成后,Schema 变为:

1. +-----------+-------+------+------+------+---------+-------+
2. | IndexName | Field | Type | Null | Key  | Default | Extra |
3. +-----------+-------+------+------+------+---------+-------+
4. | tbl1      | k1    | INT  | No   | true | N/A     |       |
5. |           | k2    | INT  | No   | true | N/A     |       |
6. |           | k3    | INT  | No   | true | N/A     |       |
7. |           | k4    | INT  | No   | true | 1       |       |
8. |           | k5    | INT  | No   | true | 1       |       |
9. |           |       |      |      |      |         |       |
10. | rollup2   | k2    | INT  | No   | true | N/A     |       |
11. |           | k4    | INT  | No   | true | 1       |       |
12. |           | k5    | INT  | No   | true | 1       |       |
13. |           |       |      |      |      |         |       |
14. | rollup1   | k1    | INT  | No   | true | N/A     |       |
15. |           | k2    | INT  | No   | true | N/A     |       |
16. |           | k4    | INT  | No   | true | 1       |       |
17. +-----------+-------+------+------+------+---------+-------+

可以看到,Base 表 tbl1 也自动加入了 k4, k5 列。即给任意 rollup 增加的列,都会自动加入到 Base 表中。

同时,不允许向 Rollup 中加入 Base 表已经存在的列。如果用户需要这样做,可以重新建立一个包含新增列的 Rollup,之后再删除原 Rollup。

注意事项

  • 一张表在同一时间只能有一个 Schema Change 作业在运行。
  • Schema Change 操作不阻塞导入和查询操作。
  • 分区列和分桶列不能修改。
  • 如果 Schema 中有 REPLACE 方式聚合的 value 列,则不允许删除 Key 列。

如果删除 Key 列,Doris 无法决定 REPLACE 列的取值。

Unique 数据模型表的所有非 Key 列都是 REPLACE 聚合方式。 - 在新增聚合类型为 SUM 或者 REPLACE 的 value 列时,该列的默认值对历史数据没有含义。

因为历史数据已经失去明细信息,所以默认值的取值并不能实际反映聚合后的取值。 - 当修改列类型时,除 Type 以外的字段都需要按原列上的信息补全。

如修改列 k1 INT SUM NULL DEFAULT "1" 类型为 BIGINT,则需执行命令如下:

ALTER TABLE tbl1 MODIFY COLUMN `k1` BIGINT SUM NULL DEFAULT "1";

注意,除新的列类型外,如聚合方式,Nullable 属性,以及默认值都要按照原信息补全。 - 不支持修改列名称、聚合类型、Nullable 属性、默认值以及列注释。

常见问题

  • Schema Change 的执行速度

目前 Schema Change 执行速度按照最差效率估计约为 10MB/s。保守起见,用户可以根据这个速率来设置作业的超时时间。 - 提交作业报错 Table xxx is not stable. ...

Schema Change 只有在表数据完整且非均衡状态下才可以开始。如果表的某些数据分片副本不完整,或者某些副本正在进行均衡操作,则提交会被拒绝。

数据分片副本是否完整,可以通过以下命令查看:

ADMIN SHOW REPLICA STATUS FROM tbl WHERE STATUS != "OK";

如果有返回结果,则说明有副本有问题。通常系统会自动修复这些问题,用户也可以通过以下命令优先修复这个表:

ADMIN REPAIR TABLE tbl1;

用户可以通过以下命令查看是否有正在运行的均衡任务:

SHOW PROC "/cluster_balance/pending_tablets";

可以等待均衡任务完成,或者通过以下命令临时禁止均衡操作:

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

相关配置

FE 配置

  • alter_table_timeout_second:作业默认超时时间,86400 秒。

BE 配置

  • alter_tablet_worker_count:在 BE 端用于执行历史数据转换的线程数。默认为 3。如果希望加快 Schema Change 作业的速度,可以适当调大这个参数后重启 BE。但过多的转换线程可能会导致 IO 压力增加,影响其他操作。该线程和 Rollup 作业共用。