Question

我正在研究Flink作业的性能，该作业将数据从Kafka传输到S3 Sink。我们正在使用BucketingSink来编写镶木地板文件。存储逻辑将消息划分为具有以下类型的文件夹：数据类型，租户（客户），日期时间，提取ID等。这导致每个文件存储在由9到10层组成的文件夹结构中（s3_bucket：/ 1/2/3/4/5/6/7/8/9 / myFile ...）

如果数据以租户类型的消息突发形式分发，我们会看到良好的书写效果，但是当数据在成千上万的租户，数十种数据类型和多个提取ID上呈现白噪声分布时，我们有一个令人难以置信的表演损失。（大约是300倍）

安装调试器后，问题似乎与在S3上同时打开以写入数据的处理程序数量有关。进一步来说：

在用于编写S3的hadoop库中进行研究后，我发现了一些可能的改进设置：

      <name>fs.s3a.connection.maximum</name>
      <name>fs.s3a.threads.max</name>
      <name>fs.s3a.threads.core</name>
      <name>fs.s3a.max.total.tasks</name>

但是这些都不会对吞吐量产生很大的影响。我还尝试将文件夹结构展平以写入单个键，例如（1_2_3 _...），但这也没有带来任何改善。

注意：测试已在Hadoop FileSystem（BucketingSink）的Flink 1.8上完成，使用hadoop fs库2.6.x写入S3（因为我们使用Cloudera CDH 5.x作为保存点），所以我们不能切换到StreamingFileSink。

Answer 1

根据科斯塔斯在https://lists.apache.org/thread.html/50ef4d26a1af408df8d9abb70589699cb6b26b2600ab6f4464e86ea4%40%3Cdev.flink.apache.org%3E中的建议

减速的原因是这段代码： https://github.com/apache/flink/blob/master/flink-connectors/flink-connector-filesystem/src/main/java/org/apache/flink/streaming/connectors/fs/bucketing/BucketingSink.java#L543-L551

仅此一项就需要大约4-5秒，总共需要6秒才能打开文件。来自已执行呼叫的日志：

2020-02-07 08:51:05,825 INFO  BucketingSink  - openNewPartFile FS verification
2020-02-07 08:51:09,906 INFO  BucketingSink  - openNewPartFile FS verification - done
2020-02-07 08:51:11,181 INFO  BucketingSink  - openNewPartFile FS - completed partPath = s3a://....

此操作与带有60秒不活动翻转的桶式接收器的默认设置一起 https://github.com/apache/flink/blob/master/flink-connectors/flink-connector-filesystem/src/main/java/org/apache/flink/streaming/connectors/fs/bucketing/BucketingSink.java#L195 意味着到我们完成创建最后一个存储桶时，在插槽上有10个以上的并行存储桶时，第一个存储桶已失效，因此需要旋转以生成阻塞情况。

我们通过替换BucketingSink.java并删除了上面提到的FS检查来解决了这个问题：

        LOG.debug("Opening new part file FS verification");
        if (!fs.exists(bucketPath)) {
            try {
                if (fs.mkdirs(bucketPath)) {
                    LOG.debug("Created new bucket directory: {}", bucketPath);
                }
            }
            catch (IOException e) {
                throw new RuntimeException("Could not create new bucket path.", e);
            }
        }
        LOG.debug("Opening new part file FS verification - done");

如我们所见，没有接收器，接收器可以正常工作，现在打开文件大约需要1.2秒。

此外，我们将默认的非活动阈值设置为5分钟。有了这一更改，我们可以轻松地为每个插槽处理200个以上的存储桶（一旦作业加快速度，它将在所有插槽上提取，因此可以延迟不活动的超时）

具有许多并行存储桶的Flink Hadoop存储桶接收器性能

1 个答案: