为什么所有数据先进湖，却只有一部分进入仓？
从 Lake-first 链路出发，根据访问、SLA、复杂度和成本收益判断哪些数据需要高性能查询服务。
银行平台每天接到三种数据
为什么所有数据先进湖，却只有一部分进入仓？
Transaction、手机银行事件和合作方文件都先进入 Lake。早上的经营看板需要稳定查询，几年前的行为记录却只在调查时才会被读到。它们不必接受同一种成本安排。
数据已经在 Lake，什么情况下还值得为查询建立 Warehouse 服务层？
核心概念
Lake-first：统一承载，按需服务
Lake 先承担完整历史、原始 / 明细和多种形态；当部分结构化数据有高频访问或明确查询 SLA 时，再把它加工到 Warehouse 服务层。
先看三种数据怎样到达同一个底座
Transaction 是一笔账户交易，字段和行含义比较稳定；手机银行行为事件会持续到达；合作方批量文件则可能保留一段时间再分析。平台先把这三类输入放进 Lake，保留原始上下文和完整历史。
这条链路给后续选择留下了空间：同一份数据可以继续在 Lake 中被低频读取，也可以因为 BI 或查询 SLA 的要求进入 Warehouse。进入仓是一次后续加工 / 同步，不是第二条并行接入路线。
- Lake 负责先接住数据，不要求每种输入一开始就拥有相同的查询组织。
- AccountBalanceSnapshot 是状态快照，Transaction 是发生事件；两者的业务语义仍要分别说明。
- “能查询”只说明有读取路径，还没有说明应该为它投入多少服务成本。
10-1 · Lake-first 数据流
改变需求，看哪些数据值得进入 Warehouse
所有输入先进入 Lake。切换访问频率、查询 SLA、查询复杂度和消费方式，观察当前需求下哪些数据需要建立 Warehouse 副本。
正在加载交互实验…
冷热是服务需求的组合判断
高频 BI 和固定 SLA 查询更愿意使用结构化、受管理的 Warehouse 服务层；低频历史分析和长期明细留存更看重 Lake 的容量、开放形态和完整上下文。查询复杂度、并发和消费方式也会改变这笔投入是否划算。
因此同一份数据可能在某个阶段只留在 Lake，后来因为访问变频繁而增加 Warehouse 副本；也可能一直留在 Lake。数据“新不新”可以提供线索，却不能单独决定它是热还是冷。