大数据架构师必懂的5大实时计算技术要点

　　去年五月份那会儿，我原以为实时计算技术选型就是挑个性能好的，结果被产品经理那句“用户反馈延迟超过两秒就卸载”给整懵了。地铁上掏手机复现问题的时候，发现Flink的checkpoint间隔调小点确实能降延迟，但资源占用直接翻倍——这哪是技术问题，分明是成本和体验的博弈。后来跟运维吵架，他们说K8s调度延迟占了大头，我盯着监控里忽高忽低的CPU曲线，突然明白为什么大厂总说“实时计算是系统工程”了。

　　先说第一个要点：状态管理。我敢打包票，90%的实时计算故障都跟状态有关。有次用Spark Streaming处理用户行为，结果状态后端用HDFS，重启任务后状态恢复花了十八分钟——用户早跑光了。后来改用RocksDB，本地存储确实快，但磁盘IO一高就抖。最离谱的是测试环境，桌上排成一排的测试机，每台跑不同参数，最后发现还是得用Redis做外部状态存储，虽然多了一层网络开销，但至少能保证重启后五秒内恢复。产品经理当时还问“就这么点东西至于吗”，我指着监控里跳变的QPS说：“这‘点东西’每秒处理三百万条，丢一条你赔？”

　　第二个要点是背压机制。我原以为背压就是简单的流量控制，结果被Kafka积压事件教育了。有次上游数据量暴涨，Flink任务直接OOM，查日志发现是消费者速度跟不上生产者。后来在代码里加了背压监控，发现默认的1000条缓冲根本不够——改到5000条后，任务倒是没崩，但延迟从500ms涨到1.2秒。这时候测试机又派上用场了，调了三天参数，最后发现得结合Kafka的分区数和Flink的并行度一起调，单纯改背压阈值就是拆东墙补西墙。凉了的外卖放在桌上，我盯着屏幕里的吞吐量曲线，突然觉得这活比送外卖还累。

　　第三个要点是时间语义。这事儿特别反常识——你以为“事件时间”比“处理时间”准，结果发现数据乱序能让你怀疑人生。有次用Flink处理支付日志，按事件时间窗口统计，结果发现同一笔订单被计入了两个窗口——原来是网络延迟导致日志顺序乱了。后来改用允许延迟的窗口，设置成五分钟，结果又漏计了部分实时性要求高的订单。最后没办法，只能用双流join，一条流走事件时间，一条流走处理时间，在内存里做合并。运维看到JVM内存涨到8G，直接在群里@我：“你这任务再这么吃内存，K8s要杀你了。”

　　说到这突然想起个跑题的——上周UI走查，设计师说实时大屏的数字跳动太频繁，用户看不清。我原以为这是前端问题，结果发现是后端推送的频率太高。改用滑动窗口统计，每秒只推送一次平均值，结果产品经理又跳出来说“这样数据不实时”。最后折中成每秒推送一次，但数字保留两位小数——设计师沉默了五秒，说“这数字跳得跟心电图似的”。

文章配图，仅供参考

　　第五个要点是资源隔离。这事儿在K8s环境下特别明显。有次把实时计算任务和批处理任务混部，结果批处理任务一跑，实时任务的延迟就飙升。查资源监控发现，批处理任务把磁盘IO打满了，实时任务的RocksDB根本没法写。后来改用资源组隔离，给实时任务单独分配CPU和磁盘，结果又发现网络带宽成了瓶颈——批处理任务的大文件下载把网卡占满了。最后没办法，只能把实时任务和批处理任务部署在不同的节点上，运维说这叫“物理隔离”，我吐槽说这叫“用空间换时间”。

　　说到底，这五大要点哪个都不是银弹。我见过用Storm处理实时指标的团队，状态全放内存，重启后数据全丢，但人家用户对延迟不敏感；也见过用Flink做风控的团队，为了Exactly-Once把性能压到极致，结果一条规则变更要重启整个集群。优胜劣汰的逻辑在这儿特别明显——不是技术越新越好，而是得看业务场景到底要什么。就像我桌上那排测试机，有的跑Flink 1.13，有的跑1.15，还有个跑某个小版本的Spark Streaming——不是我们不想统一，是不同业务对延迟、吞吐、状态的容忍度差太多了。

　　现在我最怕的是产品经理突然说“我们要加个实时推荐功能”——这五个要点每个都得重新过一遍，状态得多大？背压怎么调？时间语义用哪种？Exactly-Once要不要开？资源隔离怎么做？有时候真想跟他们说：“你们先确定要延迟两秒还是数据不丢，别总想着既要又要。”但转念一想，这不就是我们存在的意义吗？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!