我阅读了官方AWS Kinesis Firehose的文档，但它没有提到如何处理重复事件。有人有经验吗？我用谷歌搜索有人使用ElasticCache进行过滤，这是否意味着我需要使用AWS Lambda来封装这样的过滤逻辑？是否有任何简单的方法，如firehose将数据摄入Redshift，同时有＃34;恰好一次＆＃34;语义？非常感谢！
答案 0 :(得分：9)
您可以在Kinesis Stream的两侧进行复制。您可以将相同的事件两次放入Stream中，并且您可以由消费者两次阅读该事件。
如果您尝试将事件发送到Kinesis流，可能会发生生产者方面，但由于某种原因您不确定它是否成功写入，并且您决定再次使用它。如果您获得一批事件并开始处理它们，并且在您设法检查您的位置之前崩溃，并且下一个工作人员根据最后一个检查点从Kinesis流中选择同一批事件，则可能发生消费者方面的情况。序列ID。
在开始解决此问题之前，您应该评估这种重复的频率以及此类重复的业务影响。并非每个系统都处理不能容忍重复的金融交易。然而，如果您决定需要进行重复数据删除，解决问题的常用方法是使用一些事件ID并跟踪是否已经处理了该事件ID。
使用Redis的ElasticCache是一个跟踪事件ID的好地方。每次你拿起一个事件进行处理时，你会检查你是否已经在Redis的哈希表中找到它，如果你找到它，你跳过它，如果你没找到它，你将它添加到表中（带有一些TTL基于这种复制的可能时间窗口）。
如果您选择使用Kinesis Firehose（而不是Kinesis Streams），则您无法再控制使用者应用程序，也无法实现此过程。因此，您要么想要在生产者端运行这样的重复数据删除逻辑，切换到使用Kinesis Streams并在Lambda或KCL中运行您自己的代码，或者在Redshift中解决重复数据删除功能（见下文）。
如果您对复制不太敏感，可以在Redshift中使用某些函数，例如WINDOW函数中的COUNT DISTINCT或LAST_VALUE。
答案 1 :(得分：0)
不确定这是否可以解决。但是要处理重复项，您需要编写自己的KCL。 Firehose无法保证不会重复。一旦拥有自己的KCL使用者（可以处理Kinesis Date Stream中的数据），就可以摆脱Firehose。 如果这样做，您可以按照链接的文章（在此进行完整披露，在此进行身份验证）进行链接，该文章在通过KCL使用者对重复数据进行重复数据删除和处理后将事件存储到S3中。
通过根据Kinesis数据流接收事件的分钟数对事件进行分组，从而存储事件，方法是查看事件的ExploreArrivalTimestamp。给定一批记录，无论它们何时进行处理，这都使我们能够始终将事件保存在相同的键前缀上。例如Kinesis在2020/02/02 / 15:55小时收到的所有事件都将存储在/ 2020/02/02/15/55 / *。因此，如果密钥在给定的分钟内已经存在，则表示该批次已被处理并存储到S3。
您可以实现自己的ISequenceStore，将针对您的情况对Redshift进行实现（在本文中，针对S3完成）。阅读下面的全文。
https://www.nabin.dev/avoiding-duplicate-records-with-aws-kcl-and-s3