湖仓一体
问题
什么是湖仓一体（Lakehouse）？如何选择表格式？
答案
架构演进
湖仓一体 = 数据湖的低成本存储 + 数据仓库的管理能力
湖仓一体架构
表格式选型
| 场景 | 推荐 | 理由 |
|---|---|---|
| 多引擎、厂商中立 | Iceberg | 最广泛的引擎支持 |
| Databricks 生态 | Delta Lake | 原生深度集成 |
| CDC / 频繁 Upsert | Hudi | Upsert 性能最强 |
| 新项目选型 | Iceberg | 社区增长最快、最开放 |
表格式综合对比
| 维度 | Iceberg | Delta Lake | Hudi |
|---|---|---|---|
| 开源方 | Apache | Databricks | Uber → Apache |
| ACID | ✅ | ✅ | ✅ |
| 时间旅行 | ✅ | ✅ | ✅ |
| Schema 演进 | ✅ 强 | ✅ | ⚠️ 有限 |
| 分区演进 | ✅ 强 | ⚠️ 有限 | ⚠️ 有限 |
| 隐藏分区 | ✅ | ❌ | ❌ |
| Upsert | ✅ | ✅ | ⭐⭐⭐⭐⭐ |
| 增量读取 | ✅ | ✅ | ⭐⭐⭐⭐⭐ |
| 多引擎 | Spark/Flink/Trino/Doris | Spark 为主 | Spark 为主 |
| 趋势 | 📈 增长最快 | 稳定 | 稳定 |
2024+ 趋势
- Iceberg 成为事实标准：各大引擎竞相支持
- 表格式互通：Delta Lake UniForm 可兼容读 Iceberg/Hudi
- 存算分离：Lakehouse 天然适合云原生
- 流批一体：Flink + Iceberg/Hudi 实现实时湖仓
典型湖仓架构方案
| 组件 | 推荐选型 |
|---|---|
| 存储 | S3 / OSS / MinIO |
| 表格式 | Apache Iceberg |
| Catalog | Hive Metastore / AWS Glue / Nessie |
| 批处理 | Spark |
| 流处理 | Flink |
| OLAP 查询 | Trino / Doris / StarRocks |
| BI 工具 | Superset / Metabase |
常见面试问题
Q1: 为什么不直接用数据仓库？
答案：
| 痛点 | 数据湖/湖仓的解决方案 |
|---|---|
| 仓库存储贵 | 用 S3 存储，成本降低 10~100x |
| 只能存结构化数据 | 数据湖支持任意格式 |
| 厂商锁定 | 开放格式 + 开源引擎 |
| 实时能力差 | Flink + 表格式实现实时 |
Q2: Lakehouse 有什么挑战？
答案：
- 性能不如专用数仓：查询延迟通常高于 ClickHouse/Doris
- 架构复杂度：需要管理存储、表格式、引擎多个组件
- 人才门槛：团队需要掌握多个技术栈
- 小文件问题：流式写入产生大量小文件，需要定期治理
Q3: Catalog 的作用是什么？
答案： Catalog 是表的注册中心，负责管理表的元数据（位置、Schema、快照）。
- Hive Metastore：传统方案，广泛兼容
- AWS Glue：AWS 托管服务
- Nessie：支持 Git-like 分支管理的 Catalog
- REST Catalog：Iceberg 标准 REST API
相关链接
- Apache Iceberg - 最流行的表格式
- Delta Lake - Databricks 表格式
- Apache Hudi - 增量处理表格式
- 数据仓库 - 传统数仓对比
- 离线数仓 vs 实时数仓 - Lambda/Kappa 架构