腾讯实时计算弹性伸缩的前沿探索与实践
如果无法正常显示，请先停止浏览器的去广告插件。
1. 刘建刚
腾讯大数据实时平台 Flink 引擎负责人
2.
3. 基于 Apache Flink 打造 Oceanus 一站式实时计算解决方案，集实时应用的创建、调试、部署、运行、运维和监控为一
体，为实时应用提供全生命周期的服务，覆盖微信支付、腾讯视频、腾讯广告等集团所有业务。
整体规模
• 机器核数：百万级别
• 作业个数：上万级别
• 流量峰值：十亿级别
应用场景
整体架构
• 实时报表
• 特征生产
• 湖仓一体
• 数据同步
4. 目录
5. 从零断流到智能自治的一体化架构
6. Flink介绍：以流计算为内核的新一代计算引擎，提供基于数据流的有状态计算。
相比storm（流计算开创者），flink有以下优势：
•
保障数据exactly-once，通过local state和基于Chandy-
Lamport算法的快照来保障数据的不丢不重。
•
完善的Event-time机制，通过watermark解决了无限流的触
发、延迟等问题。
•
低延迟、高吞吐，主要通过资源管理、网络优化等来实现。
7. Flink是有状态的long-running在线计算，具备以下特征： SLA要求高
1. 时间维度上，作业流量呈潮汐规律变化，有上涨或者下降的趋势。 在支付/直播等场景，稳定性要求至少
2. 空间维度上，不同pod的负载不同，资源需求也不一样
99.99%，重启断流、资源不足导致的
failover&lag严重影响SLA。
成本压力大
在数据同步、实时报表等场景，按最大
值配置资源会导致严重浪费，业内资源
利用率普遍低于40%。
运维成本高
流式计算自身复杂性导致问题排查困
难，低延迟要求做到7×24h随时响应
8. 方案：K8s提供了node级别的
水平伸缩。 方案：流式系统一般支持水平
伸缩，比如flink。 方案：原地修改pod资源，支持
个性化配置。
缺点：stateful作业需要全局重
启，断流时间长。 缺点：需要全局重启，不支持
精准预测、异常处理等方案。 缺点：内存修改需要重启pod，
影响flink进程，导致全局重
启。
9. 核心技术突破
Job AutoScale Manager
Proactive
ML Model
Automated
Anomaly Handler
JobMaster
垂直伸缩：业内首创零断流，支持“千pod千
面”。
• 水平伸缩：强扩展性的秒级伸缩。
AI驱动的资源全托管
Horizontal
Vertical
Exception
Info
Oceanus
• • 模型精准预测，实现reactive向proactive的跨越
• 自动化异常处理，提供标准化的自愈方案。
TaskManager Operator
metrics Pod CPU&Memory
usage • 资源利用率提升30%+
GC events • 作业failover率下降70%
• 运维成本降低50%
显著的业务价值
Log info
Pod
弹性架构
10. 垂直与水平弹性
11. 本质上，所有的弹性伸缩都由以下操作组成：
• 垂直伸缩：表示原地变更pod的资源。
• 水平伸缩：表示变更服务使用的节点数。
12. 背景
垂直伸缩表示原地变更pod的资源，主要为CPU和Memory。
如果资源不支持动态变更（比如内存），就需要重启pod，将无可
避免的影响上面的stateful服务。
挑战
为了做到原地修改资源（CPU&Memory），流式平台需要给出一
JobManager TaskManager TaskManager
Pod Pod Pod
整套自底而上的解决方案：
1. JDK层面，修改内存必须要重启JVM，进而导致Flink重启。
2. k8s层面，没有专门的语义支持，无法保障全局资源一致性。
3. Flink层面，默认所有的算子处理性能一致，不支持异构资
源。
13. 技术实现：Flink支持异构资源弹性伸缩
1. AutoScaleService组件负责管理异构资源的弹性伸缩。
2. 资源对应关系为<Task, ResourceSpec>，保障Task重
调度时资源视图不变。
3.
资源变更会被持久化，保障job failover、task
failover、master failover后不丢失。
14. 技术实现：K8s支持原地修改pod资源
1.
K8s通过PodSpec来声名资源变更，通过Proposed等状态来标识过
程。
2.
Kubelet本地通过CRI接口调用实现pod cfs_quota和limit_in_bytes的更
新。
开源社区最新方案参考：In-place
Update of Pod Resources
3.
工程实现上加入了资源检测、负载检测、阈值检测等约束条件。
15. 技术实现：JDK支持动态修改内存
腾讯内部通过适配GC算法等支持动态修改内存的hard-limit：
1. 针对扩容，需要在启动时指定最大上限ElasticMaxHeapSize（大于Xmx）。
2. 针对缩容，如果资源不足会先通过GC来释放资源。
开源社区类似方案：ZGC | Using -XX:SoftMaxHeapSize
16. 执行效果
1. 图1为垂直伸缩的流量波动，伸缩过程不影响作业吞吐，做到了零断流。
2. 图2为垂直伸缩的资源图，伸缩后总资源下降60%+。
25
20
15
10
5
0
1
2
3
实际使用
图1
4
5
6
初始配置
图2
7
垂直伸缩
8
9
10
pod编号
17. 背景
Flink为有状态的计算，水平扩缩需要做状态重分布，断流会影响业务的SLA。
但是作为一种通用方案，我们需要尽可能的减少断流影响。
挑战
1. 销毁&重建耗时长：并发度变更会涉及状态的重分发，全局重启无可避免。
2. 资源申请慢：受到网络速度、磁盘IO、多组件交互等影响。
3. Exactly-once难以保障：做savepoint耗时较长，复用上次checkpoint存在数据重复。
18. 解决方案
180000
实现JobMaster&ZK、pod资源等的复
用。
160000
140000
1min+
效果
通过镜像预热、资源预申请、文件共享
等，扩容耗时从分钟级降至秒级。
120000
100000
80000
60000
40000
25s
3s
20000
0
基于增量checkpoint的轻量化操作。
4
6
8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50
并发度
常规扩容
热更新
热更新 + 预加载
19. 伸缩模式 优势 不足
垂直 零断流：原地修改pod资源，不影响flink任务。 • 扩容受制于单机总资源
• 处理性能可能受制于除CPU&内存外的其他资
源
水平
扩展性强：可以通过修改并发度充分利用整个集群的空闲资源。
应用场景：
1.
2.
3.
SLA要求高、断流敏感业
务，比如金融支付、模型
训练等。
实时大屏、直播大促等活
动场景。
Pod资源不均衡场景。
应用场景：
Fallback
1.
2.
个性化调整
常规实时计算，比如数据
同步、实时报表。
其他通用场景。
即便深度优化，断流也在所难免
• 智能决策（资源全托管平台）
• 协同互补，最大化价值收益。
20. 未来规划
• 垂直弹性 + pod热迁移：突破单机资源限制，如图1。
• 水平弹性 + 细粒度伸缩：彻底规避断流风险，如图2。
图1
图2
21. 智能预测与自动运维体系
22. 资源是实时保障最重要的因素
1.
作业总资源不足：消费积压、
lag变大，影响秒级延迟
2.
单pod资源不足：影响Task处理
初始资源无法满足日益变化的流量 资源配置和运维困扰着每一个人
1. 流量变大时，需要扩容来满足高负载。 1. 用户：如何配置资源（当前&未来）
2. 流量变小时，需要缩容来避免资源浪费。 2. 运维：线上资源问题占比60%，问题
性能，进而阻塞住整个pipeline
核心挑战
1. Long-running过程中，如何精准准确评估作业各个阶段需要的流量和资源？
2. 遇到线上问题（failover和lag）时，如何实时、自动化的解决资源问题？
排查困难、恢复时间要求高。
23. 自愈
全生命周期覆盖
1.
Lag
Start：启发式冷启动 + N轮智能预测，快
速收敛。
2.
Running：模型算法智能预测pod资源、算
子流量等信息 + 自动化的弹性伸缩。
3. Upgrade：基于历史运行信息的智能推荐。
4. Lag：基于专家模式的自动化异常处理
5. Failover：基于专家模式的自动化异常处理
Running
Start
Failover
Upgrade
24. 让系统预测未来，实现了从
reactive到proactive的跨越 垂直&水平融合，弹性策略协同
互补
低延时、高稳定 从检测到自愈的全链路闭环，实
现故障秒级自愈
25. 业界方案
基于简单历史指标的Reactive模式，存在以下问题：
• 预测效果差，传统算法无法精准捕获流式计算的时间规律和非线性关系，误差 > 25%。
• 被动式响应，出现问题时才会触发，往往已经错过了最佳解决时机。
腾讯方案
核心挑战
1.
智能预测
Reactive
输入指标：单一维度指标（比如CPU、Memory）难以预测变化复杂的实时计
算。
Proactive
2. 模型构建：如何在众多模型算法中选择与实时计算匹配的算法。
3. 动态自适应：如何应对流量的长期变化和异常抖动。
26. 多维度指标体系
Flink应用的构建依赖于JVM和k8s系统，资源利用情况会受到所有维度的影响。
为此我们构建了多维度指标体系，覆盖从应用到硬件的全栈特征，捕捉非线性关系（如 GC 事件与内存分配的关联）
Flink 应用层
• 数据吞吐率（Input/Output Rate
）
• 任务反压状态（Backpressure）
JVM内存层
系统层
• 堆内存使用量（Heap Used） • CPU 利用率（CPU Usage）
• GC 暂停时间（GC Pause） • 物理内存占用（Memory Usage
• 弹性最大堆（Elastic Max Heap
）
）
业务指标(因)
分配详情
黑盒表现(果)
27. 机器学习模型LightGBM
LightGBM
流式计算流量特征：
1.
多数呈24 * 7的周期性波动特征
2. 整体呈非线性、上升或者下降的趋势
3. 短期内可能呈时间相关性
模型选择
𝑛
1. 处理各种类型和维度数据 |𝑌 𝑖 − 𝑌′(𝑖)|
𝑀𝐴𝑃𝐸 =
𝑌(𝑖)
2. 擅长时间序列的非线性关系 对比效果：
3. 拟合性好，支持复杂关系 •
LGM：10%-
•
传统：25%+（ARIMA等）
特征工程
𝑖=1
平滑处理
1. Lag features：时间关系 1. 指数移动平均（EMA）
2. Rowing statistics：统计信 2. 滚动标准差
息
28. 动态自适应
1.
模型初始化时会利用历史数据进行全量训练，获取过
增量数据
去24小时和过去7天的pattern。
2.
为了增强实时准确性，模型会通过增量实时数据进行
全量训练
负载变化大
在线学习。如果输入样例变化比较大，会以天级别进
行回滚全量训练。
3.
尽管模型具备一定的鲁棒性，但是遇到异常情况时，
会出现流量急速下跌或者上升，我们会通过下一章的
异常数据
自动化异常处理模块来弥补。
异常处理
在线学习
29. 应用场景
1. 弹性伸缩出现问题，需要快速发现和回滚。
2. 在流量激增、failover等场景，模型算法预测不准，需要兜底方案。
3. 实时运维需要7×24h随时待命、出现问题快速恢复，急需自动化异常处理。
核心挑战
1. 实时性：传统依赖人工的问题排查耗时长，至少分钟级别起，严重影响SLA。
2. 异常分析：flink指标众多，逻辑和拓扑复杂，没有专业经验很难分析。
3. 解决方案：需要根据异常分析，给出最优的自动化解决方案。
30. 解决方案
1. 实时监测：实时消费，秒级延迟。
2. 标准诊断：作业失败和作业延迟。
3. 自动执行：
a、近期有scaling，快速回滚。
b、资源类问题，垂直&水平伸缩。
c、其他问题，走常规运维手段
31. 右图是线上作业晚高峰的预测值：
1.
2.
模型预测：根据历史规律和当前趋势，模型
晚高峰流量图
6000
可以提前预测出未来的流量。 5000
异常处理：过了流量高峰时，作业failover导 4000
致预测不准，平台通过实时诊断和扩容来快
速追lag。
3000
2000
1000
0
实际
预测
32. 业务价值与行业标杆
33. 核心业务的作业失败率下降超过70%，主要得益于：
1. 精准的预测 + 弹性伸缩。
2. 自动化异常处理 + 弹性伸缩
34. 核心业务在保障SLA的基础上，资源利用率普遍有30%+的提升，主要得益于：
1. 精准的预测 + 弹性伸缩。
2. 水平伸缩缩容 + 垂直伸缩个性化pod配置。
注：实际上单作业资源利用率能到80%乃至90%，
但是业务一般会冗余部分资源。
35. 下一代流式计算架构
36. 业务价值
1、稳定性
2、降本增效
驱动
应用
核心技术
突破
资源全托管
1、垂直零断流 1、模型预测
2、水平秒级伸缩 2、自动异常处理
37. 1. 构建基于大模型驱动的AI原
生弹性系统，进一步提升系
统的智能化水平。
2. 构建存算分离的流式系统，
充分拥抱云原生。
1. 更加全面的SQL支撑 打造一体化的对外服务：
2. 智能化的动态自适应 1. 统一的SQL API
3. 高性能和高稳定的系统 2. 统一的计算层
3. 统一的存储层
38.
39. 大模型正在重新定义软件
Large Language Model Is Redefining The Software