从 DynamoDB 到 S3 的增量数据捕获

0

【以下的问题经过翻译处理】 我有一个场景,我想将数据从 DynamoDB 复制到 S3(用于备份,稍后用于分析处理)。我不需要实时数据更新或有关 DDB 项目更改的任何通知。

使用 DDB Streams、Lambda、Kinesis Firehouse 和 S3 目的地的“常规”设计是可能的,但我担心初始设置的高成本、复杂性和工作量。

我已经实现了以下设计:https://aws.amazon.com/blogs/database/simplify-amazon-dynamodb-data-extraction-and-analysis-by-using-aws-glue-and-amazon-athena/

(通过ETL Glue Job从DDB下载数据到S3)

这很好用,但我对该设计有更多经验的人有以下额外问题:

1.是否有可能执行增量数据加载,例如不是每次都通过 Glue Job 加载完整的 DDB 表? 2. 是否有人对该设计在性能方面有任何实践经验?这里主要关注的是,对于大型 DDB 表(100x 百万项),完整的数据加载将 A)消耗过多的读取容量和 B)需要数小时/数天才能完成 3. 是否有任何其他实用的设计方法可以处理大型 DDB 表?

profile picture
专家
已提问 4 个月前13 查看次数
1 回答
0

【以下的回答经过翻译处理】 如果没有为此设计的数据建模(即允许跨整个数据集进行基于时间的查询的分片 GSI),则不可能从 DynamoDB 表执行增量“书签”加载,然后需要自定义读取器(Glue不支持 GSI 查询)。

使用 streams --> lambda --> firehose 是目前将增量更改从 DynamoDB 表交付到 S3 的最“托管”且最具成本效益的方式。

读取 DynamoDB 流仅具有与之关联的 Lambda 的计算成本,并且 Lambda 可以从一次调用中读取数百个项目。让 Firehose 将这些更改缓冲/打包/存储为 S3 上的压缩/分区/可查询数据既简单又经济。

如果您担心成本,可能值得打开一个 specreq 让专家看一下分析——这些配置既常见又通常具有成本效益(成本与表的大小无关,而是速度/写入的大小 - 这通常比自定义读取器/加载器更有效)。

profile picture
专家
已回答 4 个月前

您未登录。 登录 发布回答。

一个好的回答可以清楚地解答问题和提供建设性反馈,并能促进提问者的职业发展。

回答问题的准则