AWS Kinesis "DynamicPartitioning.ActivePartitionsLimitExceeded" 错误

3

解决方案概述

一个应用程序向SNS主题发布事件,Kinesis Delivery Stream(Firehose)订阅该主题,并直接将事件传递到S3存储桶中(无需Lambda)。在存储桶上定义了一个Glue表,以便我们可以使用Athena查询该表。

问题

在Firehose交付流中,我们配置了动态分区(DP),并将主键作为事件记录的主键。一切正常。但是,当我们在不到10秒的时间内发布10K个事件时,我们收到了DynamicPartitioning.ActivePartitionsLimitExceeded错误,并且很多事件没有使用正确的前缀保存到存储桶中。

我尝试关闭DP,但出现了“只有在启用动态分区时才能存在AppendDelimiterToRecordProcessor”错误。删除此处理器后,所有事件都存储在一个文件中,没有适当的分隔符,Athena只能识别第一个文件。

问题

我对Kinesis还不熟悉,但我认为Kinesis Delivery Stream + Athena应该非常好地协同工作。看起来如果没有DP,它就不会起作用?我想知道在去年底引入DP之前人们是如何使用它们的?

AWS文档确实解释了这一点,但我只是想知道Kinesis Firehose + Athena是否可以在没有DP的情况下工作?我们自己不需要DP。

更新

我的问题与以下问题类似,但当Firehose源为SNS主题时,我没有机会转换事件,而且我还不想编写用于转换数据的lambda。

Kinesis/Firehose/Athena - Creating queryable data from logs

Firehose to S3 with One Record Per Line


2
刚刚看到这个,似乎这是宇宙中唯一关于这个主题的问题,所以,谢谢...哈哈。虽然我的数据似乎已经到了S3,但我也遇到了同样的问题。你能解决吗?我正在使用动态分区和时间戳格式化的 lambda,如果必须要这样做才能解决问题,考虑放弃动态分区。 - wkhatch
@wkhatch 我并没有真正解决它,而是通过使用另一个远不如主键那么多样化的字段来解决了问题,因此即使发布了10K个事件,分区键值也远远低于500的限制。这样一切都能正常工作。唯一的缺点是,如果我们可以将主键用作前缀,那么同一记录的事件总是放置在S3中的同一文件夹下,并且更容易手动定位它们。 - Eric Xin Zhang
啊,谢谢解释是什么导致了它。这正是我正在做的事情,试图通过相关设备事件进行分区。显然,我们可以请求限制增加,但我会像你一样简化。我也完全停止使用内联解析,并在Lambda中完成所有操作;结果相同。再次感谢! - wkhatch
1个回答

2
我遇到了同样的挑战,解决方法是应该按照以下方式设计分区数量:
分区数 * 缓冲时间(秒)<= 最大活动分区数。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接