iceberg 的 hidden partitioning 不支持直接修改分区字段，否则旧数据无法查询；分区值仅存于 manifest 元数据中，变更表达式会导致新旧规则不兼容。
hidden partitioning 在 Iceberg 中到底能不能改分区字段
不能直接改，改了就查不到旧数据。Iceberg 的 hidden partitioning 是写入时自动计算并隐藏存储的，分区值不存于原始数据文件里，而是在元数据（manifest）中推导出来的。一旦你调整了分区表达式（比如把 days(ts) 换成 months(ts)），新写入的数据会按新规则生成 manifest 条目，但旧 manifest 仍按老规则解析 —— 查询时引擎无法对齐，结果就是旧分区路径“消失”或数据错位。
常见错误现象：SELECT * FROM tbl WHERE dt = '2024-01-01' 返回空，但确认数据明明存在；或者 DESCRIBE TABLE 显示分区列，SHOW PARTITIONS 却没结果。
实操建议：
- 新增分区逻辑必须用新表名，不要复用原表路径
- 迁移旧数据时，需用
INSERT OVERWRITE+ 显式SELECT把旧数据按新分区表达式重写一遍 - 避免在生产表上反复变更
partition-spec，尤其跨时间粒度（day → hour 或 year → month）
schema 演进支持哪些操作，哪些会破坏 hidden partitioning
Iceberg 的 schema 演进本身很稳健，但和 hidden partitioning 交叠时，关键看字段是否参与分区推导。只要被 partition-by 引用的字段（比如 ts）没被删除或类型变更，其他字段增删改都安全。
容易踩的坑：
- 给参与分区的列改类型（如
ts: timestamp→ts: string）：写入会失败，manifest 校验通不过 - 用
renameColumn改了分区字段名：旧 manifest 还认原名，新写入用新名，查询时两头不认 - 加了一个新字段并立即用于分区（比如新增
region后立刻partition-by days(ts), region）：没问题，但要注意历史数据该字段为NULL，会落到__HIVE_DEFAULT_PARTITION__分区下
性能影响：添加非分区字段几乎零开销；但新增一个分区字段会导致所有后续写入 manifest 增大，且过滤效率取决于该字段的统计信息覆盖率。
为什么 ALTER TABLE ... SET PARTITION SPEC 不生效
因为 Iceberg 不允许运行时修改 partition-spec —— ALTER TABLE ... SET PARTITION SPEC 这条命令根本不存在。你看到的报错通常是 UnsupportedOperationException: Cannot replace partition spec 或更隐蔽的 ValidationException: Cannot change partition spec。
真实可用的操作只有两个：
-
replacePartitionSpec（Spark / Flink 写入 API 层调用，非 SQL）：仅在创建新快照时生效，不影响已有数据 - 通过
rewriteManifests+ 自定义分区重写逻辑：手动触发，成本高，需全表扫描
别信文档里“future support”的描述，当前主流版本（v1.4+）依然不支持 SQL 级别的分区规范热更新。
hidden partitioning 和显式分区字段混用的风险
可以共存，但极易混淆语义。比如建表时写了 partition-by days(ts), country，又在 SELECT 中显式 SELECT 出 days(ts) as dt —— 这个 dt 是计算列，不是物理列，不能用于谓词下推，也不能被 Hive Metastore 识别。
典型问题场景：
- 用 Trino 查询时，
WHERE dt = '2024-01-01'无法裁剪分区，全表 scan - 导出到 Hive 表时，
country能映射，days(ts)变成空目录或乱码路径 - Spark DataFrame 写入时若同时指定
.partitionBy("dt")和 Iceberg 的partition-by days(ts)，可能生成冗余嵌套目录
最稳妥的做法：只用 Iceberg 的 hidden partitioning，彻底去掉 SQL 中对分区计算列的显式引用；需要可查列时，额外加一个物化的 dt STRING 字段，用 date_format(ts, 'yyyy-MM-dd') 初始化。
复杂点在于，partition-spec 的变更不是原子的，它依赖 manifest 列表的一致性快照。一次失败的重写可能留下混合分区规则的 manifest，查起来像数据“部分丢失”。这种状态只能靠 validate-table 发现，但修复必须人工介入。
