Question

我有一个flink作业，该作业从Kafka读取数据，执行某些聚合并将结果写入elasticsearch索引。我在源头上看到高背压。高背压导致从Kafka缓慢读取数据，我看到数据在网络堆栈中排队（netstat RecvQ显示成千上万个字节的数据卡在源kafka连接中，最终读取了数据），这依次导致滞后后要存储到弹性搜索中的数据，并且此滞后持续增加。

该源每分钟产生约17,500条记录，Flink作业为每个传入记录分配（事件）时间戳，执行12种不同类型的keyBy，将事件放入1分钟翻滚窗口中，对该键控窗口流执行聚合操作最后将结果写入12个不同的Elasticsearch索引（每个写入都是一个插入）。

问题在于，写入Elasticsearch的数据开始滞后，因此仪表板结果（建立在Elasticsearch之上）不再实时。我的理解是，这是由于背压增加而发生的。不知道如何解决这个问题。群集本身是基于VM的单节点独立群集，具有64GB RAM（任务管理器配置为使用20GB）和16个vCPU。没有证据表明（从htop看到）CPU或内存受到限制。只有一个任务管理器，这是该群集上唯一的flink作业。

我不确定这个问题是由于集群中的某些本地资源问题还是由于对Elasticsearch的写入速度太慢。我已经将setBulkFlushMaxActions设置为1（正如我在任何地方看到的所有代码示例中所做的那样），是否还需要设置setBulkFlushInterval和/或setBulkFlushMaxSizeinMB？

我经历过https://www.da-platform.com/flink-forward-berlin/resources/improving-throughput-and-latency-with-flinks-network-stack，但尚未尝试调整幻灯片19上列出的选项，不确定是否要为这些参数设置什么值。

最后，我不认为从IntelliJ IDE中运行同一作业时会看到相同的问题。

我要排除所有聚合，然后将它们逐个添加回去，以查看是否存在引发此问题的特定聚合？

任何特定的指针将不胜感激，还将尝试setBulkFlushInterval和setBulkFlushMaxSizeinMB。

更新1，2019年1月29日 似乎两个节点都以很高的堆使用率运行，因此GC一直在运行以尝试清除JVM中的空间。将物理内存从16GB增加到32GB，然后重新启动节点。那将有望解决问题，再过24小时就会知道。

Answer 1

通常在这种情况下，问题出在与外部数据存储的连接上-带宽不足，或者每个记录的同步写入，而不是批量写入。

一种简单的方法来验证Elasticsearch接收器是否存在问题（而不是说网络堆栈配置），将其替换为丢弃接收器（一个根本不执行任何操作的接收器），以查看是否可以解决问题。。像

public static class NullSink<OUT> implements SinkFunction<OUT> {
    @Override
    public void invoke(OUT value, Context context) throws Exception {
    }
}

更新：

问题是您已将bulk.flush.max.actions设置为1，从而防止了与Elasticsearch服务器的连接中的任何缓冲。

Answer 2

在问题得到了通过增加（加倍）的elasticearch群集节点上的RAM和设置索引刷新间隔（在所有elasticsearch索引）到30秒（默认为1秒）解决。进行这些更改后，flink中的背压将报告为正常，没有数据滞后，并且一切看起来都像桃子一样。

flink：处理背压（来源：kafka，sink：elasticsearch）

2 个答案: