湖仓一体是什么？到底“一体”了什么？
对照异构湖仓与共享基础能力的形态，逐项观察 Storage、Table、Metadata、Catalog、Compute 和治理边界。
两套系统的边界开始重新设计
湖仓一体到底“一体”了什么？
异构链路里，Lake 保存一份数据，Warehouse 再保存一份。另一种形态尝试让多个 Compute 访问共享的 Storage / Table，同时保留不同的查询和加工能力。
“一体”发生在存储、表语义、元数据还是数据副本？
核心概念
湖仓一体：共享基础能力，不抹平所有差异
判断“一体”要看 Storage、Data copy、Table semantics、Metadata、Catalog、Compute 和 Governance 如何协作，而不是只看物理集群数量。
先把“异构”这条旧链路摆出来
传统异构形态可以写成 Source → Lake → ETL / Copy → Warehouse。Lake 和 Warehouse 各自承担数据管理 / 计算工作，AccountBalanceSnapshot 或结构化交易结果在两侧形成可查询副本。
这种方式在高频 BI、长期保留和团队边界明确的场景里仍然合理。它的代价是同步延迟、Schema / Version 对齐和两套治理 / 运维责任。
- “异构”描述协作边界，不等于两个系统一定互相排斥。
- 共享基础能力的目标是减少割裂，具体共享哪些层要逐项确认。
- 物理上是否一个集群，不能替代对数据语义和副本的检查。
10-4 · Shared Foundations
切换形态，看“一体”落在哪些层
在异构湖仓与共享基础能力的形态之间切换，观察副本数量、Storage、Table semantics、Metadata、Catalog、Compute、Governance 以及新增责任。
正在加载交互实验…
放在一起看
Storage 与 Compute 是两个问题
数据长期保存在哪里，不等于谁负责执行查询和加工。
承载和管理数据状态
- 决定数据放置与副本关系
- 提供 Schema、Commit、Snapshot 等表语义
- 需要 Metadata / Catalog 说明对象
执行查询和加工
- 可以有 Lake Compute
- 可以有 MPP / BI Compute
- 也可以继续接入其他分析引擎
把收益和责任放在一起
- 共享可能减少复制和同步
- 表与元数据责任不会消失
- 治理仍需作用于同一数据对象