数仓建模：被神话也被误解的大数据基建核心

被忽略的起点：数仓建模到底解决什么问题

很多人入门第一节课就学，Inmon范式建模追求数据一致性，Kimball维度建模追求开发效率，吵了几十年谁对谁错。 但没人告诉你，数仓建模从诞生那天起，就不是纯技术问题。 它本质是给企业所有数据定规矩。 什么规矩？同一个指标，全公司只能有一种定义；同一份数据，能快速找到，不会存十份八个版本。 你要做用户增长，你得知道花了一块钱推广，拉来多少真实用户，这个「真实用户」的定义，就得写进建模规则里。

很多新手上来就堆范式，拆表，以为越规范越高明，最后业务改个需求，整个模型动都动不了。

我前两年接触过一家做跨境电商的创业公司，刚拿了A轮，老板听了咨询公司的忽悠，招了两个从传统银行出来的建模专家，花了四个月搞出了一套覆盖全业务的三范式模型，光文档就写了两百多页。 结果上线不到三个月，业务改了跨境物流的结算规则，整个模型的核心表全部要改，又花了三个月，那段时间运营全部靠Excel拉数，错过了黑五的旺季，太可惜。

说白了，建模的核心原理从来不是越复杂越好，是匹配你的业务阶段和需求。业务还在高速变，你就搞轻量的维度建模，先能用再说；业务稳定，合规要求高，你再搞严谨的范式建模，把冗余降到最低。

产业现状：湖仓一体时代，建模没用了吗

这两年湖仓一体火了，存储成本降了那么多，很多人喊，反正数据都存在湖上，不用提前建模，要用的时候再查不行吗？ 喊这个的大多是卖工具的，你真这么干试试。 不出半年，你的数据湖就变成数据沼泽，找个数据比找对象还难。

不过话说回来，数仓建模的边界确实变了。原来的建模是从上到下，先搞整个企业的模型，再填数据；现在更多是从下到上，业务需要什么先建什么，慢慢迭代。 国内头部的云厂商，现在推的云数仓服务，默认都是分层轻量化建模，把公共维度层抽出来，事实层完全留给业务灵活调整，比原来那种大而全的模型好用太多。

我见过做得好的，是国内某头部连锁餐饮，他们做数仓建模，不搞企业级统一大模型，按门店运营、供应链、会员营销分了三个独立的模型域，每个域自己迭代，公共的用户口径统一抽出来共享，既保证了一致性，又不会一个变全动。

落地最大的障碍还是人的问题。技术部要规范，业务部要灵活，两边掐架，最后要么规范把灵活性掐死，要么灵活把规范冲没，两头不讨好。 很多企业现在搞数据中台，其实核心就是解决这个问题，把建模的口径层拆出来，既归技术管，也让业务参与，说白了就是把规则说清楚，省得各搞各的。

未来三年：数仓建模会走向哪里

现在很多工具已经能AI自动生成数仓模型了，输入业务流程，几分钟出模型，很多人说建模工程师要失业了。 我倒觉得，AI替代的只是画ER图这种体力活，核心的口径定义还是要懂业务的人来拍。 AI怎么知道你们公司把「滞销品」定义成三个月卖不出去还是六个月？怎么知道你算GMV要不要算退款？这些都是业务的潜规则，AI学不会。

最大的风险其实是口径治理。很多企业建模的时候，为了快，给同一个指标留了好几个口径，不同部门用不同的，最后开会算业绩，技术出一套，业务出一套，吵一下午没结果，数仓的公信力直接没了。 很多企业搞了几千万的大数据项目，最后死就死在这一步，没人信数据，还谈什么用数据驱动？

未来三年，我觉得有几个趋势很明显。 第一，建模肯定会越来越轻量化，不会再搞那种几年才建完的企业级大模型，都是小步快跑，迭代着来，先能用再优化。 第二，AI会成为标准辅助工具，建模工程师不用再画图画表，把精力放在捋口径理规则上，岗位价值其实反而更高了。 第三，建模会从纯技术活变成业务和技术配合的活，以后每个业务线都会有专门的人管自己域的建模规则，不会全扔给数据部门。

说实话，做了这么多年科技产业观察，我最深刻的感受就是，所有技术活，最后都是人的活。数仓建模也一样，不是建给机器看的，是建给人用的。你把业务的需求摸透了，把口径理清楚了，哪怕模型简单点，也比那种漂亮复杂但没人用的模型强一万倍。