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 树。验证与构建主要是提取表名、字段信息

你可能感兴趣的:(程序员,flink,spark,架构)