上周跟南京新街口做连锁零售的张总喝了杯咖啡，他吐槽去年踩的坑，现在还肉疼。
去年他们做618大促，之前靠BI导T+1报表，头天的销售数据第二天才能出来，大促当天老板要实时盯各个门店的销量、库存，急得团团转。张总咬咬牙，砸了大几十万上了实时计算集群，号称能做到秒级出数，大屏实时滚动。
结果上线第二天，大促峰值流量冲上来，整个实时任务直接挂了。
大屏停在下午2点的数，一动不动。
张总脸都绿了。
别把实时计算当万能解药
那时候他们连数据倾斜是什么都没搞明白。
说白了就是，计算任务把不同的数据分到不同的分区里跑，本来每个分区的压力差不多，结果当天有款爆品的销量占了全渠道的70%，所有和这款商品相关的计算都堆到了同一个分区上，其他分区的服务器闲得发烫，这个分区的CPU直接干到100%，连带着整个任务的checkpoint（就是实时任务定期存的计算快照，防止丢数）直接超时，整个集群直接崩了。
张总说，外包当时给他吹的是”支持百万级QPS，毫秒级延迟”，根本没提过数据倾斜这茬。他们团队里两个开发，连Flink的web界面都没摸明白，出了问题只能等外包过来救场，等了三个小时，大促的高峰都过去了一半。
说实话，这种事我见得太多了。
很多团队在做技术选型的时候，只盯着厂商宣传的亮眼指标，根本没算过自己的业务到底能从这些指标里拿到多少实际收益。好像不上个实时计算，就跟不上行业趋势，技术团队就低人一等似的。
先分清真实时还是伪实时需求
我经常问来找我咨询的团队一个问题：你要的这个数据，晚10秒出来，会造成什么实际损失？
很多人答不上来。
比如零售门店的销售汇总，晚10秒看，难道门店的销量就会少一分？还是库存就会凭空多出来？根本不会。这种场景，10秒级甚至1分钟级的延迟，完全够用，硬要追求毫秒级，纯纯是浪费钱。真的。
我见过最离谱的一个团队，要做员工考勤的实时统计，要求秒级算出每个员工的打卡时间，最后算下来，光实时集群的服务器成本，每个月就花两万多，结果行政部门每周才看一次考勤数据。这不是钱多烧的是什么？
不过话说回来，真的有需要毫秒级实时的场景。
比如风控系统，要是晚100毫秒，可能就有几十万的盗刷资金被转走；比如外卖骑手的调度系统，晚1秒，可能骑手就走错了最优路线，用户要多等十分钟；比如大促的流量监控，晚几秒发现流量异常，可能整个网站就被打挂了。
去年雨花台那边一个做即时配送的小团队，就做的特别聪明。他们要做骑手的实时调度，确实需要低延迟，但他们没上来就把所有业务数据都灌进实时集群。只抽了最核心的三个字段：骑手实时位置、订单位置、预计送达时间。其他的非核心数据，比如骑手的历史好评率、用户的历史订单数，还是走原来的T+1离线计算。
最后整个实时集群的成本，只有他们最初预算的三分之一，上线之后骑手的调度效率提了27%，稳得不行。
别忽略看不见的运维成本
很多人算实时计算的成本，只算买服务器、买软件的钱，根本不算后续的运维成本。
实时系统不是上线就完事了。别不信。
你得有人天天盯着任务有没有挂，checkpoint有没有超时，有没有数据倾斜，流量涨了要不要扩容，遇到突发问题能不能在5分钟之内把任务拉起来。
之前那个踩坑的零售客户，团队里两个开发，都是做Java业务开发的，根本没人懂Flink的运维。每次出问题，要么等外包过来，要么自己瞎调，上次大促崩了之后，他们干脆把实时集群缩了一半，只留了核心的销售大盘，其他的报表全回到T+1。上次跟张总喝咖啡，他说现在每个月的技术成本降了60%，大促的时候也没再出过乱子，老板再也没对着大屏跳脚。
太真实了。
很多技术选型的时候，大家都觉得”我能搞定”，真到上线之后才发现，维护一套实时系统的精力，比你之前做十个离线报表还要多。要是你的团队没有专门的实时计算运维人员，真的别硬上太复杂的实时架构。
其实哪有什么银弹啊。
适合自己业务的，才是最好的。对吧？