-- schema does not support rename 操作受限问题

Question

在使用某些分布式数据库（如Apache Doris、StarRocks）或数据仓库系统时，常遇到“schema does not support rename”导致的表或列重命名操作受限问题。该问题源于底层存储引擎对元数据变更的严格限制，尤其是列级rename可能涉及数据类型的隐式转换或物理存储结构调整。执行ALTER TABLE ... RENAME COLUMN等语句时会直接报错，影响表结构演进和数据迁移。常见于实时数仓场景中维度字段标准化需求，需通过冗余新增列+数据回填+旧列废弃的变通方式实现，增加运维成本。如何在不中断服务的前提下安全完成字段逻辑重命名，成为Schema演进中的典型挑战。

Answer 1

1. 问题背景与技术挑战

在现代实时数仓架构中，Apache Doris 和 StarRocks 等 MPP 架构的分布式数据库因其高性能查询能力被广泛采用。然而，在进行表结构演进时，常遇到“schema does not support rename”这一限制性报错，尤其是在执行 ALTER TABLE ... RENAME COLUMN 操作时。

该问题的根本原因在于这些系统的底层存储引擎（如 Doris 的 BE 节点或 StarRocks 的列式存储模块）对元数据变更采取了强一致性策略。列名不仅是逻辑标识符，还可能绑定到物理存储路径、索引结构甚至分区表达式中。直接重命名可能导致：

• 列统计信息失效
• 物化视图依赖断裂
• ETL 流水线中断
• 历史版本兼容性破坏

因此，系统选择禁用列重命名以保障稳定性。

2. 分析过程：从错误日志到架构理解

当用户提交如下语句时：

ALTER TABLE sales_data RENAME COLUMN user_id TO customer_id;

系统返回错误：

"ERR: Schema change on column rename is not supported."

通过查阅官方文档和源码分析（如 Doris FE 模块中的 AlterTableStmt.java），可发现列操作被归类为“高风险 schema 变更”，需触发全量数据重写（rehash/repartition），而当前版本未实现此类在线迁移机制。

进一步分析其架构设计原则：

特性	Doris / StarRocks	传统 RDBMS（如 MySQL）
列重命名支持	❌ 不支持（仅支持表级）	✅ 支持（元数据更新）
Schema 变更方式	异步任务 + 版本合并	原地修改元数据
物理存储耦合度	高（列 ID 绑定 segment 文件）	低（逻辑映射层解耦）

3. 解决方案设计：安全、可回滚的字段逻辑重命名流程

为了在不影响线上服务的前提下完成字段重命名，应采用“新增-同步-切换-下线”的四阶段演进模式：

1. 阶段一：添加新列 — 使用标准 ALTER 添加目标名称的新列
2. 阶段二：双写与回填 — 应用层同时写入新旧列，并对历史数据执行批量填充
3. 阶段三：查询切换 — 将 BI 报表、API 查询逐步迁移到新列
4. 阶段四：废弃旧列 — 确认无依赖后标记为 deprecated，最终删除

此方法虽增加短期存储开销，但实现了零停机迁移。

4. 实施示例：StarRocks 中的字段标准化实战

假设原始表定义如下：

CREATE TABLE user_behavior (
    user_id BIGINT,
    action STRING,
    ts DATETIME
) ENGINE=OLAP;

需求：将 user_id 改为语义更清晰的 customer_id。

执行步骤：

-- 步骤1：添加新列（默认值可设为 NULL）
ALTER TABLE user_behavior ADD COLUMN customer_id BIGINT DEFAULT NULL;

-- 步骤2：使用 UPDATE 或 INSERT INTO ... SELECT 回填历史数据
INSERT INTO user_behavior PARTITION(p202504)
SELECT user_id, action, ts, user_id AS customer_id
FROM user_behavior_src WHERE __date__ = '2025-04-05';

-- 步骤3：应用层开启双写逻辑（伪代码）
void saveBehavior(long userId, String action) {
    Record r = new Record();
    r.set("user_id", userId);
    r.set("customer_id", userId); // 双写
    kafkaProducer.send(r);
}

-- 步骤4：监控并确认所有消费者已切换至 customer_id 后，标记 user_id 为废弃
-- 可通过注释说明
ALTER TABLE user_behavior MODIFY COLUMN user_id COMMENT "DEPRECATED: use customer_id instead";

5. 自动化与治理：构建 Schema 演进平台

为降低人工操作风险，建议构建自动化工具链，包含以下组件：

graph TD A[DDL 变更申请] --> B{是否涉及 rename?} B -- 是 --> C[生成双写脚本] B -- 否 --> D[直接执行] C --> E[调度历史数据回填] E --> F[发布变更通知] F --> G[监控消费端兼容性] G --> H[自动检测引用消失] H --> I[发起下线工单]

该流程可通过 Apache Airflow 或自研平台实现编排，集成元数据管理系统（如 DataHub）进行血缘追踪。

6. 扩展思考：未来架构优化方向

随着湖仓一体趋势发展，新一代存储格式（如 Iceberg、Hudi）已在事务性层面支持列重命名。例如 Iceberg 的 manifest 文件记录列 ID 与名称映射关系，允许独立更新 metadata。

对比方案如下：

系统类型	是否支持 Rename	实现机制	适用场景
Apache Doris	❌	强 schema 绑定	高频点查、固定模型
StarRocks (v3.x)	⚠️ 有限支持（实验中）	基于列 ID 映射	轻量级变更
Apache Iceberg	✅	Metadata 层抽象	数据湖、灵活建模

对于需要频繁迭代的业务，可考虑将冷数据迁移至 Iceberg 表，热数据保留在 Doris 中，形成混合架构。