数据仓库从来不是大号数据库

上个月接了个老客户的咨询，对方是做宠物智能喂食器的小团队，12个运营盯着后台的数表挠头。

啥问题？

运营拉的双11宠物主粮复购率数，和财务算出来的差了整整18个点。扯了三天皮，谁都觉得自己的数没错。

乱成一锅粥。

翻了他们所谓的“数仓”才发现，根本不是什么数仓——就是把业务库的订单表、用户表、商品表全导进了一个共享MySQL实例，建了一堆没做权限管控的视图，谁都能写SQL改字段。

你以为的数仓，其实是给业务库加了个读权限

很多小团队对数仓的认知，从根上就错了。觉得数仓就是把生产库的数据同步出来，不影响线上交易性能就行，至于数据干不干净、口径统不统一，没人管。

他们那个同步链路更离谱，订单表直接拉的线上生产库的binlog，连最基础的清洗都没做。用户退了款的订单，还挂在“有效订单”的统计口径里；不同渠道过来的用户，渠道字段一会写“抖音小店”一会写“抖音”，统计的时候自然对不上。

业务库与数仓数据同步链路示意图

我当时翻了半小时SQL操作日志，发现有个运营为了算自己负责渠道的转化率，直接在同步过来的原始订单表上改了字段值，把三个自然月的渠道标签全覆盖成了“自播渠道”。

你说离谱不离谱？

这种结构下别说算准数，能保证每个表不被随便改坏就不错了。生产库的权限是锁死的，大家没法改，就跑到这个同步出来的“共享库”里乱操作，最后数据越改越乱，谁都不知道哪个字段是对的。

我给他们搭第一版数仓的时候，根本没上什么复杂的大数据组件，就照着最基础的三层逻辑拆。

最上面的贴源层，原封不动把业务库的数据同步过来，连字段名都不许改，所有人只有读权限，没有任何修改权限——从根上杜绝有人乱改原始数据的可能。

中间的明细层，专门做数据清洗。把测试订单、退款订单、重复提交的订单全筛掉，提前把所有字段的枚举值锁死，比如渠道字段就固定五个值：抖音、天猫、京东、私域、线下，不许任何人随便写别名。

最下面的汇总层，直接按业务主题做好预计算，比如“用户复购主题”“商品销售主题”“渠道投放主题”，运营直接拿现成的表拉数，根本不用自己写复杂的多表关联SQL。

就这三步，搭完之后第一次拉双11的复购数据，运营和财务的数差从18个点缩到了0.2个点——那0.2的差异还是因为财务把企业采购的批量订单算成了个人复购，拉到明细里一对，当场就对上了。

爽。

之前他们每个月做经营分析会，光对数就要扯一上午，现在数拉出来直接能用，省下来的时间都能多盯两个渠道的投放策略。

很多人有个误区，觉得数仓是大厂才需要的东西，小团队月单量没到百万级，用Excel加个共享数据库就够了。

这话放在三年前可能没错。但现在的小团队，渠道杂、活动多、指标碎，月单量到5万的时候，Excel就已经扛不住了。

那个宠物团队就是典型，月单量3万的时候，大家凑在一块对着共享文档算数，确实没什么问题；等月单量冲到20万，渠道从3个变成12个，运营要算的指标从5个变成30个的时候，光靠人记口径根本对不过来。你总不能让每个运营都把所有业务规则背下来吧？

也不用觉得搭数仓就要花几十万买商业工具，一开始用开源的组件搭个简单的分层结构，把权限锁死，把口径统一，就比大家乱改生产数据强。我当时给他们搭第一版数仓，总共花了不到2000块的云服务器成本，让后端抽了两个下午的时间写同步脚本，就把核心的三个主题表搭起来了。

对了，别信那些说数仓要完全替代业务库的鬼话。

数仓是用来做分析的，不是用来扛线上交易压力的。你要是把数仓当成业务库用，下次大促的时候跑个全量统计把集群跑挂了，线上订单都付不了款，哭都来不及。

其实说穿了，数仓从来不是什么高大上的技术玩具。它就是给全公司的人搭了个统一的“数据账本”，不管是运营、财务还是老板，看到同一个数，不用扯半天皮去确认“你这个数是怎么算出来的”。

就这么简单。