上周三凌晨两点被电话叫起来。做生鲜电商的朋友在电话那头嗓子都哑了，说大促前的复盘会开了一下午，两边数完全对不上——运营拍桌子说上个月复购率涨了12%，财务翻着流水说实际营收只涨了3%，差出去快300万的GMV，谁也说服不了谁。最后翻了三个小时的系统日志才发现，运营取数的时候直接从生产业务库的用户行为表捞的，把测试环境的模拟下单数据全算进去了，连退款订单都没剔；财务是从支付系统的流水里导的数，两边的统计口径从根上就不一样。
这种场景我太熟了。很多团队刚起步的时候，根本不知道要建数据仓库，每次运营要数，开发就直接连生产库写个SQL捞完导Excel发过去。刚开始业务量小，一天几十条查询，生产库扛得住。等业务量上来，重查询直接把表锁了，客服系统点个售后单卡三秒，财务月结的时候整个系统瘫俩小时，所有人都得等着。
我见过太多团队把这种临时取数当数据仓库用。觉得不就是把几个业务库的表拼在一起，建个汇总表存着就行。错啊。
你以为的取数根本不是数据仓库
业务库从设计之初就不是为了分析用的。它的核心目标是支撑交易流程跑顺，比如用户表存的永远是当前的最新状态——昨天用户改了手机号，之前的旧号码字段直接就被覆盖了，根本留不下历史快照。你要是直接从业务库取上个月的用户分层数据，那现在所有用户的标签都是最新的状态，算出来的留存率能准就怪了。这种错我见过不下十次，每次都要花好几天擦屁股。
说白了，数据仓库和业务库的核心区别，从来不是存了多少数据，而是能不能给所有数留个可溯源的底，能不能把不同来源的数统一成大家都认的口径。不然每次开会都是各说各话，运营拿一套数，财务拿一套数，老板在中间听得云里雾里，最后拍板的决策全是拍脑袋出来的。
数对不上的核心根源是没有分层
很多人建仓库的时候图省事，所有数据进来就直接加工成给业务用的宽表，跑了半年才发现数全乱了。其实数据仓库从设计逻辑上就得按加工深度拆层，这是绕不开的规矩。最底层是贴源层，把各个业务库的原封不动的数搬过来，一点都不加工，连字段名都不改，就是为了留个原始的底，哪天数对不上了，能翻回来溯源。中间是汇总层，把那些重复的、脏的数据洗干净，把用户行为的重复点击去重，把退款订单的标记打全，把不同渠道的订单ID统一编码。最上层是应用层，直接给业务方用的宽表，比如复购率表、GMV表、用户分层表，业务方不用写复杂的关联，查一下就能拿到能用的数。
没有分层的数据仓库，本质上就是个堆数据的垃圾场。之前有个做教培的客户，当初觉得分层占存储空间，直接跳过了贴源层，所有数据进来就直接加工成汇总表。结果有次前端埋点出bug，把所有用户的观看时长都多算进去了三倍，等发现的时候，已经把三个月的汇总表都覆盖了，根本找不回来原始的埋点数据。最后只能挨个找用户补日志，花了快两周才把数捋顺，损失了好几个渠道的投放ROI核算机会。
很多人说现在存储这么便宜，多存点原始数据怎么了？真等你要溯源的时候，才知道留着贴源层有多香。那些觉得分层麻烦的团队，最后都要花十倍的代价补窟窿。
落地的时候别上来就搞大而全
不少团队，一提到建数据仓库，上来就想把所有系统的数据全接进来，什么CRM、ERP、OA、客服系统，恨不得把公司所有的数都堆到仓库里，结果搞了半年，仓库建得老大，业务方还是取数难，每次要个数还是得等开发跑半天SQL。
说实话，真没必要。你就从最痛的点切入就行。比如第一个月就先接交易系统和用户行为系统的数，先把最核心的GMV、复购率、退款率这几个数做准，让业务方先能用起来，觉得这个仓库是真的能解决问题，比你一开始铺十个系统强多了。之前有个做本地生活的小团队，三个人的技术组，用开源的数仓工具搭了个基础的仓库，每个月的服务器成本才几百块，就把之前财务和运营扯了半年的账给算明白了，比之前花几十万买的商业BI系统好用多了。
还有个常见的坑，很多人觉得数据仓库就得用最贵的服务器，买最顶级的商业软件，其实小团队根本没必要。刚开始用开源组件搭，成本低，灵活，等数据量真的上来了，再慢慢扩容就行。上来就砸钱买最贵的方案，最后大概率是技术部门的自嗨项目，业务方根本不买账——毕竟取个最简单的数还要走两周的需求排期，谁愿意用啊？
其实数据仓库从来不是什么高大上的技术概念。说白了就是给公司建一本能算清楚的账，谁什么时候买了什么，哪个渠道来的用户留存高，哪个活动投的钱真的带来了复购，这些数都能明明白白摆出来，不用每次开会的时候两边扯半天。说真的，能把数算准的团队，做业务都不会太差。