我需要将一个缓慢变化的AWS DynamoDb定期转储到S3上，以便在Athena上进行查询。需要确保Athena可用的数据与DynamoDb上可用的数据相差不远（最大延迟为1小时）
我知道以下两种方法：
使用EMR（来自数据管道）来export整个DynamoDb
此方法的优势在于，使用单个EMR脚本（每小时运行），可以在Athena上直接搜索的压缩Parquet文件可以转储到S3上。但是，此方法的一大缺点是，虽然一个小时内仅更改少量记录，但需要进行整个转储，这要求DynamoDb中的读取容量显着更高，而EMR资源也更高。
使用DynamoDB Streams反映S3上DynamoDb的任何更改。
这具有不需要在DynamoDb上处理不变数据的优点，从而减少了比正常操作所需的读取容量高得多的读取容量的需求。但是，将需要一个后续脚本（可能是另一个EMR作业）来整合DynamoDb流生成的每个记录文件，否则Athena的性能会因为文件数量过多而受到严重影响。
是否有其他方法可以比这些方法做得更好？
答案 0 :(得分：1)
从性能/成本角度来看，我认为最好的解决方案是使用DynamoDB流和Glue作业每天一次（或每周一次，具体取决于数据的速度）整合
DynamoDB流方法（以及所有以增量方式读取数据的解决方案）的一个缺点是，您必须处理从Parquet文件中更新/删除记录的复杂性。
如果您的负载不是将新数据专门“附加”到表上，则应在任何地方（可能是DynamoDB表或S3文件）写入任何已更新/删除的项目，并让Glue在将合并文件写入S3之前删除这些记录。
所有演员将是：
Lambda 处理流应：
胶水作业的运行频率较低，应该：
与使用EMR每小时转储整个表相比，这导致了更多的工作：您应该自己判断是否值得。 ：）
答案 1 :(得分：0)
我已经实现了以下数据管道，用于将数据实时流传输到雅典娜：
Dynamodb-> DynamoDB流-> Lambda-> Kinesis Firehose-> s3 <-雅典娜
如果您有任何疑问，请告诉我。
答案 2 :(得分：-1)
要从DynamoDB到Athena获取数据，我想您很想：您可以执行完全转储或利用流来获取更改。您在两者之间进行了权衡。第二种是更清洁的解决方案，您可以在其中捕获基础流提供的更改，尤其是因为数据更改缓慢。
合并由流生成的文件的问题是Athena的继承缺点。一种选择是使用AWS Lambda将流中的更新应用到Elasticsearch集群中。您将需要进行一次一次性的初始设置以使现有数据变哑，但是随后您将能够运行搜索查询。
另一种选择是使用Rockset，它与DynamoDB集成在一起以服务搜索和分析SQL查询。在Rockset中添加凭据和表名后，它将使用基础流实时与Dynamo表同步，这样您就可以避免增加读取容量以及合并S3文件的任何后台工作。您可以阅读this blog post以了解其工作方式。
还有full analysis here，其中包含与Rockset一起列出的选项的优缺点。
完全公开：我在Rockset工作。