关于后端:集度汽车-Flink-on-native-k8s-的应用与实践

摘要：本文整顿自集度汽车数据部门实时方向负责人、Apache Flink Contributor 周磊 & 集度汽车数据开发专家顾云，在 FFA 2022 行业案例专场的分享。本篇内容次要分为四个局部：

1. 集度实时计算倒退
2. FlinkSQL 实时入仓实际
3. Flink 计算平台建设
4. 将来布局

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

一、集度实时计算倒退

2021 年 3 月集度汽车成立。2021 年 11 月 Flink on native k8s 开始搭建。2022 年 4 月，集度汽车第一个实时计算工作上线，是一个小程序埋点实时入仓的 Flink SQL 工作。2022 年 9 月，Flink 计算平台一期正式上线。

那么咱们为什么抉择 Flink on native k8s 的 Application Mode 呢？

从业务现状和技术现状来讲，咱们公司有一个业余的 k8s 运维团队和 Flink 从 0-1 开始建设，没有迁徙的老本。从 k8s 自身来讲，k8s 有弹性、故障迁徙、资源隔离和易于治理运维等长处。

抉择 Native 形式的起因在于，基于原生的 k8s，HA 不再依赖于内部组件 Zookeeper。抉择 Application Mode 的起因在于，工作级别、资源隔离性更好，不存在资源抢占的状况。

那么抉择了 Flink on native k8s 咱们须要解决两个关键点。第一个是 Web UI 裸露形式，第二个是日志裸露形式。

第一个关键点 Web UI 的裸露形式有三种，别离是 NodePort、ClusterIP、LoadBalancer。

• NodePort：裸露一个 Node 的随机端口，提供给内部流量拜访 k8s 集群资源。

  • 长处：启动快，同网络环境能够间接拜访。
  • 毛病：网络隔离状况下本地无法访问线上工作的 Web UI；Node 端口数有限度，不能有限扩大。

• ClusterIP：裸露 Pod IP + Pod Port。

  • 长处：启动快，不额定裸露 Node 端口，更省资源。
  • 毛病：仅在 k8s 集群外部或同网络环境中能够拜访，网络隔离状况下本地无法访问线上工作的 Web UI。

• LoadBalancer：

  • 长处：配置简略，通过 LB 间接拜访线上 Flink 工作的 Web UI。
  • 毛病：工作启动比较慢，因为须要筹备相干的 LB 环境；资源耗费大，每个工作都会启动一个 LB；外网拜访带来平安问题。

当然个别的云厂商能够反对不启动外网 LB 通过 kubernetes.rest-service.annotations 进行配置。

联合以上三种形式的优缺点，以及咱们公司线上线下网络隔离的理论状况，咱们最终抉择 ClusterIP + Ingress 的形式来拜访 Flink 工作 Web UI。

下图是 Ingress 的配置样例。每一个 Flink 工作都配置一个对应的 Ingress 资源，用户通过 host 配置域名进行拜访，解析到对应的 Ingress Controller，而后通过 Ingress 配置找到对应 Flink 工作的 rest service 的 8081 端口。这样就实现了通过域名拜访线上工作的 Web UI。

第二个关键点日志裸露形式有很多种，比方写本地文件、写 Kafka 以及其余内部存储等。

咱们抉择的是写本地日志文件，抉择这种形式的起因次要是为了与第三方组件解耦，更加的灵便牢靠。然而通过日志组件打印的日志文件是在 pod 外部，而 pod 内部无法访问。如果须要在 pod 内部获取，须要将其映射到 Node 的磁盘上。

下图是日志映射的配置文件样例。pod 外部的日志目录为 /opt/flink/log 将其映射到 Node 磁盘 /data/logs/flinklog 下对应的 Flink 工作名的目录。这样就实现了在同一个目录下，只存在该 Flink 工作的日志文件，更容易进行日志治理。

二、FlinkSQL 实时入仓实际

如图是集度实时数据流架构，数据源分为日志类、DB 类、埋点类、数据类。

其中日志类次要包含 server 端日志、IT 系统日志、平安系统日志、各组件审计日志等。埋点类次要包含云端埋点、APP 小程序、官网、车端埋点。DB 数据指的是后端服务的 binlog 数据。数据类次要包含整车 CAN 信号数据、传感器数据等。

这些数据都流经 Kafka，而后通过 Flink 进行计算后写入上游组件。上游组件次要有 Kafka、HDFS、Hive、Doris，ES 等。

接下来分享一下集度实时入仓的工作原理和架构。在这之前，首先带大家理解一下哪些场景适宜应用 Flink SQL 进行实时入仓。

目前集度应用了 Flink SQL 实时入仓的场景次要有日志类数据实时入仓、埋点类数据实时入仓，包含前端埋点和服务端埋点。这一类型的工作没有太过简单的计算逻辑和额定须要治理的状态，须要疾速迭代，比拟适宜通过 Flink SQL 进行实现。

对于这类场景来讲，常常会有新增埋点字段的需要。应用 SQL 形式将齐全躲避掉批改代码、从新测试、从新打包的繁琐操作，间接在用户 Flink SQL 局部减少相应的字段即可。

实时入仓次要有三个模块，别离是用户 Flink SQL、Flink SQL 解析引擎、Flink Table Format。用户编写的 Flink SQL 交给 Flink SQL 解析引擎，引擎解析用户 SQL 转换为一个 Flink 工作，而后提交到 k8s 集群。数据的解析逻辑是依据 SQL 中配置的 Format Type，通过 SPI 机制加载对应的 Table Format 工厂类来进行解析的。后续会别离对 Flink SQL 解析引擎、Table Format、用户 SQL 这三局部进行论述。

第一个是 SQL 解析引擎。次要性能有三个，别离是解析并切分用户 SQL；将 SQL 转换为工作提交至 k8s 运行；Hive Catalog 治理。

就实时入仓场景来讲，对于 Hive 表，咱们心愿其元数据长久化，由 Hive Metastore 进行治理；而其余表元数据则不心愿长久化，仅在 Flink Session 中应用即可。

第二个是 Table Format。在 Flink 1.10 版本及以前，应用 Table Factory 这个工厂类，目前在 1.15 曾经是 Deprecated 状态。1.11 版本当前举荐应用 Factory 这个工厂类，目前咱们应用的 Flink 版本是 1.13。就以 1.13 为例，来形容一下 Factory 相干的类构造。

Factory 工厂类存在于 flink-table-common 包下，是 Table Source、Sink、Format 的基类。对于 Table Format，咱们次要关注五个接口，别离是 Factory，DecodingFormatFactory，EncodingFormatFactory，DeserializationFormatFactory 和 SerializationFormatFactory。如果咱们须要对某类数据进行自定义解析，能够实现 DeserializationFormatFactory 听从 Jave SPI 准则即可。

第三个是埋点入仓的 Flink SQL 样例。能够分为三个局部，Source、Sink 以及 Insert 操作。

• 第一局部是创立了一个 Hive 的 Sink 表，能够看到通过 Flink Hive 的 Catalog 进行治理，该 Hive 表是一个小时级分区表。分区 Commit 的策略是创立 Succes 文件的同时 Commit 相应的 Hive 分区。

• 第二局部是 Kafka Source 表，数据解析逻辑，由 Format 的配置项进行配置，其中 Watermark 是通过数据中的 evernt time 进行指定。

• 第三局部是 Insert 语句，将 Kafka 埋点中对应的字段值写到对应的 Hive 表中，以这样的形式实现了将数据以某种 Format 指定的逻辑进行解析，而后通过实时流的形式写到 Hive 和其余存储中。

三、Flink 计算平台建设

在往年 4 月份咱们在提交了第一个 Flink on native k8s 工作后，后续各个业务方向都想复用 Flink 实时计算的能力。比方以下三个场景：

第一个是根底的实时数据传输场景，业务方心愿将业务库的数据便捷的散发到多种存储引擎中应答不同的需要。第二个是数据分析和大屏的场景，散发用户在 APP 上的各种埋点数据来供后续的计算。第三个是车端的监控和开掘场景，接入车端的埋点数据和信号数据后，构建计算和存储链路。

在初始的开发阶段，咱们面临多个开发痛点，比方每个用户都须要手工保护本人提交的 Flink 工作，包含资源版本、配置、历史提交等等。

举一个工作降级场景的例子，咱们须要手工进行资源更新、编译打包、编辑提交命令。资源因为没有对立存储的中央很容易搞混，导致线上的版本不是最初降级的版本。

从开发角度来看，每个开发同学都须要理解 Data Stream API 和工作中每个配置的具体意义。对于不相熟 Flink 的人来说，上手老本比拟高。从工作保护角度来看，Flink 工作提交后短少对立的日志与指标收集，开发人员只能在工作失败退出后，能力收到报警信息，且在失败后想拉取日志、定位问题，目前也没有对立的日志搜寻和下载的入口。

从集群保护角度来看，咱们还碰到了因为用户不理解某些 Flink 原理，导致集群资源占满，使其余工作始终处于资源申请状态。或是多个用户更改同一个配置文件后，提交的工作没有依照预期运行等等。比方经典的数据入仓场景，因为其余的用户更改了 checkpoint 的配置，导致数据始终落不了仓。

基于以上的问题，咱们在 5 月份正式立项，开始建设集度外部 Flink 计算平台。目前集度的 Flink 计算平台曾经上线三大功能模块，别离是服务治理、运维治理、资源管理。

服务治理层面，提供了以下性能：

• 多版本的资源管理：用户能够自在切换资源版本。
• 作业生命周期治理：作业从创立到完结的所有状态变动都由平台来保护。
• 作业可配置参数治理：官网参数和平台特有的定制化参数。
• Flink 引擎多版本治理：依据用户的具体需要，提供多版本的抉择，目前默认版本为 Flink 1.13。

运维治理层面，提供了丰盛的工作指标看板，并基于这些指标定制化监控报警的性能，解决了上述所说的 Flink 工作黑盒问题。同时，为了便于用户追溯与定位问题，建设了工作提交批次的概念，收集工作分批次日志。

资源管理层面，会治理每个工作提交所需的 CPU 和 memory 资源，避免每个工作无下限的申请资源，并对集群的资源进行监控。一旦有大规模资源 pending 的状况，疾速染指运维解决。

下图展现了咱们以后 Flink 计算平台的整体架构，次要分成三个局部。

• 第一局部是咱们的平台服务。目前咱们的计算平台散布在 k8s 的服务集群上，对立走公司的服务注册，复用已有的能力，比方服务公布，域名治理，监控报警等等。
• 第二局部是咱们所有 Flink 工作运行的 k8s 集群。这个集群目前由咱们和运维团队一起保护，外面的 k8s 资源由 Flink 计算平台保护，子网地址等其余内部云服务资源由根底运维团队保护。
• 第三局部是咱们依赖的一些根底组件。比方利用公司的继续集成 CICD 来构建 docker 镜像；日志采集工具用来收集每个 K8s Node 上的日志；搜索引擎 ES 用来搜寻近期的 Flink 日志；HDFS 用来存储历史所有的 Flink 日志。

以一个 Flink Jar 包工作为例，来看一下整体 Flink 计算平台的解决流程。首先是工作提交时抉择的资源版本，因为用的是 Flink on native k8s 资源对立打包成 docker 镜像。咱们提供了两种打包形式，被动上传和主动触发。

被动上传是指，用户在上传实现后能够抉择本人上传的版本，来生成对应版本的镜像，咱们的镜像治理服务能够将工作资源生成的各版本镜像，上传到公司自建的 docker 仓库中。

主动触发的话，咱们会买通公司的 CICD 为每个 Flink Git 我的项目的变更提交产生一个新的镜像。镜像生成的时候会依据用户的配置来加载对应的 Flink 引擎版本，以及会从 HDFS 上拉取对应的依赖资源 Jar 包。

在镜像生成后的工作提交阶段，咱们会针对每个作业定制化日志映射配置和环境变量，来买通前面的批次日志采集流程。这些配置都会利用在每个工作的 k8s 资源上。

工作提交后，咱们会利用 k8s 的 watch and informer 机制监听每个工作所有资源信息的变动事件，以及获取到最新的 Flink 工作信息后，来推动每个工作的状态流转。

在工作运行阶段，咱们提供了三个工作运行状态查看的形式。

• 第一，用户能够通过域名拜访 Flink Web UI。其原理次要是通过创立的 Ingress 资源来二次反向代理到工作的 rest service。
• 第二，用户能够通过 grafana 来查看每个工作的可视化指标，Prometheus 会收集每个工作的运行指标。
• 第三，用户能够查看以后运行的日志和历史批次日志。历史批次日志是日志映射到 K8s Node 后，通过 Flume 收集到 Kafka，对立格局解析后流入 ES 和 HDFS，由对立的搜寻接口供用户应用。

而实时运行日志是通过 k8s 的 log watch 形式来增量获取实时运行日志的。

下图是咱们 Flink 计算平台的页面展现，能够看到平台上每个作业的元数据信息和以后作业的状态信息等等。目前平台治理了 100+ 的实时工作，接入的业务方包含数仓团队、实时数据开发团队、车云链路团队。

上面展现的是咱们 Flink 计算平台在工作提交后的工作状态流转图。一共列举了九个状态，接下来别离来讲一下每个状态的意义。started 是指工作胜利提交后的初始状态。jm pod running 是指 jm pod 资源申请胜利状态。工作在 started 状态下，如果申请到 jm 的 pod 资源，会在 pod 失常运行后流转到该状态。

pod running 是指工作所有集群资源都申请胜利的状态，工作在 jm pod running 状态下，如果申请到所有 tm 的 pod 资源，会在 tm pod 失常运行后流转到该状态。running 是指 Flink 工作运行态，收到 Flink 工作 running 状态信息后流转到该状态。

not running 是指 Flink 工作非运行状态，比方 tm 或者 jm 重启，收到 Flink 工作非 running 状态的信息后，流转到该状态。

success 是指工作胜利状态。stopping 是指工作进行中间状态。前置状态能够是多个状态，如果用户执行了进行操作，工作将流转到该中间状态。

stopped 是指进行状态，工作在 stopping 状态下，如果收到资源确认、删除信息当前会流转到该状态。Failed 是指工作失败状态，工作在多个状态下都能够流转到该状态。

四、将来布局

在将来的一年中，咱们将应用 Flink 更好地撑持公司的需要，会持续在平台建设的迭代和湖仓一体的建设进行摸索。

计算平台是实时业务的技术底层，也是 Flink 面向用户的惟一渠道，咱们将从三个方向一直加强性能，晋升用户体验和效率。

• 投入更多精力在 Flink SQL 的平台化上，进一步升高用户应用门槛。比方 SQL 语法校验、SQL 调试、对立治理元数据等等。
• 尝试实现资源的动静扩缩容。实现平台自动化调整 Flink 作业资源，解决某些场景下业务数据增长带来的问题。
• 稳定性建设和性能建设。比方作业在流量顶峰如何保持稳定的性能；生产上会继续产生文件的状况下，作业输入的文件如何进行调优等。

在湖仓一体方面，很多业务实质上还处于起始倒退阶段，咱们会从一个新的业务方向落地一个湖仓一体的解决方案，缓缓的去摸索和优化。在计算侧咱们次要会放在对立的数据模型、对立的 UDF、CDC 数据入湖，在存储侧咱们将会摸索一个对立的存储引擎。

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

更多内容

流动举荐

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