上周跟河西某连锁零售的技术总监在龙江喝精酿，他拍着桌子骂去年的决策——花了六十多万搭的所谓”企业级数据仓库”，现在打开后台，一半表是销售部临时要了一次就再也没碰过的垃圾数，还有一半是各部门导进去的零散Excel合并出来的四不像。每次市场部要个季度复购率，数据组还是得翻三个系统拼数，折腾大半天出来的数还跟运营部之前算的对不上，两边扯一下午皮。
太真实了。
为什么你搭的数仓总像个临时杂物间
很多团队一开始搭数仓，根本没搞清楚核心定位，就把所有能拿到的数据全往里塞——ERP的销售数，门店的POS流水，小程序的用户行为，甚至连行政部的员工打卡表都往里导，美其名曰”统一数据资产”。那个零售客户当时就是这样，业务方随口提了句”要把所有数据都存起来以后好用”，技术部就吭哧吭哧把所有能接的接口全接了，连每个门店前台的零食采购报销数据都导进去了。
一年下来，1200多张表，真正被业务查询的不到80张。
其实数仓的核心从来不是”存所有数据”，而是把不同来源的数据按统一的业务口径梳理成可直接复用的分析素材。就拿最常见的”销售额”来说，POS系统算的是刷了卡就到账的数，电商后台算的是用户付了款就算的数，财务系统算的是扣掉退款的数，要是不把这三个口径统一了，你存再多数据，出来的数也是各说各话。
很多人总觉得数仓搭不起来是技术不行，其实根本不是。是从一开始就没把最基础的口径问题掰扯清楚，到最后数仓里全是对不上的数，业务部用一次骂一次，慢慢就没人愿意用了。
真正能用的数仓，都是从一个小需求磨出来的
我之前接触的南京本地一家做鲜果茶的连锁，搭数仓的时候根本没搞什么”三年技术规划”，就从运营部提的一个小需求开始：要算每个门店每个季度的新品推广ROI。
就这一个需求，他们先拉了运营、销售、财务、门店四个部门的人开了两次会，连”新品销售额算不算员工内购””试饮成本算不算推广投入”这种细碎到离谱的问题都掰扯清楚了，最后把ROI的口径定死——分子是全渠道新品实收销售额，分母是门店新品物料成本加总部投的本地抖音推广费，连退款要扣多少都列得明明白白。
定完口径才开始搭对应的数仓分层：先把POS、小程序、抖音后台的原始数据抽进来做ODS层，按定好的规则清洗成DWD层的明细数据，最后做个DWS层的门店季度汇总表，直接给运营部导出来用。
中间还闹过个小插曲，第一次跑出来的数跟财务对不上，两边查了三天才发现，有三个门店把新品的试饮成本算到了日常营销费用里，没算到ROI的分母里。把这部分口径调完之后，两边的数终于差不到1%，运营部拿到数的时候直接给数据组全组点了奶茶，说终于不用每个月跟财务扯报销的破事了。
就这么一个小需求跑通了之后，他们才慢慢把其他需求往里面加：用户复购率、门店人效、库存周转天数，每加一个需求就先统一一次口径，从来不往里面塞没用的数据。现在他们的数仓总共才不到200张表，业务部要什么数，基本当天就能出，再也没有之前那种”你这个数跟我算的不一样”的扯皮现场。
别等数仓搭完了才想起来问业务要什么
说实话，我见过太多团队把数仓当纯技术项目做。
项目启动会上来全是技术岗的人，天天聊什么列式存储、湖仓一体、实时计算的技术选型，选个最贵的云产品，吭哧吭哧搭三个月，最后上线的时候才拿给业务部看，业务部第一句话就是”这不是我们要的”。白瞎了几十万的预算，最后数仓直接沦为技术部的自嗨项目。
之前碰到过最离谱的一个团队，搭了半年数仓，连业务部的核心对接人都没见过几次，最后上线的时候业务部问能不能导出每个门店的生日礼核销率，他们说这个数据没接，要等下个月排期。你说这不是闹呢？
当然不是说技术不重要。只是技术永远是为业务需求服务的，你要是一开始就没搞清楚业务到底要解决什么问题，选再先进的技术架构，搭出来的东西没人用，那就是一堆占存储空间的废铁。那个鲜果茶连锁的团队，一开始连实时数仓都没上，就用个普通的云数仓，每天凌晨跑一次批处理，就把业务的核心需求满足了，比那些上来就搞全链路实时计算的团队效率高太多。
上周跟那个零售客户的技术总监喝完酒，他说回去就把数仓里那1100多张没用的表全删了，先从统一”销售额”的口径开始磨，再也不搞什么”大而全”的规划了。