amazon-dynamodb - 使 DynamoDB 数据在 Athena 中可搜索的正确方法？

Question

我需要一个缓慢变化的 AWS DynamoDb 定期转储到 S3 上，以便在 Athena 上查询它。需要确保 Athena 可用的数据与 DynamoDb 上的可用数据相差不大(最大滞后 1 小时)
我知道以下两种方法:

使用 EMR(来自数据管道)到 export整个 DynamoDb
这种方法的优点是使用单个 EMR 脚本(每小时运行一次)，可以在 S3 上转储可直接在 Athena 上搜索的压缩 Parquet 文件。但是，这种方法的一个很大的缺点是，虽然一个小时内只有少量记录发生变化，但需要进行整个转储，这需要 DynamoDb 中的读取容量和EMR 资源显着增加。

使用 DynamoDB Streams反射(reflect) S3 上 DynamoDb 中的任何更改。
这样做的优点是不需要在 DynamoDb 上处理未更改的数据，从而减少了对比正常操作所需的读取容量高得多的需求。但是，需要一个后续脚本(可能是另一个 EMR 作业)来整合 DynamoDb 流生成的每个记录文件，否则 Athena 的性能会因大量文件而受到严重影响。

有没有其他方法可以做得比这些更好？

Answer 1

我认为从性能/成本的角度来看，最好的解决方案是使用 DynamoDB Streams 和 Glue Job 每天一次(或每周一次，取决于您的数据速度)整合文件。

DynamoDB Streams 方法(以及所有增量读取数据的解决方案)的一个缺点是您必须处理从 Parquet 文件更新/删除记录的复杂性。

如果您的负载不是专门将新数据“附加”到表中，您应该在某处写入任何更新/删除的项目(可能是 DynamoDB 表或 S3 文件)，并让 Glue 在将合并文件写入 S3 之前删除这些记录。

所有 Actor 将是:

Lambda 处理流应该:

将新添加的项目写入 S3 中的 Parquet 文件，

将更新(甚至是现有项目的 PutItem)和删除写入 DynamoDB 表；

胶水作业 运行频率较低，应该:

将第一个 lambda 创建的许多较小的文件合并为较少的较大的 Parquet ，

将 DynamoDB 表中记录的所有更新/删除操作合并到生成的 Parquet。

这比使用 EMR 每小时转储整个表要花费更多的精力:您应该自己判断是否值得。 :)