Apache Flink 在汽车之家的应用与实践

本文整理自汽车之家实时计算平台负责人邸星星在 Flink Forward Asia 2020 分享的议题《Apache Flink 在汽车之家的应用及实践》。主要内容包括：
1.背景及现状
2.AutoStream 平台
3.基于 Flink 的实时生态建设
4.后续规划

一、背景及现状

1. 第一阶段

在 2019 年之前，汽车之家的大部分实时业务都是运行在 Storm 之上的。Storm 作为早期主流的实时计算引擎，凭借简单的 Spout 和 Bolt 编程模型以及集群本身的稳定性，俘获了大批用户，我们在 2016 年搭建了 Storm 平台。

随着实时计算的需求日渐增多，数据规模逐步增大，Storm 在开发及维护成本上都凸显了不足，这里列举几个痛点:

1. 开发成本高
2. 我们一直是用的 Lambda 架构，会用 T+1 的离线数据修正实时数据，即最终以离线数据为准，所以计算口径实时要和离线完全保持一致，实时数据开发的需求文档就是离线的 SQL，实时开发人员的核心工作就是把离线的 SQL 翻译成 Storm 代码，期间虽然封装了一些通用的 Bolt 来简化开发，但把离线动辄几百行的 SQL 精准地翻译成代码还是很有挑战的，并且每次运行都要经过打包、上传、重启的一系列的繁琐操作，调试成本很高。
3. 计算低效
4. Storm 对状态支持的不好，通常需要借助 Redis、HBase 这类 kv 存储维护中间状态，我们之前是强依赖 Redis。比如常见的计算 UV 的场景，最简单的办法是使用 Redis 的 sadd 命令判断 uid 是否为已经存在，但这种方法会带来很高的网络 IO，同时如果没有提前报备的大促或搞活动导致流量翻倍的情况，很容易把 Redis 内存搞满，运维同学也会被杀个措手不及。同时 Redis 的吞吐能力也限制了整个作业的吞吐量。
5. 难以维护、管理
6. 由于采用编写 Storm 代码方式开发，难以分析元数据及血缘关系，同时可读性差，计算口径不透明，业务交接成本很高。
7. 对数仓不友好
8. 数据仓库团队是直接对接业务需求的团队，他们更熟悉基于 Hive 的 SQL 开发模式，通常都不擅长 Storm 作业的开发，这导致一些原本是实时的需求，只能退而求其次选择 T+1 的方式给出数据。

在这个阶段，我们支持了最基本的实时计算需求，因为开发门槛比较高，很多实时业务都是由我们平台开发来完成，既做平台，又做数据开发，精力分散很严重。

2. 第二阶段

我们从 2018 年开始调研 Flink 引擎，其相对完备的 SQL 支持，天生对状态的支持吸引了我们，在经过学习调研后，2019 年初开始设计开发 Flink SQL 平台，并于 2019 年中上线了 AutoStream 1.0 平台。平台上线之初就在仓库团队、监控团队和运维团队得以应用，能够快速被用户主要得益于以下几点:

1. 开发、维护成本低：汽车之家大部分的实时任务可以用 Flink SQL + UDF 实现。平台提供常用的 Source 和 Sink，以及业务开发常用的 UDF，同时用户可以自己编写 UDF。基于 "SQL + 配置" 的方式完成开发，可以满足大部分需求。对于自定义任务，我们提供方便开发使用的 SDK，助力用户快速开发自定义 Flink 任务。平台面向的用户已经不只是专业的数据开发人员了，普通开发、 测试、运维人员经过基本的学习都可以在平台上完成日常的实时数据开发工作，实现平台赋能化。数据资产可管理，SQL 语句本身是结构化的，我们通过解析一个作业的 SQL，结合 source、 sink 的 DDL，可以很容易的知道这个作业的上下游，天然保留血缘关系。
2. 高性能：Flink 可以完全基于状态 (内存，磁盘) 做计算，对比之前依赖外部存储做计算的场景，性能提升巨。在 818 活动压测期间，改造后的程序可以轻松支持原来几十倍流量的实时计算，且横向扩展性能十分良好。
3. 全面的监控报警：用户将任务托管在平台上，任务的存续由平台负责，用户专注于任务本身的逻辑开发本身即可。对于 SQL 任务，SQL 的可读性极高，便于维护；对于自定义任务，基于我们 SDK 开发，用户可以更专注于梳理业务逻辑上。不论是 SQL 任务还是 SDK，我们都内嵌了大量监控，并与报警平台关联，方便用户快速发现分析定位并修复任务，提高稳定性。
4. 赋能业务：支持数仓分层模型，平台提供了良好的 SQL 支持，数仓人员可以借助 SQL，将离线数仓的建设经验应用于实时数仓的建设上，自平台上线后，数仓逐步开始对接实时计算需求。

痛点：

1. 易用性有待提高，比如用户无法自助管理 UDF，只能使用平台内置的 UDF 或者把打好的 jar 包发给平台管理员，通过人工的方式处理上传问题。
2. 随着平台作业量的高速增长，平台 on-call 成本非常高。首先我们经常面对一些新用户的基础问题：平台的使用问题；开发过程中遇到的问题，比如为什么打包报错；Flink UI 的使用问题；监控图形的含义，如何配置报警。还有一些不太容易快速给出答案的问题：Jar 包冲突；为什么消费 Kafka 延迟；任务为什么报错。尤其是延迟问题，我们常见的数据倾斜，GC，反压问题可以直接引导用户去 Flink UI 和监控图表上去查看，但有时候还是需要手动去服务器上查看 jmap、jstack 等信息，有时候还需要生成火焰图来帮助用户定位性能问题。初期我们没有和运营团队合作，完全是我们开发人员直接对接处理这些问题，虽然期间补充了大量的文档，但是整体上 on-call 成本还是很高。
3. 在 Kafka 或 Yarn 出现故障时，没有快速恢复的方案，当面对一些重保业务时，有些捉襟见肘。众所周知，没有永远稳定，不出故障的环境或组件，当有重大故障出现时，需要有快速恢复业务的应对方案。
4. 资源没有合理管控，存在比较严重的资源浪费的情况。随着使用平台开发任务的用户不断增加，平台的作业数也不断增加。有些用户不能很好的把控集群资源的使用，经常出现过多申请资源的问题，导致作业运行效率低下甚至空闲，造成了资源的浪费。

在 AutoStream1.0 平台这个阶段，基于 SQL 开发的方式极大地降低了实时开发的门槛，各业务方可以自己实现实时业务的开发，同时数仓同学经过简单的学习后，就开始对接实时业务，将我们平台方从大量的业务需求中释放出来，让我们可以专心做平台方面的工作。

3. 当前阶段

针对上面的几个方面，我们有针对性行的做了以下几点升级：

1. 引入 Jar Service：支持用户自助上传 UDF jar 包，并在 SQL 片段中自助引用，实现自助管理 UDF。同时自定义作业也可以配置 Jar Service 中的 Jar，面对多个作业共用同一个 Jar 的场景，用户只需要在作业中配置 Jar Service 中的 jar 包路径就可以，避免每次上线都重复上传 Jar 的繁琐操作；
2. 自助诊断：我们开发了动态调整日志级别、自助查看火焰图等功能，方便用户自己定位问题，减轻我们日常 on-call 成本；
3. 作业健康检查功能：从多个维度分析，为每个 Flink 作业打分，每个低分项都相应的给出建议；
4. Flink 作业级别的快速容灾恢复：我们建设了两套 YARN 环境，每一个 YARN 对应一个单独的 HDFS，两个 HDFS 之前通过 SNAPSHOT 方式进行 Checkpoint 数据的双向复制，同时在平台上增加了切换集群的功能，在一个 YARN 集群不可用的情况下，用户可以自助在平台上，选择备用集群的 Checkpoint；
5. Kafka 多集群架构支持：使用我们自研的 Kafka SDK，支持快速切换 Kafka 集群；
6. 对接预算系统：每个作业占用的资源都直接对应到预算团队，这样一定程度上保证资源不会被其他团