考察点
这是一道架构题，面试官想看的不是概念，而是你有没有真的规划或参与过湖仓建设。能讲清楚「一份数据、多种计算」怎么通过表格式和统一 catalog 实现，分层怎么映射到湖上，迁移期新老系统怎么并存，才是合格答案。追问会落在具体组件选型和你遇到的实际困难上。
参考答案
先统一认知：湖仓一体解决什么
传统「湖+仓」两套体系，数据要复制两份，口径容易不一致，维护两拨人两套链路。湖仓一体的目标很朴素：数据只存一份（在对象存储的湖格式上），BI 报表、即席查询、机器学习共用这一份，靠引擎而不是靠数据复制来服务不同负载。
分层怎么落到湖上
数仓分层方法论不变，变的是承载形式：
- ODS：原始数据入湖，日志走 Flume/Filebeat 或直接 SDK 写 Kafka 再由 Flink 消费写 Iceberg；业务库走 CDC（Debezium/Canal/Flink CDC）入湖。这一层原样保留，是回溯和重跑的底牌。
- DWD/DWS：在湖上做清洗建模，流批可以共用同一套表——实时链路写近实时层，离线链路每天做 merge 修正，用湖格式的 ACID 保证两者不打架。
- ADS：面向应用的汇总层。对延迟要求高的报表，把结果同步到 StarRocks/Doris 这类 MPP 引擎；要求不高的直接查湖。
三个关键的架构决策
1. 统一 Catalog 是一体的前提。 所有引擎（Spark、Flink、Trino、StarRocks）都注册到同一个 catalog（Hive Metastore、或者更新一代的 REST catalog/云厂商 catalog），这样 Flink 写的表 Trino 立刻能查，不用导数。很多「湖仓一体」项目失败就败在元数据各管各的。
2. 引擎按负载分工。 没有银弹引擎：批量 ETL 用 Spark，实时入湖和流式计算用 Flink，即席分析和 BI 用 Trino/StarRocks 直查湖表。面试时主动说「引擎围着表转，不是表围着引擎转」，说明你抓住了湖仓一体相对数仓的范式变化。
3. 存储与治理配套。 对象存储打底，配分层存储策略（热数据 SSD/标准存储，冷数据转归档）；小文件治理（定期 compaction）、快照过期、孤儿文件清理要作为例行任务上线第一天就配好，不然三个月后集群被元数据和小文件拖死。
迁移落地的现实路径
没人能推倒重来。可行路径是增量迁移：新表一律建湖格式；老 Hive 表按访问热度排序，热点表先迁（Iceberg 支持 in-place 迁移，不动数据文件只生成元数据，成本很低）；双跑期用数据质量对账（行数、关键指标）验证一致性；最后切断旧链路。整个过程按月计，按季度收尾，谁跟你说一周迁完谁没干过。
落地效果的衡量
数出一处（同一张表服务多个团队）、存储成本下降（去掉了湖仓两份冗余）、实时链路简化（流批同表）、报表口径统一。这些是向业务证明价值的点，面试收尾时可以带一句。
可能的追问
- 为什么不直接用 Hive 表演进，要换 Iceberg？ 答 Hive 表缺 ACID、分区演进、快照、删除更新这些能力，且目录 list 模式在对象存储上性能差；Iceberg in-place 迁移成本低，值得换。
- 实时报表要求秒级，直查湖够吗？ 答不够，湖上分钟级是常态；秒级场景把 ADS 层热数据同步到 StarRocks/Doris 或直接走 OLAP 引擎的物化视图，湖做明细和回溯。
- Flink 写 Iceberg 有什么要注意的？ 答 checkpoint 间隔决定提交频率（影响小文件数量和可见延迟，常见 1-5 分钟）、开 upsert 模式处理更新、注意 equality delete 带来的读放大要配 compaction。