简介: 快手基于 Flink 的持续优化与实践的介绍。

一、Flink 稳定性持续优化

第一部分是 Flink 稳定性的持续优化。该部分包括两个方面,第一个方面,主要介绍快手在 Flink Kafka Connector 方面做的一些高可用,是基于内部的双机房读或双机房写和一些容错的策略。第二部分关于 Flink 任务的故障恢复。我们在加速故障恢复方面做了一些优化工作。

首先,介绍 Source 方面的高可用。在公司内部比较重要的数据写 Kafka 时,Kafka 层面为保障高可用一般都会创建双集群的 topic。双集群的 topic 共同承担全部流量,如果单集群发生故障,上游自动分流。Kafka 层面通过这种方式做到双集群的高可用。但是 Flink 任务在消费双集群 topic 时,本身是不能做到高可用的。Flink 任务通过两个 Source union 方式消费,Source 分别感知上游 topic 故障,单集群故障需手动将故障 Source 摘除。这种方式的缺点是故障时需要人工的干预,必须手动去修改代码的逻辑,程序内部本身是不能做到高可用的。这是做双机房读的背景。

为了解决上述问题,我们封装了一个 Kafka 的 Cluster Source,它在 API 上支持读取双集群的 topic。同时做到,可以容忍单集群故障,集群故障恢复时也可以自动将故障集群重新加入。

接下来是关于 Sink 方面的高可用。Flink 写双集群 Kafka topic,会定义不同集群 Sink,逻辑内控制拆流。这种方式灵活性差,且不能容忍单机房故障。如果单集群发生故障,仍需要手动摘除对应的 Sink。

同样,针对 sink 我们也定制了一个 Cluster Sink,它 API 上支持写双集群 topic。具体写的策略,可以支持轮询和主从写的方式。如果单集群发生故障,逻辑内会自动将流量切到正常集群 topic。如果单集群故障恢复之后,也能感知到集群的恢复,可以自动的再把相应集群恢复回来。

另外,基于 Kafka 的 connector,我们也做了一些容错的策略,这里提到三点。

  • 第一点就是 Kafka Sink 容忍丢失。该问题的背景是,如果 Kafka 服务异常引发任务失败,并且业务可以容忍少量数据丢失,但是不期望任务挂掉的情况。针对该问题,我们的优化是,设置 Kafka Sink 容忍 M 时间内 X% 丢失。具体实现上,Sink 单 task 统计失败频率,失败频率超过阈值任务才失败。
  • 第二点是 Kafka Source 一键丢 lag。该问题背景是, 一旦任务 lag 较长时间,未及时发现,或者任务 debug 环节,需要丢掉历史验证。之前只能靠重启任务来丢弃 lag,任务重启代码比较好,耗时长。我们优化后,可以热更新、无需重启任务即可以丢弃 lag。实现逻辑是动态发操作命令给 source,source 收到命令后 seek 到最新位置。
  • 第三点是 Kafka broker 列表动态获取。该问题背景是, 生产环境中 Kafka broker 机器可能会故障下线,一旦请求到下线机器,会发生获取 metadata 超时,任务频繁失败。我们优化后,Source task 启动,可以获取集群信息,动态重新获取 Kafka brokerlist,避免频繁重启。

第二部分是 Flink 任务的故障恢复优化,分为两个过程。一个是故障发现,另外一个是故障恢复。实际的生产环境中,一些不稳定的因素会导致故障恢复的时间特别的长,用户的感知会比较差。同时,内部也有一些比较高优的任务,它对稳定性的要求比较高。我们希望做一些事情,把整个故障恢复的时间尽可能缩短。我们定了一个优化目标,20 秒内做到一个自动的恢复。

在故障发现阶段的优化包括三点:

  • 第一,内部自研 Hawk 系统,5s 发现宕机。
  • 第二,Yarn 整合 Hawk,快速感知宕机。
  • 第三,Flink 感知宕机 container release。

在故障恢复阶段的优化包括:

  • 第一,允许冗余部分 Container。
  • 第二,适当调整 cancel task timeout 时间。
  • 第三,针对适合任务开启 Region Failover。

二、Flink 任务启动优化

第二部分是任务启动优化,Flink 任务启动的时候,一般会涉及到比较多的角色,还有多个实例。如下图所示,它的启动在客户端包括,初始化 Client,构建 jobGraph,上传 Flink lib、job jar,申请 AM。在 Job Master,AM 启动后、初始化,构建 ExectutionGraph,申请、启动 Container,Job Task 调度。在 Task Manager 端, 容器申请到之后,启动下载 jar 包资源,再去初始化 Task Manager 服务,然后收到 task 后才会去做部署。我们发现,线上启动一个任务的时候,基本上在分钟级别,耗时比较长。如果有一些任务需要升级,比如说,改了一些简单的逻辑,需要将原来的任务停掉,然后再去重新启动一个新的任务,这种场景可能就会更慢。因此,我在任务启动的时候做一些优化,尽可能缩短任务启动的时间,业务的断流时间也进一步缩短。

在 Flink 新任务启动优化方面,我们发现 IO 交互会比较耗时。在客户端的 IO 包括,Flink 引擎 lib 包上传 HDFS,用户上传 jar 包上传 HDFS。在 JobMaster 包括, Container 下载启动资源,TaskManager conf 上传 HDFS。在 TaskManager 包括, Container 下载启动资源,Conf 文件下载。

因此,想尽量的减少这样的一些 lO 的操作。针对 Flink 引擎 lib 包,设置 Public 权限,App 之间共享。对于用户 jar 包,提供工具,提前预发布到集群机器。对于 Conf 文件,通过环境变量传递。针对 JobMaster 启动 TM 频繁文件判断,增加 cache 缓存。

以上是针对一个新任务启动场景,下面介绍任务升级的场景。以前是同步升级,比如说,任务 A 在运行着,然后我要把任务 A 停掉,再去启动新的任务 B。如下图所示,不可用时间包括停任务 A 和启动新任务 B。是否可以不用等任务 A 完全停掉之后,再启动任务 B。针对这个想法我们做了一个异步升级的策略。新任务提前启动,初始化到 JobMaster 阶段。旧任务停掉后,完成新任务后续启动工作,这样新旧任务无缝切换。通过内部提交平台将该步骤串联起来,目标是异步升级在 20s 以内完成。

三、Flink SQL 实践与优化

第三部分会介绍一下我们在使用 Flink SQL 的一些实践和优化。首先介绍一下 Flink SQL 在快手的现状。目前,我们内部 Flink SQL 的任务占比在 30% 左右。Flink SQL 的任务个数是 360 多个。然后它的峰值处理的条目数还是比较高的,大约是 4亿每秒。在我们内部的一些重要活动的实时大屏的场景下,目前 Flink SQL 也作为一条链路,参与了相关指标的计算。

接下来介绍一下我们在使用 Flink SQL 的时候遇到的一些问题,以及我们做的一些优化。首先,关于 Flink SQL 的倾斜问题,在 UnBounded Agg 场景下的倾斜问题,已经有比较全面的思路去解决,总结为三点。

  • 第一,MiniBatch Aggregation,思路是内存缓存 batch 数据再进行聚合,减少状态访问次数。
  • 第二,Local Global Aggregation,思路是聚合操作拆分为两阶段, Local 阶段预聚合减少数据条数,Global 解决全局聚合。
  • 第三,Split Distinct Aggregation,思路是针对 count distinct 场景, 对分组 key 先分桶预聚合, 再对分桶结果全局聚合。

所以我们解决的第一个问题就是 Bounded Agg 的倾斜问题。如下图所示,拿左边的 SQL 作为例子,group by一个user,假定一天的窗口,然后去 select 每一个用户总的交易额。右边的图,假定有一些用户的交易特别多,就会造成某一些 Window Agg 的数据量特别大。

解决思路分为两点。

  • 第一,两阶段聚合,分为 Local window Agg 和 Global window Agg。Local window Agg:预聚合 window 大小与 global 阶段保持一致,checkpoint 时将结果写出,不保存状态 。Global window Agg:全量聚合。
  • 第二,增加 mini-batch,好处是 local 阶段 mini-batch 避免数据量缓存过多,Global 阶段 mini-batch 减少状态访问次数。

我们解决的第二个问题是 Flink SQL 下的 UDF 函数复用的问题。如下图所示,以左边的 SQL 为例,可以看到有两个 UDF 的函数,这两个函数在 SQL 里面都重复出现了多次。

  • 优化前:相同 UDF 多次执行,性能变差。
  • 优化后:同一条数据下 UDF 结果复用,避免多次调用执行,节约资源,性能也得到提升。拿示例 SQL 来说,性能提升了 2 倍。

四、未来工作

第四部分介绍我们未来的一些规划,分为三块。

  • 第一,关于资源利用率。目标是提升集群整体资源利用均衡性,Flink 任务内调度均衡性,以及 Flink 任务资源使用合理性。
  • 第二,关于 Flink SQL。我们会持续的去做推广。我们希望提升 SQL 任务稳定性和 SQL 任务资源的利用率。
  • 第三,探索流批统一,这也是业界的一个方向。我们希望可以一套代码就解决问题,不用重复开发两套任务。

作者:阿里云实时计算Flink

原文链接

本文为阿里云原创内容,未经允许不得转载

快手基于 Flink 的持续优化与实践的更多相关文章

  1. 趣头条基于 Flink 的实时平台建设实践

    本文由趣头条实时平台负责人席建刚分享趣头条实时平台的建设,整理者叶里君.文章将从平台的架构.Flink 现状,Flink 应用以及未来计划四部分分享. 一.平台架构 1.Flink 应用时间线 首先是 ...

  2. 学习笔记——Maven实战(四)基于Maven的持续集成实践

    Martin的<持续集成> 相信很多读者和我一样,最早接触到持续集成的概念是来自Martin的著名文章<持续集成>,该文最早发布于2000年9月,之后在2006年进行了一次修订 ...

  3. Maven实战(四)——基于Maven的持续集成实践

    Martin的<持续集成> 相信非常多读者和我一样.最早接触到持续集成的概念是来自Martin的著名文章<持续集成>.该文最早公布于2000年9月,之后在2006年进行了一次修 ...

  4. 字节跳动流式数据集成基于Flink Checkpoint两阶段提交的实践和优化

    背景 字节跳动开发套件数据集成团队(DTS ,Data Transmission Service)在字节跳动内基于 Flink 实现了流批一体的数据集成服务.其中一个典型场景是 Kafka/ByteM ...

  5. 腾讯新闻基于 Flink PipeLine 模式的实践

    摘要  :随着社会消费模式以及经济形态的发展变化,将催生新的商业模式.腾讯新闻作为一款集游戏.教育.电商等一体的新闻资讯平台.服务亿万用户,业务应用多.数据量大.加之业务增长.场景更加复杂,业务对实时 ...

  6. 实践torch.fx第一篇——基于Pytorch的模型优化量化神器

    第一篇--什么是torch.fx 今天聊一下比较重要的torch.fx,也趁着这次机会把之前的torch.fx笔记整理下,笔记大概拆成三份,分别对应三篇: 什么是torch.fx 基于torch.fx ...

  7. 基于Oracle的SQL优化(社区万众期待 数据库优化扛鼎巨著)

    基于Oracle的SQL优化(社区万众期待数据库优化扛鼎巨著) 崔华 编   ISBN 978-7-121-21758-6 2014年1月出版 定价:128.00元 856页 16开 编辑推荐 本土O ...

  8. 转://从一条巨慢SQL看基于Oracle的SQL优化

    http://mp.weixin.qq.com/s/DkIPwbDKIjH2FMN13GkT4w 本次分享的内容是基于Oracle的SQL优化,以一条巨慢的SQL为例,从快速解读SQL执行计划.如何从 ...

  9. 基于 Docker 的微服务架构实践

    本文来自作者 未闻 在 GitChat 分享的{基于 Docker 的微服务架构实践} 前言 基于 Docker 的容器技术是在2015年的时候开始接触的,两年多的时间,作为一名 Docker 的 D ...

  10. 从一条巨慢SQL看基于Oracle的SQL优化(重磅彩蛋+PPT)

    本文根据DBAplus社群第110期线上分享整理而成,文末还有好书送哦~ 讲师介绍 丁俊 新炬网络首席性能优化专家 SQL审核产品经理 DBAplus社群联合发起人.<剑破冰山-Oracle开发 ...

随机推荐

  1. Android Studio自带模拟器无法访问网络问题解决

    测试APP的时候,发现Android Studio自带的模拟器访问不了百度等网站,之前一直用的好好的,觉得可能是版本的问题,也有可能是公司网络的问题(因为在家里的电脑的Android Studio的模 ...

  2. day11-面向对象02

    面向对象02 7.继承 继承的本质是对某一批类的抽象,从而实现对现实世界更好地建模 extends的意思是"扩展".子类是父类的扩展. Java类中只有单继承,没有多继承!(一个儿 ...

  3. Android视音频基础知识

    学术概念 采样和采样频率: ⼀秒钟内采样的次数称为采样频率.采样频率越⾼,越接近原始信号,但是也加⼤了运算处理的复杂度.根据Nyquist采样定理,要想重建原始信号,采样频率必须⼤于信号中最⾼频率的两 ...

  4. 毕设系列之Linux V4L2(图形图像采集篇)

    PS:要转载请注明出处,本人版权所有. PS: 这个只是基于<我自己>的理解, 如果和你的原则及想法相冲突,请谅解,勿喷. 前置说明   本文作为本人csdn blog的主站的备份.(Bl ...

  5. 3D渲染慢,直接买显卡还是用云渲染更划算?

    3D渲染对建筑师和设计师来说并不陌生,3D渲染的过程中出现渲染卡顿.特殊材质难以渲染,或者本地配置不足.本地渲染资源不够时,常常会影响工作效率.本文比较了3D渲染时,为提高工作效率,买显卡还是用云渲染 ...

  6. 3DCAT实时云渲染助力广府庙会元宇宙焕新亮相,开启线上奇趣之旅!

    超 400 万人次打卡,商圈营业额逾 3.6 亿元,2023 年广府庙会于2023年2月11日圆满落幕. 活动期间,佳境美如画,融合VR.AR.虚拟直播等技术的广府庙会元宇宙焕新亮相,群众只需点击一个 ...

  7. Https详细分析

    目录介绍 01.为何会有Https 02.解决方案分析 03.SSL是什么 04.RSA验证的隐患 05.CA证书身份验证 06.Https工作原理 07.Https代理作用 08.Https真安全吗 ...

  8. Redis数据库安装与使用总结

    Redis语句总结 一.基本概念 Redis 全称: Remote Dictionary Server(远程字典服务器)的缩写,以字典结构存储数据,并允许其他应用通过TCP协议读写字典中的内容. 使用 ...

  9. 记录--Vue 右键菜单的秘密:自适应位置的实现方法

    这里给大家分享我在网上总结出来的一些知识,希望对大家有所帮助 下图这个情景,你是否也遇到过? 当你右键点击网页上的某个元素时,弹出的菜单被屏幕边缘遮挡了,导致你无法看清或选择菜单项? 上图中右键菜单的 ...

  10. 工作记录:Vue项目中使用WebSocket通讯

    WebSocket介绍 以下内容摘自维基百科: WebSocket是一种网络传输协议,可在单个TCP连接上进行全双工通信,位于OSI模型的应用层.WebSocket协议在2011年由IETF标准化为R ...