很多人第一次学数据仓库很快就能背出一套分层ODS → DWD → DWS → ADS。但真正到了项目里最容易卡住的往往不是这些概念而是ERP、CRM、MES、WMS里的数据到底怎么进入ODSODS已经有数据了为什么还要做DWDDWD都能查了为什么还要再建DWS甚至很多企业数仓建了几年已经有几千张表依然会遇到一个很现实的问题一个报表数字错了没有人能快速说清它到底从哪张源表来、中间经过了哪些任务。这就说明真正的数据集成架构不能只看“分了几层”还要看数据怎么进来、怎么变化、怎么加工、怎么依赖、怎么追溯。在正式展开之前我整理了一套《数据仓库建设解决方案》里面涉及数据集成、数仓建设、数据治理等内容。如果你正在梳理企业的数据架构可以结合文章一起看。需要自取https://s.fanruan.com/ahhl0复制到浏览器下面直接从企业真实的数据流转过程讲起。一、先别急着建ODS先搞清楚“数据从哪里来”假设一家制造企业同时存在ERP订单、采购、财务CRM客户、商机WMS库存、出入库MES生产、工单、设备OA组织、人员第三方平台物流、渠道、电商订单。管理层最终看到的可能只是一张“经营驾驶舱”但驾驶舱背后一项毛利指标就可能同时涉及销售订单、商品、客户、采购成本、生产成本、库存、组织等多套数据。所以企业数据集成的第一步其实不是ODS表怎么命名而是先回答三个问题。哪些系统是数据源必须先画清楚企业的数据源地图。哪些数据来自数据库哪些来自API哪些每天通过Excel、CSV交付哪些来自消息队列哪些业务系统只能定时抽取只有把来源搞清楚后面的分层才有基础。同一类数据谁才是权威源客户信息可能CRM有一份ERP也有一份商品信息可能ERP有电商系统也有。这个时候不能简单地“全部同步过来”。还需要确定客户主数据到底以谁为准商品编码冲突时听哪个系统否则数据虽然进入了数仓业务含义依然是乱的。数据变化速度有多快地区编码可能一个月都不变一次订单却可能每秒都在新增和修改库存甚至需要随着入库、出库持续变化。这直接决定后面的同步方式。所以源系统到ODS这一段本质上是一个异构数据接入问题。实际项目里我会先在FineDataLink 5.0中把数据库、API、文件等来源按照各自的数据形态接进来稳定的小维表按周期同步持续变化的交易数据再按照增量或变化捕获方式处理。先把“数据在哪里、怎么变化、多久进一次数仓”梳理清楚ODS后面的结构才不会一开始就失控。二、ODS重点不是“原样复制”而是保住业务事实ODS通常被理解成贴源层。这句话没错但容易让人产生一个误解把业务库复制一份就是ODS。实际上ODS至少有三个更重要的作用。第一隔离业务系统和分析系统如果100张报表直接查询ERP那么ERP一次字段调整可能影响几十个分析任务。有了ODS以后源系统变化先进入数据接入层再决定怎么向下游传递。这样业务系统和数据分析之间就多了一层缓冲。第二保存可以追溯的原始事实假设财务发现上个月收入比ERP少了300万元。如果数仓里只剩下加工后的结果很难判断问题发生在哪里。因此ODS除了业务字段还经常需要保留数据来源、抽取时间、更新时间、批次号、删除状态等技术信息。以后出现异常可以顺着这些信息继续往源系统追。第三为历史重算留下基础今天公司的“有效订单”定义可能是支付成功且未取消。半年以后业务可能修改为支付成功、未取消同时排除内部测试订单。如果ODS还保留完整历史事实就可以重新按照新规则计算过去的数据。如果一开始只保存加工结果很多历史数据就无法重算。所以ODS真正要守住的是源系统发生过什么。在这一层不要急着加入太多业务判断否则ODS很快就会从“原始事实层”变成另一个口径复杂的加工层。三、ODS到DWD真正困难的是把“系统数据”变成“业务事实”如果说ODS还带着明显的源系统痕迹那么从DWD开始数据就要逐步脱离“某个系统里的表”转向企业自己的业务语言。例如ERP里可能存在order_headerorder_detailpaymentrefund进入DWD以后企业真正需要思考的是我要沉淀什么业务事实可能最终形成销售订单明细事实、退款事实、支付事实、库存流水事实。这中间通常会经历四类加工。数据清洗处理重复数据、空值、非法状态、测试数据以及明显错误记录。字段标准化CRM里叫cust_noERP里叫customer_id进入统一模型以后需要逐步映射成一致的数据定义。业务规则统一这一层最重要。例如什么状态算有效订单退款以后收入怎么处理跨月退款算在哪个月销售日期看下单、支付还是发货一个订单拆成多次发货应该如何记录这些规则如果不在DWD逐步统一最终就会散落到几十张报表里。到时候财务算一套收入销售算一套收入经营部门再算第三套。增量加工随着数据量增长ODS到DWD不能永远靠全量重跑。一张订单表可能已经有20亿条历史记录而今天真正变化的只有200万条。这时更合理的思路是先识别变化再加工变化。在FineDataLink 5.0这一段就可以把不同的数据变化方式拆开处理首次建设时先完成历史数据初始化后续按照更新时间、增量标识或者日志变化继续获取新增和修改的数据再把这一批变化送入DWD加工。碰到订单修改、状态变化、退款这类场景链路关心的就不仅是“新增了多少行”还要知道哪些旧记录发生了变化以及这些变化应该怎样传递到下游。DWD真正成熟以后应该逐渐成为企业稳定的业务明细事实底座。四、DWD到DWS不要再做一遍明细而要沉淀公共分析能力很多数仓做到这里会出现一个典型问题DWD有500张表DWS又复制出了500张差不多的表。这样其实没有解决问题。DWS存在的原因是因为很多分析逻辑会被反复使用。例如销售分析中十几张报表都需要每日销售额、订单数、销量、客户数、成本、毛利。如果每张报表都重新从几亿条订单明细开始聚合不仅计算资源重复消耗更麻烦的是同一个指标可能被写出十几个版本。所以DWS更应该围绕主题域 统计粒度 公共指标来设计。比如销售主题可以形成dws_product_sales_day粒度是日期 × 产品其中提前沉淀销售额、销量、订单数、成本、毛利、客户数。客户主题还可以形成dws_customer_sales_month粒度是月份 × 客户沉淀购买次数、销售额、毛利、最近购买时间等。以后销售趋势、客户分层、产品排行、区域经营分析都可以继续使用这些公共结果。这里还有一个很重要的判断DWS不要跟着报表数量增长。今天来了“销售日报”建一张汇总表明天来了“总经理驾驶舱”再建一张后天又来了“经营分析会”再复制一张。做久以后三张表可能80%的计算逻辑都一样。因此更合理的方式是先把高频公共计算沉淀下来再由上层应用组合使用。当ODS、DWD、DWS逐渐增多以后数据加工也会从几个SQL变成几十、几百条跨层任务。此时在FineDataLink 5.0中可以继续把数据同步、转换加工和不同节点之间的前后关系组织起来。比如订单、客户维度先完成更新再启动销售明细加工最后生成产品日汇总让每一层的数据生产有明确的上游和下游避免某个节点还没更新下游已经拿旧数据开始计算。五、真正的数据集成架构要管的是整条链路到这里再重新看一遍完整架构。假设企业要建设销售经营分析。源系统中有订单、订单明细、客户、商品、组织。第一步进入ODS保留源系统里的原始业务事实。第二步进入DWD完成清洗、标准化、业务口径统一形成销售订单明细事实。第三步进入DWS按照产品、客户、区域、日期等分析粒度形成公共汇总结果。最后再进入ADS或者BI服务销售日报、经营驾驶舱、产品分析、客户分析。整个过程可以写成业务系统 → ODS → DWD → DWS → ADS/BI。但真实生产环境里仅仅画出这条箭头还不够。还必须继续回答几个问题。第一个任务依赖有没有控制ODS订单没更新完DWD就不能计算。DWD失败DWS不能继续跑。否则技术上所有任务可能都是“成功”的最后的数据却来自不同时间点。第二个失败以后怎么恢复某个DWD任务凌晨2点失败。重新运行时是全量覆盖还是只重跑当天已经写进去的数据会不会重复这其实涉及幂等、断点恢复以及数据补偿设计。第三个数据到底新不新很多企业只检查任务有没有成功。但任务成功不代表数据一定正确。比如ERP凌晨1点应该产生100万条订单变化最终只同步了80万条。任务可能没有报错但结果已经少了20万条。所以更进一步还需要关注源端变化量、读取数量、目标端写入数量、最新数据时间。第四个问题能不能快速定位当早上经营驾驶舱数字异常时最怕所有人一起开始猜是不是报表错了是不是DWS错了是不是DWD没跑是不是ODS没有同步数据链路越长越需要把任务状态、运行日志和上下游关系放在一起看。FineDataLink 5.0到这一阶段关注的也不再只是“把A表搬到B表”而是沿着数据生产过程查看任务运行情况、读写记录和异常节点。哪一段延迟、哪一步失败、问题影响到了哪些后续任务都应该尽量在链路层面暴露出来排查才不会每次都从最终报表倒推。真正成熟的数据集成架构最终管理的其实是一条持续运行的数据生产线。结语所以ODS、DWD、DWS真正的区别绝不只是名字不同。ODS解决的是企业各个业务系统的数据如何稳定进入数仓并保留可追溯的原始事实。DWD解决的是不同系统里的数据如何被整理成企业统一的业务事实。DWS解决的是反复使用的分析逻辑如何沉淀成公共的数据能力。而把这些层真正串起来以后还要继续处理数据接入、变化捕获、加工依赖、调度、异常恢复、数据质量和链路追溯。因此判断一家企业的数据仓库做得好不好不要先看它有多少层、多少张表。更值得问的是一个经营指标出现以后能不能说清数据来自哪里源系统发生变化以后能不能稳定传递到下游一条任务失败以后能不能快速找到影响范围同一种业务事实在不同报表里是不是始终保持同一套口径如果这些问题都能回答清楚ODS、DWD、DWS才真正连成了一套体系。最终的数据架构应该做到源头清楚、分层明确、口径统一、依赖可控、结果可追溯。这才是企业做数据集成和数据仓库分层真正要解决的问题。