集度汽车 Flink on native k8s 的应用与实践

本文涉及的产品
实时计算 Flink 版,1000CU*H 3个月
简介: 在集度汽车实时计算的发展过程中,Flink 起到了至关重要的作用。Flink 的低延迟,高吞吐,支撑着整个公司的实时数据流。

摘要:本文整理自集度汽车数据部门实时方向负责人、 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 计算平台一期正式上线。

1

那么我们为什么选择 Flink on native k8s 的 Application Mode 呢?

2

从业务现状和技术现状来讲,我们公司有一个专业的 k8s 运维团队和 Flink 从 0-1 开始建设,没有迁移的成本。从 k8s 本身来讲,k8s 有弹性、故障迁移、资源隔离和易于管理运维等优点。

选择 Native 方式的原因在于,基于原生的 k8s,HA 不再依赖于外部组件 Zookeeper。选择 Application Mode 的原因在于,任务级别、资源隔离性更好,不存在资源抢占的情况。

那么选择了 Flink on native k8s 我们需要解决两个关键点。第一个是 Web UI 暴露方式,第二个是日志暴露方式。

3

第一个关键点 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 进行配置。

4

结合以上三种方式的优缺点,以及我们公司线上线下网络隔离的实际情况,我们最终选择 ClusterIP + Ingress 的方式来访问 Flink 任务 Web UI。

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

5

第二个关键点日志暴露方式有很多种,比如写本地文件、写 Kafka 以及其他外部存储等。

我们选择的是写本地日志文件,选择这种方式的原因主要是为了与第三方组件解耦,更加的灵活可靠。但是通过日志组件打印的日志文件是在 pod 内部,而 pod 外部无法访问。如果需要在 pod 外部获取,需要将其映射到 Node 的磁盘上。

6

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

7

二、FlinkSQL 实时入仓实践

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

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

这些数据都流经 Kafka,然后通过 Flink 进行计算后写入下游组件。下游组件主要有 Kafka、HDFS、Hive、Doris,ES 等。

8

接下来分享一下集度实时入仓的工作原理和架构。在这之前,首先带大家了解一下哪些场景适合使用 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 这三部分进行阐述。

9

第一个是 SQL 解析引擎。主要功能有三个,分别是解析并切分用户 SQL;将 SQL 转换为任务提交至 k8s 运行;Hive Catalog 管理。

就实时入仓场景来讲,对于 Hive 表,我们希望其元数据持久化,由 Hive Metastore 进行管理;而其他表元数据则不希望持久化,仅在 Flink Session 中使用即可。

10

第二个是 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 原则即可。

11

第三个是埋点入仓的 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 和其他存储中。

12

三、Flink 计算平台建设

在今年 4 月份我们在提交了第一个 Flink on native k8s 任务后,后续各个业务方向都想复用 Flink 实时计算的能力。比如以下三个场景:

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

13

在初始的开发阶段,我们面临多个开发痛点,比如每个用户都需要手工维护自己提交的 Flink 任务,包括资源版本、配置、历史提交等等。

举一个任务升级场景的例子,我们需要手工进行资源更新、编译打包、编辑提交命令。资源由于没有统一存储的地方很容易搞混,导致线上的版本不是最后升级的版本。

从开发角度来看,每个开发同学都需要了解 Data Stream API 和任务中每个配置的具体意义。对于不熟悉 Flink 的人来说,上手成本比较高。从任务维护角度来看,Flink 任务提交后缺少统一的日志与指标收集,开发人员只能在任务失败退出后,才能收到报警信息,且在失败后想拉取日志、定位问题,目前也没有统一的日志搜索和下载的入口。

从集群维护角度来看,我们还碰到了由于用户不了解某些 Flink 原理,导致集群资源占满,使其他任务一直处于资源申请状态。或是多个用户更改同一个配置文件后,提交的任务没有按照预期运行等等。比如经典的数据入仓场景,由于其他的用户更改了 checkpoint 的配置,导致数据一直落不了仓。

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

服务管理层面,提供了以下功能:

  • 多版本的资源管理:用户可以自由切换资源版本。
  • 作业生命周期管理:作业从创建到结束的所有状态变化都由平台来维护。
  • 作业可配置参数管理:官方参数和平台特有的定制化参数。
  • Flink 引擎多版本管理:根据用户的具体需求,提供多版本的选择,目前默认版本为 Flink 1.13。

14

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

资源管理层面,会管理每个任务提交所需的 CPU 和 memory 资源,防止每个任务无上限的申请资源,并对集群的资源进行监控。一旦有大规模资源 pending 的情况,快速介入运维解决。

下图展示了我们当前 Flink 计算平台的整体架构,主要分成三个部分。

15

  • 第一部分是我们的平台服务。目前我们的计算平台分布在 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+的实时任务,接入的业务方包括数仓团队、实时数据开发团队、车云链路团队。

16

下面展示的是我们 Flink 计算平台在任务提交后的任务状态流转图。一共列举了九个状态,接下来分别来讲一下每个状态的意义。started 是指任务成功提交后的初始状态。jm pod running 是指 jm pod 资源申请成功状态。任务在 started 状态下,如果申请到 jm 的 pod 资源,会在 pod 正常运行后流转到该状态。

pod running 是指任务所有集群资源都申请成功的状态,任务在 jm pod running 状态下,如果申请到所有 tm 的 pod 资源,会在 tm pod 正常运行后流转到该状态。running 是指 Flink 任务运行态,收到 Flink 任务 running 状态信息后流转到该状态。

17

not running 是指 Flink 任务非运行状态,比如 tm 或者 jm 重启,收到 Flink 任务非 running 状态的信息后,流转到该状态。

success 是指任务成功状态。stopping 是指任务停止中间状态。前置状态可以是多个状态,如果用户执行了停止操作,任务将流转到该中间状态。

stopped 是指停止状态,任务在 stopping 状态下,如果收到资源确认、删除信息以后会流转到该状态。Failed 是指任务失败状态,任务在多个状态下都可以流转到该状态。

四、未来规划

在未来的一年中,我们将使用 Flink 更好地支撑公司的需求,会继续在平台建设的迭代和湖仓一体的建设进行探索。

计算平台是实时业务的技术底层,也是 Flink 面向用户的唯一渠道,我们将从三个方向不断增强功能,提升用户体验和效率。

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

18

在湖仓一体方面,很多业务本质上还处于起始发展阶段,我们会从一个新的业务方向落地一个湖仓一体的解决方案,慢慢的去探索和优化。在计算侧我们主要会放在统一的数据模型、统一的 UDF、CDC 数据入湖,在存储侧我们将会探索一个统一的存储引擎。

19

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


更多内容

img


活动推荐

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

image.png

相关实践学习
基于Hologres+Flink搭建GitHub实时数据大屏
通过使用Flink、Hologres构建实时数仓,并通过Hologres对接BI分析工具(以DataV为例),实现海量数据实时分析.
实时计算 Flink 实战课程
如何使用实时计算 Flink 搞定数据处理难题?实时计算 Flink 极客训练营产品、技术专家齐上阵,从开源 Flink功能介绍到实时计算 Flink 优势详解,现场实操,5天即可上手! 欢迎开通实时计算 Flink 版: https://cn.aliyun.com/product/bigdata/sc Flink Forward Asia 介绍: Flink Forward 是由 Apache 官方授权,Apache Flink Community China 支持的会议,通过参会不仅可以了解到 Flink 社区的最新动态和发展计划,还可以了解到国内外一线大厂围绕 Flink 生态的生产实践经验,是 Flink 开发者和使用者不可错过的盛会。 去年经过品牌升级后的 Flink Forward Asia 吸引了超过2000人线下参与,一举成为国内最大的 Apache 顶级项目会议。结合2020年的特殊情况,Flink Forward Asia 2020 将在12月26日以线上峰会的形式与大家见面。
相关文章
|
6月前
|
存储 监控 数据挖掘
京东物流基于Flink & StarRocks的湖仓建设实践
本文整理自京东物流高级数据开发工程师梁宝彬在Flink Forward Asia 2024的分享,聚焦实时湖仓的探索与建设、应用实践、问题思考及未来展望。内容涵盖京东物流通过Flink和Paimon等技术构建实时湖仓体系的过程,解决复杂业务场景下的数据分析挑战,如多维OLAP分析、大屏监控等。同时,文章详细介绍了基于StarRocks的湖仓一体方案,优化存储成本并提升查询效率,以及存算分离的应用实践。最后,对未来数据服务的发展方向进行了展望,计划推广长周期数据存储服务和原生数据湖建设,进一步提升数据分析能力。
533 1
京东物流基于Flink & StarRocks的湖仓建设实践
|
4月前
|
资源调度 Kubernetes 流计算
Flink在B站的大规模云原生实践
本文基于哔哩哔哩资深开发工程师丁国涛在Flink Forward Asia 2024云原生专场的分享,围绕Flink On K8S的实践展开。内容涵盖五个部分:背景介绍、功能及稳定性优化、性能优化、运维优化和未来展望。文章详细分析了从YARN迁移到K8S的优势与挑战,包括资源池统一、环境一致性改进及隔离性提升,并针对镜像优化、Pod异常处理、启动速度优化等问题提出解决方案。此外,还探讨了多机房容灾、负载均衡及潮汐混部等未来发展方向,为Flink云原生化提供了全面的技术参考。
227 9
Flink在B站的大规模云原生实践
|
5月前
|
SQL 存储 NoSQL
Flink x Paimon 在抖音集团生活服务的落地实践
本文整理自抖音集团数据工程师陆魏与流式计算工程冯向宇在Flink Forward Asia 2024的分享,聚焦抖音生活服务业务中的实时数仓技术演变及Paimon湖仓实践。文章分为三部分:背景及现状、Paimon湖仓实践与技术优化。通过引入Paimon,解决了传统实时数仓开发效率低、资源浪费、稳定性差等问题,显著提升了开发运维效率、节省资源并增强了任务稳定性。同时,文中详细探讨了Paimon在维表实践、宽表建设、标签变更检测等场景的应用,并介绍了其核心技术优化与未来规划。
469 10
Flink x Paimon 在抖音集团生活服务的落地实践
|
5月前
|
资源调度 Kubernetes 调度
网易游戏 Flink 云原生实践
本文分享了网易游戏在Flink实时计算领域的资源管理与架构演进经验,从Yarn到K8s云原生,再到混合云的实践历程。文章详细解析了各阶段的技术挑战与解决方案,包括资源隔离、弹性伸缩、自动扩缩容及服务混部等关键能力的实现。通过混合云架构,网易游戏显著提升了资源利用率,降低了30%机器成本,小作业计算成本下降40%,并为未来性能优化、流批一体及智能运维奠定了基础。
253 9
网易游戏 Flink 云原生实践
|
6月前
|
存储 负载均衡 测试技术
ACK Gateway with Inference Extension:优化多机分布式大模型推理服务实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with Inference Extension组件,在Kubernetes环境中为多机分布式部署的LLM推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
7月前
|
存储 运维 监控
阿里妈妈基于 Flink+Paimon 的 Lakehouse 应用实践
本文总结了阿里妈妈数据技术专家陈亮在Flink Forward Asia 2024大会上的分享,围绕广告业务背景、架构设计及湖仓方案演进展开。内容涵盖广告生态运作、实时数仓挑战与优化,以及基于Paimon的湖仓方案优势。通过分层设计与技术优化,实现业务交付周期缩短30%以上,资源开销降低40%,并大幅提升系统稳定性和运营效率。文章还介绍了阿里云实时计算Flink版的免费试用活动,助力企业探索实时计算与湖仓一体化解决方案。
805 3
阿里妈妈基于 Flink+Paimon 的 Lakehouse 应用实践
|
7月前
|
存储 人工智能 Kubernetes
ACK Gateway with AI Extension:面向Kubernetes大模型推理的智能路由实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with AI Extension组件,在Kubernetes环境中为大语言模型(LLM)推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
7月前
|
存储 人工智能 物联网
ACK Gateway with AI Extension:大模型推理的模型灰度实践
本文介绍了如何使用 ACK Gateway with AI Extension 组件在云原生环境中实现大语言模型(LLM)推理服务的灰度发布和流量分发。该组件专为 LLM 推理场景设计,支持四层/七层流量路由,并提供基于模型服务器负载感知的智能负载均衡能力。通过自定义资源(CRD),如 InferencePool 和 InferenceModel,可以灵活配置推理服务的流量策略,包括模型灰度发布和流量镜像。
|
7月前
|
存储 运维 BI
万字长文带你深入广告场景Paimon+Flink全链路探索与实践
本文将结合实时、离线数据研发痛点和当下Paimon的特性,以实例呈现低门槛、低成本、分钟级延迟的流批一体化方案,点击文章阅读详细内容~
|
5月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
ACK One 的多集群应用分发,可以最小成本地结合您已有的单集群 CD 系统,无需对原先应用资源 YAML 进行修改,即可快速构建成多集群的 CD 系统,并同时获得强大的多集群资源调度和分发的能力。
175 9

相关产品

  • 实时计算 Flink版
  • 推荐镜像

    更多