上周在软件大道的鸭血粉丝汤店，碰到之前共事过的老周。
他端着满满一碗飘着辣油的粉丝汤，刚坐下就开始吐槽。
说他们团队前三个月砸了快两百万搞实时计算项目，最后上线的实时大屏，数据延迟居然比原来的T+1报表还离谱。
钱花了。
效果没出来。
人还累得半死。
被神化的实时计算到底能解决啥
很多人对实时计算的误解，从一开始就偏了。
觉得只要上了实时链路，所有数据都能秒出，业务效率就能翻好几倍。
真不是。
实时计算本质上解决的，是数据从产生到被业务使用的时间差问题。原来的批处理链路，得等一天的数据攒完了再跑，你想知道今天卖了多少货，得等到第二天凌晨报表跑出来。实时链路就是把这个攒数据的过程拆成一小段一小段，可能几秒、几分钟就能算出结果。
但前提是，你的业务真的需要这个速度。
老周他们当时犯的第一个错，就是把所有能迁的指标全迁到了实时链路里。连会员积分的日度变动、门店房租的月度分摊这种本来就不需要实时更新的数，也硬塞了进去。结果为了凑全量指标，集群规模越扩越大，数据源的采集频率拉到最高，大部分算出来的结果，根本没人看。
说穿了，你不需要3秒出的数，硬搞实时就是纯浪费钱。
踩过的坑从来都不是技术本身
我问老周，当时技术方案评审的时候，没人提过需求对齐的事儿吗？
他挠挠头说，当时业务那边就提了一句”我们要实时看数”，技术这边就默认要做到秒级延迟。
没人问过，这个”实时”到底是要3秒，还是3分钟，还是3小时。
就为了这个没对齐的需求，他们把Kafka的topic分区开了32个，Flink的并行度拉到了64，结果上线才发现，大部分业务场景根本不需要这么高的并行度，反而因为分区设置不合理，经常出现数据倾斜——比如某个大促的爆款商品流量特别大，对应分区的计算节点直接跑满，其他节点闲得发慌，最后整体延迟直接飙到了10分钟以上。
更搞笑的是，他们做的那个实时大屏，上面画了一堆3秒波动的曲线，运营看了两天就嫌晃得眼晕，最后还是切回了原来的小时级报表。
说实话，现在行业里太多人把实时计算的技术难度想得太高，又把业务对齐的难度想得太低。总觉得把集群搭起来、把框架跑通，项目就成了。
哪有那么容易。
真要落地别上来就堆集群
后来我给老周提了几个很朴素的建议，他回去改了不到两周，效果直接出来了。
别全量迁。先挑最痛的场景做——比如大促的时候的库存预警，这个是真的需要实时的，晚个10秒可能就超卖几千单，损失的钱够付半年的云服务器费用。那些不需要实时的指标，该跑批还是跑批，别硬凑。
把之前设的3秒刷新大屏，改成1分钟刷新。运营反而说这个节奏更舒服，既能看到实时的波动，又不会被晃得眼晕。对应的Kafka分区数从32降到8，Flink并行度砍到16，光这一项成本就降了40%。
还有，每上一个实时指标，先算清楚投入产出比。比如为了算某个实时指标，需要加一个采集节点，每个月多花2000块，那这个指标带来的业务收益，能不能覆盖这个成本？如果不能，那就没必要上。
老周前两周给我发微信，说现在他们的实时链路整体成本比原来降了60%，库存预警的延迟稳定在1.5秒以内，大促的时候再也没出现过超卖的情况。运营现在用那个大屏，反而比之前用秒级的还顺手。
不过话说回来，现在很多团队搞实时计算，还是抱着”别人都上我也得上”的心态，根本没想清楚自己要解决啥问题。
工具就是工具。
你拿个高精度的游标卡尺去量家里的桌子，不是不行，就是太麻烦，还费钱。