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

作者：Apache Flink

2023-03-09
浙江
本文字数：5541 字
阅读完需：约 18 分钟

摘要：本文整理自阿里云高级技术专家，Apache Flink Contributor 周凯波（宝牛），在 FFA 2022 平台建设专场的分享。本篇内容主要分为四个部分：
业务背景
平台架构演进
平台核心功能建设
未来规划

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

一、业务背景

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

第一个场景是实时 ETL，这是目前使用最广泛的场景，比如在集团的实时数据公共层业务中会对数据做统一的实时清洗、转换，为其他部门提供加工好的公共数据，便于业务部门进行二次分析。
第二个场景是实时监控，比如安全部门需要实时监测和分析用户行为或事件，基于风控规则进行预警。
第三个场景是实时在线系统，它在淘宝的搜索和广告系统中使用很广泛，主要是给用户实时推荐个性化的商品和服务。
第四个场景是实时报表，比如每次大促活动的媒体大屏，以及生意参谋这种给商家的运营工具都会提供实时报表功能。

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

首先是数据采集，数据的来源有 TT 等消息队列过来的日志数据，来自数据库的 Binlog 数据，以及消息中间件的数据。
这些数据都会经过 Flink 进行处理，产出实时明细数据和汇总数据。
处理完的数据会写入 Hologres/ODPS/ADB/Lindorm 等存储和在线分析系统，既可以直接为实时大屏，报表统计等业务场景提供数据服务，也可以由 Flink 进行再一次的分析。

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

二、平台架构演进

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

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

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

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

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

第一个方面是引擎内核从 Blink 引擎升级到了 Flink 引擎，和社区接口兼容，能够随时获取社区最新的功能。同时也能通过插件化机制，做到企业级内核的增强。
第二个方面是资源底座从 Yarn 切换到了 K8s 调度，能实现 Serverless 化，便于统一资源池和统一调度。
第三个方面是平台架构也升级为微服务架构，具备灵活的可伸缩和可扩展能力。
第四个方面是技术品牌的升级，阿里云与 Flink 社区原班人马一起打造全球统一的大数据品牌 Ververica，进一步扩大 Flink 技术在全球范围内的影响力。

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

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

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

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

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

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

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

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

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

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

三、平台核心功能建设

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

自适应流量的高峰和低谷，降低业务成本。
在每年的 618、双十一等大促期间实现资源的弹性回收，无须人工干预。
实现故障的自动诊断，降低运维成本，最终帮用户达到降本增效的目的。

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

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

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

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

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

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

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

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

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

在项目空间级别做了权限的隔离，每个用户只能访问自己所在的项目空间的资源。
每个项目空间的存储是隔离的，比如采用不用的 OSS 对象存储 Bucket，对 OSS 的访问也采用临时 Token，而不是固定的账号密码，这样能保证存储的安全。
通过实现基于角色的访问控制（RBAC），在平台上定义 Viewer、Editor、Owner 和 Admin 等角色，每种角色都有自己的权限。比如 Viewer 只能查看数据，无法启停作业；Editor 可以启停作业，但没有权限进行管理的操作。