写点什么

如何降低 Flink 开发和运维成本?阿里云实时计算平台建设实践

作者:Apache Flink
  • 2023-03-09
    浙江
  • 本文字数:5541 字

    阅读完需:约 18 分钟

如何降低 Flink 开发和运维成本?阿里云实时计算平台建设实践

摘要:本文整理自阿里云高级技术专家,Apache Flink Contributor 周凯波(宝牛),在 FFA 2022 平台建设专场的分享。本篇内容主要分为四个部分:

  1. 业务背景

  2. 平台架构演进

  3. 平台核心功能建设

  4. 未来规划


点击查看直播回放和演讲 PPT


一、业务背景


1


在阿里集团内部,实时业务的场景主要分为四大类。

  • 第一个场景是实时 ETL,这是目前使用最广泛的场景,比如在集团的实时数据公共层业务中会对数据做统一的实时清洗、转换,为其他部门提供加工好的公共数据,便于业务部门进行二次分析。

  • 第二个场景是实时监控,比如安全部门需要实时监测和分析用户行为或事件,基于风控规则进行预警。

  • 第三个场景是实时在线系统,它在淘宝的搜索和广告系统中使用很广泛,主要是给用户实时推荐个性化的商品和服务。

  • 第四个场景是实时报表,比如每次大促活动的媒体大屏,以及生意参谋这种给商家的运营工具都会提供实时报表功能。


2


在集团内部,比较典型的数据处理链路分为四步。

  • 首先是数据采集,数据的来源有 TT 等消息队列过来的日志数据,来自数据库的 Binlog 数据,以及消息中间件的数据。

  • 这些数据都会经过 Flink 进行处理,产出实时明细数据和汇总数据。

  • 处理完的数据会写入 Hologres/ODPS/ADB/Lindorm 等存储和在线分析系统,既可以直接为实时大屏,报表统计等业务场景提供数据服务,也可以由 Flink 进行再一次的分析。


3


上图是实时计算 Flink 在集团内的的业务规模。在大促期间,计算资源的峰值接近 200 万 core,有 3 万多个实时任务,服务了超过 90 个部门,在大促期间的峰值处理能力达到 69 亿条每秒。

二、平台架构演进


4


阿里实时计算平台的发展分为四个阶段,在 2013 年之前,处于一个百花齐放的状态,没有统一的实时计算平台。2013 年,基于自研 Galaxy 引擎的 Bayes 平台上线,开始服务数据魔方,双 11 等实时业务场景。2017 年,集团将内部广泛使用的三大实时计算引擎统一,合力打造 Blink 引擎,这时候基于 Blink 的全新的 Bayes 平台上线。随后的几年,在阿里将 Blink 代码贡献给 Flink 社区之后,开始打造内部的企业级增强 Flink 引擎。到了 2021 年,基于 Flink 引擎的云原生大数据平台阿里云实时计算平台 Realtime Compute 上线。


5


实时计算平台 2.0 的特点是一个用户一个 Hadoop 集群,集群中的计算节点是 ECS 机器。这套基于 Hadoop 生态的架构,虽然在当时能做到较好的资源隔离,但是也带来了两个问题:多租户成本比较高和资源弹性不足。

我们需要运维很多个 Hadoop 集群,除了运维成本高之外,Hadoop Master 节点也无法共用,造成管控资源的浪费;其次由于底层是基于 ECS 的资源粒度,扩缩容时间很长,用户也无法按量付费去购买 1 个核的 CPU 资源,用户的使用成本较高。

为了实现轻量化的多租户和灵活的资源弹性,我们需要将实时计算平台从 Hadoop 生态转型到基于 K8s 的云原生时代。


6


实时计算平台 2.0 到 3.0 的升级包括四个方面:

  • 第一个方面是引擎内核从 Blink 引擎升级到了 Flink 引擎,和社区接口兼容,能够随时获取社区最新的功能。同时也能通过插件化机制,做到企业级内核的增强。

  • 第二个方面是资源底座从 Yarn 切换到了 K8s 调度,能实现 Serverless 化,便于统一资源池和统一调度。

  • 第三个方面是平台架构也升级为微服务架构,具备灵活的可伸缩和可扩展能力。

  • 第四个方面是技术品牌的升级,阿里云与 Flink 社区原班人马一起打造全球统一的大数据品牌 Ververica,进一步扩大 Flink 技术在全球范围内的影响力。


7


3.0 平台的技术栈,包括五层。最下面是 IaaS 层,主要是硬件基础设施,包括物理机、虚拟机、神龙裸金属和 ARM 机型等。往上是存储层,象 OSS,HDFS 这些系统主要用来存储 Flink 作业的 Checkpoint/Savepoint 数据,以及用户作业的 jar 包等资源。

再往上是调度层,由 K8s 进行统一调度。调度层之上是引擎层,是阿里基于开源 Flink 打造的企业级增强引擎,比如自研了状态后端存储 GeminiStatebackend。最上面一层是平台层,阿里云实时计算 Flink 平台通过 Gateway 作为统一入口,内部分为 AppManager,SQLService 和 AutoPilot 等各个微服务。


8


3.0 平台是采用的是基于微服务的分层架构,技术特点是容器化,微服务化和插件化。Gateway 作为整个平台的入口,负责用户认证和鉴权,通过 API 路由统一透出平台能力。AppManager 是一个 region 化的中心化管控服务,负责作业生命周期的管理。

在计算层,基于 K8s 之上的 VC 隔离技术,每个用户看到的都是一个虚拟的 K8s 集群,用户之间的操作互不干扰,实现了比较好的多租户隔离。同时,基于 K8s 的能力可以做到容器级别的资源弹性,比如可以支持申请一个核的 CPU 资源。

3.0 架构将功能拆分成一个个的微服务,每个服务能独立开发部署和扩缩容。这样的好处是能比较方便地做到服务能力的弹性扩展。另外,不同团队可以负责不同微服务的开发,互不影响,提高协作效率。最后通过插件化来对接各种外部系统,具备很好的灵活性。


9


3.0 架构是一个基于 VC 的 Flink 硬多租 Serverless 架构,隔离性非常好。

首先,每个用户的 AppAgent 和 SQLService 这些管控服务是部署在用户自己的虚拟集群 VC 里面,管控上做到了隔离。

其次,每个用户有一套自己的 Tenant Master,对 K8s 的访问互不干扰,做到了 Master 的隔离,而底层的 Super Master 是共享的,能节省管控成本。

最后,通过 kata 安全容器,云盘,VPC 和弹性网卡 ENI 这些阿里云的基础设施可以做到计算,存储和网络的隔离。

在资源弹性方面,基于容器化技术实现了以 pod 为粒度的资源弹性,能满足用户按量付费的购买需求,降低用户成本。最后,由于集群资源的管理下层到了底座,平台方不用关心底层的集群和硬件,大大降低了运维成本。

三、平台核心功能建设


10


作为一个全托管的大数据平台,最核心的功能是对作业全生命周期的管理,包括作业的开发、调试,运行、监控告警、错误/性能问题的诊断、性能的调优。用户在平台上的活动都是围绕这些操作进行的。


11


在 3.0 平台上,用户可以使用默认的开发平台,通过功能丰富的 SQL 编辑器进行 SQL 的开发调试,同时平台也具备良好的被集成能力,第三方平台可以通过 OpenAPI 进行接入。比如像菜鸟物流云、Dataphin 等都可以往 Flink 上提交作业。

我们知道 Flink 是一个流批一体的计算引擎,因此我们在平台上也提供了流批一体的开发体验,用户只需要写一个 SQL,就可以同时运行流和批作业,极大简化 Flink 作业的开发运维成本。其次是 SQL 调试能力,通过和 Flink Session Cluster 结合,能够做到秒级别的 SQL 调试,大大提升了用户的开发效率。


12


在作业运维方面,平台有两个目标,分别是全托管和免运维。

全托管:用户不需要关心集群运维和 Flink 作业具体的提交流程,平台帮用户管理好作业,比如 Flink 作业生命周期管理,作业 Checkpoint 和 Savepoint 这些状态集的管理,以及指标监控和告警等。

免运维:平台提供一些白屏化的运维工具降低用户的运维成本。以作业探查为例,平台提供了日志归档、分类、基于 Arthas 的火焰图、基于 JMX 的内存动态和线程动态,帮助用户去分析定位作业的运行瓶颈。

但是这些工具对用户还是有一定的使用门槛,因此平台提供了 AutoPilot 智能诊断调优系统进一步达到免运维的目的。


13


Flink 作业如果想在有限的资源使用下达到最优的性能,需要对不同算子的内存和并发度等参数分别进行配置。在社区开源版本中,用户只能通过配置文件进行全局的配置,无法精确控制作业资源,这样会造成资源浪费。另外对于 DataStream 作业,每次进行资源配置都需要修改代码,打包和部署都不够灵活。

针对这个问题,我们通过 JSON 文件描述作业的执行计划,实现了算子级别的 CPU/Mem 和并发度的精细化资源配置,同时提供可视化的方式方便用户进行编辑,用户也可以通过 UI 界面配置算子的 CPU/Mem 和并发度。这样对于 SQL 和 DataStream 作业都能提供同样的用户体验。

通过细粒度资源调优功能,对于一些专业用户来说,能够将作业性能调到最优,同时降低资源的成本。


14


接下来以 SQL 作业为例,介绍一下细粒度资源调优的基本原理。在 SQL 文本到 JobGraph 的翻译中间过程中,会经过一步 StreamGraph 的生成。我们可以通过 JSON 文件对 StreamGraph 中的各个算子的资源进行描述,同时提供可视化编辑的方式。

用户通过可视化界面,可以修改算子并发/内存,还可以决定前后算子是否 Chain 在一起,甚至还可以调整 SlotSharingGroup 来决定算子是否共享同一个 Slot。

用户调整好后的 JSON 文件会应用到 StreamGraph 之上,生成最终的 JobGraph 去运行。


15


细粒度资源调优虽然可以将作业性能调到最优,同时降低资源成本,但是每个作业都手工配置也比较繁琐。此外,用户经常会遇到类似的问题,比如 Flink 调优参数众多,需要了解底层细节;业务的流量有波峰和波谷,作业配置需要手工切换;作业运行不稳定,定位困难;集群或者底层的硬件有问题,导致排查问题无从下手等等。

针对这些问题,在平台上的解法是智能诊断和智能调优,让系统自动化的做一些判断,尽可能降低人工操作和干预,让系统自动去做一些判断。比如,作业的 Checkpoint 失败,或者运行中发生了数据倾斜,这些平台都可以监控到,然后反馈给用户。


16


智能诊断调优系统分为多个模块,包括 Agent Manager,它负责管理所有 Agent 节点,Agent 节点负责对于某个任务进行具体的诊断和调优。它包括定时调度器、检测、分析、选择和执行等各个服务。

智能诊断调优系统的工作原理是,从各个地方收集作业的运行信息,比如日志,Metrics 指标,以及集群层面的硬件和网络等信息。将这些信息汇总后,就可以分析出当前作业的症状,然后从平台积累的规则库中选择对应的方案去执行。比如,发现某个节点的性能不够,建议用户调大作业的并发度等配置参数;比如发现 JobManager 或 TaskManager 节点的 GC 严重,建议用户调整内存参数等等。


17


智能诊断调优系统的业务收益体现在以下三个方面:

  • 自适应流量的高峰和低谷,降低业务成本。

  • 在每年的 618、双十一等大促期间实现资源的弹性回收,无须人工干预。

  • 实现故障的自动诊断,降低运维成本,最终帮用户达到降本增效的目的。


18


在 Flink 作业运维过程中,经常会遇到平台上的运维功能很多,但是不知道什么时候用哪个,比较分散。比如作业出现问题后,是先看日志、Metrics 指标,还是 Flink Web UI。

其次,不同类型的异常需要处理的紧急程度不一样。比如 Failover 异常,如果不是大面积出现,只是偶尔出现一次,不需要太关心。如果是 Checkpoint 超时,偶尔出现一次问题也不大,但是长时间出现就需要处理了。否则作业 Failover 后回追数据的成本会比较高。但是像 Connector 连接异常或者资源不足,会影响到作业的结果产出,就需要立即进行处理。

此外,不同人员的 Flink 专业知识背景也不一样,因为并不是每个人都清楚该如何运维 Flink 作业。

针对这些问题,在平台上的解法是,引入打分机制量化评估作业的风险程度,将健康分作为统一的入口,打通从现象到决策的端到端链路。


19


健康分的工作原理是通过智能诊断服务获取日志、Metrics、集群等信息,诊断出作业的症状,然后健康分服务进行统一打分,将作业判断为高、中、低三个风险,并给出具体的 Action 告诉用户应该怎么操作。

这样,用户不需要掌握太多的专业知识,只需要看到健康分就能一目了然清楚的知道哪些作业需要处理,以及需要做什么操作。

在健康分体系中,每个作业的初始分数是满分 100 分,当作业出现一个高等级风险时扣五分,中等级风险时扣三分,低等级风险时扣一分。

以上图中的作业为例,作业 A 是 95 分,处于低风险状态,对应的 Action 是加大 akka 超时时间,这时候用户并不需要进行紧急处理。作业 B 是 72 分,处于中风险状态,对应的 Action 是调大 3 号节点并发,用户可以稍后进行处理。作业 C 是 46 分,处于高风险状态,对应的 Action 是下游 Kafka 服务访问异常,请检查服务是否正常。这时候数据已经无法正常产出了,用户需要进行紧急处理,否则会引发生产故障。


20


除了前面介绍的在架构上做到了硬多租的隔离保证安全之外,平台还提供了很多企业级的安全能力建设。

  • 在项目空间级别做了权限的隔离,每个用户只能访问自己所在的项目空间的资源。

  • 每个项目空间的存储是隔离的,比如采用不用的 OSS 对象存储 Bucket,对 OSS 的访问也采用临时 Token,而不是固定的账号密码,这样能保证存储的安全。

  • 通过实现基于角色的访问控制(RBAC),在平台上定义 Viewer、Editor、Owner 和 Admin 等角色,每种角色都有自己的权限。比如 Viewer 只能查看数据,无法启停作业;Editor 可以启停作业,但没有权限进行管理的操作。


21


在权限认证方面,通过接入 OIDC 这种标准的身份认证机制,可以实现单点登陆。通过 OIDC 不仅可以接入阿里云 RAM 账号体系,也可以通过 DEX 插件接入 Github/Google 等其他账号体系。

在 API 访问认证方面,针对不同场景,实现了基于 Token 和基于 AK/SK 两种 API 访问认证。比如在 On-Premise 场景中,直接通过 Token 访问平台的 Resuful API。在公共云场景中,第三方平台通过 AK/SK 和 SDK 这种安全的方式访问平台。

最后,还可以对账号密码等敏感信息进行加密。比如用户在 Flink SQL 作业中看到的账号密码等敏感信息都是加密后的,平台只有在真正提交作业前才会做解密。

四、未来规划


22


平台未来的规划大体分为三个方向:

  • 体验优化:比如更顺滑的流批一体开发体验,更好的自助运维能力。

  • 功能完备:元数据的管理,SQL 的调试等都需要继续加强。

  • 场景丰富:支持更丰富的场景,如实时数仓,实时风控和实时样本等。


点击查看直播回放和演讲 PPT



更多内容




活动推荐

阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动:99 元试用 实时计算Flink版(包年包月、10CU)即有机会获得 Flink 独家定制卫衣;另包 3 个月及以上还有 85 折优惠!了解活动详情:https://www.aliyun.com/product/bigdata/sc


image.png


发布于: 刚刚阅读数: 3
用户头像

Apache Flink

关注

Apache Flink 中文社区 2020-04-29 加入

官方微信号:Ververica2019 微信公众号:Apache Flink 微信视频号:ApacheFlink Apache Flink 学习网站:https://flink-learning.org.cn/ Apache Flink 官方帐号,Flink PMC 维护

评论

发布
暂无评论
如何降低 Flink 开发和运维成本?阿里云实时计算平台建设实践_大数据_Apache Flink_InfoQ写作社区