我们使用 Kinesis 作为 Lambda 的缓冲区，然后将其插入 Redshift。Lambda 函数在 S3 中创建一个文件，并在 Redshift 中执行 COPY 以插入数据。我们看到 Kinesis 的数据延迟非常高，我们担心这会导致超过 24 小时的数据被丢弃。我们目前有 3 个分片在运行，并且离我们的最大吞吐量还很远。
在同一时间段内，我们还看到进入 Kinesis 的数据量有所增加。然而，由于我们只使用了大约三分之一的写入吞吐量，我们不应该受到限制。任何 Lambda 或 Redshift 指标都没有波动。
附加文件显示了来自我们的 Kinesis 流的统计数据。什么可能导致这种情况发生，我将如何解决它？
最有可能发生的事情是您的 lambda 函数跟不上 Kinesis 的数据速率。Kinesis 事件流的 lambda 函数的工作方式是，每个分片只有一个（单核）lambda 函数。所以你只得到3个功能。
您可以通过查看 Kinesis 上的 iteratorAgeMilliseconds 指标来查看函数是否落后。再加上查看 lambda 函数的平均执行持续时间和 lambda 事件源批处理大小，您应该可以很好地了解 lambda 函数每秒实际处理的数据量。 (Event source batch size) * (average size of each record) / (average duration of lambda invocation) * (number of shards) = total bytes/second processed. 您可以使用它来确定需要多少 Kinesis 分片才能跟上负载。
此外，您可能希望查看“扇出”设置，其中您有一个 lambda 函数从流中读取事件，然后直接使用事件调用另一个 lambda 函数。这使您远离 lambda 中的分片关联性。