关于flink:Apache-Flink-在斗鱼的应用与实践

摘要：本文整顿自斗鱼实时计算负责人夏畅在 Flink Forward Asia 2021 行业实际专场的分享。本篇内容次要分为四个局部：

1. 背景介绍
2. 实时平台建设
3. 实时数仓摸索
4. 将来倒退与瞻望

点击查看直播回放 & 演讲 PDF

一、背景介绍

斗鱼成立于 2014 年，是一家致力于为所有人带来欢畅的，弹幕式直播分享平台。在斗鱼，实时计算倒退得并不算早。

2018 年前后，为了满足一些近实时数据需要，如 5 分钟、1 小时等场景，先后引入了 Spark streaming 和 Storm 技术。随着业务的继续倒退，实时指标的需要更加多样性，Spark streaming 和 Strom 也越加难以反对。

大略在 2019 年，斗鱼引入了 Flink 技术，起初以 Flink jar 的开发方式，来反对这类实时数据需要。但 Flink jar 的形式应用起来门槛和老本还是太高了。

在 19 年底 20 年初，设计开发落地了基于 K8s 的 Flink 实时计算平台，同时反对以 SQL 和 JAR 两种形式的作业开发，在外部这个平台称为“玄武计算平台”。

玄武计算平台上线后，撑持了不少业务场景，如广告、大屏，举荐、系统监控、风控，数据分析和实时标签等。

截止到 2021 年 3 季度，斗鱼实时计算平台的用户数达到 100+，Vcore 达到 2000+，作业数达到 500+，日解决数据量超过千亿条。

二、实时平台建设

在建设玄武实时计算平台之前，咱们次要以 Flink jar 的形式开发，有以下几个痛点：

• 开发门槛高；
• 部署老本高；
• 没有监控告警；
• 没有作业版本治理。

基于以上四点，咱们设计开发了本人的实时计算平台。

玄武实时计算平台构建在 K8s 集群之上，反对多个 Flink 版本，一站式实时数据开发平台。架构上从上到下，能够分为四层：平台层、服务层、调度层、以及 K8s 集群层。

• 平台层：提供包含元数据管理、作业管理、作业运维、案例示范、监控大盘、调度治理、告警治理等用户交互性能。

• 服务层：分为 Flink 作业服务和 Flink 网关服务，提供 SQL 校验、SQL 调试、作业运行、作业进行、日志查问等能力。

• 调度层：借助 K8s 的容器镜像，实现 Flink 多个版本的共存。每个 Flink 版本都对应一个 K8s 的镜像，从而实现作业版本的随时切换。当然，为了实现一个 SQL 在多个 Flink 版本下通用，咱们还做了一层 SQL 的映射，次要为了解决 Flink 版本间 connector 的配置差别。此外，咱们还在调度层内提供了残缺的作业状态跟踪机制。

• K8s 集群层：次要是提供根底的运行环境。

上图是实时计算平台进行作业开发的实例图。能够看到整个平台提供如下能力：SQL 化作业开发、在线调试、语法校验、作业多版本、元数据管理、配置脱敏、集群治理、参数调优等。

搭建平台的过程中，咱们也遇到了不少的挑战。

第一个挑战是 Flink on K8s 集群的部署资源问题。计划上，咱们是应用 Standalone Kubernetes 部署，理论是在 K8s 的集群中，创立了两个实例组。一个实例组用来运行 JM 过程，另一个实例组用来运行 TM 过程。两个实例组之间，通过设置 HA 的集群 id 雷同来实现绑定。

• JM 实例组运行多个 pod 时，除其中一个作为 master 节点外，其余的 pod 都将以 StandBy 的身份运行；
• TM 实例组运行多个 pod 时，每一个 pod 都将注册到 JM 上，作为一个作业执行器存在。

为了使资源充沛隔离，依靠于 K8s 的能力，生产部署时，咱们是一个作业创立一个 Flink 集群。咱们晓得 K8s 创立一个 pod 时，须要指定 CPU 和内存的设置。而 Flink 集群启动的时候，须要在 Flink-conf 文件指定 JM 和 TM 的资源配置。

在这个计划中，咱们遇到的挑战就是如何对立设置 K8s 实例资源与 Flink 集群资源。

为了解决这个问题，咱们革新了 Flink 镜像启动脚本 entrypoint，在脚本中减少了两个操作：

• 一个是拉取作业定义，以获取作业的运行配置；
• 第二个是替换 flink-conf 文件 memory size 配置。

当然，在最新的 native kubenates 计划中，这个问题官网通过参数化配置解决了。

平台遇到的第二个挑战，就是如何去监控每个作业的运行状态。计划上，咱们将每个作业形象成一条音讯，寄存在基于 ZK 开发的音讯队列中。并且在音讯队列虚化了 5 个状态，Accept、Running、Failed、Cancel 以及 Finish。

每个状态都有一个独立的线程池去监控生产。比方 Running 状态，线程池从音讯队列中获取一条作业音讯，从中解析 Flink 集群信息，获取 FlinkUI 域名，通过 K8s 的 Nginx Ingress，应用域名去拜访 Flink JM Pod，从而获取运行作业的状态。当获取作业状态还是 Running 时，将重入队到队尾，否则将挪动到对应状态队列下。

实时计算平台上线初期，咱们又遇到了新的挑战。在 Flink 的集群中，如何读取 Hive 表，以及如何应用 Hive-Udf 函数。

咱们将一个 FlinkSQL 的提交拆分成三个局部：作业组装、上下文初始化和 SQL 执行。

作业组装，咱们实现了 2 个形式：

• 第一个是 SDK GET，通过 SDK 封装的办法，申请平台的服务层，去获取作业定义；
• 第二个是 FILE GET，间接读取以后机器，指定门路下的 SQL 文件，生成作业定义。第二个形式次要是不便本地不依赖平台服务，可疾速调试引擎。

上下文初始化局部，分为两个过程：

• 一个是调优参数的设置，相似罕用 HiveSQL 的 Set 命令；
• 另外一个就是 Catalog 初始化，而 Flink 集群与 Hive 的集成，就是在整个环节实现的。

以 Hive 为例，在 Catalog 注入之前，平台元数据管理模块有一个 Catalog 初始化的过程，事后将 Catalog 的创立语句存储起来。当一个 Flink 作业提交时，抉择须要注入的 Catalog。创立 Catalog，并注册到 Flink 的上下文中，从而实现 Catalog 的元素注入。

随着工作的减少，对于老手来说，在平台上开发 Flink 作业，从 SQL 编写到上线，往往须要改写数十个版本。平台短少疾速试错的能力。所以咱们设计开发了实时监控、实时调试性能。

在架构方面，斗鱼引入了 Flink Gateway Server 对 Flink 集群接口二次分装。蕴含语法校验、SQL 提交、SQL 状态查看、SQL 进行、SQL mock 等性能。将 Flink 集群和网关服务的日志对立收集。通过预启动 Flink 集群，缩短作业启动工夫，达到疾速调试的能力。

实时调试次要分为四个步骤，即 SQL 解析、规定校验、执行打算，和物理执行。

SQL mock 就是改写了原有的 SQL 解析过程。依据 SQL 解析后失去 Node 数，剖析 SQL 的血缘关系，去判断 Source 起源表和 Sink 目标表。动静的将 Source 表改写为 dataGen 的数据源，和 Sink 表改写成 console 的数据源。

动静批改 Source 和 Sink 表的配置，实现数据源的 mock。这个带来的益处是：线上开发 SQL 可间接用于调试，不须要批改，并且也不必放心会产生脏数据，可疾速验证 SQL 逻辑是否合乎预期。

Flink 作业的监控告警，应用自定义 Metrics Reporter，将 metrics 指标上报到 Kafka 集群，继而应用 Flink 工作去生产 Kafka 里的 metrics 信息，实现如聚合、补充链路维度等操作，解决后的数据再推送到 Push Gateway，写入 Prometheus 中。最初监控大盘基于 Grafana 绘制。

斗鱼的监控大盘分为资源监控，稳定性监控，Kafka 监控和 CPU 内存监控。

三、实时数仓摸索

第一版实时数仓计划，借鉴离线数仓的分层与开发思路，以 Kafka 作为中间层的数据存储。DB 和 LOG 数据别离通过 Canal 和打点服务写入 Kafka，作为实时数据的 ODS 层。

1. 生产 ODS 层，应用 Flink 做维度补充和荡涤等操作后，写回 Kafka，生成 DWD 层数据；
2. 生产 DWD 层，以分钟、小时的窗口，和指定维度产生聚合数据，写回 Kafka，生成 DWS 层的数据；
3. 最初生产 DWS 层的数据，写入到 HBase、MySQL、ES、Redis、ClickHouse 等数据源中，供数据服务应用。

随着业务场景越来越多，这个计划显现出了四个问题：

• Kafka 数据保留工夫无限；
• 离线、实时数据存储层不对立；
• 中间层较难间接查问剖析；
• 数据回溯场景不敌对。

基于上诉问题，咱们尝试了第二套计划，应用 Iceberg 作为中间层存储。利用后面提到的 Catalog 注入，咱们注入了 Iceberg 的元数据，将 DWD、DWS 层应用 Iceberg 来存储。

这个计划解决了应用 Kafka 作为中间层的局部问题，然而又引入了新的问题。Flink 写入 Iceberg 表时，数据的可见性依赖 Checkpoint 的 Commit 操作。因而 Iceberg 数据的提早取决于 Checkpoint 的周期。而 Checkpoint 是阻塞式操作，往往不倡议设置过于小。也就是说 Iceberg 作为中间层会比 Kafka 提早高。对于时延要求高的场景就不太适宜。

最终咱们通过自定义元数据服务，保护库表的 Catalog 信息，以及动静注入 Catalog 能力，实现双计划并行。当然，咱们也在持续摸索更加便捷的计划去开发实时数仓。

四、将来倒退与瞻望

Flink 让实时计算更加简略，斗鱼在搭建实时计算平台过程中也并非一帆风顺。对于实时计算平台将来的倒退，咱们有三个瞻望：

• 第一个是 Flink 的动静扩缩容，实现平台自动化，调整 Flink 作业资源，解决业务数据突增引起的问题；
• 第二个是简化实时数仓开发模型，升高实时数仓开发门槛，在企业内，将实时数仓真正大规模推广应用；
• 最初一个是欠缺实时数据品质监控体系，实现实时数据品质可验证与可追溯。

点击查看直播回放 & 演讲 PDF

更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～