关于后端:FLINK-在蚂蚁大规模金融场景的平台建设

摘要：本文整顿自蚂蚁团体高级技术专家、蚂蚁团体流计算平台负责人李志刚，在 Flink Forward Asia 2022 平台建设专场的分享。本篇内容次要分为四个局部：

1. 次要挑战
2. 架构计划
3. 核心技术介绍
4. 将来布局

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

一、次要挑战

1.1 金融场景业务特点介绍

第一局部是时效性。金融场景谋求时效性，特地是一些风控类的业务。首先，无论是宕机还是其余危险状况，对业务的影响须要在秒级以内。其次，业务逻辑常常变更，不能影响时效性。最初，金融业务上下游依赖特地简单，须要保障时效性不受到影响。

第二局部是正确性。金融数据在任何状况下，计算出来数据必须保障 100% 正确。不能因为呈现任何故障或者其余问题导致数据出错，一旦数据出错业务是不可承受的。以后很多业务都是先开发一套离线的数据模型，而后再开发实时的数据模型，这两边如果应用了不同的引擎，就这会导致数据核查相当艰难。如果数据呈现问题，咱们须要像写 JAVA 代码或者 C++ 代码一样，有比拟不便的调试技术，发现问题所在，并进行修改。

第三局部是稳定性。蚂蚁业务混布在大的物理集群，有在线业务、离线业务、实时业务。在如此简单、多变、混布的环境下，须要保障实时业务的稳定性，不能因为在云化环境下的 K8s 组件或者其余组件影响实时业务。在申请特地大的 Pod 资源时，工夫会特地长，就满足不了实时业务的秒级规范。因为金融场景这些特点，咱们提出翻新的解决方案。

1.2 蚂蚁流计算业务的根本状况

流计算规模大略在 78w Core，1.2w+ 个流作业，所有的集群都运行在云原生的集群上。咱们每年撑持的大促流动特地多，反对 15 次以上的大促流动。因为大促业务会常常变动，须要动静的弹性计算能力。

1.3 流计算业务的次要挑战

近几年，实时计算的技术处于稳定期，在弹性方面的挑战有以下局部：

• 在大促常态化后，集群能够随时扩缩容。
• 在混布环境下，如何保障实时业务的稳定性。不能因为别的业务影响到实时计算稳定性。
• 流计算最外围的技术是优化状态的性能。如何极致优化状态性能，保障在任何大数据 Join 或者窗口的状况下没有性能问题。

在易用性方面的挑战有以下局部：

• 金融业务或者 BI 业务会随时进行变更。如何在变更的状况下，疾速重启作业。
• 如何解决 SQL 作业调试难问题。
• 如何做到流批对立。

1.4 应答挑战的办法

在易用性方面，咱们的解决方案是：

• 对实时计算平台进行革新，提出热启动技术，解决在云化环境下启动慢的问题。
• 调试 SQL 代码像在 IDEA 调试 JAVA 代码一样，解决排查数据艰难的难题。
• 提出了基于 Flink 的流批对立的开发平台。

在弹性方面，因为大促流动十分多，须要随时扩缩容。所以咱们的解决方案是：

• 基于 K8s 全面进行混布。
• 对 Flink 原生的 K8s 模式进行革新，提出云原生的 Flink 集群模式，防止因为 K8s 的问题导致影响实时业务稳定性。

二、架构计划

<p style=”text-align:center”> 蚂蚁实时计算平台的架构图 </p>

最底层是 K8s 平台，上一层是 Flink runtime 流批一体，蚂蚁流计算的核心技术。提出了 K8s 集群模式，采纳开源社区 DophinScheduler 来实现工作流的调度。

核心技术包含内存优化、窗口优化、复杂多变的云化环境下的智能诊断（如何发现问题，问题的定位等）；调节流计算作业的参数艰难，因而提出基于 AI 学习算法自动化解决调参问题；社区版本 RocksDB 状态在某些状况下性能不好，咱们做了状态存储 AntKV，相比 RocksDB 性能有两倍的晋升。

提出了调试 SQL，像调试 JAVA 代码一样不便的性能；热启动解决作业启动速度慢的问题；用户只有写一套 SQL 作业，指定跑流模式还是批模式，解决用户不必写两套代码和其余开发的问题。

三、核心技术介绍

3.1 热启动技术

第一局部，为什么须要热启动技术？

首先，开发实时作业的人都晓得，批改作业参数，比方内存、并发等，改完之后重启整个作业的工夫特地长。特地在云原生环境下，提交作业、申请 Pod、Pod 发下来、拉起镜像等一系列流程，要花费几分钟。对于金融的实时业务来说很难承受。

其次是流量渐变，在大促流动时，流量常常会发生变化。面对这种变动，咱们须要疾速适应它，改并发、内存、UDF 的状况常常产生。如果应用原生版本的 Flink，流程会特地长。从改，到提交，再到资源真正下来、作业跑起来等流程均匀下来可能要四分钟。

咱们要怎么解决呢？

咱们提出了热启动技术，它的技术原理是用户在前端界面，会申请一个 rest 服务。而后咱们把批改后的执行打算参数提供给 rest，会做一些前置校验。接着把前置校验后的参数和执行打算，提到曾经在跑的那个作业上。当它拿到新的执行打算后，会把旧的暂停，而后 cancel 掉，复原之后再缓缓创立进去。

总的来说，把新的执行打算提上去，把旧的暂停，而后依据新的执行打算生成新的部署模式。这么做的益处是，绕过了后面的 SQL 编译阶段，包含 SQL 下载 Jar 包等简单的流程，节俭了 Pod 申请的工夫，作业重启操作在秒级实现。

<p style=”text-align:center”> 热启动技术解决流程 </p>

第一，将携带过去的新 JobGragh 和旧的 JobGragh 进行 merge，将旧的 JobGragh 中能够复用的数据进行回填到新的 JobGragh 中，包含 Jar 包、资源、文件等。

第二，新的执行打算生成后，把旧的 Task、两头的 Checkpoint Coordinator 两头的协调节点暂停掉。

第三，全副暂停后，把新的 JobGragh 调度起来，加载新的状态。如果新的执行打算调度失败，须要有回滚技术，回滚到上一个失常状态，保障用户操作体验的敌对性。

<p style=”text-align:center”> 热启动成果 </p>

采纳热启动技术，作业操作工夫节俭 90% 以上。也就是说，原来大部分启动作业须要 300 秒，当初应用热启动技术只须要两秒，甚至一秒。

3.2 K8S 集群模式

第二局部，为什么须要 K8s 集群模式？

• 上图右侧是开源社区版本提供的原生 K8s 提交 Flink 作业形式。首先 K8s Client 找 K8s 的 API Server 申请 K8s Service，K8s 启动 K8s 的 deployment，而后拉起 Master 角色，再在 Master 里申请 Flink 须要的 Pod，在 Pod 启动 TaskManager 等流程。这些简单流程都依赖 K8s 组件，像 API Server、K8s Master，这就会导致单点。一旦 API Server 呈现降级或者故障，就会影响作业的提交、运维等。在蚂蚁实际下来，历史上呈现过很多问题，碰到 K8s 集群降级会导致实时作业不能提交、运维。
• 申请大的资源 Pod 时，工夫就会特地漫长，甚至是五分钟级的，对用户体验特地蹩脚。
• 申请大 Pod 32 核 64GB 的常常失败。
• 在实时业务大促流动时，不能动静的满足业务新增资源需要。
• K8s API Server 性能是有瓶颈的。如果一次大批量创立几百个 Pod，就会特地慢，容易超时。

为了解决以上问题，咱们提出了 K8s 集群模式。

<p style=”text-align:center”>K8s 集群模式 </p>

基本思路是先通过 Operator 向 K8s 申请大量资源，而后 ClusterManager 会把资源 hold 住。之后提交作业，就不必去找 K8s 的 API Server 或者 Master 申请 Service、Deployment 等资源。

这样有什么益处呢？

首先，能够缩小或者不须要和 API Server、Master 打交道。其次，Pod 曾经申请在机器上，就不必每次提交作业的时候，再申请新的 Pod，能够节俭大量工夫。

从上图能够看到：因为 K8s 组件导致的问题，间接缩小 95%。作业启动的工夫，从以前的 100 秒以上，缩小到当初的 50 秒，再加上热启动技术，一两秒就把作业启动起来。资源利用率进步了 5%。

3.3 流批一体技术

第三局部，为什么须要流批一体技术？

如果要开发 800 个指标的 BI 报表，前面发现了有 750 个要用离线开发，有 650 个要用 Flink 实时开发，两头还会有 500 个是反复的。反复的意思是离线也要做一套 SQL，实时也要做一套，但实际上它的业务逻辑是截然不同的。这样就会导致在数据开发的过程中，有很多反复工作。比方你用批引擎开发了一套，而后又用 Flink 实时引擎开发了一套，两边的 SQL 语法都不一样，核查起来就特地艰难。为了解决以后业务开发的痛点，就提出了蚂蚁的流批一体技术。

如上图所示，流批一体技术底层也在 K8s 上。再上一层咱们用的是 Flink runtime。

在往上一层是插件化 shuffle service、插件化调度、插件化状态。

• 插件化 shuffle service。shuffle service 在批计算十分重要，比方能够通过 shuffle service 解决在云化环境下本地盘很小的问题。
• 插件化调度。流和批的调度形式是不一样的，调度也能够插件化。
• 插件化状态。比方 RocksDB、内存、AntKV 型的状态类型。

最下面是平台的对立入口。用户在对立入口上能够抉择对立写一套 SQL，而后指定跑流还是批，这样就解决了写两套 SQL 的难题。

<p style=”text-align:center”>Flink 调试技术 </p>

开发的时候可能要写一个批的 SQL 和流的 SQL。如果数据常常有问题，写 JAVA 代码、C++ 代码都晓得，应用 IDE 或者 GDB 等工具，进行单步调试。咱们提出了对 SQL 代码单步调试技术。计划有两种：第一种计划，批改在 Flink 代码里的所有算子，包含批的算子、流的算子。而后在入口处减少 trace 代码，即在入口处把输出数据打进去，在输入的中央把输入数据打进去。但这个计划有一个问题，会侵入原生的 Flink 引擎代码，导致代码很不优雅。第二种计划，字节码加强。

那么字节码加强技术是怎么做的呢？大家可能晓得，平时从 IDE 里调试 JAVA 代码或别的代码时，实际上底层是通过 JAVA agent 技术进行调试的。JAVA agent 是一门技术，通过这个技术能够把类代理掉。也就是在执行类之前 mock 掉新的类，而后本人管制这个新的类的行为。所以 JAVA agent 是通过把跑的类代理掉，而后通过代理跑真正要跑的类。从上图右侧能够看出，底层 Flink 引擎的代码是不会改的。所以通过代理的形式，在类加载之前通过 JAVA agent 代理出改写的新类。

新类次要分为两局部，第一局部是 Stream Operator。在执行完 Stream Operator 后，会插入输出、输入的办法，这样就能够把算子的输出数据和输入数据打印进去，即通过 Byte Buddy 来实现类的改写。

这里有一个问题，Flink 代码中有很多 codegen 代码，运行的时候会主动生成一些动静代码，就是把一些函数调用合成一个函数来执行的。但通过 JAVA agent 的 Byte Buddy 改写类的时候，如果调用的是外部办法就会有问题。

从上图能够看出，通过 JAVA agent 技术对 codegen 进行类的重写。先把 codegen 代码下载一份到本地存储起来，再通过 Byte Buddy 把它改写，之后再插入输入输出代码，这样就能够看到算子的输入输出。就像调试 JAVA 代码一样，输出是什么、输入是什么、下节点的输出是什么、下节点的输入是什么，都能够具体的打印进去。

四、将来布局

第一，优化 Flink 批性能、反对全向量化计算。业界也有很多引擎在做全向量化计算，通过一些开源技术，比方 Databricks 公司的全向量化计算引擎，它的性能晋升了两倍以上。

第二，基于机器学习的自动化调优。因为流计算里的参数较多，用户用起来有些门槛，咱们将通过机器学习的办法来解决自动化调参数问题。

第三，倒退基于 Flink 的湖仓技术。流批对立后，存储、计算、平台都会对立，这样一个入口就能解决用户批、流、AI、学习等所有计算需要。

第四，云化环境下智能化诊断。云化环境比较复杂，呈现问题很难排查到具体问题。咱们提出了一个智能化诊断工具，它能够诊断到底层云化环境的状况，比方机器、IP、机器负载等一系列状况，帮忙用户疾速发现问题。

第五，流批混合部署下分时调度，晋升利用率。流批不仅是引擎的对立，对立之后还要进一步晋升资源的利用率，咱们将在晋升利用率的方向上持续致力。

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

更多内容

流动举荐

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