1. 为什么总有人在这两个词上栽跟头先厘清“模式”而不是“存储”前阵子帮一家创业公司做技术评审他们的数据团队leader信誓旦旦地讲“我们已经把数仓全部迁到了数据湖上现在数据湖就是我们的数仓。”我问他数据怎么组织的他说“Parquet文件一股脑扔S3里要用的时候临时拉”。再问数据质量怎么保障他说“业务部门自己看着办”。这种场景我见过太多次了——很多人把数据仓库和数据湖当成单纯的存储选型其实这是两种完全不同的数据管理哲学。先说一个最容易混的点数据仓库是“写时建模”数据湖是“读时建模”。这句话是理解两者差异的总钥匙。传统数仓的理念是数据进来之前先想清楚它长什么样、代表什么、怎么关联。就像图书管理员在买书之前就规划好了书架编号、分类规则、索引卡片每本新书进馆按既定规则摆放读者查询时才能秒级定位。整个过程叫ETL抽取-转换-加载数据在写入阶段就已经被清洗、标准化、建模使用的时候拿到的是规规整整的“成品”。数据湖的理念反过来了先把所有数据原样扔进一个巨大的池子不管它是结构化表格、半结构化的JSON日志还是非结构化的图片视频音频先存下来再说。存的时候不急着定义它的用途、格式、关联关系等将来某个业务方说“我要分析这批东西”时再现场设计读取逻辑这个过程叫ELT抽取-加载-转换。就像你家里有一个大收纳箱所有东西先扔进去哪天要用了再翻出来整理。对比一个典型场景就明白了业务系统每天产生一批订单明细文件字段有变更有新增。在数仓里你必须先改表结构、调整ETL映射、重跑历史数据才能查询新字段在数据湖里文件直接丢进去查询时用SQL引擎现场解析新字段旧查询不受影响。这个本质差异带来了一连串连锁反应存储成本、查询性能、数据治理难度、使用灵活性全部不同。我在后续章节详细拆开讲。2. 从一份订单数据的完整旅程看两类系统的设计取舍光讲概念太空了。我拿一个真实业务来推演假设你是电商平台每天产生千万级订单数据现在需要做“按用户维度的消费行为分析”。同一个需求在数仓和数据湖里的处理路径完全不同。2.1 在数据仓库里的处理路径订单数据从业务库出来先经过清洗去掉测试订单、填充缺失值、统一金额单位再转换把商品ID关联到商品维表把订单时间对齐到日期维表把用户ID关联到用户画像最后加载到一个叫fact_order的星型模型事实表中。整个过程是固定管道跑批任务定时调度结果写入高性能存储比如ClickHouse、Doris或者传统MPP数据库。分析师查询“近30天高价值用户的下单频次”时SQL直接扫事实表因为数据已经按用户维度做了预聚合毫秒到秒级出结果。这个过程非常稳定但代价是改模型很痛苦。如果业务方说我不要按用户维度了要按商品品类分析那就要重建一整套维度和事实表重跑历史数据。数仓的排期通常以天为单位从需求提出到数据可查往往要一周以上。2.2 在数据湖里的处理路径订单数据直接以Parquet格式写进数据湖的raw/order/目录分区按照dt2024-01-01这样的结构组织。不建表、不建模、不校验格式。分析师想查高价值用户的消费行为直接写一条Spark SQL或者Trino查询在读取时现场做关联、过滤、聚合。这个过程灵活到什么程度你不需要提前定义“高价值用户”的口径——在SQL里现场用窗口函数算就行。今天觉得消费金额前10%算高价值明天改成交互频次第20百分位以上算高价值随时改随时查。业务口径还没定的时候数据湖能让你边探索边定口径这是数仓给不了的。但代价也很明显每次查询都要全量扫描/过滤底层文件计算引擎要现场解析整个目录结构如果文件数量太多或者格式不优一个查询跑十几分钟甚至更久很正常。而且由于没有统一的模型层同一个指标在不同人写的查询里口径可能完全不同——A算的GMV含退款订单B算的GMV不含两个人各自认为自己对。2.3 两者对比直接拉一张表对比维度数据仓库数据湖建模时机写入前schema-on-write读取时schema-on-read数据形态已清洗、已建模的结构化数据原始数据为主格式多样查询延迟低毫秒~秒级高秒~分钟级存储成本高需要高性能存储低廉价对象存储灵活性低改模型成本高高随时尝试任意分析数据质量强有统一标准弱依赖使用方自行把控使用人群分析师、报表系统数据科学家、临时探索人员对应存储引擎MPP数据库、OLAP引擎Hadoop、Spark、Iceberg等从这个表格能看出来数仓和数据湖不是升级关系而是面向不同场景的差异化工具。用数仓的核心诉求是稳定可靠地支撑报表和固定看板用数据湖的核心诉求是灵活低成本地支撑探索和分析。3. 选型判断框架你的业务到底处在哪个阶段最蠢的决策方式是“因为数据湖很火所以我要上数据湖”或者反过来“数据仓库是老技术我们不用了”。我自己的经验是从三个维度来逼自己做判断。3.1 业务对数据延迟的容忍度如果是实时风控、实时大屏、OLTP联机分析这种——查询必须秒出、延迟抖一下就报警——那没得商量必须用数仓或者至少用支持索引预聚合的OLAP引擎。数据湖的现场解析模式在延迟上先天吃亏你可以在湖上做优化但天花板就摆在那里。如果是离线报表、T1分析、机器学习训练样本准备——查询跑几分钟能接受——那数据湖完全够用甚至更合适因为训练样本通常需要大量探索性清洗数据湖的灵活性正好匹配。3.2 数据形态的多样性我见过最典型的“数仓之痛”一家物流公司想把快递柜的摄像头录像、传感器日志和运单数据放在一起分析。运单数据放数仓没问题但录像文件和日志进了数仓基本就是灾难——要么转格式存Blob失去分析能力要么塞进数仓的二进制字段查询时完全用不上。这种情况下数据湖是唯一合理选择。反过来如果你的数据基本都是业务库的表用数仓从成本、效率、治理上都是最优的。判断标准很简单你日常处理的数据里结构化表格占多少如果低于80%建议认真考虑数据湖。3.3 团队的建模能力和治理习惯这部分是最容易被低估的。数据湖的灵活性是把双刃剑它把数据治理的责任从“平台侧”转移到了“使用方侧”。没有建模能力、没有元数据管理工具、没有数据质量监控体系的团队上了数据湖大概率会变成“数据沼泽”——所有数据扔进去找不着、不知道谁在用、口径乱成一锅粥。之前见过一个真实案例某零售企业上了数据湖三个月后湖里躺了2万多张“临时表”一半以上没人知道是谁建的、逻辑是什么。反观数仓因为写入前就要强制建模反而逼着团队想清楚。我的建议技术团队少于10人、还没有专职数据工程师的时候老老实实用数仓选个开源的Doris或者ClickHouse就行。等团队规模上来了再来谈数据湖的架构优势。4. 架构实战数据仓库与数据湖的常见协同模式实际生产环境里绝大多数中大型企业不是二选一而是“湖仓并行、数据分层”。下面是我观察到的几种高频架构模式以及它们各自适合的场景。4.1 数据湖为基座数仓为输出层这是目前最主流的数据架构演进方向。原始数据先进数据湖——成本低、不限制格式所有明细数据、日志、归档数据都在湖里完整保留然后通过调度任务把湖里的数据按需抽取、建模、聚合装载到数仓的模型层供报表和固定分析使用。这种模式的最大优点湖是“数据全集”仓是“数据精品”。任何历史数据都能在湖里找到原始凭证数仓只保留高质量、高复用度的模型数据。遇到数仓模型算错或口径大改可以从湖里重新跑一遍不用发愁原始数据丢了。4.2 数仓支撑日常分析数据湖承载临时探索如果团队已经有成熟的数仓体系不必强拆。我见过不少团队的做法是日常看板、固定报表走数仓所有“没有明确口径的探索性分析”一律引导到数据湖上去跑。数据湖上建一套完整的原始数据接入链路分析师自己拉数据自己算不用再排队改数仓模型。这种模式的好处极其明显数仓团队的工作量急降分析师自主性大增。坏处是需要在数据湖上做一定程度的元数据登记比如用Hive Metastore或者Glue Catalog挂表否则湖上数据没人找得到。4.3 利用湖格式技术实现“湖上建仓”这几年Iceberg、Hudi、Delta Lake这类湖表格式技术发展得很快它们把数仓的ACID事务、时间旅行、增量读取能力带到了数据湖上。听起来很完美但我必须提醒几句。我自己的实测经验Iceberg在并发写入场景下性能还是没法跟成熟的MPP数仓比而且技术栈复杂度陡增——你要维护Hive Metastore、Spark/Flink引擎、文件压缩调度、快照过期策略。团队没有专门的大数据平台组慎上。就拿数据回滚和时间旅行来说Iceberg确实能让你把表回滚到任意快照但快照文件会疯狂膨胀没人定期清理的话存储成本直接翻倍。我在后面第5节专门列了一堆翻车点。4.4 选型决策表直接抄作业业务场景推荐架构理由百人以上团队有专职数据平台组数据湖数仓双层或湖仓一体能驾驭复杂度中小团队核心需求是固定报表单数仓Doris/ClickHouse上手快运维简单大量非结构化数据分析需求必上数据湖数仓存不了/难分析实时性要求高的场景数仓实时链路如Flink写入Doris延迟敏感数据科学团队做模型训练数据湖为主灵活探索样本特征5. 数据湖的隐藏成本与翻车现场数据湖看起来是“便宜大碗”但生产环境跑起来隐形坑一个接一个。我挑几个最常见的展开讲这些是我自己和客户们踩过的真实坑不是网上抄来的。5.1 小文件问题数据湖性能杀手数据湖底层通常挂对象存储S3、OSS、HDFS而这玩意最怕大量小文件。举个例子Flink实时写数据湖默认的checkpoint频率如果设置很高——比如每5秒一个checkpoint——一天下来可能产生上百万个小文件。查询时要频繁打开/关闭文件句柄集群元数据服务直接被压垮。解决思路用Iceberg的RewriteDataFiles定期合并小文件或者在Flink端增加写入buffer、降低checkpoint频率、用分区粒度控制文件大小。我建议的优化路径是小文件合并任务每1小时跑一次目标文件大小控制在128MB-512MB之间。这块具体参数没有通解得用你的实际数据量和查询频次来试。5.2 元数据失控湖里的表没人说得清文件存了一堆但“这个目录是什么数据、字段含义是什么、谁负责更新”这些元信息完全没记录是数据湖最常见的腐化路径。很多团队以为用Hive Metastore挂个表就够了但元数据不止是schema还包括数据血缘、数据owner、更新频率、质量规则。我的应对经验是建湖第一天就强制登记元数据。没有登记的数据不允许写入事实目录宁可多花时间在前期也比后期捞数据时大海捞针强。用Apache Atlas或者DataHub这种工具做自动血缘采集再配一个字段注释规范基本能解决问题。5.3 权限模型混乱数据泄露的温床对象存储上的目录权限和SQL引擎里的行级/列级权限是脱节的。生产上最常见的翻车案例数据湖里存了用户手机号、身份证、地址但分析师用Athena/Trino查询时能SELECT整个表没有任何行级限制。这时候你再回头看数仓——通常有完整的权限模型和脱敏策略——差距就出来了。我的建议数据湖上必须做统一权限网关至少要接一层Ranger或者类似组件给不同角色分库分表授权敏感字段强制脱敏。对象存储的IAM权限只是第一层不是全部。5.4 数据质量没人负责湖里的脏数据拖垮下游数仓里ETL任务失败会有告警、有重跑、有补偿机制数据湖里文件写了一半就标记完成的情况太常见了。最坑的是下游任务读到脏文件不知道导致分析结果偏差业务方拿着错数据做了决策回头追责发现根因在数据湖的写入链路上。建议在数据湖写入链路里加一个质量校验步骤文件落库后计算引擎抽查行数、空值率、主键去重率不达标就打回重跑达标才算任务成功。这部分可以用Apache Griffin或者自研但千万别省。6. 一个真实落地节奏的数据架构演进路径参考最后我拿一个真实的金融行业场景来串一下前面所有内容——这里可以引用热搜里提到的中行广东分行这类实践方向但我不讨论具体某个机构只讲这类场景下最常见的数据架构演进路径。6.1 起步阶段0-1年单数仓打天下刚起步的团队核心诉求是“先把报表跑起来、把业务口径定下来”。这时候不需要数据湖一套成熟的数仓方案就够。选型建议如果用云直接上云数仓如Redshift、MaxCompute如果自建Doris或ClickHouse能覆盖绝大多数需求。这个阶段最重要的是建立维度建模规范和数据质量体系而不是追逐潮流。6.2 扩张阶段1-3年湖仓双层并行业务变多、数据源变杂日志、传感数据、外部三方数据数仓的存储成本和建模周期开始卡脖子。这个阶段就开始建设数据湖把原始数据湖作为公共服务层所有原始数据先沉淀到湖区数仓保留服务质量和模型资产。双层的核心挑战是湖到仓的数据装载链路必须可靠调度、监控、重试机制做扎实。6.3 成熟阶段3年以上湖仓一体当团队掌握了Iceberg/Hudi这类湖表格式数据工程师能力也到位了再考虑把部分数仓模型迁到湖上实现“一份存储、多种引擎”。这也是主流厂商Databricks、华为FusionInsight等在推的方向。但我必须泼冷水湖仓一体的收益主要体现在节省了数据搬迁的成本和扩大数据分析的边界同时这个阶段大幅依赖团队工程能力。我见过不少团队上了湖仓一体后因为Flink/Spark调优不到位性能比原来的MPP数仓差了两三倍还得请外部专家救火。所以就落地路径来看很多金融、政企用户的节奏是数仓先行把业务跑稳再逐步引入湖的能力等工程团队真正能驾驭大数据组件之后才谈架构大合并。数据架构没有一步到位的银弹只有匹配当前阶段的最优解。6.4 决策自查清单动手前过一遍数据延迟要求秒级还是分钟级或离线数据格式多样性结构化数据占比高不高团队规模有没有专职的大数据平台工程师治理需求是否需要行级权限、脱敏、数据血缘成本预算存储成本优先还是研发人力优先这张清单每一行都值得认真思考。我自己在无数的架构评审里见过太多因为跳过其中某条而翻车的项目——尤其是团队规模这条很多人以为上个数据湖框架不费事结果运维半年后哭着改回数仓。做数据架构选择先别急着追新把业务需求、团队能力、数据形态、成本模型想清楚比选哪个具体技术栈重要得多。你可以从数仓起步也可以从湖起步但真正关键的是搞清楚自己当前到底需要什么以及未来一年会需要什么。这个判断做对了后续的架构演进才走得稳。