上周跟南京做社区零售的老周在珠江路喝冰美式，他吐槽公司去年花了六十万搭的数仓，运营要上周南京片区的社区店复购率，技术部攒了三天数，给出来的数跟门店店长报的差了快两成，运营差点跟技术部在周会上拍桌子。
太扯了。这种事真的不是个例。
别把数仓做成没人用的技术孤岛
说真的，很多团队对数仓的理解从根上就错了。以为数仓就是把各个业务系统的数据抽到一个大数据库里，建一堆漂亮的表，写一堆复杂的SQL，就算完成任务了。谁管这些表做出来的数能不能对上业务的实际情况？谁管业务人员查个数要不要翻三层文档？数仓的核心从来不是技术栈有多新，是能让业务的人不用找技术部，自己就能查到可信的数。
之前见过一个做本地生活的团队，数仓搭了快一年，最后业务端用的最多的还是Excel导出的零散表格，数仓里存了快两亿条日志，真正被调用的表还不到总表数的10%。这钱花得，听着都心疼。
那些被过度设计的数仓分层
聊到数仓，绕不开分层。很多人搭数仓的第一反应，就是照着大厂的开源文档抄一套四层架构，ODS贴源、DWD明细、DWS汇总、ADS应用，一层都不能少。
不过话说回来，我也不是说分层不好，只是很多团队的规模根本撑不起这么重的设计。之前碰到一个做宠物用品的小电商，整个技术部加起来才8个人，非要照着大厂的标准搭四层，每层之间还要做三遍数据脱敏和格式清洗，最后算个每天的销售额，从抽数到跑批要三个半小时。等数导出来的时候，运营的直播促销都结束两个小时了，要这数有啥用？
其实分层从来没有标准答案。十个人的小团队，两层就够了——一层存原始的业务数据，一层存算好的核心指标，简单直接。等团队规模上来了，业务线多了，再慢慢加中间的分层节点，完全来得及。没必要一开始就把链路拉得老长，最后维护的成本比产生的价值还高。
数仓落地最容易被忽略的校验环节
很多数仓做出来的数不准，根本不是技术能力的问题，是从一开始就没把校验环节当回事。之前老周他们的数仓为什么数对不上？因为接门店POS数据的时候，直接把POS系统导出的流水全抽进了数仓，根本没核对门店端上报的日结总额。POS系统里有一半的流水是顾客退单的，还有一部分是门店员工测试用的测试单，这些数据全算进了销售额里，算出来的复购率能准才怪。
指标口径统一才是数仓能活下去的根本。就拿复购率来说，是买过一次就算复购，还是要间隔多久的购买才算？是按手机号算用户，还是按会员ID算？这些事如果不提前跟业务、门店、运营三方对齐，最后不管技术部把SQL写得再复杂，做出来的数都没人信。
跨源对账的流程必须嵌到日常的数仓更新链路里。每天数仓跑批完，要自动跟业务系统的核心报表数对一遍，差了超过0.5%就直接报警，别等业务端发现数不对了，再翻半天日志找问题。老周他们现在就是这么做的，每天早上数仓更新完，自动跟POS系统的日结数、会员系统的注册数做对账，现在出来的数跟门店报的差基本都在千分之三以内，运营再也不追着技术部要数了。
真要搭数仓，别上来就被厂商的销售忽悠买几十万的全套系统。先把业务端每个月必须算的十几个核心指标列出来，把每个指标的口径跟所有相关的人对齐，再顺着这些指标找对应的数据源，先把这几个数做准了。比你搭再华丽的数仓架构都有用。对吧？