【发布时间】：2022-07-23 20:19:34
【问题描述】：
解决方案概述
应用程序将事件发布到 SNS 主题，Kinesis 传输流 (Firehose) 订阅该主题，并将事件直接（无 lambda）传输到 S3 存储桶。在桶上定义了一个粘合表，以便我们可以使用 Athena 查询该表。
问题
在 Firehose 交付流中，我们配置了动态分区 (DP)，键是事件记录的主键。它工作正常。但是，当我们在不到 10 秒的时间内发布 10K 事件时，我们得到了这个 DynamicPartitioning.ActivePartitionsLimitExceeded 错误，并且很多事件没有保存到具有正确前缀的存储桶中。
我尝试关闭 DP，但出现“AppendDelimiterToRecordProcessor 只能在启用动态分区时出现”错误。在我移除这个处理器后，所有事件最终都存储在一个没有适当分隔符的文件中，而 Athena 只能识别第一个。
问题
我是 Kinesis 的新手，但我认为 Kinesis 交付流 + Athena 应该可以很好地协同工作。在我看来，如果没有 DP，它就行不通？我想知道在去年底推出 DP 之前人们是如何使用它们的？
AWS doc 确实解释了这一点，但我只是想知道 Kinesis Firehose + Athena 是否可以在没有 DP 的情况下工作？我们自己真的不需要 DP。
更新
我的问题与以下类似，但是当 Firehose 的源是 SNS 主题时，我没有机会转换事件，而且我还不想编写 lambda 来转换数据。
【问题讨论】：
-
刚刚遇到这个问题，这似乎是宇宙中关于这个主题的唯一问题，所以，谢谢......哈哈。我遇到了同样的问题，尽管我的数据似乎确实到达了 S3。你能解决吗？我正在使用动态分区和 lambda 进行时间戳格式化，并且正在考虑完全放弃动态分区，如果这是通过它所需要的。
-
@wkhatch 我并没有真正解决它，只是通过使用另一个不那么多样化的字段而不是主键来解决它，因此即使发布了 10K 事件，分区键值也要少得多超过 500 的限制。这样，一切仍然正常。唯一的缺点是，如果我们可以使用主键作为前缀，那么同一记录的事件总是在 S3 中的同一文件夹下，并且更容易手动定位。
-
啊，感谢您解释导致它的原因。这正是我正在做的，也是；试图通过关联设备的事件进行分区。显然，我们可以要求增加限制，但我会像你一样简化。我也完全停止使用内联解析，并在 lambda 中做了所有事情；同样的结果。再次感谢！
标签： amazon-web-services amazon-kinesis