数据湖仓一体架构选型：数仓、数据湖与 Lakehouse 决策

数据仓库、数据湖与湖仓一体（Lakehouse）并不是"谁取代谁"的路线之争，而是不同成本结构、时效要求与负载特征下的适配问题。一句可执行判断是：当业务要求强一致、口径稳定的报表与财务数据，数仓仍是稳妥选择；当核心场景是低成本的原始数据沉淀、探索性分析与机器学习训练，数据湖具备天然优势；当同一份数据既要支撑报表又要喂给 AI、且希望减少多套系统间的搬运成本，湖仓一体是当前性价比最高的方向。选型的顺序应当是"先定位负载，再定架构，最后才谈存储格式"。

三种架构的边界：先回到定义

• 数据仓库：schema-on-write，数据在写入时就完成建模与约束，提供强一致的 ACID 事务，治理与权限体系成熟，但存储与计算成本高、扩展灵活性弱，适合口径稳定、变更频率低的报表与分析。
• 数据湖：schema-on-read，原始数据按低成本对象存储沉淀，schema 在使用时再定义，灵活性高、存储便宜，但早期的数据湖缺少事务、schema 约束与索引，容易演变成难以使用的"数据沼泽"。
• 湖仓一体（Lakehouse）：由 Databricks 在 2019 年前后提出并系统化（见 https://www.databricks.com/blog/what-is-data-lakehouse ），本质是在廉价的对象存储/分布式存储之上，用开放表格式补上 ACID 事务、时间旅行、schema 演化与索引能力，让"数据湖的存储成本"与"数仓的分析体验"在同一份数据上共存。

理解这个递进关系很重要：湖仓一体不是在数仓旁边多建一套系统，而是把数仓的"体验层"下沉到湖的存储之上。这也是为什么近年架构讨论的焦点从"要不要湖"转向"用什么开放表格式给湖加事务"。

架构层决策矩阵：四个维度打底

选型不必从几百个特性出发，先围绕四个维度打分即可。每个维度给出判断问题，答案越明确，架构倾向越清晰。

• 成本：存储单价、计算与存储是否解耦、小文件与压缩治理的人力成本、多套系统间的数据搬运成本。数据湖与湖仓一体的存储成本显著低于数仓，但运维复杂度会转化为隐性人力成本。
• 时效：核心分析是 T+1 批处理、分钟级微批还是秒级实时？数仓与湖仓一体都能承载批与微批，秒级实时需要额外的流处理链路；纯数据湖对实时查询支持弱，通常需要计算引擎兜底。
• 一致性：是否存在跨表事务、跨域 join 后必须对账一致的口径？强一致要求越高，越需要数仓或带事务层的湖仓一体，裸数据湖不适合直接承载这类场景。
• AI 负载：特征工程是否直接读取原始数据？训练样本是否需要版本化与时间旅行回溯？是否要管理图片、文本等非结构化数据？AI 负载越重，越倾向"一份数据多种消费"的湖仓一体，而不是为报表单独物化一份。

把四个维度列成团队内部打分表（每维度 1-5 分），通常会得到清晰结论：全链路强一致、口径固定 → 数仓；原始探索与训练为主 → 数据湖；混合负载、希望一份数据多消费 → 湖仓一体。打分过程本身也是与业务方对齐需求的契机，比直接讨论"买什么平台"更有效。

三类架构的适用边界

• 数仓适合：财务口径、监管报表、核心 KPI 这类"变了要出大事"的数据；团队数据工程能力有限、需要成熟治理工具支撑的场景。不适合：海量原始日志的高吞吐沉淀、schema 频繁变化的探索场景、非结构化数据管理。
• 数据湖适合：原始数据全量归档、探索性分析与数据科学实验、训练数据集的低成本存放。不适合：需要 ACID 的增量更新、跨多表的一致性分析；如果只存不管，数据湖会快速退化为数据沼泽。
• 湖仓一体适合：报表 + 探索 + AI 训练混合负载，数据规模大且希望避免多套系统重复存储，团队愿意投入表格式与存储层的运维能力。不适合：对一致性要求极高但团队没有事务层运维经验，或数据量很小、一套数仓完全够用的场景。

开放表格式成熟：架构选择的分水岭

以 Apache Iceberg 为代表的开放表格式（https://iceberg.apache.org/ ）是湖仓一体从概念走向生产的关键。它给对象存储上的数据加上了事务、快照、时间旅行与 schema 演化，让"先存后治理"成为可行路径：数据可以先低成本入库，再由消费侧按需建模，而不是像传统数仓那样必须在写入前完成全部建模。

需要说明的是，表格式层的具体对比——比如 Iceberg 与 Hudi、Delta Lake 的差异——属于另一个主题，本文只讨论数仓/数据湖/湖仓一体的架构层选型边界。真正影响架构决策的是：开放表格式让"湖"第一次具备了承载企业级分析的一致性能力，也让 AI 负载有了统一的数据底座。对 AI 场景而言，特征与样本需要版本化、可回溯、支持按时间点重建，这些能力恰好与湖仓一体的事务与快照机制对齐，因此湖仓一体正在成为 AI-ready 数据层的事实选择。

迁移路径规划：从现状盘点开始

无论从数仓迁向湖仓一体，还是从裸数据湖"补课"升级，迁移都不应该是一次性"搬库"动作。推荐按以下顺序推进：

1. 盘点现状：列出所有数据源、消费方、SLA、计算成本与存储成本，先搞清"谁在用、多久用一次、多贵"。
2. 按负载分类：把数据分为稳定报表类、探索分析类、AI 训练类三类，分别标注时效与一致性要求。
3. 选试点域：从"成本最高或时效最差"的一个业务域开始，不要全量启动。
4. 双跑校验：新旧链路并行运行一段时间，逐口径对比结果，确认迁移不影响报表数字。
5. 灰度切流：按消费方分批切换，先切内部探索场景，再切正式报表，最后切对账类场景。
6. 治理前置：schema、血缘、权限、质量规则必须在迁移前定义，而不是迁移完成后再补。

整个过程中最容易犯的错误是"先迁数据再定治理"——数据一旦搬过去，再补 schema 约束与权限体系的成本会成倍上升。

常见失败模式

• 把湖仓一体当成"换存储"：只搬数据、不搬治理，结果是把数仓的规范丢掉，换了一个更大的沼泽。
• 平台先行、场景后置：先采购平台再找业务场景，架构与业务需求错位。
• 忽略表格式版本与兼容性：不同引擎对表格式版本支持不一致，跨引擎读写出现兼容性问题。
• 强一致场景裸跑在湖上：没有事务层兜底就承载对账与财务口径，一旦失败回滚成本极高。

落地建议

选型的终点不是"选了湖仓一体"，而是"选了一个能承载迁移与混合负载的底座"。选型之后，落地环节通常需要一套能统一承载批/流/OLAP 与湖仓存储的底座，袋鼠云 EasyMR 在 Hadoop 自研增强的基础上把这几类负载收进同一平台，适合作为迁移落地的参考。下一步最实用的动作是：本周内完成一次数据分类盘点，把四维打分表填出来，让架构结论从"感觉"变成"数据"。