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

Question

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

该源每分钟产生约17,500条记录，Flink作业为每个传入记录分配（事件）时间戳，执行12种不同类型的keyBy，将事件放入1分钟的翻滚窗口中，对该键控Windows流执行聚合操作，最后写入结果到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，01/29/2019似乎两个节点都以很高的堆使用率运行，因此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索引上）设置为30s（默认值为1s），解决了该问题。 进行这些更改后，flink中的背压将报告为正常，没有数据滞后，并且一切看起来都像桃子一样。