ApacheFlink在蔚来汽车的应用
摘要：本文整理自蔚来汽车大数据专家，架构师吴江在 Flink Forward Asia 2021 行业实践专场的演讲。主要内容包括：
1.实时计算在蔚来的发展历程
2.实时计算平台
3.实时看板
4.CDP
5.实时数仓
6.其他应用场景
Tips：点击「阅读原文」查看原文视频 & 演讲PDF～
一、  实时计算在蔚来的发展历程
∙18 年 5 月份左右，我们开始接触实时计算的概念，最初是用 Spark Streaming 做一些简单的流式计算数据的处理；
∙
∙19 年 9 月份我们引入了 Flink，通过命令行的方式进行提交，包括管理整个作业的生命周期；
∙
∙到了 21 年 1 月份，我们上线了实时计算平台 1.0，目前正在进行 2.0 版本的开发。
二、实时计算平台
在实时计算平台 1.0，我们是通过将代码进行编译，然后上传 jar 包到一个服务器上，以命令行的方式进行提交。这个过程中存在很多问题：
∙首先，所有流程都是手动的，非常繁琐而且容易出错；
∙
∙其次，缺乏监控，Flink 本身内置了很多监控，但是没有一个自动的方式将它们加上去，还是需要手动地去做配置；
蔚来汽车∙
∙此外，任务的维护也非常麻烦，一些不太熟悉的开发人员进行操作很容易出现问题，而且出现问题之后也难以排查。
实时计算平台 1.0 的生命周期如上图。任务写完之后打成 jar 包进行上传提交，后续的开启任务、停止、恢复和监控都能够自动进行。
作业管理主要负责作业的创建、运行、停止、恢复和更新。日志主要记录 Flink 任务提交时的一些日志，如果是运行时的日志还是要通过 Yarn 集里的 log 来查看，稍微有点麻烦。关于监控和告警模块，首先 metrics 监控主要是利用 Flink 内置的指标上传到 Prometheus，然后配置各种监控的界面，告警也是利用 Prometheus 的一些指标进行规则的设置，然后进行告警的设置。Yarn 负责整体集资源的管理。
上图是实时计算平台 1.0 的界面，整体功能比较简单。
上图是实时计算平台 2.0。相对于 1.0，最大的区别是蓝的部分。对于实时计算平台的形态，可能并没有一个统一的标准，它与每个公司本身的情况息息相关，比如公司本身的体量和规模、公司对实时计算平台的资源投入等，最终还是应该以适用于公司本身的现状为最佳标准。
2.0 版本我们增加从开发到测试两个阶段功能的支持。简单介绍一下它们的具体功能：
∙FlinkSQL：它是很多公司的实时计算平台都支持的功能，它的优点在于可以降低使用成本，也比较简单易用。
∙
∙空间管理：不同的部门和不同的组可以在自己的空间里进行作业的创建、管理。有了空间的概念之后，我们可以利用它做一些权限的控制，比如只能在自己有权限的空间里进行一些操作。
∙
∙UDF 管理：使用了 FlinkSQL 的前提下，就可以基于 SQL 的语义用 UDF 的方式扩充功能。此外，UDF 还能用于 Java 和 Schema 任务，可以把一些公用的功能包装成 UDF，降低开发成本。它还有一个很重要的功能就是调试，可以简化原有的调试流程，做到用户无感知。
实时计算平台 2.0 的实现，带给我们最大的影响就是减轻了数据团队的负担。在我们原先的开发流程里，经常需要数据团队的介入，但实际上其中的很大一部分工作都是比较简单的，比如数据同步或数据的简单处理，这类工作并不一定需要数据团队去介入。
我们只需要把实时计算平台做得更完善、易用和简单，其他的团队就可以使用 FlinkSQL 去做上述简单的工作，理想的情况下他们甚至不需要知道 Flink 的相关概念就可以做一些 Flink 的开发。比如后台人员做业务侧开发的时候，对于一些比较简单的场景就不需要依赖数据团队，大大降低沟通成本，进度会更快。这样在部门内有一个闭环会更好一点。而且以这样的方式，各个角其实都会觉得比较开心。产品经理的工作也会变得更轻松，在需求的阶段不需要引入太多的团队，工作量也会变少。
所以，这是一个以技术的方式来优化组织流程的很好的例子。
三、实时看板
实时看板是一个比较常见的功能，在我们的具体实现中，主要发现了以下几个难点：
∙第一，数据延迟上报。比如业务数据库发生问题后，进行 CDC 接入的时候就需要中断，包括后续写到 Kafka，如果 Kafka 集负载很高或 Kafka 发生问题，也会中断一段时间，这些都会造成数据的延迟。上述延迟在理论上可以避免，但实际上很难完全避免。此外还有一些理论上就不能完全避免的延迟，比如用户的流量或信号有问题导致操作日志无法实时上传。
∙
∙第二，流批一体。主要在于历史数据和实时数据能否统一。
∙
∙第三，维度的实时选择。实时看板可能需要灵活选择多个维度值，比如想先看北京的活跃用户数，再看上海的活跃用户数，最后看北京 + 上海的活跃用户数，这个维度是根据需要可以灵活选择的。
∙
∙第四，指标的验证。指标的验证在离线的情况下，相对来说比较简单一些，比如说可以做一些数据分布，看看每个分布的大概情况，也可以通过 ODS 层数据的计算与中间表进行比对，做交叉验证。但是在实时的情况下就比较麻烦，因为实时处理是一直在进行的，有些情况很难去复现，此外也很难进行指标范围或分布的验证。
实时看板一般存在两个方面的需求：
∙首先是时延方面，不同的场景对时延的要求是不同的，比如有些场景下能够接受数据延迟 1-2 分钟到达，但有的场景下只允许延迟几秒钟。不同场景下实践的技术方案复杂度不一样。
∙
∙其次，需要兼顾实时与历史看板的功能。有些场景下，除了需要看实时的数据变化，还需要对比着历史数据来一起分析。
实时与历史数据应该进行统一的存储，否则可能会存在很多问题。首先，实现的时候表结构比较复杂，查询的时候可能需要判断哪段时间是历史数据，哪段时间是实时数据，然后对它们进行拼接，会导致查询的实现成本过高。其次，在历史数据进行切换的时候也很容易出现问题，比如每天凌晨定时刷新历史数据，此时如果历史任务发生延迟或错误，很容易导致查出来的数据是错误的。