Flink 在 B 站的多元化探索与践行
发布时间：2022-05-19 21:15:14 所属栏目：大数据 来源：互联网
导读：本文整理自哔哩哔哩基础架构部资深研发工程师张杨在 Flink Forward Asia 2021 平台建设专场的演讲。主要内容包括： 1.1 基础功能完善 在平台的基础功能方面，我们做了很多新的功能和优化。其中两个重点的是支持 Kafka 的动态 sink 和任务提交引擎的优化。
|
本文整理自哔哩哔哩基础架构部资深研发工程师张杨在 Flink Forward Asia 2021 平台建设专场的演讲。主要内容包括： 1.1 基础功能完善 在平台的基础功能方面，我们做了很多新的功能和优化。其中两个重点的是支持 Kafka 的动态 sink 和任务提交引擎的优化。 我们遇到了大量这样的 ETL 场景，业务的原始实时数据流是一条较大的混合数据流，包含了数个子业务数据。数据通过 Kafka 传输，末端的每个子业务都对应单独的处理逻辑，每个子业务都去消费全量数据，再进行过滤，这样的资源消耗对业务来说是难以接受的，Kafka 的 IO 压力也很大。因此我们会开发一个 Flink 任务，对混合数据流按照子业务进行拆分，写到子业务对应的 topic 里，让业务使用。 技术实现上，早期 Flink SQL 的写法就是写一个 source 再写多个 sink，每个 sink 对应一个业务的 topic，这确实可以满足短期的业务诉求，但存在的问题也较多： 第一是数据的倾斜，不同的子业务数据量不同，数据拆分后，不同 sink 之处理的数据量也存在较大差别，而且 sink 都是独立的 Kafka producer，高峰期间会造成 sink 之间资源的争抢，对性能会有明显的影响; 第二是无法动态增减 sink，需要改变 Flink SQL 代码，然后重启任务才能完成增减 sink。过程中，不仅所有下游任务都会抖动，还有一个严重的问题就是无法从 savepoint 恢复，也就意味着数据的一致性无法保证; 第三是维护成本高，部分业务存在上百个子分流需求，会导致 SQL 太长，维护成本极高。 基础功能上做的第二个优化就是任务的提交引擎优化。做提交器的优化主要是因为存在以下几个问题： 第一，本地编译问题。Flink SQL 任务在 Yarn 上的部署有三种模式：per-job、application 和 yarn-session。早前我们一直沿用 per-job 模式，但是随着任务规模变大，这个模式出现了很多的问题。per-job 模式下，任务的编译是在本地进行再提交到远程 app master，编译消耗提交引擎的服务性能，在短时批量操作时很容易导致性能不足; 第二，多版本的支持问题。我们支持多个 Flink 版本，因此在版本与提交引擎耦合的情况下，需要维护多个不同代码版本的提交引擎，维护成本高; 第三，UDF 的加载。我们一直使用 Flink 命令里的 -c 命令进行 UDF 传递，UDF 代码包存在 UDFS 上，通过 Hadoop 的 web HDFS 协议进行 cluster 加载，一些大的任务启动时，web HDFS 的 HTTP 端口压力会瞬间增大，存在很大的稳定隐患; 第四，代码包的传输效率。用户代码包或者 Flink 引擎代码包都要做多次的上传下载操作，遇到 HDFS 反应较慢的场景,耗时较长，而实时任务希望做到极致的快速上下线。 因此我们做了提交器的优化： 首先引入了 1.11 版本以上支持的 application 模式，这个模式与 per-job 最大的区别就是 Flink 任务的编译全部移到了 APP master 里做，这样就解决了提交引擎的瓶颈问题; 在多版本的支持上面，我们对提交引擎也做了改造，把提交器与 Flink 的代码彻底解耦，所有依赖 Flink 代码的操作全部抽象了标准的接口放到了 Flink 源码侧，并在 Flink 源码侧增加了一个模块，这个模块会随着 Flink 的版本一起升级提交引擎，对通用接口的调用全部进行反射和缓存，在性能上也是可接受的; 而且 Flink 的多版本源码全部按照 maled 模式进行管理，存放在 HDFS。按照业务指定的任务版本，提交引擎会从远程下载 Flink 相关的版本包缓存到本地，所以只需要维护一套提交器的引擎。Flink 任何变更完全和引擎无关，升级版本提交引擎也不需要参与; 完成 application 模式升级后，我们对 UDF 和其他资源包的上传下载机制也进行了修改，通过 HDFS 远程直接分发到 GM/TM 上，减少了上传下载次数，同时也避免了 cluster 的远程加载。 （编辑：常州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
