我登上去一看，差点气笑。
所谓的数仓，就是一台配置拉满的MySQL实例，直接同步了业务库的所有表，连个清洗步骤都没有。
别把数仓当超大号MySQL用
真的见过太多团队犯这个错。
他们觉得反正都是存数据的，把订单、用户、交易的表直接丢到更高配置的数据库里，平时跑个日销总表好像也能用，直到某次南京国际美食节的活动上线，运营要实时看不同商圈的核销数据，SQL一跑直接把库锁了半小时，整个大促保障会全卡在那儿，连个实时的客流数据都拿不出来。
业务库和数仓从根上就不是一个东西。业务库是面向事务的，要保证每笔订单的扣减、每笔支付的一致性，写操作多过读操作；数仓是面向分析的，几乎没有写操作（除了同步原始数据的环节），所有的设计都是为了让多维度的查询足够快。
我之前碰到过一个刚从Oracle DBA转岗做数仓的兄弟，上来就给所有数仓表加了外键约束，还配了触发器做数据同步，我看到那段代码的时候差点当场辞职。
数仓的核心从来不是存数据
很多人对数仓的误解，就是觉得它是个更大的存储池，能装更多数据就行。
根本不是。
数仓的核心价值，是把零散的、口径混乱的业务数据，整理成统一的、可复用的分析指标。不然你存了几个PB的原始数据，运营要查个用户复购率，还得自己写SQL关联七八张表，稍微改个筛选条件就得跑半小时，那要数仓干嘛？
我现在给客户搭数仓，第一周绝对不接任何业务侧的需求。先把过去半年的脏数据清干净——比如用户表里面有几千个空手机号的测试账号，订单表里面有三个重复枚举的“已支付”状态，还有些同步的时候带过来的重复数据，这些东西不处理，后面跑出来的报表全是错的，业务方骂都骂不过来。
清完脏数据就分层。不用搞那些花里胡哨的概念，就三层足够用：最上层是贴源层，直接同步业务库的原始数据，一点都不改，方便后面溯源；中间是明细层，把清洗完的、结构化的明细数据存在这儿，所有的计算都在这层做；最下层是汇总层，把常用的指标按天、按商圈、按品类提前算好，做成宽表，运营查的时候直接拿就行，不用扫全表。
哦对了，指标口径必须统一。之前那个美食导航的客户，三个部门对“活跃用户”的定义都不一样：运营说的是当天打开过APP的，产品说的是当天点过商家详情的，财务说的是当天有过支付的，每次开周会对着数据吵两个小时，最后数仓团队背锅。我现在给所有客户定的规矩，所有上线的指标必须把口径写在数仓首页，谁要改必须走审批，不然一律不认。
小团队根本不用买昂贵的数仓产品
说真的，别被那些卖数仓产品的销售忽悠了。
他们一上来就给你讲什么湖仓一体、AI赋能、实时数仓云平台，张口就是几十万的报价，你一个几十人的小团队，连每天的订单数据都没理清楚，搞那些花架子有什么用？
去年帮南京做景区票务的客户搭数仓，十几个人的技术团队，之前被销售忽悠买了十万块的所谓大数据平台，结果用了半年连个分景区的月度客流报表都做不对，钱全打了水漂。我过去给他们改，总共就用了两台云服务器，装了开源的ClickHouse存数据，Flink做实时同步，每个月的硬件成本不到两千块。之前他们跑月度客流报表要跑一晚上，现在实时看板几秒钟就出数，老板直接在朋友圈吹了半个月。
真的没必要追求那些高大上的技术栈。
小团队的数仓，能把常用的报表跑快，能把指标口径统一，能不让业务方自己写SQL查数，就已经合格了。那些上来就谈千万级数据量、谈PB级存储的，大概率是自己的业务根本没到那个规模，纯纯的技术自嗨。
我见过太多团队在数仓上走弯路，花了大价钱搭了一套看起来很厉害的系统，结果业务方根本用不起来。
其实数仓这东西，从来都不是什么高大上的黑科技。说白了就是帮大家把数理顺，让每个部门拿到的数都是对的，不用再对着一堆零散的表瞎猜。
踩的坑多了就懂了。