Apache Flink 替换 Spark Stream的架构与实践( bilibili 案例解读)_streamsparkflink加载udf

3.基于 Apache Flink 的流式计算平台

为解决上述问题，bilibili 希望根据以下三点要求构建基于 Apache Flink 的流式计算平台。

• 第一点，需要提供 SQL 化编程。bilibili 对 SQL 进行了扩展，称为 BSQL。BSQL 扩展了 Flink 底层 SQL 的上层，即 SQL 语法层。
• **第二点，**DAG 拖拽编程,一方面用户可以通过画板来构建自己的 Pipeline，另一方面用户也可以使用原生 Jar 方式进行编码。
• **第三点，**作业的一体化托管运维。

涵盖场景：bilibili 流式计算平台主要涵盖四个方面的场景。

• AI 工程方向，解决了广告、搜索、推荐的流式 Joiner 和维表 Joiner；
• 实时计算的特征支持，支持 Player 以及 CDN 的质量监控。包括直播、PCU、卡顿率、CDN 质量等；
• **用户增长，**即如何借助实时计算进行渠道分析、调整渠道投放效果；
• 实时 ETL，包括 Boss 实时播报、实时大屏、看板等。

二、Saber 的平台演进

1.平台架构

实时平台由实时传输和实时计算两部分组成，平台底层统一管理元数据、血缘、权限以及作业运维等。实时传输主要负责将数据传入到大数据体系中。实时计算基于 BSQL 提供各种应用场景支持。

如下图所示，实时传输有 APP 日志、数据库 Binlog、服务端日志或系统日志。bilibili 内部的 Lancer 系统解决数据落地到 Kafka 或 HDFS。计算体系主要围绕 Saber 构建一套 BSQL，底层基于 YARN 进行调度管理。

上层核心基于 Flink 构建运行池。再向上一层满足多种维表场景，包括 MySQL、Redis、HBase。状态（State）部分在 RocksDB 基础上，还扩展了 MapDB、Redis。Flink 需要 IO 密集是很麻烦的问题，因为 Flink 的资源调度体系内有内存和 CPU，但 IO 单位未做统一管理。当某一个作业对 IO 有强烈的需求时，需要分配很多以 CPU 或内存为单位的资源，且未必能够很好的满足 IO 的扩展。所以本质上 bilibili 现阶段是将 IO 密集的资源的 State 转移到 Redis 上做缓解。数据经过 BSQL 计算完成之后传输到实时数仓，如 Kafka、HBase、ES 或 MySQL、TiDB。最终到 AI 或 BI、报表以及日志中心。

2. 开发架构设计

（1）开发架构图：如下图左侧所示。最上层是 Saber-Streamer，主要进行作业提交以及 API 管理。下一层是 BSQL 层，主要进行 SQL 的扩展和解析，包括自定义算子和个性算子。再下层是运行时态，下面是引擎层。运行时态主要管理引擎层作业的上下层。bilibili 早期使用的引擎是 Spark Streaming，后期扩展了 Flink，在开发架构中预留了一部分引擎层的扩展。最下层是状态存储层，右侧为指标监控模块。

（2）平台设计准则：Saber 平台系统设计时团队关注其边界以及规范和准则，有以下四个关键点。第一是对 Streaming workflows 进行抽象。第二是数据规范性，保证 schema 完整。第三是通用的 BSQL 解析层。第四是工程效率。

• Streaming workflows：下图为流计算模型抽象。大数据计算引擎的本质是数据输入经过一个 function 得到输出，所以 function 本质是一个能够做 DAG 转换的 Transform。Saber 平台期望的流计算抽象形态是提供相应的 Source，计算过程中是一个 Transform 的 DAG，最后有一个 Sink 的输出。

在上述抽象过程中规范语义化标准。即最后输入、输出给定规范标准，底层通过 Json 表达方式提交作业。在没有界面的情况下，也可以直接通过 Json 方式拉起作业。