易君召
易君召
发布于 2026-07-30 / 5 阅读
0

数据仓库(DW)与数据湖(Data Lake)协同工作完整方案

一、先厘清核心定位(协同的基础)

维度

数据湖 Data Lake

数据仓库 Data Warehouse

数据形态

原始、半结构化、非结构化(日志、音视频、JSON、原始数据库 binlog),原生格式存储

清洗、整合、建模后的结构化数据,范式 / 维度建模(星型模型)

存储模式

低成本对象存储(S3/MinIO/HDFS),存原始全量数据

高性能列式存储(ClickHouse、Snowflake、Hive 数仓、Greenplum),优化查询

Schema

Schema-on-Read(读时校验),灵活扩展

Schema-on-Write(写时固化),强约束、稳定

典型场景

数据采集、原始留存、探索分析、AI 特征、实时原始流、机器学习

BI 报表、指标口径统一、经营分析、固定报表、合规统计、OLAP 查询

核心思想:数据湖存 “所有原材料”,数据仓库加工 “标准化成品”;湖提供源头,仓服务确定性业务,二者不是替代关系,是上下游分工。

二、主流协同架构:湖仓一体(Lakehouse)是当前标准范式

行业两套落地路线:

  1. 传统分离架构(独立湖 + 独立数仓):适合存量系统改造

  2. 湖仓一体架构(统一存储,双层计算):现代云原生主流(Databricks、Iceberg+Hudi、StarRocks)

架构 1:传统分离式协同(最常见企业现状)

数据流链路:多源业务系统 → 数据湖 → 数据加工 → 数据仓库 → 应用

  1. 采集层(源头入湖)

    业务数据库、API、日志、物联网、文件、实时数据流(Kafka)全部先入数据湖

  • 数据湖分层:原始层(Raw)→ 清洗层(Staging)

  • 价值:永久保存原始数据,一旦上游数据丢失、口径变更,可回滚重跑,保留数据溯源基线。

❌ 误区:不要直接把业务数据灌入数仓!数仓成本高,不适合存海量原始日志。

  1. 数据湖进行初步治理与轻加工

    在湖中完成:去重、格式标准化、脱敏、简单清洗,生成湖内中间数据

    两类分流:

  • 分流 A:探索类需求留在湖内

    算法建模、临时自助分析、非结构化数据处理、新需求探索,直接使用湖数据,不需要进入数仓;

  • 分流 B:标准化指标、经营数据同步至数据仓库

    将经过统一口径、验证后的结构化明细 / 汇总数据,定时 / 实时同步到数据仓库。

  1. 数据仓库承担标准化服务

    数仓内按照分层建模(ODS/DWD/DWS/ADS)构建企业统一指标体系,面向:

    BI 看板、管理报表、业务固定查询、财务统计、合规报表。

  2. 双向回流(可选)

    数仓产出的高质量汇总指标,回写到数据湖,供算法、跨部门二次复用。

架构 2:湖仓一体(Lakehouse,下一代融合方案)

统一底层存储(对象存储),一份数据,两套计算引擎共享

不再物理拷贝数据,数据只存一份(Iceberg/Hudi/Delta Lake 表格式):

  • 用 Spark/Flink(湖引擎)做原始数据接入、ETL、特征工程、AI 计算;

  • 用 OLAP 引擎(StarRocks/Doris/Snowflake)直接读取同一份存储文件,提供数仓级高性能 SQL 查询;

优势:消除数据拷贝、减少存储冗余,统一元数据,避免湖、仓两套元数据不一致问题。

三、标准分层协同数据流(实操分层)

1)数据湖分层

  • Raw 层(原始层):原样落盘,不修改,不可删除,数据基线

  • Clean 层(清洗层):脏数据过滤、格式统一、脱敏

  • Feature 层(特征层):面向 AI、探索分析

2)数据仓库分层(来源于湖 Clean 层)

  • DWD 明细层:从湖中清洗后的明细数据同步

  • DWS 汇总层:轻度聚合

  • ADS 应用层:业务指标宽表

完整流转示例

业务 MySQL binlog → Kafka → 数据湖 Raw → 清洗至数据湖 Clean

→ ① 算法团队直接读取湖 Clean 做模型训练

→ ② 同步到数据仓库 DWD → 逐层汇总 → BI 报表查询

四、两者协同的核心价值

  1. 低成本留存全量原始数据

    数据湖解决数仓不敢存海量原始日志、非结构化数据的痛点;数据仓库不承担冷数据存储压力。

  2. 隔离两种分析模式

  • 探索式、不确定、灵活多变分析 → 湖

  • 确定性、口径严格、高并发报表 → 仓

    避免临时探索查询冲击报表业务。

  1. 统一数据源头,保障口径一致

    所有加工起点统一来自数据湖原始数据,杜绝 “湖一套数据、仓一套源头” 造成指标打架。

  2. 数据可回溯

    当报表指标出错,可从湖中原始数据重新计算,不需要依赖数仓历史快照。

五、关键技术实现要点(落地避坑)

1. 数据同步方式(湖→仓)

  • 批量同步:Flink/Spark 定时将湖内结构化数据写入数仓(Greenplum、ClickHouse)

  • 实时同步:基于 CDC + 湖内增量文件,实时落地数仓明细

  • 湖仓一体方案:OLAP 引擎直接挂载对象存储,无物理同步(推荐新项目)

2. 元数据协同(重中之重)

必须统一元数据中心(Apache Atlas、Hive Metastore、Catalog):

数据湖的表、分区、字段、血缘同步给数据仓库,实现统一数据地图,避免两套目录。

3. 权限与治理打通

统一数据脱敏、访问权限、数据质量规则:

原始数据在湖完成脱敏,下游同步到数仓的数据天然合规,不需要重复治理。

六、常见误区

  1. ❌ “有数据湖就不需要数据仓库”

    数据湖缺少强建模、稳定查询优化,直接用湖对外提供 BI 报表,并发、延迟、稳定性很难满足业务;

  2. ❌ “先建数仓,再考虑湖”

    原始数据没有留存,后续指标回溯、算法建模缺少数据源;

  3. ❌ 湖和仓分别采集业务数据(双采集)

    两套源头极易出现数据不一致,标准做法:统一入湖,仓从湖取数

七、极简总结一句话

数据湖作为企业统一数据底座,承载全品类原始数据与灵活探索计算;数据仓库从湖中获取经过清洗规范的数据,构建标准化模型与统一指标,支撑企业稳定经营报表;二者共享统一数据源,分工承载 “灵活探索” 和 “确定性业务分析”,湖仓一体是消除数据冗余的最优演进方向。


原文链接 https://www.yijunzhao.cn/archives/data-warehouse-data-lake-collaboration-guide

欢迎访问 小易撩挨踢

https://www.yijunzhao.cn/