关于后端:如何降低-Flink-开发和运维成本阿里云实时计算平台建设实践

47次阅读

共计 5955 个字符,预计需要花费 15 分钟才能阅读完成。

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

  1. 业务背景
  2. 平台架构演进
  3. 平台外围性能建设
  4. 将来布局

点击查看直播回放和演讲 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 能够启停作业,但没有权限进行治理的操作。

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

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

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

四、将来布局

平台将来的布局大体分为三个方向:

  • 体验优化:比方更顺滑的流批一体开发体验,更好的自助运维能力。
  • 性能齐备:元数据的治理,SQL 的调试等都须要继续加强。
  • 场景丰盛:反对更丰盛的场景,如实时数仓,实时风控和实时样本等。

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


更多内容


流动举荐

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

正文完
 0