1. 五种架构不是替代关系而是五种不同的数据组织方式我最早接触这几套概念的时候也以为它们是按时间顺序排队出现的先有数据仓库然后数据集市再进化到数据湖接着是数据网格最后大家发现都不完美于是搞出湖仓一体。这个线性理解害我走了不少弯路直到有一次在做一份跨部门报表时同一个活跃用户数在三个系统里跑出三个数字我才明白问题的本质——这五个词描述的压根不是同一件事它们在回答的是五个不同层次的问题。数据仓库回答的是口径怎么统一、指标怎么复用数据集市回答的是部门要的东西怎么快速给到数据湖回答的是什么数据都先存下来行不行数据网格回答的是数据团队扛不动全公司的需求怎么办湖仓一体回答的是存下来的原始数据和加工过的指标能不能放在一个体系里管。你看这五个问题可以同时存在很多公司今天的实际状态就是五套东西并存而不是谁把谁干掉了。这篇文章我打算按每种架构解决什么问题、代价是什么、什么时候该上、踩过哪些坑这条线来讲不讲教科书定义讲实际落地时你会遇到的选择。判断自己该用哪一种的标准其实很朴素先看你当前最大的痛点是数据找不到、口径对不上、部门需求响应慢、还是存储成本压不住痛点决定架构而不是反过来。一个我踩过的坑先别急着选技术栈先把谁负责哪些数据、谁有权用哪些数据这两张表画出来。技术选型错了好换责任边界错了要重构组织。还有个前提得说清楚这五种形态背后其实只有三个变量在变数据的结构化程度、加工的时机先加工后存还是先存后加工、以及治理权的归属集中还是分布。你把这三个变量想明白任何新冒出来的名词你都能自己归类不需要追着一波又一波的概念跑。2. 数据仓库先把口径钉死再谈性能数据仓库最核心的价值从来不是快而是准。它是那种你愿意为了一致性牺牲一点灵活性的地方。我见过太多团队上来就纠结用 ClickHouse 还是 Doris结果三种口径的 GMV 在系统里飘着性能再快也是白搭。数据仓库的本质是面向主题、集成、相对稳定、反映历史变化的数据集合。这四个词里集成是最费劲的因为集成意味着你要把来自十几个业务库的编码表、状态值、时间口径全部对齐。举个例子A 系统的订单状态用 0/1/2 表示B 系统用 pending/paid/cancelled 表示进了仓库必须统一成一套状态枚举还要映射历史数据。这一步没做完后面所有建模都是空中楼阁。2.1 分层设计ODS、DWD、DWS、ADS 各自该放什么分层不是为了好看是为了让每一层只有一种职责出问题的时候能快速定位是哪一层错了。我习惯的分法是这样层次存放内容加工方式典型保留周期ODS贴源数据与业务库结构基本一致抽取、轻量清洗3~12 个月DWD明细事实做过编码统一、去重、维度补全清洗、规范化12~36 个月DWS按主题聚合的轻度汇总如用户日粒度行为聚合、宽表化12~36 个月ADS直接服务报表和接口的结果表按需定制6~24 个月ODS 层我建议不要做业务逻辑只做技术处理字段类型转换、脱敏、时区统一。很多团队在 ODS 就开始写 case when结果业务规则一改追溯都追溯不到。DWD 层是真正干重活的地方编码映射、拉链、去重全在这层。DWS 层要克制别做成什么维度都往宽表里塞宽表一旦超过 200 个字段维护成本会指数级上升。实践里有个小技巧表命名带上层次前缀和更新频率比如dwd_order_detail_di日增量、dws_user_action_1d日粒度全量。命名规范这件事团队小的时候觉得无所谓等到表数量过千你会发现没有规范根本找不到表。2.2 维度建模与范式建模的分歧点在哪这个争论持续了三十年其实答案取决于你的使用场景。范式建模第三范式为主适合数据变化频繁、写入密集的场景冗余少、一致性强但查询往往要 join 七八张表分析师写 SQL 写到崩溃。维度建模星型、雪花把业务过程抽象成事实表加维度表查询简单、性能可控代价是维度更新时要处理缓慢变化维。我的选择标准很直接面向分析用维度建模面向集成用范式建模两者可以在同一仓库里共存。DWD 层用偏范式的方式保持干净DWS 和 ADS 层用星型模型服务查询。缓慢变化维我一般用拉链表记录 start_date、end_date、is_current因为很多业务要复盘当时的用户等级是什么直接覆盖维度的做法会把历史判断全部抹掉。拉链表的坑更新逻辑一定要幂等跑重了不能产生重复区间。我一般会加唯一索引或者用 merge 语法跑批前先删当天分区再重跑。2.3 小型数据仓库的选型清单不是每个团队都需要一套庞大的集群。数据量在千万级到亿级、并发查询几十个的场景下面这几种组合完全够用PostgreSQL 分区表 物化视图单机就能扛住几亿行配合列存扩展如 cstore_fdw 之类思路还能更省。运维成本几乎为零适合 5 人以下数据团队。ClickHouse 单机或小集群写入吞吐和聚合查询极强适合日志、埋点类宽表分析。缺点是 join 弱、更新麻烦别拿它当交易库用。Apache Doris / StarRocks 小集群MPP 架构支持较好的 join 和实时更新三五个节点就能跑起来适合既要实时又要多维分析的场景。DuckDB单文件、嵌入式适合本地做数据探索和中小规模 ETL直接把 parquet 文件当表查做原型验证特别快。选型的核心不是比谁参数好看而是比你的团队能不能维护它。一个需要专职 DBA 才能跑稳的系统放在只有两个数据开发的小团队里迟早会变成事故源。3. 数据集市把全公司的仓库切成部门能用的表数据集市经常被误解成小号数据仓库其实它更像是一种交付方式。它的核心特征是面向特定部门或特定分析主题字段精简、口径固定、响应快。销售部门要的集市里不会有生产设备的传感器数据风控部门要的集市里也不会放市场活动的曝光日志。为什么需要它因为一个全公司共用的仓库随着表数量膨胀分析师找表的成本会超过写 SQL 的成本。数据集市的作用是把这个部门关心的 30 张表从几千张表里挑出来配上说明文档和统一的指标定义让人一进去就能干活。3.1 独立数据集市与从属数据集市的成本差异这里有个经典分歧。独立数据集市由各部门自己建直接抽业务库见效快但三五年后必然出现同一个客户在三个集市里三个 ID的局面跨部门分析基本做不了。从属数据集市从企业级仓库里派生一致性有保障但建设周期长部门会觉得我要个报表怎么要走三个月流程。我的折中做法是关键实体客户、商品、组织、时间必须由仓库统一供维业务指标允许部门在集市里自行组合。这样既保证了跨部门口径能对上又给了部门足够的灵活性。实施上就是仓库出一套 conformed dimension一致性维度表集市里的事实表通过代理键去关联这些维度而不是各自维护一份客户表。3.2 一致性维度没做好数据集市就会变成数据孤岛一致性维度这件事说起来简单做起来要命。难点在于不同部门对同一个实体的关注字段完全不同客户维度在销售眼里是等级、来源渠道在客服眼里是会员状态、历史工单数。硬把所有人的字段塞进一张维度表它就会变成一个没人敢改的怪物。我通常的做法是维度表分核心属性和扩展属性核心属性ID、名称、创建时间、状态由仓库统一维护扩展属性按主题拆成多个卫星表部门按需关联。这样一致性有保证扩展也不打架。判断标准是凡是会被两个以上部门用于筛选或分组的字段就必须进核心属性。还有一个容易被忽略的点是维度版本管理。产品分类体系一年改两次很正常如果集市直接引用最新分类去年的报表口径就和今年对不上了。所以维度表要带生效时间报表默认按业务发生时间去找对应的版本。4. 数据湖存得下不等于用得好数据湖最初的承诺很诱人先把所有数据原样存下来管它结构化的还是非结构化的等需要用的时候再定义 schema。这个schema on read的思路解决了传统仓库改表结构要走流程的痛点但代价是——如果没有强治理它会迅速变成一个谁都说不清里面有什么的沼泽。我在一个项目里见过真实的数据沼泽对象存储里两万多个目录命名从data_2020到new_new_final_v3没有人知道哪个是权威版本也没有人知道哪些字段是加密的。这种湖的存储成本很低但使用成本极高本质上等于没有数据。4.1 数据沼泽是怎么一步步形成的它不是一天变成沼泽的通常是这几个动作叠加的结果写入无规范任何团队都能往湖里扔文件路径和格式随缘csv、json、parquet 混着放。元数据不登记文件扔进去就没人管没有分区信息、没有字段说明、没有数据负责人。只写不删不归档冷数据一直占着存储成本慢慢堆上去。权限一刀切要么全开放要么全锁死中间没有细粒度控制。对应的解法其实很朴素统一存储路径规范、强制元数据登记、按生命周期分层存储、按列和行做权限。路径规范建议用域/主题/表名/分区四级结构分区统一用dtYYYYMMDD这种带键名的形式这样所有引擎都能自动识别分区。4.2 开放表格式解决了哪些老问题Hive 表玩了十几年几个顽疾一直存在小文件多、不能行级更新、并发写入容易冲突、schema 改了历史数据读不出来。开放表格式Iceberg、Hudi、Delta Lake 这类主要就是在解决这些问题能力Hive 表开放表格式行级更新删除不支持要重写分区支持 merge on read并发写入靠分区隔离易冲突乐观锁 快照隔离时间旅行不支持按快照或版本号查询历史Schema 演进危险易读错支持加列、改名、类型提升小文件治理手动 compact内置 compaction选哪种其实取决于生态。如果你的计算引擎以 Spark 和 Flink 为主Iceberg 的社区活跃度和引擎兼容性更稳如果实时写入场景多、需要分钟级可见Hudi 的 upsert 能力更顺手如果全栈都在某个云厂商体系内Delta Lake 的集成度会更高。别忽略 compaction。流式写入小文件的速度远超你的想象一天下来可能几万个几十 KB 的文件查询时元数据开销比读数据还大。一定要配定时 compaction 任务并且监控文件数量这个指标。4.3 湖上的元数据与权限治理湖里最值钱的不是数据是元数据。我的经验是至少要维护三类信息技术元数据表结构、分区、文件数、大小、更新时间、业务元数据表的中文名、字段含义、指标口径、负责人、操作元数据谁在什么时候读了什么、跑了多久。前两类决定别人能不能用第三类决定你能不能查问题。权限控制上行级和列级权限是刚需。比如用户手机号只有特定角色能看明文其他角色只能看脱敏值再比如区域经理只能看自己区域的明细。这些在数据湖上通常有两种实现路径一是通过统一的 catalog 层做策略查询时动态改写二是通过视图封装。前者维护成本低后者更直观我一般两者结合敏感的用视图兜底。5. 数据网格把数据当产品交付的组织级改造数据网格这个词听起来很玄剥开看其实是一个很现实的判断当公司有几十个业务域、几百个数据消费者时一个集中式数据团队无论如何都排不完需求。它不是技术方案而是组织方案技术只是支撑。它的四个核心原则我按重要性重排一下领域所有权、数据即产品、自助式平台、联邦式治理。注意顺序很多人上来就搭自助平台结果没人认领数据平台搭好了也是空的。5.1 四个核心原则拆开看领域所有权指的是每个业务域自己负责自己产生的数据从采集到质量到对外发布。这跟过去的数据团队统一收口完全相反好处是业务域最懂自己的数据坏处是每个域的能力参差不齐需要平台和标准兜底。数据即产品意味着每一份数据都要有明确的负责人、SLA、文档、质量指标和版本。我一般要求每个数据集至少回答五个问题谁负责、多久更新一次、字段含义是什么、质量怎么衡量、出问题找谁。回答不上来的就不算产品只能算临时文件。自助式平台是把采集、存储、计算、权限、监控这些能力做成开箱即用的服务让业务域不需要自己从零搭。联邦式治理是先定一套全局标准比如指标定义、命名规范、隐私分级各域在标准内自治而不是中央强行管到每个字段。5.2 数据网格最容易落空的地方我见过几个失败的案例问题几乎都出在同一处只做了平台没有做组织。业务域被要求你们自己管数据但没有给编制、没有给激励、也没有评审机制最后数据产品的负责人变成了一个挂名的名字SLA 写了也没人看。要落地至少得配套三件事一是把数据质量指标纳入业务域的考核不然优先级永远排不上二是建立跨域的口径评审会不然各域自说自话跨域分析又回到手工对齐三是平台必须真的做到自助如果一个数据产品的上线还要找平台团队排队两周那网格的意义就没了。我的判断标准如果你所在的组织连数据负责人这个角色都还没有先别谈数据网格。从建元数据和明确责任人开始比引入任何新架构都实在。6. 湖仓一体统一元数据才是关键动作湖仓一体经常被简化成湖加仓这个理解太表面了。它真正要解决的是同一份数据在湖和仓里各存一份、各算一遍、口径不一致的问题。核心动作是让多种计算引擎批处理、流处理、交互式查询、机器学习能直接读同一份存储上的同一份数据并且共享同一套元数据和权限。6.1 湖仓一体要解决的三类割裂第一类是存储割裂。过去原始数据在对象存储加工结果在仓库内部存储要跨过去就得导数据链路长、延迟高、还容易出错。湖仓一体的做法是全部落到开放格式的对象存储上由表格式提供事务和索引能力。第二类是元数据割裂。湖里有自己的 catalog仓里有自己的 catalog同一个业务实体两套定义。解决方式就是统一到一个 catalog 上让引擎都往这里注册和查询这样 lineage血缘才能连起来。第三类是计算割裂。批任务用 Spark、实时用 Flink、BI 用 MPP 引擎、算法用 Python各自要把数据搬到自己的存储里才能跑。统一之后这些引擎可以针对同一份数据直接计算减少了大量重复的搬运和冗余存储。这三类割裂里元数据统一最难但收益最大。因为一旦元数据统一血缘分析、权限继承、数据发现全都能串起来反过来如果元数据还是两套你会陷入改了 A 系统 B 系统不知道的持续混乱。6.2 落地时的技术组合与常见坑组合上通常是这样对象存储或分布式文件系统作为统一底座开放表格式管理事务和快照统一 catalog 管元数据上面接多引擎。数据量大的话再叠一层缓存或本地 SSD 加速热数据读取。实际落地我最常遇到的三个坑小文件问题在统一后变得更严重因为写入来源变多了。必须在上线前就把 compaction 策略、文件大小目标定下来一般 128MB~512MB 一个文件比较合适并且做成自动任务。权限模型不统一湖的权限和仓的权限是两套体系统一之后要么全部迁到 catalog 层要么做双向同步千万别指望用户手动维护两份。性能预期错配大家以为统一之后查询会更快实际上从对象存储读数据比从本地磁盘慢必须靠缓存层和统计信息来补。上之前先做压测别在报表上线当天才发现慢了三倍。另外一个经验是别一次性迁移所有表。先挑几条核心链路的数据试跑通血缘、权限、性能三件事再逐步铺开。全量迁移最大的风险是问题集中爆发排查的时候连是哪一层的问题都判断不出来。7. 选型对照与落地顺序别一上来就上最贵的把五种形态放在一张表里对照选型会清晰很多架构核心解决的问题主要代价适合的团队状态数据仓库口径统一、指标复用建模周期长、灵活性偏低有多部门共用指标需求数据集市部门响应速度易产生孤岛、重复建设部门需求密集且差异大数据湖全量保存、格式自由治理成本高、易成沼泽有非结构化与半结构化数据数据网格集中团队排不过来的需求组织改造成本极高多业务域、数据团队长期过载湖仓一体存储与元数据的重复割裂初期投入和调优成本高已有湖和仓且两者并行运行落地顺序我的建议是一句话先把仓库做扎实再谈湖。仓库的核心产物是统一口径和一致性维度这两样东西是你后面所有架构的公共基础。仓库没打好直接上湖只会把混乱从结构化数据扩展到半结构化数据湖仓一体也一样如果仓库侧的指标定义本身就是乱的统一元数据只会把混乱放大到更大的范围。如果已经有一个不错的仓库下一步通常是把非结构化和高频原始数据放进湖用开放表格式管理再逐步把湖和仓的元数据打通走湖仓一体的路线。数据网格我放在最后因为它依赖前面所有能力都足够成熟才能把责任下放给业务域而不失控。具体到指标上我一般用四个数来判断当前该往哪走表数量与月活查询人数的比值太高说明发现成本大需要集市、跨部门指标口径不一致的数量大于零就要先补仓库、存储年增长率和冷数据占比冷数据超过六成要考虑分层和归档、需求平均交付周期超过两周说明集中团队过载要么加人要么考虑网格。最后提醒一句架构升级的收益往往滞后半年到一年才显现所以推进时一定要挑一个能快速见效的点先做出来比如把某个高频报表的交付周期从三周压到三天。有了这个案例后面的推广会顺畅得多。这套东西我在几个规模差很多的团队里都落地过最大的体会是别用架构去套组织要用痛点去选架构。很多团队卡住不是因为技术选错了而是因为没人愿意为数据质量负责。技术方案再先进也扛不住一个没人认领的数据表。