Spark Dstream 中的窗口函数导致长时间挂起的任务

Question

我们正在尝试在 spark 中实现 Window 功能。 Spark 通过 Kafka（有 5 个分区）接收数据，我们使用 Spark Java DStream 进行处理。一旦来自 kafka 的逗号分隔数据映射到 Spark 中的对象，我们就会创建一个 20 秒的窗口，该窗口以 1 秒的速度滑动。在这个 Java DStream 上，我们计算并打印输出（实际上我们想做更多的处理，但为简单起见只应用了计数）。一切正常，直到处理时间出现峰值，处理一个任务大约需要 40 秒，然后发布，我们得到了一个很长的队列。 集群详情： - 3节点集群 - 每个有 45 个核心（总共 135 个核心） - 每个都有 256 GB RAM 设置测试： 设置1：- - 5 个 Kafka 分区 - 20 秒窗口，以 1 秒滑动 - 每个节点 9 个执行器（总共 27 个执行器） - 为每个 Executor 分配 10 GB 设置 2：- - 5 个 Kafka 分区 - 20 秒窗口，以 1 秒滑动 - 每个节点 45 个执行器（总共 135 个执行器） - 为每个 Executor 分配 1 GB 设置 3：- - 5 个 Kafka 分区 - 20 秒窗口，以 1 秒滑动 - 每个节点 15 个执行器（总共 45 个执行器） - 为每个 Executor 分配 6 GB 设置 4：- - 5 个 Kafka 分区 - 120 秒窗口，以 1 秒滑动 - 每个节点 9 个执行器（总共 27 个执行器） - 为每个 Executor 分配 10 GB 设置 5：-（这是我们的实际场景） - 27 Kafka 分区 - 120 秒窗口，以 1 秒滑动 - 每个节点 9 个执行器（总共 27 个执行器） - 为每个 Executor 分配 10 GB

在所有设置中，在某些时候处理需要太多时间（在大多数处理问题中接近 40 秒）。 如果有人对此有解决方案或任何参数更改建议，那就太好了。

Answer 1

如果您不想建立队列，您可以启用背压。这是通过将 spark.streaming.backpressure.enabled 设置为 true 并且自 spark 1.5 起可用 除此之外，重要的是要了解生产者以什么速率生成数据，以及您是否有足够的资源以该速率处理数据。 Spark-UI 将让您对此有所了解。 还有其他因素需要考虑会影响性能，例如您是使用基于接收器的方法还是 kafka-direct，有或没有复制，有或没有检查点等。