上一篇文章解决了“数据怎么进来”的问题——通过ETL/ELT管道、CDC实时同步、对账引擎和调度编排，将分散在数十个异构系统中的数据汇聚到统一的平台上。
但数据进来之后，存在哪里？怎么存？怎么管？怎么用？
如果存储层设计不当，数据集成再高效也是徒劳——数据可能杂乱无章地堆积、查询性能低下、数据质量无法保障、分析人员找不到想要的数据。数据底座的地基，一半在集成，一半在存储。
本章聚焦数据底座的存储与计算层，拆解湖仓一体的架构设计——为什么快消品企业需要湖仓一体？数据湖和数据仓如何分工？从ODS到DM的四层建模如何落地？DataOps如何让数据工程从“手工作坊”变为“自动化流水线”？
一、为什么快消品需要湖仓一体
传统数据仓库的局限
数据仓库是过去二十年企业数据架构的主流选择。它通过严格的分层建模（ODS→DWD→DWS→DM）和预先定义的数据模型，提供了高性能的查询能力和规范化的数据管理。但它的局限同样明显——无法存储非结构化数据（如图片、视频、日志、JSON文档），扩展性差、改造成本高。
对于快消品企业而言，非结构化数据的价值正在急剧上升：门店的货架照片、消费者的社交评论、生产线上的设备日志、电商平台的用户行为数据——这些都无法被传统数仓有效处理。
数据湖的短板
数据湖的出现解决了非结构化数据的存储问题。它允许企业以原始格式存储任何类型的数据，成本低廉、扩展性强。但数据湖也有明显的短板——缺乏ACID事务保障、数据质量难以管控。数据湖往往沦为“数据沼泽”——数据越堆越多，但没人知道里面有什么、质量如何、能不能用。
湖仓一体：兼得两者之长
湖仓一体将数据湖的灵活性和数据仓库的易用性、规范性、高性能结合起来。它基于开放格式（如Iceberg、Delta Lake、Hudi）构建，既支持海量原始数据的低成本存储，又支持高性能的BI分析和AI/ML工作负载。
对于快消品企业而言，湖仓一体的价值在于：一套架构、一份数据、多种用途——既支持日常的BI报表，也支持AI模型训练；既处理批量数据，也处理实时数据。
行业趋势
湖仓一体正在成为快消品行业数据架构的主流选择。行业实践表明，传统饮料企业正在采用先进的湖仓一体与流批一体架构作为数据中台的技术支撑。欣和食品从“多引擎、多链路、无平台”的困局中走出，构建了近实时湖仓一体平台。青岛啤酒于2023年采用Cloudera私有云方案，迁移至灵活的数据湖仓架构。百事可乐从超过60个分散的数据湖整合为一个统一的数据架构。
二、湖仓一体的架构设计
数据湖（原始层）——所有数据的“原产地”
数据湖存储所有原始格式的数据——数据库的binlog日志、JSON格式的API响应、图片、视频、音频、传感器数据等。数据按原样入湖，不做任何清洗和转换。
这一层的价值在于保留数据的“原始面貌”。当未来的分析需求发生变化时，企业可以从原始数据重新加工，而不必因为前期“过度加工”而丢失信息。
数据仓（分层建模）——从原始到可用的四次跃迁
数据仓采用经典的四层建模架构，每一层都有明确的职责：
ODS（操作数据存储，贴源层）：与源系统基本一致，保留最原始的业务数据。这是数据进入数仓的第一站，主要作用是“原样接入”。
DWD（明细数据仓库，明细层）：对ODS层数据进行清洗、标准化、维度退化。比如将“小米椒”“小米辣”“小米辣椒”统一为“小米椒”，将不同系统的日期格式统一为标准格式。
DWS（汇总数据仓库，汇总层）：按主题进行轻度汇总。比如按“日+区域+品类”汇总销售额，供后续分析使用。
DM（数据集市）：面向特定业务场景的聚合表。比如“门店销售日报”“品类库存周报”——直接供BI工具和业务人员使用。
缓存与归档——热数据加速、冷数据降本
缓存层：将高频访问的热数据（如最近30天的销售数据）存储在Redis等高速缓存中，实现毫秒级查询响应。
归档层：将低频访问的冷数据（如5年前的财务数据）迁移至廉价存储（如OSS归档），降低存储成本。
欣和食品的湖仓一体实践
欣和食品的实践是湖仓一体架构设计的典型案例。欣和创立于1992年，是国内领先的高端调味品生产企业，旗下拥有葱伴侣、六月鲜、六月香、黄飞红、醯官醋等11个品牌，产品涵盖酱油、酱、醋、蚝油、有机酱油、休闲零食等多个系列。在全国，每天超过4000万家庭在使用欣和的产品。¹
随着多年业务积累，欣和大数据平台已运行7年，面临技术栈异构、运维与开发效率瓶颈等核心挑战。平台依赖多种自建与云上组件（它云云原生数仓/EMR/Airflow等），技术体系分散，导致维护成本高昂，新业务数据需求响应缓慢。¹
欣和最终选择基于阿里云数据中台产品体系，构建以MaxCompute（离线计算）+Hologres（实时分析）为核心的湖仓一体架构，DataWorks作为统一调度与数据治理中心。¹ 该架构全面替代了原开源ClickHouse、开源StarRocks、它云云原生数仓等多引擎并存的复杂环境，实现了“流批一体化”处理能力。¹ 通过近实时湖仓MaxCompute，防止数据重复处理，通过范数仓分层简化数仓架构。基于Hologres实现OLAP查询、即席分析、点查和在线数据服务的统一，提升分析效率。¹
迁移历时3个月完成。¹ 迁移后，任务整体耗时从8小时降低到4小时，ODS层数据及时性提升99%。¹ 迁移过程中制定了核心表全表比对、差异控制在0.0001%以内的高标准验收规范。¹ 通过双写、灰度发布等策略，实现了对BI报表等业务的无感迁移，真正做到“飞行中换引擎”。¹ 近实时湖仓一体平台支持准实时增量同步，显著增强数据处理时效性。¹
三、DataOps——让数据像代码一样高效流转
数据工程的“手工作坊”困境
传统的数据开发模式类似于“手工作坊”——数据工程师手动编写ETL脚本、手动调度任务、手动处理异常。随着数据量和任务数量的增长，这种模式难以为继。
联合利华的案例很有代表性。联合利华是全球最大的快消品公司之一，每天销售超过10亿件产品，旗下拥有多芬、好乐门、Tresemmé等品牌。² 其数据生态系统横跨PB级信息，来自内部来源、第三方合作伙伴和外部供应商，以不同的间隔和格式流入。² 工程团队依赖通过外部编排工具触发的Spark任务，但环境已变得过于复杂而无法高效管理。管道脆弱且相互依赖，调试问题耗时，解决一个故障往往意味着更新多个系统才能让报表恢复在线。²
联合利华客户分析团队高级数据科学经理Evan Cherney坦言：“我们团队被困在维护管道上，而不是创造洞察，这限制了我们的影响力。”²
DataOps的核心思想
DataOps将软件工程中的CI/CD（持续集成/持续交付）理念引入数据领域。它的核心思想是：像管理代码一样管理数据——建立自动化的数据管道、引入数据沙箱进行安全测试、实现全链路的数据可观测性。
联合利华的DataOps实践
联合利华围绕Databricks Data + AI Platform和Spark声明式管道重建了数据架构。² 从手动编排的管道转向声明式工作流，系统自动处理依赖关系、强制执行数据质量，并提供数据如何在系统中流转的完整可见性。²
采用奖章架构（Medallion Architecture），以青铜层（Bronze）、白银层（Silver）、黄金层（Gold）和白金层（Platinum）四层来组织数据。² 批处理和流数据现在通过单一、弹性的管道流动，质量检查和转换在管道内原生处理。² “不再需要手动拼接表格和担心刷新依赖，我们现在专注于交付洞察。Spark声明式管道管理工作流，处理质量检查，并给了我们前所未有的透明度。”Cherney说。²
成果显著：整体基础设施成本降低25%，管道和数据处理效率带来200-500%的时间节省。²
四、湖仓一体与DataOps的实践案例
青岛啤酒：从传统架构到灵活湖仓
青岛啤酒成立于1903年，是中国最早的啤酒企业之一，在全国拥有60家啤酒厂，月产数百万罐，产品销往全球120多个国家，是世界第六大啤酒厂商。³
2018年，青岛啤酒启动了数字化转型计划，从“产品中心”转向“用户中心”，建立了智能工厂以支持个性化定制。³ 但随着数据量的持续增长，数字化转型也带来了新的挑战——扩展性问题、新的数据孤岛、缺乏统一的数据标准、数据汇聚困难等。³
2023年，青岛啤酒采用Cloudera私有云方案，迁移至灵活的数据湖仓架构。³ 新架构同时支持实时数据处理和批量数据处理。³ 实施后，报表加载时间从10分钟缩短至秒级，数据加载和处理时间从天级缩短至小时级。³ 团队能够进行实时数据分析以获得即时销售洞察。³ Cloudera灵活全面的数据管理技术帮助其降低了成本并推动了效率提升。³
百事可乐：企业级数据智能平台
百事可乐是全球最大的食品和饮料公司之一。⁴ 四年前，百事可乐启动了一项为期多年的数字化转型，目标是将一个存在了27年的碎片化BI环境迁移到一个统一的、受治理的分析和AI平台上。⁴
百事可乐选择了Azure Databricks SQL和Unity Catalog作为其数据治理与分析的核心工具。⁴ Unity Catalog已成为百事可乐数据基金会（PepsiCo Data Foundation）不可分割的一部分，这是一个集中化的全球系统，整合了全球超过6PB的数据。⁴
成果可量化：一个主要的销售分析工作负载成本下降了约80%——从大约50万美元降至17.5万美元，同时性能相似。⁴ 核心财务和商业表格现在在Databricks SQL中构建一次，即可提供给Power BI和Tableau使用，处理时间提升了约50%。⁴ 来自多个旧数据仓库和业务数据湖的数据现在存在于一个统一的企业数据基础中，简化了技术栈，并为AI驱动的规模化分析做好了准备。⁴
联合利华：声明式管道与数据治理
联合利华的数据生态系统横跨PB级数据，来自内部来源、第三方合作伙伴和外部供应商。² 工程团队依赖通过外部编排工具触发的Spark任务，但环境已变得过于复杂而无法高效管理。²
联合利华围绕Databricks Data + AI Platform和Spark声明式管道重建了数据架构。² 采用奖章架构（Bronze、Silver、Gold、Platinum四层）来组织数据。² 批处理和流数据现在通过单一、弹性的管道流动，质量检查和转换在管道内原生处理。²
成果：基础设施成本降低25%，管道和数据处理效率带来200-500%的时间节省。²
五、避坑指南——湖仓建设中的常见陷阱
陷阱一：认为“买了湖仓产品就等于建好了湖仓”
湖仓一体是架构理念，不是某个产品。购买了云厂商的湖仓产品只是起点，真正的挑战在于数据建模、数据治理、团队能力的建设。欣和食品的案例表明，从“多引擎并行”到统一湖仓，核心是架构治理而非产品采购。¹
陷阱二：忽视数据治理，让湖仓沦为“数据沼泽”
数据湖如果没有良好的治理，很快就会变成“数据沼泽”——数据越堆越多，但没人知道里面有什么、质量如何、能不能用。百事可乐的经验是从第一天起就将治理内建于架构中。百事可乐选择了Databricks Unity Catalog作为数据治理的核心工具，将治理、目录、血缘管理内建于数据平台中。⁴
陷阱三：盲目追求“实时”，忽视成本与复杂度
CDC实时同步虽然强大，但也会增加系统复杂度和运维成本。并非所有数据都需要实时。企业需要根据业务需求，合理区分“实时”“准实时”和“批量”的数据处理场景。欣和食品的“近实时”方案——而非全实时——提供了一个务实的参考。¹
陷阱四：忽视团队能力建设
湖仓一体和DataOps对团队能力提出了更高要求。如果团队不具备相应的技能，再好的架构也无法发挥价值。联合利华的经验表明，简化架构本身就是降低团队负担的重要手段——从手动编排管道转向声明式工作流，系统自动处理依赖关系。²
湖仓一体解决了“数据怎么存、怎么算”的问题——数据湖保留原始面貌，数据仓完成四次跃迁（ODS→DWD→DWS→DM），DataOps让这一切自动化运转。欣和食品50%的任务性能提升、青岛啤酒从天级到小时级的数据加载提速、百事可乐80%的成本节省、联合利华200-500%的管道效率提升——这些数字背后，是一套扎实的存储与计算架构带来的真实价值。
但存储和计算只是手段。数据的终极价值在于被使用——被业务人员找到、被分析师理解、被AI模型调用。
下一篇文章，我们将进入数据服务层，拆解数据资产管理平台的建设——如何将数据从“成本中心”转变为“利润中心”？如何让数据资产入表？如何建立统一的指标体系和数据血缘？
注释
¹来源于欣和食品公开案例。欣和创立于1992年，旗下运营11个品牌，全国每天超4000万家庭使用欣和产品。原有大数据平台已运行7年，面临技术栈异构、运维瓶颈等挑战。迁移至阿里云MaxCompute+Hologres湖仓一体架构，以DataWorks为调度治理中心。项目历时3个月完成，任务整体耗时从8小时降至4小时，ODS层数据及时性提升99%，核心表差异控制在0.0001%以内。
²来源于联合利华公开技术分享及行业报道。联合利华日销超10亿件产品，数据生态系统横跨PB级。采用Databricks Data + AI Platform和Spark声明式管道重建架构，以青铜层、白银层、黄金层、白金层四层奖章架构组织数据。客户分析团队高级数据科学经理Evan Cherney的相关评论引自其公开分享。成果：基础设施成本降低25%，管道效率带来200-500%时间节省。
³来源于青岛啤酒公开案例。青岛啤酒成立于1903年，全国60家啤酒厂，产品销往全球120多个国家，世界第六大啤酒厂商。2018年启动数字化转型，2023年采用Cloudera私有云方案迁移至湖仓架构。报表加载时间从10分钟缩短至秒级，数据加载从天级缩短至小时级。
⁴来源于百事可乐公开技术分享。百事可乐启动多年数字化转型，将碎片化BI环境迁移至统一分析平台，选择Azure Databricks SQL和Unity Catalog，整合全球超6PB数据。销售分析负载成本下降约80%（从50万美元降至17.5万美元），核心表格处理时间提升约50%。
