摘要:本文由快手开发工程师刘建刚分享,主要介绍春晚活动下快手实时链路保障实践。内容包含以下四部分:
快手 Flink 简介
春晚实时保障方案
春晚实时大屏
未来规划
Tips: 点击「 阅读原文 」链接可查看作者原版 PPT 及分享视频~
一、快手 Flink 简介
我们首先来看一下快手的实时计算架构图。主要分为4个部分,包括数据接入、数据计算、数据应用和数据展示。各层职责分明、衔接顺畅,方便用户开发。快手的 Flink 集群规模大概有 3000 多台机器,日处理条目数为20万亿,峰值为38亿条。主要应用场景包含以下四类:
实时 SQL 平台,这是 Flink 托管的一个产品化的 SQL 平台。
短视频、直播等指标的实时计算,涵盖了公司的主要业务和产品。
机器学习的数据预处理,支撑着快手广告等各种模型的训练。
快手所有的日志拆分、同步等实时的数据流。
二、春晚实时保障方案
快手中标了2020年的央视春晚,春晚作为全球华人辞旧迎新的晚会,数据量之大前所未有。快手 Flink 作为公司的实时计算平台,支持春晚超大状态和千万并发等复杂计算。春晚项目的挑战主要体现在稳定性、实时性、准确性三个方面,我们为此制定了一系列方案为春晚保驾护航。下面我会通过这4个方面来介绍一下我们为春晚做的努力。
第一个是过载保护,主要介绍极端压力下的技术应对方案;
第二个是全系统的稳定性,确保各个方面都万无一失;
第三个是压力测试,它是春晚的提前模拟;
第四个是资源的保障,涉及到资源的管理和保障。
1.过载保护
Flink 在流量激增或者单点性能不足的情况下,有可能会发生卡死、雪崩或者失败的情况。这个时候一旦我们的实时作业挂掉,整个作战计划就会被打乱,可能给公司带来很大的损失。
我们针对这种场景设计了一种健康检查、智能限速、源端控制相结合的柔性可用技术。为什么要通过源端控制?首先,如果出了问题,我们可以在下游的 task 上进行控制,但是这样的话可能带来一个问题,它会造成反压等阻塞行为,有可能会把整个作业卡死,所以我们通过控制数据源来从本质上解决问题。下面是我们技术实现:
TaskManager 作为从节点,将自己的健康信息定期汇报到 Master 节点。
Master 节点一旦检测到极端压力,立刻要求所有的 source 限速 50%。
如果之后作业状态良好,就会慢慢的提高我们的输入 QPS,每次 10%。
我们还设计了一种轻量级的热更新模型,在作业不停止的情况下通过 restful 接口实时的控制作业去应对各种压力,避免了繁琐的修改代码、打包、上线等耗时过程。常见功能包括关闭快照、设置采样率、source 源限速,如下图所示。
分布式系统涉及到方方面面,任何一个环节出了问题都可能是致命的,我们为此在故障应对和项目管理上做了很多工作。故障应对包含故障排除、故障演练、故障预案,项目管理包含作业管理、集群管理、工程管理。
首先进行的是 Flink 的故障排除。Flink 的交互组件包括 Yarn,HDFS,Kafka,Zookeeper,我们逐一的对每个组件进行故障排除。它们各自的风险排除步骤,如下图中的表格所示。
故障排除完了之后,就需要在真实的场景中进行故障演练。主要的演练方法就是在我们的集群中,随机的注入各种异常来测试并且完善 Flink 的稳定性,确保 Flink 做到以下保障:
相关组件异常不影响 Flink,比如 Yarn 和 HDFS 的主节点挂掉。
作业宕机,Hawk 监测系统5秒内发现并作相关处理。
作业 Failover 在30秒以内。
作业管理系统支持高可用。一旦出问题可以快速的切换。
Checklist 规范用户开发,包括快照设置和数据源对齐等实战经验。
常见工具,包含全局日志查询、高负载查询、快速迁移等。
报警机制和 metric 的展示,做到问题提前发现和及时发现。
针对高优作业搭建多套实时集群,避免离线的干扰。
关键队列物理隔离。针对特定集群要求的作业,通过物理隔离来保障其稳定性。
机器环境的排查。确保机器环境符合我们的预期。
重要作业实现多集群的部署,出现问题秒级切换。(实时大屏会详细介绍)
压力测试相当于春晚的一个模拟,它能够帮助我们发现很多问题。针对春晚,压力测试比一般的时候要更复杂一些。面临的最主要的两个问题,第一个问题就是数据模型怎么构造,比如说有哪些 topic、各 topic 的数据分布是怎么样的。第二个问题是我们如何根据这些模型生成符合条件的数据。
数据翻倍,基于 bytes 的流量翻倍,性能最佳。
时间压缩,在不改变数据分布的情况下压缩数据、提高 QPS。
样本生成,根据用户提供样本生成符合条件(QPS、UV等)的数据。
春晚对数据的实时性要求比较高。只有资源保障到了才可以实现我们的实时性。
P0 是高优作业,跟春晚相关的一些活动。
P1 是重要的作业,是指业务方的一些重要作业。
P2 是普通的任务,一般指非核心的作业。
为了做到分级保障,我们制定了重点保障高优先级作业的降级策略:
春晚之前,我们会批量的把 P2 的任务都停止掉,把资源全部都挪给 P0 和 P1。
春晚中,如果有需要,降级 P1 的资源来保障 P0 作业的资源。
春晚后,我们会把之前停掉的 P2 作业再重新提起来,并且从 kafka 最新的 offset 开始消费。
通过分级保障,在资源有限的情况下,优先保障了我们的重点作业,确保了高优任务的实时消费。分级保障对今后的服务治理意义重大。比如说以后的资源调度、灰度上线、作业迁移等等,都可以参考分级保障的策略。
三、春晚实时大屏
下面我们以实时大屏作为经典案例来介绍。快手春晚实时大屏为作战指挥官提供最核心的活动和公司大盘实时数据,总共承接了100多个实时指标的计算,包括在线、红包、互动等各项指标。主要的挑战表现在三个方面:数据量大,QPS 在千万级别;
实时性要求比较高,在秒级以内;
稳定性要求高,可用性为4个9。
接下来我会从技术选型、压力测试、服务部署三个方面顺序展开。
架构组件是以 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 达到百万级别。
全链路压测这一块,用来评估整体性能,需要协调所有数据和作业,具体操作如下所示。
最后一步是多链路的服务部署。实时大屏作业的稳定性要求特别高,必须多链路热备:
双机房热备。一旦机房挂掉,立刻切到另一个机房。
多链路热备。针对全量链路和采样链路,集群内物理隔离、多链路运行。
指标故障用户无感知。最上面视图层屏蔽底层链路,底层出问题可以秒级切换。
四、未来规划
上面是春晚实时大屏案例的介绍,下面也跟大家分享一下我们将来的一些规划:推广 SQL,探索批流统一、Table&Stream 的广泛用途。
自研 SlimBase statebackend,实现存储计算分离。
提升 Flink 故障自愈能力。
建立作业诊断模型,实现问题快速定位。
探索数据库、K8s 等相关系统的组合应用。
文章不够看?点击「阅读原文」可直接回顾作者现场分享的讲解视频~
你在看」吗?
本文分享自微信公众号 - 大数据每日哔哔(bb-bigdata)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。