上周跟南京河西那家做社区生鲜的老板在南湖喝皮肚面，他吐槽去年618的糗事——当天丹东草莓被首页推了个流量位，等运营盯着小时级的报表反应过来库存告急的时候，后台已经挂着两百多笔超卖的订单。
客服电话从下午两点打到凌晨三点。
光赔优惠券就赔了小两万。
之前的数仓为什么救不了超卖的火
他们之前用的还是传统T+1数仓，每天凌晨两点跑前一天的全量销售数据，大促当天临时把报表的更新频率调到了每小时一次。听起来好像够快了？
根本不是。
每小时跑一次的报表，意味着从数据产生到同步到后台的库存显示页面，中间最长要等60分钟。那天草莓的实际库存是120份，10点15分就卖空了，但系统显示的库存还是9点整同步的数字，整整空窗了45分钟，才攒够了后面的超卖订单。
别把实时计算当成要烧几百万的重武器
很多小团队一听到实时计算，第一反应就是要搭Flink集群，要招专门的流处理工程师，要花几百万改整套系统。
真的想多了。
实时计算的核心从来不是技术栈有多新，而是让数据产生价值的延迟，能不能匹配业务决策的反应速度。你不需要为了一个超卖预警的场景，去搭一整套覆盖全公司所有业务的实时数仓。就像你不会为了去楼下买瓶水，专门开个跑车出去。
那个生鲜店的问题，本质上就是库存同步的延迟太高。我们给他们改的方案特别简单：把每笔支付成功的订单流，直接接到一个轻量的流处理任务里，每收到一笔订单，就实时扣减对应商品的可售库存，库存扣到预警线，直接给运营的企业微信群弹消息。
根本没有上什么复杂的窗口计算，也没有搞什么数据湖的架构，就是把之前每小时跑一次的批处理逻辑，换成了数据一进来就触发计算的流处理逻辑。
小团队落地实时计算别上来就堆技术栈
说实话，我见过太多团队做实时计算，一开始就奔着”行业标杆”去，买最贵的服务器，搭最复杂的组件栈，最后跑了三个月，业务方连实时看板的地址都没存进收藏夹。
纯纯浪费。
落地的时候别贪大。真的没你想的那么难。先找业务里最痛的那个延迟场景——就是那种因为数据出来太晚，已经造成实际损失的场景。比如那个生鲜店，第一期就只做超卖预警，总共花了三天就上线了，跑在之前闲置的两台测试服务器上，连新的云服务器都没买。上线之后第一次大促，超卖的订单直接降了92%，运营小姐姐当天就给我们带了两杯冰奶茶。
当然也不是什么场景都要上实时计算。比如每个月给老板看的年度营收报表，你就算每秒算一次，也没人会实时盯着数字看。硬上只会平白增加系统的运维成本。
没人愿意等。
你想啊，用户点下支付按钮的那一秒，库存有没有扣、优惠有没有算对、后续的配送人员能不能在30分钟内把菜送到，所有的判断如果要等十几分钟甚至几个小时才能反馈，不管是用户还是运营，都会被拖得非常被动。实时计算干的，就是把这些等待的时间，压到最短。
上周再跟那个老板吃皮肚面，他说现在大促的时候，运营不用再盯着报表熬一下午，能准时下班接孩子了。
就这。
比吹多少技术架构都实在。