bilibili 实时计算平台架构与实践( 二 ) 基于对bilibili实时计算的痛点分

文章插图
2. 开发架构设计
① 开发架构图：如下图左侧所示。最上层是 Saber-Streamer ，主要进行作业提交以及 API 管理。下一层是 BSQL 层，主要进行 SQL 的扩展和解析，包括自定义算子和个性算子。再下层是运行时态，下面是引擎层。运行时态主要管理引擎层作业的上下层。 bilibili 早期使用的引擎是 Spark Streaming ，后期扩展了 Flink ，在开发架构中预留了一部分引擎层的扩展。最下层是状态存储层，右侧为指标监控模块。
② 平台设计准则：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 和 watermark 信息的完善。另外，平台对 SQL 有一些扩展。第三块是扩展的核心工作，将 SQL 树中扩展的子树转换为新的节点，然后将 SQL 的 DAG 提交到 Flink 上运行。

文章插图

效果展示-DAG：如下图所示， DAG 产品展示，包括并行度的设计、日志、监控指标告警输出。

文章插图

效果展示-BSQL：用户根据选择的表的输入源的 schema 编写相应的 SQL 。最后选择相应 UDF 就可以提交到相应集群。

文章插图

效果展示-作业调试：如下图所示为平台支持的作业调试。如果只有 SQL 开发却没有作业调试环节，是令用户痛苦的。故平台支持通过文件上传的方式以及线上采样的方式进行作业调试 SQL 。
- 上一页
- 1
- 2
- 3
- 4
- 5
- 下一页