上周三晚上十点半，我在公司茶水间啃着放了三小时的冷三明治，运营组的小周端着半杯凉掉的美式，蹲在我工位边等。
数不对。
之前他们自己从业务系统拉的上周复购率，把新客首单换赠品的零元订单也算进了复购口径，算出来的数比真实值高了17个点，第二天就要给老板报季度复盘的材料，要是把这个数递上去，整个季度的用户运营策略都得跟着歪。那天我们对着SQL改到十二点多，最后把导出来的正确数发给他的时候，他长舒了一口气，说这已经是这个月第三次因为口径不对返工了。
别再把数据仓库当大号Excel用
刚接触数仓的团队，十个有九个会走这个弯路——觉得数仓不就是个超大号的存储池，把所有业务系统的表都导进去存着，谁要数谁自己捞就行。
我们刚搭第一版数仓的时候就是这么干的。
产品部要算渠道转化率，直接从用户行为日志表捞数，把测试账号的浏览记录全算进去了；销售部算渠道贡献，又从订单表捞数，把还没完成退款的订单也算成有效成交。两边对着报表吵了一下午，算出来的转化率差了快30%，谁也说服不了谁。
那次吵到整个部门都围观的时候，我才突然反应过来，数仓的核心从来不是存数据，是统一口径。所有公共的统计规则，比如什么算有效新客，什么算有效成交订单，哪个时间窗内的用户行为算转化，这些规则不是哪个部门拍脑袋定的，是拉着运营、产品、销售坐下来对齐过的，要固化在数仓的公共维度层里，谁要用数直接从这层取，就不会出现同个指标两个版本的笑话。
那些听起来很玄的数仓分层，本质都是为了少加班
很多刚接触数仓的人，一听到ODS、DWD、DWS、ADS这些分层概念就头大，觉得是工程师故意搞出来的玄乎术语。说白了真没那么复杂，所有分层设计的初衷，都是为了少做点重复劳动，少加没必要的班。
ODS层就是把业务系统每天产生的原始数据原封不动搬过来，像小区楼下的快递驿站，所有刚到的包裹先堆在这，谁的包裹谁认领。DWD层就是把这些原始包裹拆成标准件，把没用的垃圾——比如测试数据、重复上报的日志、异常到离谱的数值——全部挑出去，把订单、用户、行为这些数据拆成统一粒度的明细，就像驿站把所有快递按手机号、收件地址整理好，不会出现一个包裹塞了三个人东西的混乱情况。DWS层就是把这些明细按主题提前汇总好，比如按用户维度汇总他最近半年的消费金额、下单次数，按渠道维度汇总这个渠道带来的新客数、转化成本，你要什么主题的汇总数直接拿就行，不用每次都从最底层的明细表跑全量计算。ADS层就是最后给业务看的报表层，所有要给老板看、给业务团队看的最终指标，都在这层算好等着人取。
之前我们没搭分层的时候，每次业务要个季度复购数，工程师都得从最原始的日志表开始写SQL，跑一次要四十多分钟，中间还经常因为数据重复算错，加班到凌晨是常事。
真的爽。
后来把分层搭顺了，所有公共的汇总逻辑都提前算好存在DWS层，业务要数的时候从ADS层取，几秒钟就能出结果。上次有个业务临时要算618大促期间各个渠道的客单价波动，换之前至少要花两个小时写SQL跑数，那天我们直接从已经搭好的渠道主题层捞数，不到三分钟就把结果发给他了，他站在我工位边眼睛都直了，说之前找别的团队要数，最少也要等半天。
别等数据乱成一锅粥了才想起来搭数仓
我见过太多小团队的负责人，觉得我们现在才十几个人，业务量也不大，根本不需要搞什么数据仓库，用Excel拉数就够了。
去年接触过一个做本地连锁餐饮的客户，团队一共二十多个人，之前所有的经营数据都是各个店长用自己的Excel记，每个月财务要花一周时间把各个店的表合到一起，算营收、算食材成本，经常算错。等他们想搭数仓的时候才发现，之前半年的Excel数据格式全乱，有的店记营收是把外卖平台扣点扣完才记，有的店是把总营收直接记上，口径根本不统一，光整理历史数据就花了快一个月。
不用追求完美。
其实搭数仓根本不需要一开始就照着大厂的架构抄，又是上实时数仓又是搞全链路数据治理，花几十万搭一套系统最后业务根本用不起来。小团队刚开始的时候，先把最核心的几个指标的口径定死——比如营收、新客数、复购率——把这些指标的计算逻辑存在固定的地方，每次算的时候都按同一个规则来，就已经比乱拉数强太多了。我见过太多团队一上来就追求技术上的高大上，最后系统搭完了，里面的口径还是之前大家吵来吵去没定下来的版本，最后又回到了谁要数谁自己从原始表捞的老路，钱花了，加班还是没少。
上次碰到之前一起加班的小周，他现在已经是运营组的主管了，上次吃饭他还说，现在再也不用每个季度为了对数熬到半夜了。
挺好的。
我们折腾这么久搞数仓，说到底不就是为了让大家少点无意义的扯皮，把时间花在真正能帮业务增长的事情上嘛。