大讲堂
上周跟一个做连锁零售的CIO在南京的小馆子吃鸭血粉丝，他喝了两口冰啤酒开始吐槽：去年咬着牙批了三百万预算换的所谓”新一代实时数仓”，到了双11大促那天，跑全渠道的销售汇总，还是卡了两个半小时才出数。技术团队换了一茬又一茬，从原来的Teradata迁到了云原生的新平台，钱花得哗哗的，核心的痛点半毛钱没解决。
说实话，这种场景我这两年见得太多了。
别扯什么”实时”，先搞懂数据仓库到底不是什么
很多厂商现在卖数仓，上来就把”毫秒级查询”、”PB级承载”当核心卖点，说的好像只要够快、能存，就是合格的数仓。
根本不对。
数据仓库从1990年代被Bill Inmon提出来的那天起，核心目标就从来不是”快”，而是”把散在各个业务系统里、口径互相打架的数据，拼成企业能拿来拍板做决策的统一账本”。
你想啊，企业日常用的业务系统，不管是ERP、CRM还是电商的订单系统，本质上都是为了支撑日常交易的OLTP库——这些系统的核心要求是”不卡单、不丢单”，每个表都是为了某一个具体的业务流程设计的，根本不会考虑跨部门的数据打通。
比如销售系统里存的”成交客户”，是只要付了定金就算；财务系统里存的”有效客户”，是要等全款到账、过了退款期才算；运营系统里存的”活跃客户”，是只要一个月内打开过APP就算。三个系统三个标准，你要是直接把这些库里的数据导出来拼个报表，开经营会的时候能吵到掀桌子。
这才是数仓要解决的核心问题。至于快不快，那是解决完”数对不对”之后才该考虑的事。
很多人到现在都把数仓当成大号的关系型数据库，觉得无非就是把几个库的数据导进去，建几个宽表跑查询。我见过太多团队上来就把全量的业务日志、订单数据、用户行为数据一股脑倒进数仓，连个基本的口径定义文档都没有，跑出来的数连业务部门自己都不敢认。
快有什么用？
跑出来的全是错数，再快也是白搭。
现在的数仓圈，早就在卷”谁的账单更难看”
最早那批集中式的数仓，比如Teradata、Oracle Exadata，贵到什么程度？一个中型企业用个三五年，光硬件和维保费用就能砸进去上千万，很多企业的数仓成本，最后都占到了整个IT部门预算的三分之一还多。
后来云原生的数仓出来，打着”按量付费、不用不花钱”的旗号，把很多企业从原来的重资产投入里拉了出来。一开始大家都觉得捡到便宜了——原来买一套库要几百万，现在按量付，每个月可能几万块就搞定了。
结果呢？
跑了一年账单出来，大家都傻了。
因为云原生数仓是计算和存储完全分离的架构，你存多少数据、每次跑查询扫了多少数据，都是单独计费的。很多团队一开始图方便，把所有能找到的数据都倒进数仓，连那些三年前就没人查过的历史日志、重复导了好几遍的同一份订单表，全都原封不动存在那边。我见过最夸张的一个做在线教育的客户，月度数仓账单14万，翻了明细才发现，有9万是在存那些早就过期的、连业务部门都忘了存在过的数据。
不过话说回来，这也不能全怪客户。
厂商在卖货的时候，根本不会主动提醒你”数据治理要花多少精力”、”重复存储会产生多少隐形费用”。大家都在比谁的性能跑分高，谁的营销概念新，很少有人站在客户的角度算一笔总账：你用我这套数仓，三年下来总共要花多少钱，能省多少钱。
现在整个赛道的竞争早就变味了。原来大家拼的是技术参数，现在拼的是谁能把账单做的好看——毕竟现在企业的IT预算都在砍，你能帮客户把总持有成本降下来，比你吹再多的”AI原生”、”湖仓一体”概念都管用。
别迷信技术噱头，真正卡住数仓落地的从来不是性能
我接触过的上百家企业里，能把数仓用明白的，连20%都不到。
不是技术不行。
是组织没跟上。
很多企业搞数仓，都是技术部门牵头，拉上几个开发，花几个月时间把数据从各个业务系统导出来，建上几十上百张表，然后就等着业务部门过来用。结果呢？业务部门根本不买账。为什么？因为数仓里的数，跟他们日常算的口径对不上。
比如市场部算的获客成本，是把所有投放费用除以新注册的用户数；销售部算的获客成本，是把同样的投放费用除以第一次下单的用户数；财务部算的获客成本，是把投放费用扣除渠道返点之后，除以实际回款的用户数。三个部门三个数，技术团队坐在中间，根本不知道该听谁的。
数仓真正的壁垒，从来不是代码写的有多好，引擎有多快，而是能不能把跨部门的数据话语权给理顺。
你要定下来，”GMV”到底含不含退款、含不含渠道分润、含不含线下的自提订单；”获客成本”到底从哪个节点开始算、哪个节点结束；”用户留存”到底是按注册时间算，还是按首次下单时间算。这些规则不定下来，就算你把查询延迟从小时级压到毫秒级，跑出来的数还是个谁都不敢拍板的糊涂账。
更别说现在的合规风险了。数仓里存了全公司最核心的数据——客户的手机号、消费记录、财务成本、供应链的报价，要是权限没管好，随便一个运营就能把全量数据导出去，那等着你的就是几百万的罚单。之前有个做社交的公司，就是因为数仓的权限配置错了，导致全量用户的聊天记录被爬走，最后被罚了两千万，相关的技术负责人直接被开除。
这真不是危言耸听。
未来三五年，数仓的故事根本不会像你想的那样演
很多人现在在吹，说AI会颠覆整个数仓行业，说以后大家不需要写SQL，对着数仓说句话就能出报表，说数仓会变成AI的训练数据底座。
我是不太信的。
那些所谓的”AI原生数仓”，我几乎都去体验过，本质上就是在原来的数仓上面套了个大语言模型的接口，你问它问题，它帮你把自然语言转成SQL去跑，核心的存储、计算逻辑，跟三年前的架构根本没区别。
未来三五年，这个赛道根本不会有什么颠覆性的黑科技。
第一，整个行业的竞争焦点，会从”比谁快”彻底转到”比谁帮客户省钱”。毕竟现在企业的IT预算都在收紧，你能帮客户把数仓的存储成本降30%，把重复计算的浪费砍掉一半，比你吹再多的”亚秒级查询”都有吸引力。
第二，之前吵得不可开交的”湖仓一体”，根本不会是什么非此即彼的替代革命。最后落地的形态一定是非常朴素的：经常查的热数据，放在数仓里算；很久没人碰的冷数据，存在便宜的对象存储里；中间靠一套自动的数据流转逻辑，按照访问频率自动在两边挪，根本不需要给客户讲那么多玄乎的技术概念。
第三，真正能把数仓做透的团队，一定不是最会写代码的，而是最懂业务口径的。那些上来就跟你讲”我们的引擎性能比别人快三倍”的厂商，基本都是卖完货就不管售后的；那些愿意花时间帮你梳理跨部门的数据标准、帮你把重复的数据清理掉的厂商，才是真的能跟客户长期走下去的。
说到底，数仓从来不是什么高深的黑科技。它就是个给企业算账的工具而已。账算不对，再先进的技术，都是白搭。
作者|大讲堂
排版|大讲堂
审核|安然