首次揭秘！​春晚活动下快手实时链路保障实践

摘要：本文由快手开发工程师刘建刚分享，主要介绍春晚活动下快手实时链路保障实践。内容主要包含以下四部分：

1. 快手 Flink 简介
2. 春晚实时保障方案
3. 春晚实时大屏
4. 未来规划

Tips：点击「阅读原文」链接可查看作者原版 PPT 及分享视频～

一、快手 Flink 简介

我们首先来看一下快手的实时计算架构图。主要分为4个部分，包括数据接入、数据计算、数据应用和数据展示。各层职责分明、衔接顺畅，方便用户开发。

640 1.png

快手的 Flink 集群规模大概有 3000 多台机器，日处理条目数为20万亿，峰值为38亿条。主要应用场景包含以下四类：

• 实时 SQL 平台，这是 Flink 托管的一个产品化的 SQL 平台。
• 短视频、直播等指标的实时计算，涵盖了公司的主要业务和产品。
• 机器学习的数据预处理，支撑着快手广告等各种模型的训练。
• 快手所有的日志拆分、同步等实时的数据流。

640 2.png

二、春晚实时保障方案

快手中标了2020年的央视春晚，春晚作为全球华人辞旧迎新的晚会，数据量之大前所未有。快手 Flink 作为公司的实时计算平台，支持春晚超大状态和千万并发等复杂计算。春晚项目的挑战主要体现在稳定性、实时性、准确性三个方面，我们为此制定了一系列方案为春晚保驾护航。

640 3.png

下面我会通过这4个方面来介绍一下我们为春晚做的努力。

• 第一个是过载保护，主要介绍极端压力下的技术应对方案；
• 第二个是全系统的稳定性，确保各个方面都万无一失；
• 第三个是压力测试，它是春晚的提前模拟；
• 第四个是资源的保障，涉及到资源的管理和保障。

640 4.png

1.过载保护

Flink 在流量激增或者单点性能不足的情况下，有可能会发生卡死、雪崩或者失败的情况。这个时候一旦我们的实时作业挂掉，整个作战计划就会被打乱，可能给公司带来很大的损失。

640 5.png

我们针对这种场景设计了一种健康检查、智能限速、源端控制相结合的柔性可用技术。为什么要通过源端控制？首先，如果出了问题，我们可以在下游的 task 上进行控制，但是这样的话可能带来一个问题，它会造成反压等阻塞行为，有可能会把整个作业卡死，所以我们通过控制数据源来从本质上解决问题。下面是我们技术实现：

• TaskManager 作为从节点，将自己的健康信息定期汇报到 Master 节点。
• Master 节点一旦检测到极端压力，立刻要求所有的 source 限速 50%。
• 如果之后作业状态良好，就会慢慢的提高我们的输入 QPS，每次 10%。

640 6.jpg

然后看一下我们的测试效果图。流量高峰到来时 QPS 为 200K。一旦 Master 节点检测到极端压力，直接将 QPS 限速到 100K。之后检测到作业状态良好，就逐步地进行恢复。经过测试（随着逐渐恢复各项指标会有波动），我们的 CPU 使用率从最高的 100% 降到了 80%~90%，ygc 由每分钟的10秒降到了每分钟3秒以内，同时也避免了的 oom、心跳超时、卡死等各种问题。这种技术能够保障我们 Flink 在极度压力下的存活，起到了削峰保命的效果。

640 7.png

我们还设计了一种轻量级的热更新模型，在作业不停止的情况下通过 restful 接口实时的控制作业去应对各种压力，避免了繁琐的修改代码、打包、上线等耗时过程。常见功能包括关闭快照、设置采样率、source 源鲜素，如下图所示。

640 8.png

2.全系统稳定性

分布式系统涉及到方方面面，任何一个环节出了问题都可能是致命的，我们为此在故障应对和项目管理上做了很多工作。故障应对包含故障排除、故障演练、故障预案，项目管理包含作业管理、集群管理、工程管理。

640 9.png

首先进行的是 Flink 的故障排除。Flink 的交互组件包括 Yarn，HDFS，Kafka，Zookeeper，我们逐一的对每个组件进行故障排除。它们各自的风险排除步骤，如下图中的表格所示。

640 10.png

故障排除完了之后，就需要在真实的场景中进行故障演练。主要的演练方法就是在我们的集群中，随机的注入各种异常来测试并且完善 Flink 的稳定性，确保 Flink 做到以下保障：

• 相关组件异常不影响 Flink，比如 Yarn 和 HDFS 的主节点挂掉。
• 作业宕机，Hawk 监测系统5秒内发现并作相关处理。
• 作业 Failover 在30秒以内。

640 11.png

为了更好地应对各种故障，我们还制定了完善的故障预案，这是一套完整的应急指导方针。针对每一种故障，我们都有快速的问题排查和解决手段。

640 12.png

除了快速应对故障，良好的管理手段也必不可少，它可以有效的减少故障。下面介绍我们管理上的一些手段。

首先是作业管理这一块，包含作业管理系统的稳定性和相关的运维工作。包括四个方面：

• 作业管理系统支持高可用。一旦出问题可以快速的切换。
• Checklist 规范用户开发，包括快照设置和数据源对齐等实战经验。
• 常见工具，包含全局日志查询、高负载查询、快速迁移等。
• 报警机制和 metric 的展示，做到问题提前发现和及时发现。

640 13.png

接下来是集群管理。集群作为我们整个系统的物理载体，一旦出现问题就是致命性的：

• 针对高优作业搭建多套实时集群，避免离线的干扰。
• 关键队列物理隔离。针对特定集群要求的作业，通过物理隔离来保障其稳定性。
• 机器环境的排查。确保机器环境符合我们的预期。
• 重要作业实现多集群的部署，出现问题秒级切换。（实时大屏会详细介绍）

640 14.png

最后一个就是工程的管理。工程管理的关键是时间线预案，主要是指导我们在什么时间点该做什么事情，贯穿整个项目开发。下面简单描述了下春晚的事前、事中、事后的主要操作：

640 15.png

3.压力测试

压力测试相当于春晚的一个模拟，它能够帮助我们发现很多问题。针对春晚，压力测试比一般的时候要更复杂一些。面临的最主要的两个问题，第一个问题就是数据模型怎么构造，比如说有哪些 topic、各 topic 的数据分布是怎么样的。第二个问题是我们如何根据这些模型生成符合条件的数据。

640 16.png

数据模型的难点在于构建的数据分布必须跟春晚保持一致。我们的解决方案是以人为参考单位，基于统计规律建立人与数据分布的映射关系。简单来说，计算出每个人在各个 Topic 的数据量，预估有多少人各个 Topic 的 QPS 就翻多少倍，当然实际情况会复杂许多。最终，我们根据公测和元旦当天用户产生的数据来进行春晚模型的建立。

640 17.png

模型构建完成之后，需要根据模型生成数据。为此，我们构建了一整套完善的数据生成服务，用户只需要进行简单的配置就可以，而流量控制、多 task 的协作、分布式生成等复杂的实现全部由平台实现。主要有三种形式的数据生成：

• 数据翻倍，基于 bytes 的流量翻倍，性能最佳。
• 时间压缩，在不改变数据分布的情况下压缩数据、提高 QPS。
• 样本生成，根据用户提供样本生成符合条件（QPS、UV等）的数据。

640 18.png

4.资源保障

春晚对数据的实时性要求比较高。只有资源保障到了才可以实现我们的实时性。

640 19.png

资源保障的关键策略是分级保障。我们把作业分了三个优先级：P0、P1 和 P2：

• P0 是高优作业，跟春晚相关的一些活动。
• P1 是重要的作业，是指业务方的一些重要作业。
• P2 是普通的任务，一般指非核心的作业。

为了做到分级保障，我们制定了重点保障高优先级作业的降级策略：

• 春晚之前，我们会批量的把 P2 的任务都停止掉，把资源全部都挪给 P0 和 P1。
• 春晚中，如果有需要，降级 P1 的资源来保障 P0 作业的资源。
• 春晚后，我们会把之前停掉的 P2 作业再重新提起来，并且从 kafka 最新的 offset 开始消费。

通过分级保障，在资源有限的情况下，优先保障了我们的重点作业，确保了高优任务的实时消费。分级保障对今后的服务治理意义重大。比如说以后的资源调度、灰度上线、作业迁移等等，都可以参考分级保障的策略。

640 20.png

资源保障的另一个体现在于快速扩容，分为实时指标监控和资源选择两个方面。实时指标监控包括作业吞吐，作业延时，快照信息，物理信息，通过这4个重要的部分就可以衡量一个作业是否健康。如果我们检测到作业有性能问题需要扩容，需要按照一定顺序选择资源来补充——集群内冗余资源，备用集群，低优任务资源。

640 21.png

三、春晚实时大屏

下面我们以实时大屏作为经典案例来介绍。快手春晚实时大屏为作战指挥官提供最核心的活动和公司大盘实时数据，总共承接了100多个实时指标的计算，包括在线、红包、互动等各项指标。主要的挑战表现在三个方面：

• 数据量大，QPS 在千万级别；
• 实时性要求比较高，在秒级以内；
• 稳定性要求高，可用性为4个9。

接下来我会从技术选型、压力测试、服务部署三个方面顺序展开。

640 22.png

1.技术选型

架构组件是以 Flink 为主，Redis 为辅。Flink 适合大规模的实时计算，Redis 作为一款高效的 KV 查询工具来辅助实时计算。

各项指标中，基于 deviceld 的 UV 计算最多、复杂度最高。一般来说，先将字符串类型的 deviceId 转成数字类型的 id，然后存储在位图结构 bitmap（存储空间小）中进行计算。这里介绍下快手的技术方案：

• Flink+HBase。HBase 负责将 deviceId 转成 id，Flink 负责计算。
• Flink+Redis。通过 Redis 判断 deviceId 是否首次出现，如果是就下发计算。
• Flink 自身。Flink 自建字典为快手内部实现的精准一次方案。

前面两种方案将字典和计算解耦，适合多个作业共享一个字典。最后一种方式不再依赖外部系统，性能最佳。实时大屏根据自己需求和熟练度选择了第二种方案。

640 23.png

2.压力测试

压力测试分为单作业的压测和全链路的压测。

• 单作业压测这一块，我们通过增量计算、批量访问、本地缓存、objectReuse 等优化技术，使单个作业的 QPS 达到百万级别。
• 全链路压测这一块，用来评估整体性能，需要协调所有数据和作业，具体操作如下所示。

640 24.png

3.服务部署

最后一步是多链路的服务部署。实时大屏作业的稳定性要求特别高，必须多链路热备：

• 双机房热备。一旦机房挂掉，立刻切到另一个机房。
• 多链路热备。针对全量链路和采样链路，集群内物理隔离、多链路运行。
• 指标故障用户无感知。最上面视图层屏蔽底层链路，底层出问题可以秒级切换。

640 25.png

四、未来规划

上面是春晚实时大屏案例的介绍，下面也跟大家分享一下我们将来的一些规划：

• 推广 SQL，探索批流统一、Table&Stream 的广泛用途。
• 自研 SlimBase statebackend，实现存储计算分离。
• 提升 Flink 故障自愈能力。
• 建立作业诊断模型，实现问题快速定位。
• 探索数据库、K8s 等相关系统的组合应用。

文章不够看？点击「阅读原文」可直接回顾作者现场分享的讲解视频～