做实时计算别上来就堆框架

去年七月在软件大道的咖啡馆蹭空调，碰到之前在外卖团队带数仓的老周。他刚从客户那边出来，T恤领口全湿了，一屁股坐下来就灌了半杯冰美式。

他说给一个做社区团餐的客户救急。之前客户的技术团队上来就拍板要上Flink集群，咬咬牙买了三台物理服务器，搭了整整半个月的实时链路，结果跑出来的餐品销量数据，比实际门店的出餐节奏慢四十分钟。那时候正是南京最热的伏天，冰粉、酸梅汤这类易化的冷品，要么送多了化得没法卖，要么送少了中午十二点就被抢空，老板站在自提点急得跳脚。

先搞清楚你要的“实时”到底有多快

很多人对实时计算的误解，从一开始就偏了。总觉得实时计算就得是毫秒级延迟，用户点一下按钮，数就得跳。

真不是。

那个团餐客户要的根本不是毫秒级响应。他要的，是能每十五分钟汇总一次各个自提点的热销品销量，让跑路线的配送师傅能灵活调整车上带的货量——就这么点需求。之前那套追求毫秒级的Flink方案，光调优checkpoint就花了快一周，算出来的数固然准，可业务上根本不需要这么高的精度。

我之前跟一个做直播电商的朋友聊，他们之前为了算实时GMV，搭了三套并行的实时链路，从Kafka到Flink再到ClickHouse，整套体系看起来特别专业。结果主播根本不看毫秒级跳的数，人家就盯着每五分钟弹一次的累计成交数，那套占了大半服务器资源的毫秒级链路，最后每个月烧两万多的云服务费，纯粹是给技术团队撑门面用的。

实时计算的核心从来不是技术栈有多新，而是你的延迟要求能不能刚好匹配业务的真实需要。你要是做金融交易的风控，那确实得要毫秒级，晚个几百毫秒就可能被薅走几百万；可你要是做社区团餐的备货，15分钟一次的延迟，完全够把损耗降下来，根本没必要为了那点技术上的“先进”，多花好几倍的成本。

真落地的时候要算清楚账

老周最后给那个团餐客户改的方案，说出来都没人信。根本没动之前买的那三台Flink服务器，就用他们已经跑了三年的MySQL从库，开了个binlog的CDC同步，每10分钟触发一次汇总计算，把各个自提点的冷品、主食、小料的销量拉出来，自动推到对应的自提点企微群里。

整个方案搭下来花了不到两天，一分钱额外的服务器成本都没加。

精度是要花钱的。

很多技术文档里把实时计算的精度、延迟、吞吐量三个指标摆在同等重要的位置，但真的落到具体业务里，你总得先问清楚，业务方愿意为多出来的那点精度，多掏多少服务器钱，多搭多少监控告警，多留多少人半夜爬起来处理故障。我们之前团队自己做实时链路的时候，一开始为了追求Exactly-Once的语义，调了整整一周的checkpoint参数，把延迟从2秒拉到了12秒，结果后来跟业务方聊才知道，他们根本允许统计里最多丢个两三单的误差——本来就有用户下单又取消的情况，为了那万分之几的精度，多花三倍的算力，完全是捡了芝麻丢了西瓜。

别让实时链路变成没人碰的黑盒

我见过太多团队的实时计算系统，搭的时候轰轰烈烈，拉个大群，开好几次项目会，上线那天还要在群里发个红包庆祝。结果过了俩月，链路里某个Kafka topic积压了三天的消息没人发现，推给运营的数还是上周的，最后出了大问题才有人过来查。

之前有个做即时零售的团队，大促的时候实时算出来的缺货率比实际低了30%，运营照着那个数备的货，当天下午三个核心商圈的矿泉水全卖空了，客诉爆了一整面墙。最后查了半天才发现，是实时链路里的一个过滤规则，把“已售罄”的商品标记给漏判了——那个规则还是半年前一个离职的开发写的，后来没人碰过。

说实话，这种事真的太常见了。

系统是死的。人是活的。

你哪怕搭的是最复杂的流批一体数仓，也得给每个实时链路配个能说清楚逻辑的负责人，每周抽五分钟看一眼消息积压量、数据波动值，比你搞一堆花里胡哨的平台门户、权限管控有用得多。别总觉得上了实时计算就万事大吉，链路跑在那，没人盯着，指不定哪天就给你捅个大娄子。

上周在软件大道又碰到老周，他说那个团餐客户现在夏天的冷品备货损耗降了快40%，老板现在逢人就夸他们家的实时系统好用。可谁能想到，那套被老板吹得神乎其神的系统，根本没用到什么高大上的技术，就是把原来散在各个表里的数，按业务需要的频率凑到了一起而已。

哪有那么多高深的技术啊。能解决实际问题的，就是好的实时计算。