B站的平台建设有哪些优化？

在平台的基础功能方面，B站做了很多新的功能和优化。其中两个重点是支持 Kafka 的动态 sink 和任务提交引擎的优化。 B站存在大量如下的 ETL 场景：业务的原始实时数据流是一条较大的混合数据流，包含了数个子业务数据。数 据通过 Kafka 传输，末端的每个子业务都对应单独的处理逻辑，每个子业务都去消费全量数据，再进行过滤， 这样的资源消耗对业务来说是难以接受的，Kafka 的 IO 压力也很大。因此我们会开发一个 Flink 任务，对混合数据流按照子业务进行拆分，写到子业务对应的 topic 里，让业务使用。 技术实现上，早期 Flink SQL 的写法就是写一个 source 再写多个 sink，每个 sink 对应一个业务的 topic，这确实可以满足短期的业务诉求，但存在数据倾斜、无法动态增减sink和维护成本高的问题。

为了解决相关问题，B站开发了一套 Kafka 动态 sink 的功能，支持在一个 Kafka sink 里面动态地写多个 topic数据。该功能对 Kafka 表的 DDL 定义进行了扩展，在 topic 属性里支持了 UDF 功能，它会根据入仓的数据计算出这条数据应该写入哪个 Kafka 集群和 topic。sink 收到数据后会先调用 UDF 进行计算，拿 到结果后再进行目标集群和 topic 数据的写入，这样业务就不需要在 SQL 里编写多个 sink，代码很干净，也 易于维护，并且这个 sink 被所有 topic 共用，不会产生倾斜问题。UDF 直接面向业务系统，分流规则也会平台化，业务方配置好规则后，分流实施自动生效，任务不需要做重启。第二个优化是任务的提交引擎优化，这主要是因为本地编译、多版本支持、UDF加载和代码包传输效率四个方面的问题。相关的优化内容如下：

• 首先引入了 1.11 版本以上支持的 application 模式，这个模式与 per-job 最大的区别就是 Flink 任务的编 译全部移到了 APP master 里做，这样就解决了提交引擎的瓶颈问题；• 在多版本的支持上面，B站对提交引擎也做了改造，把提交器与 Flink 的代码彻底解耦，所有依赖 Flink代码的操作全部抽象了标准的接口放到了 Flink 源码侧，并在 Flink 源码侧增加了一个模块，这个模块会随着 Flink 的版本一起升级提交引擎，对通用接口的调用全部进行反射和缓存，在性能上也是可接受的； 此外，Flink的多版本源码全部按照 maled 模式进行管理，存放在 HDFS。按照业务指定的任务版本，提 交引擎会从远程下载 Flink 相关的版本包缓存到本地，所以只需要维护一套提交器的引擎。Flink 任何变更完全和引擎无关，升级版本提交引擎也不需要参与；

• 完成 application 模式升级后，B站对 UDF 和其他资源包的上传下载机制也进行了修改，通过 HDFS 远程 直接分发到 JM/TM 上，减少了上传下载次数，同时也避免了 cluster 的远程加载。

以上内容摘自《Apache Flink 案例集（2022版）》电子书，点击https://developer.aliyun.com/ebook/download/7718 可下载完整版