2. AWS DataOps技术栈概览

在 DataOps 的持续交付体系中，AWS 提供的服务并不是孤立存在的，而是围绕“代码托管 → 构建 → 部署 → 编排 → 基础设施即代码”形成一条完整的交付链。理解每个服务在数据交付中的定位，比记住它们的名字更重要。本节将逐一梳理 CodeCommit、CodeBuild、CodeDeploy、CodePipeline、CloudFormation、CDK 与 Step Functions 的核心用途，并说明它们如何协同支撑数据管道、ETL 作业与数据基础设施的自动化发布。

代码托管与构建：CodeCommit 与 CodeBuild

CodeCommit 是一项托管的 Git 仓库服务，用于存放数据管道的源代码、SQL 脚本、Glue 作业、Lambda 函数以及基础设施模板。它的价值在于为数据团队提供版本控制能力：每一次对 ETL 逻辑的修改、每一个数据模型的变更，都可以通过提交记录追溯。在 DataOps 中，CodeCommit 通常作为整条流水线的起点，任何一次 push 都可能触发后续的构建与部署。

CodeBuild 是托管的持续集成服务，负责在隔离环境中执行构建命令。对于数据项目，CodeBuild 的典型任务包括：安装依赖、运行单元测试、执行 SQL lint、打包 Glue 脚本、构建 Lambda 部署包，以及生成 CloudFormation 模板的产物。它通过 buildspec.yml 定义构建阶段，例如：

version: 0.2
phases:
  install:
    runtime-versions:
      python: 3.11
  build:
    commands:
      - pip install -r requirements.txt
      - pytest tests/
      - aws cloudformation package --template template.yaml --s3-bucket my-artifacts --output-template packaged.yaml
artifacts:
  files:
    - packaged.yaml
    - scripts/**/*

这段配置说明：CodeBuild 先安装 Python 依赖，再运行测试，最后将 CloudFormation 模板打包并输出为构建产物。构建产物会被后续的部署阶段消费，因此 CodeBuild 在数据交付中承担“质量门禁”和“产物生成”的双重角色。

部署与编排：CodeDeploy 与 CodePipeline

CodeDeploy 负责将构建产物部署到目标计算资源。在数据场景中，它常用于将 Lambda 函数、ECS 任务或 EC2 上的数据处理程序更新到新版本。CodeDeploy 支持蓝绿部署和滚动部署，这对于数据管道尤为重要：当 ETL 逻辑变更时，可以先在小流量环境验证，再逐步切换，避免一次性影响全部数据生产。

CodePipeline 是整条交付链的编排器。它把 CodeCommit、CodeBuild、CodeDeploy 以及自定义动作串联成阶段化的流水线。一个典型的数据管道流水线可能包含四个阶段：Source（拉取代码）、Build（构建与测试）、Deploy（部署到测试环境）、Approve（人工审批后部署到生产）。CodePipeline 的价值在于把分散的服务统一为可观测、可重试、可审计的发布流程。

基础设施即代码：CloudFormation 与 CDK

数据平台的基础设施——包括 S3 存储桶、Glue 数据库、Kinesis 流、Redshift 集群、IAM 角色——如果靠手工创建，将无法保证环境一致性。CloudFormation 通过声明式模板解决这一问题：模板描述“最终状态”，CloudFormation 负责创建、更新或删除资源，并在失败时自动回滚。对于数据团队，这意味着开发、测试、生产三套环境可以用同一份模板派生，减少“在我机器上能跑”的问题。

AWS CDK 则进一步降低了 IaC 的门槛。它允许用 TypeScript、Python、Java 等编程语言定义基础设施，再通过 cdk synth 生成 CloudFormation 模板。CDK 的优势在于抽象和复用：可以封装一个“数据管道构造器”，把 Glue 作业、Step Functions 状态机和告警规则打包成可复用的组件。例如，用 Python CDK 定义一个 Glue 作业：

from aws_cdk import aws_glue as glue, Stack

class DataPipelineStack(Stack):
    def __init__(self, scope, id, **kwargs):
        super().__init__(scope, id, **kwargs)
        glue.CfnJob(self, "TransformJob",
            name="daily-transform",
            role="arn:aws:iam::123456789012:role/GlueRole",
            command=glue.CfnJob.JobCommandProperty(
                name="glueetl",
                script_location="s3://my-scripts/transform.py"
            ),
            glue_version="4.0",
            worker_type="G.1X",
            number_of_workers=5
        )

这段 CDK 代码最终会生成对应的 CloudFormation 资源。它的教学意义在于：数据工程师可以用熟悉的编程方式管理基础设施，同时保留 CloudFormation 的可靠性和可审计性。

工作流编排：Step Functions

数据交付不仅仅是部署代码，还包括运行时的任务编排。Step Functions 以状态机的方式定义数据工作流，支持顺序执行、并行分支、条件判断、错误重试和等待。一个典型的每日 ETL 流程可能包含：从 S3 读取原始数据 → 运行 Glue 清洗作业 → 检查数据质量 → 若通过则加载到 Redshift，否则发送告警。Step Functions 把这些步骤可视化，并记录每次执行的状态，便于排查和重跑。

与 CodePipeline 的区别在于：CodePipeline 面向“代码发布”的持续交付，而 Step Functions 面向“数据任务”的运行时编排。两者可以集成——例如 CodePipeline 部署完新的 Glue 脚本后，触发 Step Functions 执行一次验证运行。

服务协同与选型建议

在实际项目中，这些服务通常按以下方式组合：CodeCommit 存放所有数据代码和模板；CodeBuild 运行测试并打包；CloudFormation 或 CDK 定义基础设施；CodeDeploy 发布计算资源；CodePipeline 串联发布流程；Step Functions 负责运行时的数据工作流编排。选型时需注意：如果团队没有容器或 EC2 部署需求，CodeDeploy 可能不是必需的；如果基础设施简单，CloudFormation 直接写 YAML 即可，不必引入 CDK；如果数据任务只是简单的定时 Lambda，Step Functions 也可能过度设计。

关键参数与观察点

在配置这些服务时，有几个参数直接影响数据交付的稳定性。CodeBuild 的 timeout 默认是 60 分钟，对于大型数据测试可能需要调高；CodePipeline 的阶段转换需要配置 IAM 角色，确保有权限读取 CodeCommit 和写入 CloudFormation；CloudFormation 的 OnFailure 行为应设置为 ROLLBACK，避免半成品栈残留；Step Functions 的 Retry 和 Catch 字段需要根据数据任务的实际失败模式配置，例如对超时错误重试 3 次，对数据质量错误直接跳转到告警分支。

观察交付是否成功，不能只看流水线是否变绿。还应检查：CloudFormation 栈的事件列表是否有 CREATE_FAILED 或 UPDATE_ROLLBACK_COMPLETE；CodeBuild 的日志中测试通过率是否达标；Step Functions 的执行历史中每个状态是否按预期流转。这些观察点构成了 DataOps 的可观测性基础。

小结

AWS DataOps 技术栈的核心逻辑是：用 CodeCommit 管代码，用 CodeBuild 管质量，用 CloudFormation/CDK 管基础设施，用 CodeDeploy 管发布，用 CodePipeline 管流程，用 Step Functions 管运行时。每个服务解决一个特定问题，组合起来才能支撑数据管道的持续交付。理解它们之间的边界与衔接点，是设计可靠数据交付体系的前提。