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

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

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

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

1、快手 Flink 简介

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

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

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

2、春晚实时保障方案

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

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

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

1.过载保护

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

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

• TaskManager 做为从节点，将本身的健康信息按期汇报到 Master 节点。
• Master 节点一旦检测到极端压力，马上要求全部的 source 限速 50%。
• 若是以后做业状态良好，就会慢慢的提升咱们的输入 QPS，每次 10%。

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

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

2.全系统稳定性

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

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

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

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

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

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

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

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

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

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

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

3.压力测试

压力测试至关于春晚的一个模拟，它可以帮助咱们发现不少问题。针对春晚，压力测试比通常的时候要更复杂一些。面临的最主要的两个问题，第一个问题就是数据模型怎么构造，好比说有哪些 topic、各 topic 的数据分布是怎么样的。第二个问题是咱们如何根据这些模型生成符合条件的数据。

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

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

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

4.资源保障

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

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

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

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

• 春晚以前，咱们会批量的把 P2 的任务都中止掉，把资源所有都挪给 P0 和 P1。
• 春晚中，若是有须要，降级 P1 的资源来保障 P0 做业的资源。
• 春晚后，咱们会把以前停掉的 P2 做业再从新提起来，而且从 kafka 最新的 offset 开始消费。

经过分级保障，在资源有限的状况下，优先保障了咱们的重点做业，确保了高优任务的实时消费。分级保障对从此的服务治理意义重大。好比说之后的资源调度、灰度上线、做业迁移等等，均可以参考分级保障的策略。

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

3、春晚实时大屏

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

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

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

1.技术选型

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

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

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

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

2.压力测试

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

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

3.服务部署

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

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

4、将来规划

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

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

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