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 作业共用。