在不断变化的数据管理领域中，将原始数据无缝转化为可操作的洞察对全球企业而言至关重要。应运而生的是AWS Glue，这是一款专门设计用于提取、转换和加载（ETL）操作的AWS服务。
Glue 简化了传统上复杂且耗时的 ETL 任务，通过自动化许多繁重的工作流程，抽象底层基础设施，并提供了一个直观的用户界面。
然而，和大多数云服务一样，测试、部署以及编排 Glue ETL 作业会面临若干挑战，这些挑战包括但不限于代码版本控制和依赖管理，还包括基础设施搭建和权限控制。解决这些挑战需要一个专为 AWS Glue 设计的结构严谨的 CI/CD 策略。
这篇博客文章探讨了这种策略。具体来说，我们探索了一个全面的蓝图，旨在简化和自动化AWS Glue的CI/CD工作流程，该蓝图可在 companion GitHub 仓库中找到。
该蓝图的GitHub仓库源于一个集体学习的过程，并提供了其关键概念的示例说明。我们一直将其作为基于Glue的数据湖实现的起点，加快了数据工程师的培训进程，并使与团队成员一起更容易地验证不同的部署方法。它按以下方式组织：
aws-glue-ci-cd-blueprint
├──.github/
└──**workflows/ (CI/CD 流程)**
├──infrastructure/
└──**environments/ (部署环境设置)**
└──dev/
└──prod/
└──qa/
└──staging/
└──**modules/ (可复用的基础设施模块)**
└──athena/
└──core/
└──glue/
├──**src/ (用Python编写的ETL脚本)**
├──**tests/ (Python代码的单元测试脚本)**
├──...主要的组成部分和框架有如下：
这里强调一点，理解概念比掌握工具更为重要，以便利用蓝图。例如，GitHub Actions 的代码可以轻松转换为 GitLab CI。这也适用于 Terraform 和 AWS CloudFormation，当然也适用于你选择的编程语言和 QA 工具。
开始用蓝图请看下面的图片。你会看到有两个泳道，一个泳道对应基础设施，另一个对应Python代码。我们决定分别处理这两个泳道，因为根据经验，在数据管道开发过程中，这类代码通常由不同的人或在不同的时间来处理。通常来说，在部署任何ETL任务之前，需要先准备好基础设施。
图1. AWS Glue CI/CD 蓝图的概况（图由作者提供）
自动化如今的数据团队使用不同的环境来开发、验证并交付数据流——这些环境运行在云上，依赖于许多连接的资源。没有自动化的话，复制这些资源的配置几乎是不可能做到的。也就是说，蓝图提供了关于基础设施和代码质量保证的自动化的指导。
在基础设施即代码（IaC）方面，Terraform 负责设置与数据管道相关的所有 AWS 资源——例如，S3 桶、具有最小权限的 IAM 角色、Glue 作业、工作流、填充数据目录的爬取程序，以及细粒度的 IAM 策略。
关于ETL代码、单元测试、代码格式和代码规范检查，在每次有新的提交推送到pull requests或合并到dev和main分支时都会运行，以防止影响流水线的更改。如果一切顺利，代码将被部署到相应的位置上。
在GitHub上运行的任务是通过GitHub Actions配置的。请查看aws-glue-ci-cd-blueprint/.github/workflows以获取更多详细信息；以“on-iac-”开头的文件是属于基础设施即代码（IaC）的CI/CD，而以“on-”开头的其他文件则属于Python代码的CI/CD流程。
不过，开发人员可以在本地执行Terraform、AWS CLI命令以及质量保证任务，尤其是在使用开发环境（如“部署策略”部分所述）时。
测试一下.Terraform配置会执行三种类型的检查，如果其中任何一个失败，将立即停止基础设施部署流程（参见on-iac-pr-against-dev.yaml作为参考）。
- 代码格式校验 :
terraform fmt -check - 代码准确性验证 :
terraform validate - 执行计划可行性分析 :
terraform plan
对Python代码应用了三种类型的检查，这些检查在任何失败出现时都会停止部署流水线（参见on-pr-against-dev.yaml）：
- 单元测试 ：
pytest - 代码风格审查 ：
black --check ./src ./tests - 代码风格
flake8 ./src ./tests
如下图所示，蓝图涵盖了四个环境。
图2. AWS Glue CI/CD蓝图管理的部署环境（图源：作者）
根据项目需求，视项目需求而定，使用所有这些环境可能有点过于繁琐了，不过我们建议至少要有开发和生产环境，以提供更好的开发人员和用户体验。
使用指南免责声明：首次遵循本节中的动手指南可能需要几个小时，这取决于您对这些工具的熟悉程度。花时间熟悉蓝图是值得的。几次互动后就能感受到更短的交付时间和更高的质量标准带来的好处。
概念概述之后，是时候玩转蓝图了。我们将设置 Glue 作业，将 examples/us-legislators/all/persons.json 文件从 awsglue-datasets 公共 S3 存储桶复制到您指定的私有 S3 存储桶中。在后续步骤中，Crawler 将检查指定的表并生成相应的 Data Catalog 条目。尽管工作流很简单，但已经足够用于演示。如图 3 所示，它描述了 Terraform 模块、AWS 资源及其之间的关系。
（作者供图）以下是用于展示蓝图的 Terraform 模块和 AWS 资源（图像由作者提供）
我假設一下：
- 您已经克隆了 aws-glue-ci-cd-blueprint 仓库，该仓库包含
main和dev分支。 - 您已经在本地环境中安装了 Terraform 和 AWS CLI。
- 您具有 Glue、IAM 和 S3 的管理权限；否则，您可能需要他人的帮助来继续下面的步骤。有 Athena 访问权限会更方便。
Terraform 在创建每个 AWS 资源时，都会加上 dev|qa|staging|prod 后缀，因此，所有四个部署环境可以作为一个账户搭建起来。这适合培训用途，但在实际项目中则不应这样使用，在实际项目中，至少生产环境需要单独且适当管理的账户。
现在，几个手动操作步骤……你需要一个具有以下权限策略的IAM用户。
AmazonS3FullAccessAWSKeyManagementServicePowerUserAWSGlueConsoleFullAccessIAMFullAccess- 一个自定义策略允许执行以下操作：
kms:EnableKeyRotation和kms:EnableKeyDeletion。
该用户无需控制台访问权限，因为该用户仅用于本地开发环境中的 Terraform 和 AWS CLI。为此用户创建一个密钥，并安全地保存其访问密钥的 ID 和秘密。
你也需要一个S3桶来存放Terraform的状态文件。查看infrastructure/environments/*/provider.tf文件，你会看到glue-ci-cd-terraform桶已经被配置在蓝图中，所以请更新这些文件。
另外，在 infrastructure/environments/*/variables.tf 文件里给不同的桶命名：data_bucket_name，glue_assets_bucket_name，glue_scripts_bucket_name 和 athena_query_results_bucket_name。只需给出这些名称，Terraform 会创建这些桶。
是时候展示了！请在终端中（从仓库根目录下）运行以下命令：
export AWS_ACCESS_KEY_ID=<YOUR-ACCESS-KEY-ID> # （您的访问密钥ID）
export AWS_SECRET_ACCESS_KEY=<YOUR-SECRET-ACCESS-KEY> # （您的秘密访问密钥）
export TF_VAR_aws_access_key=$AWS_ACCESS_KEY_ID # 设置 Terraform 变量
export TF_VAR_aws_secret_key=$AWS_SECRET_ACCESS_KEY # 设置 Terraform 变量
cd infrastructure/environments/dev/ # （切换到开发环境目录）
terraform init # 初始化 Terraform 配置
terraform plan # 查看 Terraform 计划执行的操作
terraform apply # 应用 Terraform 配置Terraform 是一个用于基础设施即代码 (IAC) 的工具，AWS 是 Amazon Web Services 的缩写。
大约二十个构成示例ETL管道基础设施的AWS资源在开发环境（带有dev后缀）中创建，包括S3桶、IAM策略和角色、Glue（Glue服务）作业、数据库、爬网程序和工作流。
复制ETL代码到脚本桶以完成开发人员的配置过程如下：
# 切换到上级目录
cd ../../..
# 将本地目录./src与S3存储桶<YOUR-GLUE-SCRIPTS-BUCKET>同步，包括删除S3中不再存在的文件
aws s3 sync --delete ./src s3://<YOUR-GLUE-SCRIPTS-BUCKET>然后，在AWS控制台中转到Glue工作流页面并选择glue-ci-cd-us-legislators-dev这个工作流。点击运行工作流按钮并等待大约10分钟左右直到它完成。
图4. 美国立法者的“粘合工作流”（图片由作者提供）
查看数据存储桶，找到bronze文件夹，其中存储了原始的JSON数据。还有一个silver文件夹，存储的数据是Parquet格式的——从JSON转换到Parquet是样本流程中的一个步骤。Glue工作流还包括一个爬虫，用于检查silver表并创建其相关数据目录条目。
图像 5。us_legislators表表条目，Glue爬虫自动创建的，图由作者提供。
最后一步是为CI/CD配置GitHub仓库。进入你的仓库设置页面并选择Environments。创建三个环境：quality-assurance，staging和production。为每个环境设置一个AWS_ACCOUNT_ID密钥值以及AWS_REGION和GLUE_SCRIPTS_S3_BUCKET变量。请注意，你无需在这里提供任何访问密钥或密钥值，因为GitHub操作运行器将使用特定的IAM角色，如下面所述。
检查任何 CI/CD YAML 文件，并查找 配置 AWS 凭证 步骤以确认 GitHub Action 运行器将使用 GlueCICDGitHubActionsServiceRole。此 IAM 角色在您的 AWS 账户中还没有创建，因此请创建它，并根据 在 Amazon Web Services 中配置 OpenID Connect 的说明完成设置。给它相同的权限，就像你给以前创建的 IAM 用户的一样。
完成以后，您可以根据“部署策略”部分中描述的规则，利用这些自动化和质量检查，在其余三个环境中进行操作。您也可以修改脚本，在管道中添加新的步骤。例如，在您的存储库上创建拉取请求。然后将它们合并到dev分支，之后再将dev合并到main分支，看看会发生什么。您也可以看看蓝本仓库中的一些CI/CD运行示例。
图6. 一个成功的CI/CD流水线示例（作者提供）
挑战及考虑因素尽管提供的蓝图已经提供了许多有助于简化AWS Glue CI/CD管道的资源，仍然有改进的空间。以下是我想在未来解决的主要问题：
- 支持多个开发和质量保证环境。目前，只有单一的开发环境和质量保证环境，这可能会导致大型团队中的并发问题。更好的解决方案是为每个工程师支持一个开发环境，并为每个 Pull Request 支持一个质量保证环境，例如。
- 数据质量功能。数据操作（DataOps）不仅仅是在数据上应用开发操作；在初始版本中，蓝图只是针对 Glue 数据管道的 DevOps。自动设置数据质量检查将有助于将其提升到数据操作级别。
- 集成测试。单元测试对 Python 代码很有效，但 ETL 管道通常依赖于不适合进行单元测试的 SQL 语句。添加对集成测试或系统测试的支持是合适的。
最后：
在数据管理的动态领域中，AWS Glue 在促进 ETL 过程中扮演着关键作用，使组织能够有效地利用其数据的潜力。在这次探索中，我们发现了管理 AWS Glue 作业的 CI/CD 所面临的挑战，并提出了一套全面的蓝图，以直接解决这些复杂性。
拥抱变化通常需要投入时间和精力。值得注意的是，使用说明中详细的实际操作步骤可能需要一些时间，尤其是对于新手来说。但是请放心，这个过程的成果绝对物超所值。
随着这段阅读的结束，我邀请您加入数据敏捷之旅。探索GitHub仓库页面，了解实现细节的具体内容，并根据您的项目需求灵活运用这些原则。如果有任何问题，欢迎随时联系我们。
祝您的数据项目又快又好！
共同学习，写下你的评论
评论加载中...
作者其他优质文章
