接收器较少的方法用于运动的火花蒸汽

Question

对于使用kafka的Spark流，我们有Directstream，它是接收器较少的方法，并映射kafka分区以激发RDD分区。目前我们有一个应用程序，我们使用Kafka Direct方法并在RDBMS中维护我们的偏移量，

Kinesis有一个类似的吗？当我阅读spark-Kinesis集成的文档时，感觉就像检查点有区别。以下是我的一些问题

1. 使用kinesis流式传输将kinesis分片映射到RDD分区吗？如果我在传入的RDD上使用forEachPartition，我可以在分片级别维护有序处理吗？
2. 从文档中解释说，kinesis在dynamoDB中维护了单独的检查点？我们不能忽视它并使用我们自己的抵消管理吗？
3. 在KinesisUtils.createStream api中，我看到对于[initial position]变量，它只需要LATEST或TRIM_HORIZON。在那种情况下，我怎么能不能像我在kafka案例中提供的那样提供碎片地图？

如果我们的应用程序是幂等的，我们如何才能完成一次处理？

Answer 1

  

使用kinesis流式传输将kinesis分片映射到RDD分区吗？

不，如documentation中所述，Kinesis分片和RDD分区之间没有1：1映射：

  

在输入DStream处理期间，Kinesis流分片的数量与在Spark群集中创建的RDD分区/分片的数量之间没有相关性。这是2个独立的分区方案

  

如果我在传入的RDD上使用forEachPartition，我可以在分片级维护有序处理吗？

每个创建的分区，内部维护订单（不确定有帮助）：

  

Kinesis数据处理按每个分区排序，每个消息至少发生一次。

  

从文档中解释说，kinesis在dynamoDB中维护了单独的检查点？我们不能忽视它并使用我们自己的抵消管理吗？

不，您受Kinesis客户端实现的约束，该实现使用DyanmoDB作为后备存储。

  

在KinesisUtils.createStream api中，我看到对于[initial position]变量，它只需要LATEST或TRIM_HORIZON。在那种情况下，我怎么能不能像我在kafka案例中提供的那样提供碎片地图？

没有。没有相同的Kafka偏移量。

如您所见，Kinesis API的当前实现限制了您。如果您需要灵活的偏移存储和恢复，并希望实现一次语义，请考虑与Kafka一起使用此解决方案。