快手计算链路详解：从Kafka到Flink，再到数据应用与离线计算

		作者 | 董亭亭	
		整理 | 蒋晓峰	
		编辑 | Natalie	AI 前线导读： 作为短视频分享跟直播的平台，快手有诸多业务场景应用了 Flink，包括短视频、直播的质量监控、用户增长分析、实时数据处理、直播 CDN 调度等。本文将从 Flink 在快手的应用场景以及目前规模、Flink 在落地过程的技术演进过程、未来计划这三个方面详细介绍 Flink 在快手的应用与实践。
一．Flink 在快手应用场景与规模
	1. Flink 在快手应用场景
	

现在，在这个由数据驱动的互联网时代里，实时计算技术已经成为许多科技公司用来处理海量信息的核心引擎，并且，它也是这些公司优化业务决策的核心引擎 。

快手实时计算架构概览

快手的数据处理链路，起始于数据库变更记录，起始于前端服务日志，这些信息被送至Kafka消息队列，数据随后流入Flink计算框架，在其中进行多维度实时处理，处理涵盖数据清洗转换，涵盖实时分析，涵盖时间区间关联，涵盖模型训练，最终结果存储在Druid系统中，或存储在Elasticsearch系统中快手买fs，或存储在HBase等系统中，为上层数据应用提供支撑，这套架构于2023年支撑了平台数亿日活用户产生的实时数据流转。

实时数据关联的技术实现

在广告推荐场景里，系统要有实时关联，关联的是用户行为流与广告曝光流，Flink的区间连接机制是怎样的，这种机制把双流数据缓存在内部状态库，任一流数据到达时，此机制会自动获取对应时间窗口内的匹配数据，进而执行关联函数，如此设计有效解决了流式数据处理中的时序对齐难题，还保障了关联操作的准确性以及时效性。

状态存储的性能挑战

实际上在应用当中，基于RocksDB的状态存储，执行时间范围查询操作，采用前缀扫描机制，这种方式要遍历大量无效数据条目，并致使PageCache缓存层负载激增，数据解码过程中有效性校验环节，消耗大量CPU资源，最终成为系统性能瓶颈重要成因之一，此类问题在数据峰值时段格外显著。

KeyedStreamA.intervalJoin(KeyedStreamB)         .between(Time.minutes(0),Time.minutes(20))         .process(joinFunction)
         .process(joinFunction)

实时监控与调度体系

平台借助Druid储存关键运行指标，Druid支持多维度实时分析，Druid支持异常告警，平台构建了直播流量调度系统，该系统借助Flink作业，Flink作业动态调节各内容分发网络间的流量配比，这套体系在2023年双十一期间成功保障千万级并发用户的观看体验，达成了网络资源的最优化安置配置 。

复杂作业的优化策略

碰到难题，涉及多数据源，还有并发读取状况，刚开始的时候，采取暂行办法，也就是去重置消费组偏移量，之后呢，研发一套源头控速机制，凭借它，精确调控各个数据源的读取速度，借此避免单个节点出现性能问题，进而致使系统级雪崩，这个方案，在2024年年初施行以后，系统稳定性有显著提升。 。

未来发展方向

数仓需求持续增长，在这种情形下，Flink SQL因具备低代码特性成为重点发展方向，它能够大幅降低开发门槛，它还可以加快业务迭代速度，虽然当下仍然面临状态管理、资源调度等挑战，但是通过持续优化，预计在2024年内能够完成核心业务的SQL化改造。

疑问各位读者快手买fs，于其实际工作时间段，有无遭遇实时计算系统性能调优这般困难状况呢？若有愿分享经验见解、觉此篇文章具一定助益之想法，那就勿吝操作，点赞予以支持吧！