可以，iceberg通过add-column实现原子、向后兼容的字段新增，新字段在旧数据中为null，需用原生api或支持引擎执行，避免replace columns；hidden partitioning不暴露分区字段，由iceberg自动处理，更安全灵活；旧snapshot无法读出新字段，因各snapshot绑定独立schema版本。
Iceberg 表能直接加字段而不影响查询吗？
可以，但得用 add-column 而不是 ALTER TABLE ... ADD COLUMNS 这类传统 SQL 语法。Iceberg 的 schema evolution 是原子的、向后兼容的：新加的 nullable 字段在旧数据里自动为 NULL，老查询完全不受影响。关键在于 Iceberg 把 schema 存在元数据文件里，不依赖底层 Parquet/Orc 的 schema。
- 必须通过 Iceberg 原生 API 或支持 Iceberg 的引擎（如 Trino、Spark 3.4+）执行变更，比如 Spark SQL 中用
ALTER TABLE t ADD COLUMN desc STRING 是有效的，但 Hive Metastore 直连模式下会失败
- 避免用
REPLACE COLUMNS —— 这会重写整个 schema，触发全表 rewrite，且旧快照读取可能报 SchemaMismatchException
- 新字段名不能是保留字（如
data、partition），否则 Spark 写入时 silently 跳过该列
hidden partitioning 和传统 partition by 的区别在哪？
核心区别是：hidden partitioning 不暴露分区字段给用户 SQL，分区逻辑由 Iceberg 在写入/读取时自动处理；而 PARTITIONED BY 会让字段真实出现在表结构里，用户必须显式插入值或用 INSERT ... PARTITION。
- 使用 hidden partitioning 时，建表语句里写的是
partitioning = array['days(ts)']（Trino）或 partitionBy(days("ts"))（Spark），但表描述里看不到 day 列，SELECT * 也不会返回它
- 传统分区字段一旦写错（比如漏写
PARTITION (dt='2024-01-01')），数据就进错目录，且无法靠查询修复；hidden partitioning 完全规避了这个风险
- hidden partitioning 支持更灵活的转换函数，比如
bucket(16, user_id) 或 truncate(3, product_name)，这些在 Hive 兼容模式下无法实现
schema evolution 后，旧 snapshot 还能读出新字段吗？
不能。Iceberg 的每个 snapshot 绑定一个独立 schema 版本，旧 snapshot 只认它写入时的 schema。如果你在 snapshot #5 加了字段 score INT，那 snapshot #3 的数据查出来就没有 score，哪怕你用新 client 查询。
- 查询指定 snapshot 时（如
SELECT * FROM t VERSION AS OF 3），Iceberg 严格按该版本 schema 解析数据文件，不会“补”字段
- 如果需要跨版本统一视图，得靠视图（View）做字段对齐，或者用
UNION ALL 手动合并不同版本的 SELECT，但要注意 nullability 匹配
- Spark 中若开启
spark.sql.iceberg.handle-unknown-partition-filter=true，对新增 partition 字段的 filter 会被静默忽略，而不是报错——这容易掩盖逻辑错误
为什么 hidden partitioning 对 compaction 更友好？
因为 Iceberg 知道哪些字段是用于分区裁剪的，compaction 时能复用已有的分区信息做文件合并策略，比如只合并同一天的数据文件，而不用扫描所有文件的完整内容。
- hidden partitioning 的分区值从原始列计算得出（如
days(ts)），所以 compaction 能基于 manifest 文件里的分区统计信息快速判断文件归属，避免全量读取
- 如果用传统分区，每次 compaction 都要解析路径（如
/dt=2024-01-01/hour=14/），路径格式一变（比如改成 /date=20240101/），就得重跑 repair table
- 注意：hidden partitioning 的函数必须是 deterministic，否则 compaction 可能误判分区归属，导致数据丢失或查询结果错乱——比如用
rand() 做 bucket 就绝对不行
ALTER TABLE t ADD COLUMN desc STRING 是有效的，但 Hive Metastore 直连模式下会失败 REPLACE COLUMNS —— 这会重写整个 schema，触发全表 rewrite，且旧快照读取可能报 SchemaMismatchException data、partition），否则 Spark 写入时 silently 跳过该列 PARTITIONED BY 会让字段真实出现在表结构里，用户必须显式插入值或用 INSERT ... PARTITION。
- 使用 hidden partitioning 时，建表语句里写的是
partitioning = array['days(ts)']（Trino）或partitionBy(days("ts"))（Spark），但表描述里看不到day列，SELECT *也不会返回它 - 传统分区字段一旦写错（比如漏写
PARTITION (dt='2024-01-01')），数据就进错目录，且无法靠查询修复；hidden partitioning 完全规避了这个风险 - hidden partitioning 支持更灵活的转换函数，比如
bucket(16, user_id)或truncate(3, product_name)，这些在 Hive 兼容模式下无法实现
schema evolution 后，旧 snapshot 还能读出新字段吗？
不能。Iceberg 的每个 snapshot 绑定一个独立 schema 版本，旧 snapshot 只认它写入时的 schema。如果你在 snapshot #5 加了字段 score INT，那 snapshot #3 的数据查出来就没有 score，哪怕你用新 client 查询。
- 查询指定 snapshot 时（如
SELECT * FROM t VERSION AS OF 3），Iceberg 严格按该版本 schema 解析数据文件，不会“补”字段
- 如果需要跨版本统一视图，得靠视图（View）做字段对齐，或者用
UNION ALL 手动合并不同版本的 SELECT，但要注意 nullability 匹配
- Spark 中若开启
spark.sql.iceberg.handle-unknown-partition-filter=true，对新增 partition 字段的 filter 会被静默忽略，而不是报错——这容易掩盖逻辑错误
为什么 hidden partitioning 对 compaction 更友好？
因为 Iceberg 知道哪些字段是用于分区裁剪的，compaction 时能复用已有的分区信息做文件合并策略，比如只合并同一天的数据文件，而不用扫描所有文件的完整内容。
- hidden partitioning 的分区值从原始列计算得出（如
days(ts)），所以 compaction 能基于 manifest 文件里的分区统计信息快速判断文件归属，避免全量读取
- 如果用传统分区，每次 compaction 都要解析路径（如
/dt=2024-01-01/hour=14/），路径格式一变（比如改成 /date=20240101/），就得重跑 repair table
- 注意：hidden partitioning 的函数必须是 deterministic，否则 compaction 可能误判分区归属，导致数据丢失或查询结果错乱——比如用
rand() 做 bucket 就绝对不行
SELECT * FROM t VERSION AS OF 3），Iceberg 严格按该版本 schema 解析数据文件，不会“补”字段 UNION ALL 手动合并不同版本的 SELECT，但要注意 nullability 匹配 spark.sql.iceberg.handle-unknown-partition-filter=true，对新增 partition 字段的 filter 会被静默忽略，而不是报错——这容易掩盖逻辑错误 - hidden partitioning 的分区值从原始列计算得出（如
days(ts)），所以 compaction 能基于 manifest 文件里的分区统计信息快速判断文件归属，避免全量读取 - 如果用传统分区，每次 compaction 都要解析路径（如
/dt=2024-01-01/hour=14/），路径格式一变（比如改成/date=20240101/），就得重跑 repair table - 注意：hidden partitioning 的函数必须是 deterministic，否则 compaction 可能误判分区归属，导致数据丢失或查询结果错乱——比如用
rand()做 bucket 就绝对不行
复杂点在于，schema evolution 和 hidden partitioning 都依赖 Iceberg 元数据的一致性。一旦手动改 manifest 或跳过 Iceberg API 直写文件，这两项能力都会失效，而且问题往往延迟到查询时才暴露。
