湖里已经有一份，为什么仓里还要再有一份？
沿 Source → Lake → Transform / Sync → Warehouse 看清复制带来的查询收益与双体系责任。
经营分析需要昨天的账户余额
湖里已经有一份，为什么仓里还要再有一份？
AccountBalanceSnapshot 已经完整落在 Lake。BI 查询要在固定窗口内反复回答机构和账户问题，团队决定把需要的结构化结果同步到 MPP / PG 类分析仓。
复制没有改变业务数据的含义，却改变了系统需要维护的边界。
核心概念
异构湖仓：能力互补，也要管理副本
两套数据管理 / 计算体系可以分别承载完整历史和高频查询；当数据在两侧出现时，Schema、Version、延迟和重跑都需要明确责任。
Warehouse 的第二份数据从哪里来？
这里的 Lake 可以代表 Hive / 文件型存储这一类角色，Warehouse 可以代表 MPP / PG 类分析仓角色。它们不是产品对比对象，而是链路中两个不同的数据管理和计算边界。
AccountBalanceSnapshot 的一行代表一个 Account 在某个 snapshot_date 的余额状态。Lake 适合保存这份完整历史，Warehouse 则为反复访问的结构化查询准备更直接的服务路径。
- 数据先到 Lake，再由后续 Transform / Sync 产生 Warehouse 副本。
- Warehouse 的存在理由是查询方式和 SLA，不是因为 Lake 中的那份“不算数据”。
- 同一业务数据两侧都存在时，双方都要保留可解释的版本语义。
10-2 · Transform / Sync
执行一次同步，观察副本和责任同时增加
先看 Lake 中唯一的一份 AccountBalanceSnapshot，再执行同步。页面只模拟链路结果，不展开 CDC、ETL 工具或具体产品实现。
正在加载交互实验…
放在一起看
复制换来的能力与新增成本
两侧的分工可以合理，代价也要写进架构记录。
完整承载与开放访问
- 保存原始 / 明细和长期历史
- 容纳事件与文件等多种形态
- 适合低频、上下文优先的访问
高频查询与明确 SLA
- 服务 BI、报表和聚合
- 为结构化查询投入组织与计算资源
- 让固定查询更容易形成服务契约
副本与双体系责任
- 重复存储和同步延迟
- Schema / Version 一致性
- 重跑、对账、治理与运维边界