理解 Parquet、Iceberg 和数据湖仓
现代数据团队正越来越多地在对象存储中的 Parquet 文件之上标准化采用 Apache Iceberg、Delta Lake 和 Hudi 等开放表格式，目标是将存储与查询引擎解耦并避免厂商锁定。评论者围绕 Iceberg 与 Delta 在开放性、生态支持（尤其是 JVM 之外）以及现实性能方面的取舍展开讨论，并指出 Snowflake、Microsoft 和 Google 等大型厂商正分别支持不同方案。抛开格式细节，许多人认为湖仓本质上只是把传统数据仓库的理念（星型模式、ETL/ELT、治理）重新包装到更便宜的云存储之上，而建模和数据质量仍远比所选文件或元数据格式更重要。
新表格式的作用
- Parquet 被广泛视为数据湖的事实标准列式存储；Iceberg/Delta/Hudi 在其之上增加了表级元数据、模式演进、分区以及 ACID 语义。
- 这使组件解耦：例如，S3 用于存储，Parquet 用于数据，Iceberg/Delta 用于元数据，DuckDB/Spark/Trino/Snowflake/BigQuery 作为引擎。
开放性与治理（Iceberg vs Delta vs Hudi）
- Iceberg 常被视为更清晰、规范更完备的开放标准；Delta 的规范则被认为更复杂，并且与 Databricks 的实现紧密耦合。
- 有人认为 Delta 只是“名义上”开放：规范变更由一家厂商推动，某些功能被保留在开源之外。
- 反方观点则是，Delta 多年来在实践中已经足够开放，而且 Microsoft 等大型玩家正在大举押注它。
- 还有几位提到 Snowflake 和 BigQuery 正在加入 Iceberg（而不是 Delta），这被解读为 Iceberg 中立性的信号。
工具与语言生态
- 过去，Iceberg 以 Spark/Hadoop 为中心；非 JVM 支持（PyIceberg、DuckDB 扩展）正在到来，但仍在成熟过程中。
- Delta 现在有面向 Python/Rust 的 delta-rs，在 JVM 之外通常被认为更容易使用，不过其起源和治理仍有争议。
- Trino 已移除了 Hadoop/Hive 依赖；许多人认为整个生态正逐步摆脱旧式大数据栈。
数据湖、数据仓库与湖仓
- 一个强烈的主题是：格式只是实现细节；真正的价值来自建模（例如星型模式）、ETL/ELT 和 BI/报表。
- 单靠数据湖往往会变成“沼泽”，堆满原始数据却鲜有洞见；湖仓则在廉价对象存储之上重新引入类似表的结构和事务。
- 也有人认为，鉴于数据量通常并不大，而且已有关系型系统，大多数企业根本不需要数据湖。
性能、成本与可移植性
- 对象存储上的表格式承诺更低成本、厂商中立的存储，以及用较少锁定来切换查询引擎的能力。
- 多位评论指出，在湖或湖仓上查询通常比专门构建的列式数据库更慢；对许多分析场景可以接受，但对交互式 BI 则是问题。
- 厂商声称他们的目标是让开放表格式的性能接近原生存储，但是否会放弃专有内部实现仍受到质疑。
文件格式与实践问题
- Feather vs Parquet：许多人更偏好 Parquet，因为它更具未来兼容性和互操作性；使用 Feather 可能会破坏某些 Python 湖仓栈。
- CSV 被广泛批评为脆弱；Parquet 的采用被视为一个重大的实践胜利。
- 还提到了 Lance 和 Zarr 等专用格式，用于低延迟或多维场景，但相较于 Parquet 仍属小众。