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

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 方式拉起作业。

• 让数据说话：数据抽象化。计算过程中的数据源于数据集成的上报。数据集成的上报有一套统一的平台入口。用户首先需要在平台上构建一个输入的数据源。用户选择了一个对应的数据源，平台可以将其分发到 Kafka、 HBase、 Hive 等，并且在分发过程中要求用户定义 Schema。所以在数据集成过程中，可以轻松地管理输入语言的 Schema。计算过程中，用户选择 Input Source，比如选择一个 HBase 的表或 Kafka 的表，此时 Schema 已是强约束的。用户通过平台提供的 BSQL 或者 DAG 的方式进行结果表或者指标的输出。

• BSQL 通用设计：BSQL 是遵照 Streaming workflows 设计的思想,核心工作围绕 Source、Transform 以及 Sink。Transform 主要依托 Flink SQL，所以 BSQL 更多是在 Source 和 Sink 上进行分装，支持 DDL 的分装。此处 DDL 参照阿里云对外资料进行了扩展。另外，BSQL 针对计算过程进行了优化，如针对算子计算的数据倾斜问题采取分桶 + hash 策略进行打扫。针对 distinct 类 count，非精准计算采用 Redis 的 HyperLogLog。

• BSQL 解析模型：BSQL 解析模型拓扑展开如下图。当用户提交了一个 SQL，目标是将 SQL 转化成树。之后可以获取 SqlNode 节点。SqlNode 节点中有很多元数据信息。在 SqlNode 树的情况下实现 Table 解析器，将不同的 SqlNode 节点转化成 Flink 相应的 Streamer 进行映射。

• BSQL 执行流程：用户提交 SQL，BSQL 首先进行验证并构建 SQL 树。验证与构建主要是提取表名、字段信息，从元数据库中提取 schema 验证 SQL 的规范性、完整性和合法性。验证完成后，将输入表和结果表注册到 Flink 的运行时态，其中还包括 UDF