[参赛项目] 基于 Flink + Pravega 优化 Pravega 读取历史消息数据

[hzh0425]

一 背景

我们知道, Flink + Pravega 是现代大数据流计算领域的最佳搭档:

以 Apache Flink 作为计算引擎，通过统一的模型/API来统一批处理和流处理。以 Pavega 作为存储引擎，为流式数据存储提供统一的抽象，使得对历史和实时数据有一致的访问方式。两者统一形成了从存储到计算的闭环，能够同时应对高吞吐的历史数据和低延时的实时数据。同时 Pravega 团队还开发了 Flink-Pravega Connector，为计算和存储的整套流水线提供 Exactly-Once 的语义。

Pravega 的架构设计如下图所示, 其采用分层存储:

• Tier 1 存储

Tier1 的存储通常部署在 Pravega 集群内部，主要是提供对低延迟，短期的热数据的存储。在每个 Segment Store 结点都有 Cache 以加快数据读取速率，Pravega 使用Apache Bookeeper 来保证低延迟的日志存储服务。

• Long-term 存储

Long-term 的存储通常部署在 Pravega 集群外部，主要是提供对流数据的长期存储，即冷数据的存储。不仅支持 HDFS，NFS，还会支持企业级的存储如 Dell EMC的 ECS，Isilon 等产品。

二 目标

然而, 和其他的 '消息队列' 产品类似, 对于冷数据的读取, Pravega 也同样具有读取性能慢的痛点, 这使得在使用 Flink 进行历史数据分析的场景下, 无法和实时流数据的处理速度相媲美.

因此, 我们团队计划优化 Pravega 读取冷数据, 为 Flink 而加速!

三 实施方案

1.核心思路

设计思路核心: SSD - 4KB 对齐

SSD 4kb 对齐是读写文件优化的重要手段, 举个例子:

SSD就好比一个大仓库，里面由很多小“房间”组成，每个房间的容量都是一样的（4KB的倍数）。每个房间放入货物（文件）的次数是有限制的（10万次）并且每个房间只能放一种货物。货物的放入和拿出是由管理员（操作系统）来协调解决的。但是无论货物有多大，管理员都会把这些货物分成好多块放入房间。每块的大小都是一样的

• 对于没有对齐的仓库，很多文件可能同时占用了两个房间。如果要把货物搬出去就相当于两个房间各使用了一次。也即读写性能都会下降.如下图, '簇0' 和 '簇1' .... , 每个 '簇' 都横跨了两个扇区, 而硬盘的基本读写单位是“扇区”, 这样每次读取这个 '簇' 时, 都需要进行两次 IO, 效率十分低下.

​

• 对齐过后的仓库，货物分成多块, 大小和房间大小一样，放进取出非常方便.

因此, 核心思路就是:

• 写的时候 , 进行数据规整, 4kb 对齐
• 读的时候, 分块读

2.设计方案

主要改进点在 Pravega-flink-connector 中:

• 当 flink 要将序列化后的数据推入到 Pravega 中时, 可以对数据进行规整, 对于缓冲块不满 4kb 的, 就让其 4kb 对齐填充:

  例如:

    int position = writeBuffer.position();
    int mod = position % Constants._4kb;
    if (mod != 0) {
      writeBuffer.position(position + Constants._4kb - mod);
    }

• 当 flink 订阅 Pravega 的历史数据时, 每次分块进行读取

四 成员介绍

• 黄章衡: flink 爱好者, 分布式存储研究者 天池昵称: hzh0425
• 戴锦坤: flink 流计算方向硕士研究生 天池昵称: szx222