如何通过 Amazon Glue 爬网程序和 Amazon Glue ETL 作业原生读取 DynamoDB 表中数据的功能

不愧是 Amazon Web Services 的做派，我在 Amazon Web Services 大数据博客上发表 How Goodreads offloads Amazon DynamoDB tables to Amazon S3 and queries them using Amazon Athena 之后不到一周， Amazon Glue 团队就发布了 通过 Amazon Glue 爬网程序和 Amazon Glue ETL 作业原生读取 DynamoDB 表中数据的功能。我对此兴奋不已。代码越少意味着缺陷更少。最初的架构已经存在了至少 18 个月，只需稍加改进即可实现大幅简化。

我在之前的博文中概要介绍的 Amazon Data Pipeline 架构现已问世将近两年时间。我们曾使用数据管道将 Amazon DynamoDB 数据备份到 Amazon S3，以防发生灾难性的人为错误。但是，使用 DynamoDB 时间点恢复功能，我们便拥有了更好的原生灾难恢复机制。此外，对于数据管道，我们仍然负责着与集群本身相关的运维操作，即使这些集群只是短暂存在的。一个常见的挑战是如何让我们的集群与最新版本的 Amazon EMR 保持同步，以减少软件重大缺陷的影响。另一个不够高效的地方是需要为每个 DynamoDB 表启动一个 EMR 集群。

我决定回退一步，先列出我想在下一次迭代中拥有的功能：

• 使用 Amazon Glue 而不是 EMR 导出表。
  • Amazon Glue 提供无服务器 ETL 环境，我不必关心底层基础设施。这可以最大限度地减少操作任务，比如与 EMR 发布标签保持一致。
• 使用适用于 Amazon Glue 和 Amazon Athena 等服务的工作流程解决方案。
  • 在第一次迭代中，工作流程分布在各种服务中。除非您对整个数据管道了然于心，否则很难直观了解管道的进展情况。

• 能够选择不同导出格式。
  • 作为数据工程师，我青睐 Apache Parquet。但是，客户可能倾向于其他格式。

• 将导出的数据添加到 Athena。
  • 我发现数据越容易查询，此数据被用到的可能性就越大。

我们从全局来看这个架构：

• 我们使用 Amazon Step Functions 作为工作流程引擎。
  • 每个步骤要么是内置的 Step Functions 状态，要么是服务集成，或者是简单的用 Python 语言开发的 Amazon Lambda。例如，GlueStartJobRun 按文档中所述使用同步作业运行服务集成。
  • 我们获得整个管道的直观表示。
  • 新开发人员可以快速上手。
• Amazon CloudWatch Events 中禁止启动的事件会触发一个 Step Functions 状态机，其 JSON 格式的事件数据中包含以下内容：
  • Amazon Glue 作业名称
  • 导出目标位置
  • DynamoDB 表名称
  • 所需的读取百分比
  • Amazon Glue 爬网程序名称
• Amazon Glue 以您的首选格式将 DynamoDB 表作为 snapshots_your_table_name 导出到 S3。数据按 snapshot_timestamp 进行分区
• Amazon Glue 爬网程序在 Amazon Glue Data Catalog 中添加或更新数据的架构和分区。
• 最后，我们创建一个仅包含最新导出快照数据的 Athena 视图。

相关文章

返回上一级 云数据库文章 >>