1

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

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

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

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

4

1 回答 1

3

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

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

  • 如果您想始终处理所有消息，并且有一个逻辑使用者 ，请使用 SQS
    • 把它想象成一个经典的队列，消息需要从队列中“消费”。
    • 绝对是一个更容易理解和使用的模型，但它本质上是一个缓冲区
  • 如果您想轻松跳过消息，或者有多个逻辑消费者 ，请使用 Kinesis

对于您有“无法立即处理的大量传入实时数据”的用例，我会将您的精力集中在 Kinesis over SQS 上，因为 Kinesis 模型还可以更好地与 Spark / Kafka 等其他流媒体机制保持一致.

于 2018-04-09T14:22:27.850 回答