陈剑：虎牙实时计算平台服务的SLA之路

分享嘉宾：陈剑 虎牙 大数据架构师

编辑整理：谢宇 北京邮电大学

出品平台：DataFunTalk

导读：随着实时计算的发展，越来越多的业务利用实时计算平台开发实时数据。与离线任务不同，实时任务需要更小的时延和更高的可靠性，如何更好地保障实时数据的质量是每个实时计算平台都需要解决的问题。本次的分享题目为虎牙实时计算SLA实践之路，主要分为以下几个部分：

平台介绍

核心SLA定义

核心能力建设

未来展望

1. 发展历程

虎牙业界领先的实时内容创造与直播互动能力离不开有力的基础支撑，实时计算平台作为一个关键技术，发展历程主要分为四个阶段：

混沌期：在2019年之前，业务各自搭建实时计算引擎，导致技术栈的不统一和资源利用率不高。

统一期：2019年之后统一使用Flink，提供集中任务和资源的管理。主要采用jar包模式和config模式开发任务，具有基础运维保障。

完善期：引入Flinksql，实现了全球化能力支持海外业务的需要，任务从Yarn集群迁移到容器平台实现容器化，同时增加了实时数仓支持和完善任务监控保障。

转型期：转型期主要分为两个部分：服务化的转型和智能化的实践。

2. 平台架构概览

数据从各端采集进入Datahub之后流向数据湖，然后分流到离线数仓和实时数仓，最后在应用层使用。其中实时计算平台横跨了整个流程，应用于每个流程中。

转型期关注用户核心问题，平台化思维向服务化思维转型。

1. 平台和服务思维

平台思维主要关注平台的可用性、任务稳定性、信息全面性、监控完善性。在转型期中，虎牙实时计算平台更加关注用户关心的问题诉求，而减少其他问题对用户造成的干扰。

2. 核心SLA

用户在使用平台时，关注的问题不是任务的稳定性、平台的可用性，而是数据的时效性是否符合要求。于是实时计算平台定义了延时达标率作为核心SLA，对于不同时延需求进行不同的保障，从而对用户需求进行管理并进行统计。

核心SLA代表从平台化思维向服务化思维转变，不再推脱由于其他系统出错导致的责任，眼光更加开阔，真正关注用户的需求。此外，核心SLA使得平台的覆盖面更广，比如用户的代码导致的时延问题，平台也要去帮助用户进行代码的优化。而通过关注延时达标率SLA，平台团队可以较为灵活地选择对SLA影响最大的问题优先解决。平台从平台化思维到服务化思维的转变，使团队的价值更加凸显。

平台具有很全面的指标数据，但用户实际不需要了解这些东西。所以平台应该解决用户最关注的问题。同时对于任务的成本，平台应该尽可能帮助用户建立问题分析的能力，提升使用效率。

核心能力建设主要分为延时需求管理及监控、任务分析能力、资源评估、扩缩容能力等。

1. 需求管理及监控

对于每个任务，平台提供用户定义其延时需求，而平台针对该需求进行监控。目前采用的是source的消费时间减去消息队列写入时间，再加上checkpoint的总耗时。Flink自带的latency tracking对于生产环境性能有影响，并且只反映Flink内部的处理因素，无法反应端到端的延时，比如消息队列里的消息积压。

因此，平台层面提供一个轻量级的监控，无需要花费太大的成本，并且作为大范围任务的监控，相对准确能反映出问题。

2. 任务分析能力

在丰富专业指标的基础上，平台提供了任务分析的能力，包括异常分析、延时分析和资源分析，针对一些典型问题平台给出判断。当一个任务的延时或者cpu利用率很高，之前需要用户去查看是哪个节点出问题，找到节点后观察线程堆栈，明确利用率占用在哪里。平台帮助用户完成这一过程，算子消耗了cpu或者是一直在gc等问题可以通过系统定位到，减小用户分析成本。

3. 资源评估以及动态扩缩容

资源评估主要分为两个阶段：上线前和运行时。在上线前会对资源初始化进行评估，根据用户使用的topic流量相关数据计算算子的复杂度，进行资源的初始评估。同时，平台开发了基于调试模块的压测模拟评估，在任务上线之前进行压测的评估。

在运行时有一个性能诊断引擎，根据指标输入因子，通过一些规则引擎进行性能诊断。当出现性能问题时，引擎会给出资源扩缩容的建议。当获取到扩缩容建议后，平台会提供动态扩缩容的能力。

（1）调试压测

调试压测会经历三个阶段：

首先是调试配置。用户设置调试的时长，当运行时间达到设置时间后自动停止。第二点是资源的配置，针对调试任务设置任意的资源配置。第三个是source的抽样，以及放大抽样。用户不需要造数据而是使用真实数据进行调试，并且可以指定某个source的数据流进行按比例放大。压测主要针对上线前的测试，防止高峰期资源不足。第四点是sink的模拟，把结果输出到控制台或者真实的存储上。

第二阶段是编译任务提交。这部分包括source/sink的替换，sql验证编译和资源配置的申请。在调试模式下，资源以用户粒度申请并支持资源的缓存，保证多次执行任务的情况下保持资源的可用。

第三阶段是任务运行期间。任务运行期间具有控制台的输出，支持表格和控制流、真实存储，和正式任务一致具有完整的监控分析，还具有定时停止和集群预留缓存。

（2）运行时资源评估

运行时资源评估具有一个规则引擎，根据任务监控的数据和相应的规则，给出一些诊断结果。资源配置模块通过诊断结果，产生一个推荐资源的配置，最终这个配置下发到具体的任务中，用户可以自己定义是否应用该配置。

（3）任务扩缩容

任务扩容面临两个问题，一个是耗时过长导致影响SLA，另一个是资源的不足。当容器平台处于高峰期时，可能存在资源被抢占的情况。基于这个问题，平台在扩容时，确定资源使用量之后，先确保资源申请到再进行任务的切换。对于一般的任务该方法能够将影响控制在分钟之内。除此以外，当机房资源完全不足时还支持跨机房的一键切换。

上面的图是资源推荐的曲线图，红框内的资源推荐数与高峰期的数据基本一致。

下图是资源的利用情况，红框代表应用了动态扩缩容之后的任务状态，在应用动态扩缩容之前任务之间有许多空隙，导致利用率较低。在应用之后空隙被填补了很多，整体效果较好。

（4）任务容灾

任务容灾抽象为三个层面：输入、计算和输出。

输入和输出主要针对消息队列的情况下，遇到集群雪崩、流量暴涨或者线路异常等情况。在计算层面，可能会出现任务的异常导致任务需要重启，还有资源不足如何高效迁移。

在计算层面的容灾主要是任务的恢复。平台将其分为任务层和平台层。在任务层会有一个默认的重启策略以及用户自定义的策略。

另外，平台基于ZooKeeper的高可用策略，ZooKeeper 单节点的故障可能导致任务的批量失败。原因是平台采用任务的故障率判断任务是否失败，而ZooKeeper单节点的异常导致任务同时接收到很多异常信息而导致任务的批量失败。针对ZooKeeper的异常，平台使其对于任务的敏感度降低而避免。

在平台层要做到高效迁移，一键跨机房的迁移。其核心问题在于同步底层状态，当前平台基于混合云存储来实现，在数据储存之后最终会同步到不用的机房。还有资源的预申请避免资源不足的情况。

还有一点是基于公司的容器平台去做的，容器平台对于某些节点的宿主机负载非常高时，会执行一个驱逐策略导致任务的失败。因此平台通过优先级保障，比如按任务冷却等策略来避免该问题。

对于输入输出层，最终体现的是数据调度的能力。当一个topic出现问题的时候，需要快速地将数据调度到另一个机房或是集群。

针对这一需求，平台做了两个层面的抽象：

对消息队列进行了抽象：平台会分配一个逻辑的topic，用户只需要关注逻辑的topic，不用关心topic在哪个集群上。平台在分配时，会考虑用户实际数据的位置。有了这层抽象后，平台可以高效地完成数据切换集群或是跨机房的迁移。

对Flink的库表层进行了抽象：具体的每个表会关联一个topic，这个topic同样可以动态切换，并且在切换过程中对上层无感知。

实际的效果如上图所示，其中虚线的部分表示可以基本做到动态切换，不需要用户去做应用上的改动。中间会依赖云存储进行状态的同步。

（5）算力均衡

Flink的TaskManager中，slot基于内存均分而cpu共享无法隔离。

于是，考虑到一种情况：有abc三种节点，其中并行度分别为2，4，2。

在进行分配时，首先将其分为四个group，可能会出现上图的情况。假设a任务的负载非常高的话，会导致TaskManager1的负载非常高。TaskManager2的负载比较低，就会出现算力不均衡的问题。主要原因有两点：

一是Flink在分配group时，TaskManager1已经注册完成但TaskManager2未注册完，导致前面两个group都注册到TaskManager1上。

二是SharingGroup在选择group时是无序的，意味着分配不可控。

针对以上两点，平台做了两点优化。

第一个是延缓任务的调度，比如任务包含的task数较多而且负载较高，平台会等到TaskManager1和TaskManager2都创建完成后再去分配。

第二是在分配slot之前，对group先做一个排序，确保负载高的group分配完成。

改造之前节点会分配到相同的服务器上，并且节点又是负载相对高的任务，导致算力非常不均衡。经过优化之后，最终的结果是SLA从年初的70%提升到年末的99%，均值资源利用率从12%提到了21%。绿色条形代表使用的core数，曲线代表利用率，从20年10月份随着资源相关的功能发布，使用的资源明显下降，利用率明显的上升。

未来展望分为四个方向：

一是易用性，平台本身功能需要强化的地方还很多，比如sql、上下游连通性、希望结合业务进行端到端的产品探索，做一些端到端的产品。

二是稳定性，平台的智能化方面还远不足，保障承诺仍需要更高，做到99.9%甚至99.99%的SLA保障。

三是开放性，希望能和社区有更多的互动，一起学习一起分享。

四是统一性，主要是流批一体化，需要在存储层、计算层和元数据层统一。

Q：资源利用率是怎么计算的？

A：资源利用率依托容器平台，容器平台层面会针对每一个任务涉及到的具体节点，统计出每一个节点的利用率情况。我们根据利用率向上划分到不同的任务上，再分到不同的业务中。

Q：易用性的上下游连通是指什么？

A：用户在使用我们平台时，会有一些库表的支持，这种库表对应不同的存储，就会有一个上下游的关系。易用性是指往上再抽象一层，针对一些具体的业务场景做一些端到端的产品。比如实时分析平台，数据的实时性是由计算平台承担的，用户只需要知道使用哪些数据做分析，不需要关注上下游细节的东西。

Q：什么情况下会动态驱逐？

A：容器平台会根据主机的利用率情况决定，是否需要驱逐一些容器。我们会考虑到容器平台把我们的任务驱逐，导致任务失败率过高。因此我们会在上面做一些策略，避免容器平台把重要任务驱逐。

Q：能介绍一下性能诊断引擎吗？

A：我们建立了一个规则引擎，根据过往的经验做了规则的配置，然后根据这些指标判断我们的算力够不够，算不算高负载，还要根据数据的延迟来判断。一般的扩缩容方案，更多的是通过容器的cpu利用率或者是其他资源层面的去判断。这种方式有一个核心问题，可能出现在资源层面的数据没有问题，但是业务侧数据延迟非常高的情况。因此我们的性能诊断引擎会根据业务侧的数据延迟判断，使得扩缩容机制更加精确，效果更好。

Q：扩缩容是横向扩还是纵向扩？

A：我们目前主要是横向扩。