上周跟河西做生鲜电商的兄弟在科巷撸串，他把刚烤好的筋往桌上一摔，说上周618大促差点给公司赔进去。
我叼着烤茄子抬头，问他咋了。
原来他们之前一直用离线数仓，每天凌晨跑前一天的数，大促当天用户领了券，要等半小时才能在账户里看到余额，投诉工单直接爆了，客服那边电话都被打冒烟。老板拍板说上实时计算，一周之内必须搞完。
他们倒也快，找了个开源的流处理框架，把订单流往里面一塞，第二天就上线了。结果上线当天，实时大屏上的GMV跳得飞起，比去年同期高了30%，运营刚准备发朋友圈庆祝，财务那边的电话就打过来了——数不对。
差了快20万。
你以为的实时，根本不是业务要的实时
很多人对实时计算的误解，从一开始就偏了。
觉得只要数据延迟从24小时变成秒级，就算完成任务。但实际上，业务要的实时，从来不是技术指标上的毫秒级延迟，是能直接用来做决策的、和离线口径完全对齐的准确数。
那个生鲜团队的问题就出在这。他们的流处理任务里，把所有下单的请求都算成了GMV，包括那些拼团没成团的、支付超时取消的、还有用户重复提交的订单。更离谱的是，他们根本没做水位线设置，那些晚到了几个小时的订单，直接被算进了大促当天的GMV里，能不差才怪。
我之前还见过一个做在线教育的团队，为了赶风口上实时计算，专门招了两个流处理开发，花了三个月搭了一套完整的流处理平台，最后算出来的实时完课率，跟离线的数差了15%，问原因才知道，实时任务里把试看的用户也算成了完课用户。运营拿着这个数给老板汇报，说完课率涨了20%，转头就被教务的老师打脸——那些用户连第一节课都没看完。
说白了，你实时算出来的数不准，再快有什么用？还不如不实时，至少不会给业务指错路。
别上来就堆全家桶，先算清楚投入产出比
说实话，我见过太多团队跟风上实时计算，一上来就把Kafka、Flink、ClickHouse的全家桶全配齐，光服务器成本一个月就十几万，最后用了不到三个月就闲置了。
有个做本地生活的小团队，之前找我咨询，说要上实时计算，用来算用户的到店核销率。我问他们一天多少核销订单，他们说一天才三千多笔。我当时就劝他们，别折腾了，离线数仓每半小时跑一次，完全够用，花那钱干嘛。他们不听，说老板要实时大屏，结果花了二十多万搭了平台，最后大屏就用来给来访的客户参观，平时根本没人看。
80%的中小团队，根本不需要全量上实时计算平台。你得先想清楚，你的业务场景是不是真的扛不住延迟。
比如大促的时候实时调整库存、风控那边实时识别盗刷、网约车实时算用户排队时长，这些场景晚个几分钟，真的会丢钱，上实时计算是值得的。但要是你只是想给老板做个好看的大屏，或者算个一天才更新一次的用户留存率，真没必要费那劲。
不过话说回来，真有刚需的团队，也不用把实时计算想得太玄乎。我见过不少小团队，用消息队列加个简单的聚合脚本，就能实现秒级的订单统计，根本不需要搭复杂的流处理集群。能解决问题就行，管他用什么技术呢。
落地的时候，别让数仓和开发踢皮球
很多公司上实时计算踩坑，根本不是技术的问题，是团队协作的问题。
数仓团队说，我本来就管离线数仓，实时的东西是后端开发的事。后端开发说，我不懂数仓的指标逻辑，你给我个数仓表我能算，但是指标怎么定义我不管。两边扯来扯去，最后做出来的实时数和离线数对不上，业务方问起来，两边都甩锅。
之前那个生鲜电商的团队，就是这样。实时GMV是后端开发写的任务，离线GMV是数仓团队算的，两边的逻辑差了十万八千里，最后翻了三天的日志，才发现实时任务里把未支付的订单也算进去了。
要解决这个问题其实很简单。不管是实时还是离线的指标，必须有统一的owner。最好是数仓团队统一负责所有指标的逻辑定义，后端开发只需要按照这个逻辑去写流处理的任务，最后上线之前，必须把实时数和离线数跑一周的对比，误差在1%以内才能上线。
别嫌麻烦。我见过太多团队为了赶上线，跳过了口径对齐的环节，最后出了问题，花几倍的时间去补锅。
对了，还有个小细节。实时任务跑起来之后，一定要做监控。别等数据差了十万八千里才发现任务挂了，那时候黄花菜都凉了。
上周跟那个做生鲜的兄弟又去撸串，他说现在实时任务已经调好了，大促的时候用户领券10秒到账，投诉少了一大半。
他跟我说，早知道一开始就别上来就赶进度，先把口径对齐，也不至于熬三个通宵补bug。
我笑他，谁踩坑的时候不是这样想的。
下次再有人跟你吹实时计算有多牛，你先问问他，上次算出来的数跟财务对得上不。