SIGMOD 2025｜腾讯 Oceanus 开创云原生流计算弹性新纪元-CSDN博客

随着互联网海量数据爆发，各行各业对实时计算的需求愈发强烈，尤其是短视频、AI 应用、搜广推等场景。但是，实时计算面临着资源浪费、超用和分布不均衡等问题，业界常规的重启手段无法有效解决这些问题，还会因为断流严重影响在线服务的 SLA。针对这种情况，腾讯实时计算团队提出了一站式资源弹性解决方案，通过 AI 模型预测、细粒度资源管理和零断流的垂直伸缩，做到了提前感知、无损调整和自动化运维，实现了云原生场景下的极致弹性。在腾讯内部开源团队 Flink Oteam 的协同合作下，腾讯实时计算团队联合 KonaJDK、基础算法、峰峦团队以及北京师范大学将该方案成功落地于腾讯大数据生产环境中，并将成果整理成论文《Oceanus: Enable SLO-Aware Vertical Autoscaling for Cloud-Native Streaming Service in Tencent》发表于 SIGMOD 2025 INDUSTRIAL TRACK，本次为大家带来该篇论文的核心内容解读。

一、研究背景

随着腾讯旗下应用（如微信、腾讯会议、QQ等）的广泛使用，产生了大量极富价值的实时数据。在大数据场景中，普遍依赖于流处理引擎（例如 Apache Flink）处理大量的实时数据。并且随着云原生技术的不断发展，用户不仅追求数据处理的时效性，还越来越重视成本效益以及稳定性，因此更多的实时任务均部署在 K8s 上。同时，在实际的业务场景中，流量数据具有十分显著的流量潮汐、流量突增、流量不均衡等多种动态特性。基于这些原因，腾讯实时计算团队以流计算场景的成本效益及稳定性为出发点，对云上实时计算场景的弹性伸缩能力进行了探索，提出了一种针对云原生流计算场景的自动化垂直弹性解决方案，通过云原生跨层动态调整技术细粒度地调整计算资源，解决流计算场景的动态特性问题，同时最大程度地降低弹性伸缩对流计算服务 SLO 的影响，从而提升资源利用率及稳定性。在该课题的研究过程中，主要面临以下技术挑战：

● 流量的动态特性并非具备绝对的周期性，需要准确地进行扩缩容预测；

● 资源调整行为需要保证流计算处理不会中断；

● 需要有效处理扩缩容后的各种异常情况，确保任务的稳定性。

二、方案介绍

该解决方案通过主动式机器学习预测、跨层原地资源调整机制、标准异常解决流程，实现了一套完整的垂直弹性伸缩机制，旨在为云原生流服务提供精确且自动化的资源调整能力，同时确保满足流式服务 SLO。平台使用定制 JDK 版本启动流式服务，并实时收集运行时的各项关键指标进行分析、构建预测模型。基于模型预测结果启动资源弹性流程，通过完备的弹性机制保障资源调整跨层同步生效。同时全流程的资源调整行为将统一收集分析，用于观测资源调整的有效性，对于异常可以及时进行处理，其主要架构设计如下图所示：

主要包含以下四个关键组件：

● Metric Repoter：当流式计算任务运行后，实时收集来自 Flink、Kubernetes、JVM 的多维运行时指标，丰富特征数据，用于分析及构建预测模型；

● Scaling Predictor：根据收集到的多维指标，构建主动式预测模型，预测 Flink 各资源块（例如堆内存、堆外内存、CPU等）的实际资源需求及调整时机，同时通过在线学习来增强模型效果；

● Scaling Executor：基于模型预测结果，通过云原生跨层动态调整技术，动态调整 Flink 的资源管理模型、Kubernetes Pod 资源以及JVM 进程资源，实现在不重启容器及 JVM 的前提下动态调整资源，避免因资源调整导致的服务中断；

● Oceanus Server：管理用户定义的弹性规则，并对相关异常、弹性历史进行跟踪，以实现快速检测、诊断并处理异常情况，确保满足 SLO 并保持流式计算服务的可靠性。

1、主动式（Proactive）机器学习预测

反应式（Reactive）的预测在流式计算场景中存在一定的局限性，对于突发的资源需求无法提前预测，例如需要在 OOM 发生之后提高权重从而预测出较高的资源推荐值，这将影响流式服务的稳定性。同时传统的基于系统级指标的预测方法，只能基于历史的系统资源使用情况进行预测，提供了对资源使用情况的基本理解，但是缺少了上层应用的特定指标特征，在流式计算场景中无法更全面地捕捉到流式服务复杂且动态的资源需求。为了解决该问题，Oceanus 通过收集和分析更广泛的指标（包括应用特定指标、JVM 指标等），利用机器学习模型理解复杂的特征关系进行预测，能够解决缺失上层应用特定指标特征的问题，更准确地捕捉流式服务的动态需求，并且引入自动化异常诊断解决不可预测问题，从而做出更及时、准确的扩缩容决策。

🔵多维输入指标

Oceanus 弹性预测所收集的指标如下表所示：

🔹云原生流式服务指标：Flink 指标例如数据输入/输出速率，可以反映工作负载强度和数据处理速度，这些指标将直接影响 Pod 资源的使用情况。如果数据输入速率激增，可以通过评估数据输入/输出速率与当前资源配置的关系，进行弹性决策，从而实现有效的资源分配，快速地应对任务流量激增，解决任务延迟问题；

🔹JDK 内存管理指标：有效的资源分配可确保任务性能稳定，堆大小和 GC 信息指标提供了关键的内存管理视角。堆内存使用大小和 GC 统计信息（例如 GC 次数、GC 持续时间）可以直观地表示 JVM 的内存使用情况。当存在较高的堆内存利用率和频繁的 GC 时，标志着存在持续的内存压力，需要快速按需对堆内存进行弹性触发以适配新的内存需求；

🔹系统指标：当应用特定的指标不满足对资源的精准预测时，系统级指标（例如系统层的 CPU 使用、内存使用）可以反应进程的实际占用情况，协助对流式服务的实际资源使用情况做进一步的分析，以作出更为精确的弹性决策。

🔵预测模型

🔹模型选择：Oceanus 弹性资源预测过程中采集了丰富的相关指标，并且考虑到流式计算场景的复杂性，流式服务指标与系统指标之间存在着复杂的非线性关系，传统的 ARIMA 等统计模型不适合用于捕获流式服务中的非线性特征。因此我们采用 LightGBM 机器学习技术，尝试从历史数据中学习指标间的非线性关系，从而实现更精确的预测能力。

🔹特征工程：在流式计算场景中，资源需求往往呈现出较明显的周期特征，以及在 GC 触发后内存占用得到释放，然后随着时间的推进将再次逐渐累积，滞后特征通过引入过去不同时间步长的指标数据，能够较好地帮助模型捕捉对时间的依赖性，从而提高预测准确性。另外，为了避免因短期波动导致模型预测出现较大的偏差，通过滚动特性（滚动均值、滚动标准差）以及指数移动平均（EMA）平滑处理技术的结合，能够一定程度上解决工作负载抖动从而导致预测噪声，提供更稳定的模型预测能力。

🔹效果评估：使用平均绝对百分比误差（MAPE）指标来量化模型预测的错误平均幅度，从而评估模型的整体准确性。

🔹迭代反馈：为了维持长期准确性，框架结合了反馈驱动的增量更新策略。新数据将不断地进入在线学习的模型中，从而使系统能够适应流式服务的负载变化。

🔵自动化异常诊断

与上述特征工程处理的短期波动不同，当流式服务遇到突发的数据增量时，由于其不可预测的性质，已经超出了模型的可预测范围。为了解决该问题，将引入额外的自适应反馈机制，自动化激活预定义的响应策略及专家规则应对突发流量。

Oceanus 通过整合这些相互依存、紧密耦合的指标多维度分析指标特征，并结合负载预测建模及自适应反馈机制，在主动式预测和反应式处理进行权衡，最大限度保证流式服务的稳定性。

2、跨层原地资源调整机制

对于传统的资源调整机制需要重新启动 Flink 任务导致流式服务中断，而在金融、广告等多种业务场景中，用户对于流式服务的稳定性要求较高，需要尽可能避免数据断流。Oceanus 通过在流处理框架中实现统一的资源调整方案，引入紧密结合的跨层调整机制，从而实现 Flink、Kubernetes、JVM 三个组件层面的资源动态调整，实现原地资源调整并维持流式服务不间断运行。核心思想是统一流计算框架的资源管理与 Kubernetes、JVM 的资源声明及申请，从而实现资源的跨层实时变更能力。

🔵Flink 资源调整管理

在 Flink 引擎中，通过 JobManager 开放资源调整的 RESTful API，JobManager 遵循 Flink 资源模型规范构建完整的预期资源模型，并且校验请求的合法性，确保任务处于可调整状态（例如是否有充足的资源）。验证后，通过扩展的 RPC 机制实现 JobManager 与 TaskManager 的低延迟通信，并且通过完整的资源调整机制维护与 Kubernetes Pod、JVM 进程的资源强一致性，确保 Flink 运行时的资源弹性能够在容器级别、进程级别立即生效，使得重新分配的计算资源能够被有效利用。最后将调整结果反馈至 JobManager，以确定资源调整执行成功或者报告异常，从而实现引擎层面的操作一致性保障。

🔵Kubernetes 原地资源调整

不重启 Pod 的原地资源调整能力，能够使用户在不重建 Pod 的情况下动态调整其资源配额，满足了资源管理的灵活性以及业务的高稳定性要求。Oceanus 以 Kubernetes PodSpec 内的可变字段动态地声明 Pod 的内存和 CPU 资源需求，Kubelet 将更新的资源需求转换为节点上对 Cgroup 的相应修改，进行这些调整时，无需重新启动 Pod，从而在 Kubernetes 层面实现资源弹性调整过程中容器不间断运行。同时为了尽可能保证集群层面的资源分配稳定性，增加了部分强制约束条件，例如禁止修改 Pod Qos 类型，禁止修改 Limit 缺失的 Pod 等，防止存在不可预测的调度行为。

🔵JDK 自适应内存编排

传统的 JVM 在启动时通过定义静态的堆大小边界，限制了 JVM 在执行过程中调整内存的能力，因此云原生的动态调整能力也受到 JVM 内存不可调整的限制，无法提供完整、灵活的内存管理机制。为了解决该问题，自适应内存编排引入了运行时可配置的堆边界以及动态内存调整能力，通过 GC 策略将内存块调整至目标需求，可以在运行时无缝地进行调整而无需中断进程，该能力目前支持了常见的 GC 算法，例如 PS、G1、CMS 等，通过该方法可以突破 JVM 内存管理的固定边界，解决流式服务内存波动的需求。以 PS 垃圾收集算法为例，算法过程如下所示：

🔹堆扩大：当进程的内存需求超过当前堆配置大小时，Oceanus 可以使 JVM 动态扩展堆空间，缓解 GC 压力并降低内存异常的风险。通过引入 ElasticMaxHeapSize 突破标准的 -Xmx 最大堆限制，在物理内存充足的情况下动态调整堆空间，以满足潜在的资源增长需求，在内存空闲时可安全释放，确保了堆内存空间可根据服务需求灵活调整，即使在流量高峰期也支持服务不中断。

🔹堆缩小：传统的 JVM 在堆空间释放时面临的挑战是如何安全地将内存释放给操作系统，当 GC 回收掉未使用的对象释放内存空间时，该部分内存仍然被进程持有，Oceanus 通过与 Kubernetes 集成的自适应内存编排机制解决该问题。以 Parallel GC 为例，当 Oceanus 发出内存空间缩小的请求时，JVM 根据当前已使用的内存大小以及最小的释放比例等参数计算安全的收缩阈值；如果老年代的内存状态满足收缩需求，JVM 将采用增量收缩方式，逐步回收内存以确保内存空间安全，避免破坏 GC 行为或者增加 GC 频率；如果由于存在暂未回收的内存对象而导致无法安全收缩，主动触发 GC 以尝试回收内存空间，然后重新评估收缩可行性，确保不会影响进程的稳定性，并且最终释放物理内存空间。这种自适应的调整机制，在非高峰期可释放多余的内存空间，从而使系统具备更高的资源利用率，降低成本。

Oceanus 通过 Flink 资源调整管理、Kubernetes 原地资源调整以及 JDK 自适应内存编排，实现了跨层的资源动态调整，有效地平衡了应用程序的稳定性和资源成本，确保流式服务在不同的工作负载下保持动态弹性。

3、标准异常解决流程

为了有效解决弹性扩缩异常，我们提出了标准化的异常解决流程，旨在快速检测、诊断、推荐相关问题的解决方案。该框架利用实时监控、专家诊断规则以及可操作的解决方案，确定异常根本原因，使服务能够快速进行针对性的调整，进一步维护 SLO，流程如下所示：

● 异常检测：该模块实时监控服务的处理性能、稳定性指标、弹性事件等，重点识别关键指标中的异常情况，在该流程中无需进行归因。例如当垂直扩缩行为调整了 Pod 的内存分配，服务对应的处理性能指标、资源利用率等指标发生了相应的变化，这些行为将会统一进行关联，在诊断阶段进行进一步的分析。

● 异常诊断：该模块通过预定义的规则进行异常分析，通过多个专家规则诊断异常的根本原因，将异常情况进行归类。特别是对于流量突增场景，例如突增的流量已经超过了垂直弹性调整提供的性能，则将会诊断为流量突增问题；如果内存利用率超过预定义的阈值或者 Full GC 短时间内的频率过高，将会诊断为内存紧缺；另外也支持用户自定义业务流量阈值规则以适应不同的业务需求等等，通过这些诊断规则的结合，能够识别大部分的异常问题。

● 可操作建议：对于诊断归因结果，将转化为可操作的建议提供给用户，或者由 Oceanus 进行弹性行为介入，保证流式服务的稳定性。以流量突增为例，Oceanus 首先尝试通过支持运行时调整的垂直弹性解决，如果垂直弹性无法为当前流量提供足够的性能支持，Oceanus 会尝试通过水平弹性解决流量问题，分配更多的计算资源保证服务稳定性，并且联动优先级调整、弹性系数自适应等能力，快速实施资源调整，最大程度地减少服务中断事件以确保提供稳定的性能。

Oceanus 通过设计标准化的异常处理流程来处理扩缩容后的异常情况，包括异常检测、异常诊断和可操作建议三个部分。通过实时监控系统性能和扩缩容事件，结合专家诊断规则，能够快速检测和诊断异常的根因，并提供统一的建议和指导，高效地解决问题。

三、实验评估

我们在某个生产集群中对 Oceanus 弹性能力进行了测试评估，该集群 CPU 平均利用率由 20% 提升至 60%，内存平均利用率由 45% 提升至 70%。并且随着弹性规模的扩大，相关偶发的资源问题导致不稳定事件得到了较好的改善，部分业务线该部分不稳定事件降低了将近 70%，极大提高了任务的稳定性。

1、提升资源利用率

我们选择了一个生产集群，对比了 Oceanus 弹性方案对生产任务的资源利用率影响情况，如下图所示。可以看到对于 CPU 利用率普遍都较低，将近 80% 的任务 CPU 利用率低于 30%，并且平均 CPU 利用率低于 20%；而内存利用率相对来说比较高，60% 的任务可以达到 50% 的内存利用率，平均利用率仍低于 45%，但也存在一定的提升空间。在 Oceanus 弹性方案的应用下，平均 CPU 利用率超过 60%，内存利用率超过 70%，与用户静态配置的基线效果相比，资源利用率得到了极大的提升，测试结果表明动态的资源管理可以有效提高资源管理效率、资源利用率。

资源利用率的提升主要得益于主动式的资源预测能力，能够按需预测流式服务所需的资源需求，在高峰期主动扩容，低峰期主动缩容释放资源。对于缺乏多维度的应用特定指标，预测能力将无法更加精确地为特定应用提供更加精确的预测能力；而反应式的预测行为会存在着预测滞后的缺点，无法有效应对资源上涨的问题，最终触发异常处理流程；为了达到生产可用的标准，通过平滑处理技术解决抖动问题，避免因为抖动而导致服务频繁进行资源调整影响服务稳定性。Oceanus 通过综合多项技术优化能力，实现了较为理想的预测效果。我们在测试环境进行实验对比，以内存维度为例，展示不同的优化手段带来的效果提升：

2、提升服务稳定性

通过对相关服务不稳定事件进行监控，随着 Oceanus 弹性能力的应用规模逐渐扩大，对于服务的 SLO 提升十分明显。一方面由于重启引起的服务中断而导致无法满足 SLO，该部分通过 Oceanus 跨层原地资源调整技术无需重启服务，极大地降低了该部分不稳定事件。另一方面得益于 Oceanus 作出更精准的弹性决策，减少了部分资源不足引起的服务中断事件，并且随着预测模型的迭代增强，模型在连续反馈迭代中变得更加精确，进一步减少了不稳定弹性事件而导致的不规范行为。对于其余的不稳定事件，将通过标准异常处理流程进行扩展专家规则，进一步提高 Oceanus 的自适应能力。

在流式计算场景中，我们选取了服务型应用、数据处理型应用两个典型的应用场景，展示运行时调整带来的收益。对于服务型应用，在传统的资源调整过程中，随着资源规模的增大，由于资源申请、任务部署等阶段耗时的线性增大，其重启代价将逐步提高，服务可用性将受到更大的影响，而 Oceanus 运行时资源调整方案可以实现服务无损进行资源调整，保持服务的可用性。对于数据处理型应用，资源调整重启任务时，会从持久化的状态位点回溯部分数据，引起短期的流量波动，并且存在数据处理断流情况，而 Oceanus 能够有效解决该问题，在不影响正常的数据处理，保证流量稳定的前提下，实现资源的动态调整。

服务型

数据处理型

四、总结

腾讯 Flink Oteam 提出了一个针对于云原生流式服务动态调整资源的有效解决方案，通过主动式的机器学习预测模型、跨层原地资源调整能力、标准异常解决流程，创新性地实现了适用于云原生流式计算场景的主动式资源原地调整技术，并且在腾讯大数据的生产环境中得到了充分验证，可以解决资源倾斜、资源调整带来的服务重启等问题，提高资源利用率以及服务稳定性。但是对于爆炸性的流量突增、严重的资源浪费等问题，受限于原地调整资源的限制，需要将水平弹性作为另外的解决方案进行扩展实现，我们将持续优化 Oceanus 弹性能力，推动云原生流式计算资源弹性技术朝着智能化、全自动化演进。

关注腾讯开源公众号

获取更多最新腾讯官方开源信息！

加微信进群即可了解更多“腾讯开源新动态”！