当缓慢的消费者在流处理（spark、aws）中强制背压时避免数据丢失

Question

我是分布式流处理 (Spark) 的新手。我已经阅读了一些教程/示例，这些教程/示例涵盖了背压如何导致生产者响应过载的消费者而减速。给出的经典示例是摄取和分析推文。当出现意外的流量峰值导致消费者无法处理负载时，他们会施加背压，而生产者会通过调低速率来做出响应。

我没有真正看到的是在实践中使用了哪些方法来处理由于整个管道容量较低而无法立即处理的大量传入实时数据？

我想这个问题的答案取决于业务领域。对于某些问题，只删除该数据可能没问题，但在这个问题中，我想重点关注我们不想丢失任何数据的情况。

由于我将在 AWS 环境中工作，我的第一个想法是在 SQS 队列或 Kinesis 流中“缓冲”多余的数据。是在实践中这么简单，还是有更标准的流式解决方案来解决这个问题（可能是 Spark 本身的一部分）？

Answer 1

“有更标准的流媒体解决方案吗？” - 也许。有很多不同的方法可以做到这一点，目前还不清楚是否有“标准”。不过，这只是一种意见，您不太可能得到这部分的具体答案。

“实践中就这么简单吗？” - SQS 和 Kinesis 有不同的使用模式：

• 如果您想始终处理所有消息，请使用 SQS，AND 有一个逻辑使用者
  • 将此视为一个经典队列，需要从队列中“使用”消息。
  • 绝对是一个更易于理解和使用的模型，但它本质上是一个缓冲区
• 如果您想轻松跳过消息，请使用 Kinesis，OR 有多个逻辑使用者
  • 将此视为具有“跳过”功能的流，其中多个消费者可以位于流中的不同点，或过滤以使用特定的消息类型
  • 需要更多努力才能使用，但提供了更多消息消费和处理背压的选项
  • 请注意（默认情况下）Kinesis will drop data in the stream if it's more than 24h old, though this can be increased to 7 days

对于您有“无法立即处理的大量传入实时数据”的用例，我会将您的精力集中在 Kinesis 而不是 SQS，因为 Kinesis 模型还可以更好地与其他流传输机制（例如火花/卡夫卡。