Amazon SAA-C03: 分析、数据湖、ML 与专用工作负载 — 学习指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

属于 AWS SAA-C03 — 完整学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

数据湖基础：Lake Formation 和 Glue Data Catalog

AWS 分析服务的重心是 AWS Glue Data Catalog——一个与 Hive Metastore 兼容的元数据存储，Athena、Redshift Spectrum、EMR 和 Glue ETL 都会使用它。所有的表定义、分区、列类型和 SerDe 配置都存储在这里，每个下游引擎都从中读取。如果两条摄取路径（例如，一个 Glue 爬网程序和一个手动的 CREATE EXTERNAL TABLE 语句）对同一个 S3 前缀的模式（schema）定义不一致，查询就会在不报错的情况下返回错误结果或直接失败。正确的模式是为每张表指定唯一的权威来源：要么由爬网程序拥有模式的所有权，要么由您的 ETL 作业通过 glueContext.write_dynamic_frame.from_catalog 写入，但若没有合并策略，绝不能两者并用。当批量 ETL、Firehose Parquet 转换和手动 DDL 都写入同一张表时，元数据目录漂移是无声的杀手。请强制每张表只有一个所有者，对流式生产者使用 Glue Schema Registry，并在由 ETL 作业拥有的表上以 LOG 模式（而不是 UPDATE_IN_DATABASE）运行爬网程序，这样它们就能发现漂移，而不会覆盖已经整理好的模式。

AWS Lake Formation 位于 Data Catalog 之上，用一个数据库风格的权限层取代了粗粒度的 IAM/S3 存储桶策略模型。您不再需要为某个前缀授予 s3:GetObject 权限，而是执行 GRANT SELECT ON customers.orders TO role/AnalystRole，当 Athena 或 Redshift Spectrum 接触底层对象时，Lake Formation 会透明地提供短期凭证。其真正的价值在于细粒度授权：列级过滤、通过数据过滤器实现的行级安全，以及可扩展到数千张表的基于标签的访问控制（LF-Tags）。一个在 customers 表中包含 PII（个人身份信息）的零售平台，可以授予分析师访问 customer_id, region, signup_date 的权限，同时阻止访问 email 和 ssn——这在查询时强制执行，无需创建大量视图。

一个受治理的数据湖的标准设置：

1. Register S3 locations with Lake Formation (removes IAMAllowedPrincipals default).
2. Create databases and let Glue crawlers populate tables.
3. Define LF-Tags (e.g., Classification=PII, Domain=Sales).
4. Grant tag-based permissions to IAM principals.
5. Point Athena/Redshift/QuickSight at the catalog — permissions flow through.

Lake Formation 蓝图是预构建的工作流模板，可将爬网程序、作业和触发器串联起来，以将数据从 JDBC 源或 S3 摄取到经过整理的数据湖中——将原本需要手动配置的数十个 Glue 资源简化为一个向导驱动的流程。

一个常见的错误是试图仅在 QuickSight 中强制执行列级限制。QuickSight 拥有与数据集绑定的行级和列级安全，但它只保护 QuickSight 这一层——任何能直接访问 Athena 或 S3 的人都可以绕过它。列级控制必须在数据层强制执行（通过 Lake Formation 授权，或在 ETL 过程中物理分离列），而 QuickSight 通过其 IAM 角色继承这种安全态势。

Athena：基于 S3 的无服务器 SQL

Athena 是一个无服务器、按查询付费的 Presto/Trino 引擎，可直接从 Amazon S3 读取数据。无需预置集群，查询前无需 ETL 步骤，空闲时无成本——您只需为扫描的数据量付费（通常为 5美元/TB）。这使得 Athena 成为对已存放在 S3 中的文件（无论是 JSON 应用程序日志、CSV 导出文件还是 Parquet 事实表）进行即席分析的标准选择。Athena 需要模式和分区布局，这些信息存储在 Glue Data Catalog 中。

由于 Athena 按扫描的 TB 数计费，存储格式对成本和延迟有巨大影响。两个关键因素是格式和分区：

• 列式存储格式（Parquet、ORC）让 Athena 能够裁剪列和行组。在 Parquet 格式上执行像 SELECT sum(amount) FROM orders WHERE region='us-east-1' 这样的查询，只会读取被引用的两列；而对于 CSV，它会读取每一行的每一个字节。
• 对高选择性列进行分区（例如，dt=2024-03-11/）能将全表扫描缩减为目标性读取。对于数 TB 的日志（CloudFront、ALB、VPC Flow Logs），这就是 0.15 美元查询和 30 美元查询之间的区别。

将原始的 JSON 或 CSV 转换为分区化、经 Snappy 压缩的 Parquet 格式，几乎总是首选的成本优化手段。结合 LIMIT 下推，Athena 能够以零基础设施满足大多数基于 S3 的分析需求。

一个将“读数”表存储为分区化 Parquet 的经济高效的模式：

CREATE EXTERNAL TABLE readings (
  station_id string,
  reading_ts timestamp,
  temp_c    double
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://weather-lake/readings/'
TBLPROPERTIES ('has_encrypted_data'='true');

SELECT station_id, AVG(temp_c) OVER (
         PARTITION BY station_id
         ORDER BY reading_ts
         ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg
FROM readings
WHERE dt = '2024-03-11';

跳过爬网程序是一个常见错误。如果没有目录条目，您要么需要手动编写 CREATE EXTERNAL TABLE DDL（随着模式演变而变得脆弱），要么使用那些会扫描每个文件的“读取时定义模式”的取巧方法。更糟糕的是，如果没有 MSCK REPAIR TABLE 或分区投影，Athena 每次查询都会扫描整个前缀。Glue 爬网程序会按计划检测新分区并原子化地更新目录。

Athena 处理加密的 S3 数据。 Athena 支持 SSE-S3、SSE-KMS 和 CSE-KMS，但前提是调用者拥有正确的 KMS 权限，并且工作组或客户端已针对所使用的加密模式进行了配置。对于 CSE-KMS，文件在上传前已在客户端加密；运行查询的 IAM 主体需要对该 CMK 拥有 kms:Decrypt 和 kms:GenerateDataKey 权限，并且密钥策略也必须授予相应权限。一个常见的失败场景是：加载了 CSE-KMS 加密的 Parquet 文件，但只授予了 Athena 角色 S3 读取权限，然后收到不透明的 AccessDenied 或 HIVE_CANNOT_OPEN_SPLIT 错误——对象本身可读，但密文无法解开。另一个常见错误是在注册表时指定了错误的加密模式（对象是用 CSE-KMS 写入的，但在表属性中指定了 SSE-KMS）；Athena 在 GetObject 期间尝试进行服务器端解密，返回的负载是原始密文，导致 Parquet 的幻数检查失败。

Athena 联合查询让您可以将 S3 数据与操作型数据存储（如 DynamoDB、RDS）进行连接，而无需移动数据。请将 Athena 用于面向读取的即席分析；使用 Glue 作业来按计划规整和塑造策展区的数据。

Glue 爬网程序、ETL 作业和作业书签

Glue 爬网程序扫描 S3 路径，推断 schema（包括从 year=2024/month=01/ 这样的目录结构中推断分区键），并在数据目录中注册或更新表。对于“我们将文件放入 S3，使其可查询”这类需求，它们是低代码的解决方案。针对一个着陆存储桶（landing bucket）安排每小时运行一次爬网程序，Athena 就能立即看到新的分区。

aws glue create-crawler \
  --name logs-crawler \
  --role AWSGlueServiceRole-Logs \
  --database-name analytics_db \
  --targets '{"S3Targets":[{"Path":"s3://acme-logs/app/"}]}' \
  --schedule "cron(0 * * * ? *)"

Glue ETL 作业（Spark、Python shell 或 Ray）负责处理转换部分。Glue 是无服务器的——您按 DPU-小时付费，最低一分钟——并且其运行时会自动扩展工作节点。主流模式是输入 CSV/JSON，输出分区化的 Parquet：

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="raw", table_name="reports_csv")
glueContext.write_dynamic_frame.from_options(
    frame=df,
    connection_type="s3",
    connection_options={"path": "s3://curated/reports/",
                        "partitionKeys": ["report_date"]},
    format="parquet",
    format_options={"compression": "snappy"})

关键的运维特性是作业书签 (job bookmark)：Glue 会持久化记录已处理过的文件或分区的状态，因此后续运行仅读取新数据。忘记启用书签意味着每次运行都会从头开始重新处理整个数据集，导致成本和运行时间线性增长，并常常产生重复的输出。书签是按作业启用的，并且必须与支持它们的源选项配对（通过 Glue DynamicFrame 读取器访问的 S3 源支持；任意的 Spark 读取则不支持）。书签要求在每个源上都有一个 transformation_ctx 参数，并用 job.init(...) / job.commit() 将代码括起来：

job = Job(glueContext)
job.init(args['JOB_NAME'], args)   # bookmark state loaded

datasource = glueContext.create_dynamic_frame.from_catalog(
    database="analytics_db",
    table_name="app_logs",
    transformation_ctx="datasource"   # required for bookmarking
)
# ... transforms ...
job.commit()                          # bookmark state persisted

对于没有业务逻辑的纯格式转换，最省力的选择通常是在原始数据上运行一个 Glue 爬网程序，再加上一个在可视化编辑器中创建的 Glue 作业（或一个 DataBrew 配方）——无需编写 Spark 代码。自定义的 EMR 集群或 Lambda 转换器会增加额外的运维开销，而 Glue 的无服务器模型则消除了这些开销。

一个典型的日常作业，负责整理 S3 数据并加载到 Redshift Serverless：

# Glue 4.0 PySpark: S3 raw -> curated -> Redshift Serverless
df = glueContext.create_dynamic_frame.from_catalog(
        database="raw", table_name="orders").toDF()
df = df.filter("order_status <> 'CANCELLED'") \
       .withColumn("order_date", to_date("order_ts"))

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame       = DynamicFrame.fromDF(df, glueContext, "out"),
    catalog_connection = "redshift-serverless-conn",
    connection_options = {"dbtable": "fact_orders", "database": "analytics"},
    redshift_tmp_dir   = "s3://stg/redshift-tmp/")

Glue 安全配置和多租户 ETL

Glue 爬网程序和作业需要具备与 Athena 相同的加密意识。Glue 安全配置 (security configurations) 是一些命名的配置包，用于指定 S3 目标、CloudWatch 日志和作业书签的加密方式——包括使用特定 CMK 的 CSE-KMS。附加了安全配置的作业会透明地解密 CSE-KMS 输入，并以同样的方式加密输出，前提是该作业的 IAM 角色对引用的密钥拥有 KMS 权限。

对于多租户 ETL——例如一个 SaaS 平台使用每个客户自己的 CMK 来处理其数据——正确的模式是为每个客户配置一个安全配置（或使用一个作业参数来选择 CMK），并配上一个限定于该 CMK 的 IAM 角色。用一个共享密钥通过单个作业处理所有客户的数据，违背了 CSE-KMS 旨在提供的隔离保证。

一个相关的准则：生产环境的分析表不应成为探索性 Glue 作业或 notebook 的直接目标。应将快照导出到 S3 的“analytics”前缀下，然后让 Athena 或 Spark 指向该副本。在实时表上运行实验性转换会带来分区级重写、书签损坏和锁争用的风险，并且会模糊运维数据和分析衍生数据之间的审计边界。

AWS Glue DataBrew

DataBrew 是 Glue 的低代码兄弟产品，专为那些不能或不应编写 Spark 代码的用户设计。它提供了一个电子表格风格的用户界面，内置了超过 250 种预构建的转换（例如，插补、PII 屏蔽、异常值分箱、日期解析）。它的差异化特性是共享配方 (shared recipes)——可以发布并在不同项目中重复应用的版本化 JSON 工件——以及数据血缘可视化 (data lineage visualization)，该功能可以追溯列从源数据集经过配方和作业到输出位置的全过程。当分析师负责转换逻辑时，选择 DataBrew；当工程师负责转换逻辑，且管道需要自定义代码、流处理或复杂连接时，选择 Glue Studio/脚本。

Amazon EMR：分布式批处理和运行时角色

Amazon EMR 是一个托管的集群平台，可运行 Spark、Hadoop、Hive、Presto、HBase 和 Flink。它的最佳应用场景是大型、可并行的批处理或交互式工作负载，这些工作负载读取 PB 级的 S3 数据集，并与另一个记录系统（通常是 Redshift）进行连接以进行数据扩充。EMR 可以运行瞬态集群（启动、执行、终止）或长期运行的集群，并可以通过实例舰队（instance fleets）混合使用按需实例、Spot 实例和预留实例。

一个典型的模式是：一个 Spark 作业从 S3 读取 Parquet，通过 UNLOAD-to-S3 从 Redshift 拉取维度表，在多个执行器（executor）之间进行连接，然后将扩充后的输出写回 S3：

# Spark on EMR: enrich S3 events with Redshift dimensions
df_events = spark.read.parquet("s3://raw/events/dt=2024-11-01/")
df_dims = (spark.read
    .format("io.github.spark_redshift_community.spark.redshift")
    .option("url", "jdbc:redshift://cluster:5439/analytics")
    .option("dbtable", "public.customer_dim")
    .option("tempdir", "s3://staging/redshift-unload/")
    .load())

enriched = df_events.join(df_dims, "customer_id", "left")
enriched.write.mode("overwrite").partitionBy("region").parquet("s3://curated/events/")

EMR 在此场景中胜出，因为 Spark 将连接操作分布到数十个节点上，并且通过 S3 进行数据中转避免了单线程的 JDBC 瓶颈。一个常见的陷阱是，只要需要查询 S3 数据就条件反射地选择 EMR。对于几十或几百 GB 数据的即席 SQL 查询，配置和调优一个 Spark 集群纯粹是运维开销——包括集群规模调整、YARN 配置、自动扩展、日志轮转、打补丁等。只有当数据量、自定义代码需求或执行引擎的灵活性证明其合理性时，EMR 才物有所值。

EMR 运行时角色 (runtime roles)。 历史上，集群上的所有步骤都继承 EC2 实例配置文件——即附加到底层节点的一个角色——这意味着共享集群的每个团队都拥有所有团队所需权限的并集。运行时角色解决了这个问题：当用户提交一个步骤时，他们传递 --execution-role-arn 参数，EMR 会在该步骤的持续时间内代入该角色。团队 A 可以被限制在 s3://team-a/*，团队 B 可以被限制在 s3://team-b/*。实例配置文件变成了一个轻量的引导角色，只用于获取集群工件。

运行时角色也是阻止 IMDS 访问的机制。启用后（EMR 6.7+ 及以上版本，在 YARN 上运行 Spark/Hive），用户代码无法访问实例元数据服务——包括 IMDSv2——因为平台会拦截这些调用。这关闭了一个权限提升的路径，否则作业本可以调用 http://169.254.169.254/latest/api/token 并代入功能强大的 EC2 实例配置文件。

aws emr create-cluster \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --security-configuration team-isolation-sc \
  --service-role EMR_DefaultRole \
  --ec2-attributes InstanceProfile=EMR_EC2_MinimalRole,...

aws emr add-steps --cluster-id j-XXXX \
  --steps Type=Spark,Name="TeamA-ETL",\
ActionOnFailure=CONTINUE,\
Jar=command-runner.jar,\
Args=[spark-submit,s3://team-a/jobs/etl.py] \
  --execution-role-arn arn:aws:iam::111122223333:role/TeamA-EMRRuntime

安全配置是启用运行时角色强制执行和 IMDS 阻止的关键。没有它，那种认为 EMR 工作负载“自动使用最小权限角色”的假设是错误的——默认情况下，它们共享实例配置文件，并且用户代码可以访问 IMDS。

Amazon Redshift 与 Redshift ML

Redshift 是一个列式 MPP 数据仓库，适用于需要亚秒级仪表板响应、对数十亿行数据进行复杂连接以及在并发 BI 用户下保持一致延迟的持续性分析工作负载。RA3 节点将计算与托管存储分离；Redshift Serverless 按 RPU-秒计费，基于配置的基础容量，在负载下自动扩展，并在空闲时暂停，从而消除了传统的集群规模规划问题。

Redshift 以两种丰富模式参与分析管道：

• 作为源端： EMR 上的 Spark 通过 UNLOAD-to-S3 拉取维度数据，或者 Glue 通过 Redshift Data API 读取数据。
• 作为目标端： Firehose 或 Glue 作业将丰富后的数据 COPY 进去。

Redshift Spectrum 扩展了这一能力，它允许 Redshift SQL 通过 Glue Data Catalog 直接查询 S3——这与 Athena 使用的是同一个目录——这也是湖仓一体（lake-house）模式得以实现的原因。当您已经有一个 Redshift 集群，并希望将仓库中的事实数据与 S3 中的冷历史数据进行连接而无需移动数据时，这是理想的选择。

批量加载使用 COPY 命令从 S3 进行，该过程会在计算节点间并行化；文件应被分割成大致相等的数据块（切片数量的倍数）以实现并行处理：

COPY events FROM 's3://acme-lake/events/dt=2024-05-12/'
IAM_ROLE 'arn:aws:iam::111:role/RedshiftLoader'
FORMAT AS PARQUET;

流式摄取通常通过 Firehose（缓冲的 COPY）进行，以实现零运维交付。

Redshift ML 允许 SQL 用户通过 CREATE MODEL 创建、训练和调用模型：

CREATE MODEL churn_predictor
FROM (SELECT tenure, plan, monthly_spend, churned FROM customers)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'redshift-ml-artifacts');

SELECT customer_id, predict_churn(tenure, plan, monthly_spend)
FROM customers_current;

在底层，Redshift 将训练集导出到 S3，调用 SageMaker Autopilot（或像 XGBoost 这样的指定算法），然后将编译好的模型导入数据库内进行推理。当分析师已经习惯于在 SQL 环境中工作时，这个功能非常强大，但它不能替代一个完整的 ML 平台：到 S3 的数据移动和 SageMaker 的训练计算是单独计费的，大型训练集可能会产生显著的出口流量和 Autopilot 运行时费用，并且没有内置的工作流来支持特征存储、实验跟踪或 A/B 部署。应将 Redshift ML 视为在 Redshift 数据上实现民主化推理的工具，而不是通用的训练平台。

在 Athena 和 Redshift 之间进行选择

流式摄取：Kinesis Data Streams、Firehose 和 MSK

这三个 AWS 流处理服务解决的问题有重叠，但提供的保障有本质区别：

Kinesis Data Streams 使用分片（或按需模式）；具有相同分区键的记录会落入同一个分片并按顺序被消费。消费者可以使用经典的 GetRecords 或增强型扇出（Enhanced Fan-Out，为每个消费者提供专用的 2 MB/s 带宽）。附加为事件源的 Lambda 函数会按分片批量调用，从而保留顺序。当需要处理非简单的下游逻辑、当多个独立消费者必须重放历史数据、或者当点击流数据量巨大时——例如，一个每天产生 30 TB 数据的网站，数据会流经 KDS 进入 Firehose，最终存入 S3 以供 Athena/Spectrum 分析——这便是正确的选择。

Kinesis Data Firehose 是一种“发后即忘”的托管交付服务：它按大小或时间（例如，5 MB / 300 秒）进行缓冲，可选择性地调用 Lambda 进行转换，可选择性地使用 Glue 表的 schema 将 JSON 转换为 Parquet/ORC，然后写入 S3、Redshift（通过 S3 + COPY）、OpenSearch 或 Splunk。在 Firehose 中开启 Parquet 转换是低成本地将流数据以查询优化格式落地的方法，无需下游的 Glue 作业：

Firehose delivery stream → 
  Record transformation: Lambda (optional, for enrichment) →
  Format conversion: enabled, schema from Glue table "events.raw" →
  Destination: s3://lake/events/ partitioned by !{timestamp:yyyy/MM/dd}

Firehose 没有端到端的顺序保证，不能支持多个可重放的消费者，并且其目标端是固定的。如果需求中提到“按顺序处理每条记录”或“多个独立消费者”，那么选择 Firehose 在这两点上都是错误的。同样，期望单靠 Firehose 来执行复杂的转换也是一个陷阱——它唯一的转换钩子是针对每个缓冲批次调用的 Lambda。任何涉及外部数据丰富、多记录聚合或条件路由的逻辑都必须在该 Lambda 中实现，或者上移到 Managed Service for Apache Flink 中处理。

Amazon MSK 是托管的 Apache Kafka。当您已经有 Kafka 生产者/消费者，需要 Kafka 特有的功能（如 compacted topics、事务、Kafka Streams、Connect），或者需要的吞吐量超出了基于分片的 Kinesis 所能轻松提供的范围时，应选择它。

使用 SQS 或 EventBridge 作为分析摄取路径是一个错误：SQS 在单个流中不保证顺序且缺乏重放功能；EventBridge 专为事件路由优化，而非持续的数 MB/s 的数据摄取。

实时搜索：KDS + Firehose + OpenSearch + QuickSight

本地部署的 Elasticsearch+Logstash 技术栈的典型替代方案是：

Firehose 缓冲流记录并将其直接交付到 OpenSearch 域，同时处理重试、S3 备份和可选的 Lambda 转换。OpenSearch Dashboards 内嵌于域中且免费，适合需要监控实时流的操作人员。QuickSight 为面向业务的分析提供了补充——它可以直接查询 Athena、Redshift、RDS 和 OpenSearch，其 SPICE 内存中列式引擎可缓存处理过的数据集，以实现亚秒级的仪表板性能。

一个典型的分工是：OpenSearch Dashboards 用于操作人员；QuickSight 用于管理层，他们消费来自 Athena/Glue 数据湖的聚合、精选数据集。两者都必须被授予 IAM 读取权限，并在适用情况下，授予对保护底层存储的 CMK 的 KMS Decrypt 权限——否则可视化层将渲染空面板，并在查询日志中深藏权限错误。

QuickSight 访问控制

QuickSight 首先构建数据集（逻辑查询加上计算字段和行级安全性），然后基于数据集创建分析，最后发布仪表板（只读的可共享视图）。访问控制是分层的，必须在正确的层级应用。一个常见的陷阱是在仪表板级别授予过宽的访问权限——例如，当只有一部分人应该看到底层数据时，却将其共享给整个组织范围的群组。

在 QuickSight 中实现最小权限原则意味着：

• 仅与需要它的用户/群组共享数据集。
• 通过一个按用户名或群组筛选行的权限数据集来应用行级安全性。
• 应用列级安全性以隐藏敏感字段。
• 与特定用户、群组或（对于嵌入式分析）命名空间共享仪表板。

将仪表板设为公开或在账户范围内共享，会绕过数据集级别控制的初衷，因为仪表板的查看者会继承对可视化数据的读取权限，无论底层源的权限如何。请记住，QuickSight 的列级安全性只保护 QuickSight 这一层；任何拥有直接 Athena 或 S3 访问权限的人都可以绕过它，因此敏感的控制应放在 Lake Formation 或 ETL 中，而不仅仅是在 QuickSight 中。

QuickSight 的角色——Admin、Author、Reader——控制用户可以做什么，这与控制他们可以看到什么的共享权限是不同的。Reader 的每次会话成本低于 Author 许可证，因此查看者群体应默认为 Reader，并且访问权限应通过群组成员资格授予，而不是单独分配。

用于图工作负载的 Amazon Neptune

Neptune 是一个托管的图数据库，支持属性图模型（Gremlin、openCypher）和 RDF（SPARQL）。它专为高度连接的数据而构建——例如社交关系、欺诈团伙、知识图谱、推荐引擎——在这些场景中，关系型数据库中的递归连接会变得不切实际。一个包含用户、关注、点赞和帖子的社交平台，可以很自然地映射为顶点和边，而 Neptune 可以在毫秒内响应多跳遍历（例如“喜欢 X 的好友的好友”）。

Neptune Streams 会暴露一个有序的、基于时间的日志，记录对图的每一次变更。轮询该流的 Lambda 或应用程序可以对变化做出反应——例如重新计算推荐、更新搜索索引、触发欺诈警报——而无需定制的变更数据捕获（CDC）管道。要在 Aurora 或 DynamoDB 上实现这一点，需要应用级别的图遍历外加独立的 CDC 设施。当问题陈述同时包含“分析关系”和“监控变化”时，带有 Streams 的 Neptune 是最直接的匹配方案。

SageMaker：端到端的自定义机器学习

SageMaker 提供完整的生命周期管理：Studio 笔记本、托管的训练作业（支持 Spot 实例）、Model Registry、实时和无服务器终端节点、批量转换以及用于 MLOps 的 Pipelines。一个典型的流程是：将训练数据上传到 S3，启动一个指定内置算法或自定义容器的训练作业，然后 SageMaker 会预置临时实例，将日志流式传输到 CloudWatch，并将模型构件写回 S3。部署只需一个 API 调用：

from sagemaker.estimator import Estimator
est = Estimator(image_uri=xgb_image, role=role,
                instance_count=2, instance_type="ml.m5.xlarge",
                output_path="s3://models/xgb/")
est.fit({"train": "s3://data/train/", "validation": "s3://data/val/"})
predictor = est.deploy(initial_instance_count=1, instance_type="ml.m5.large")

无需管理 Kubernetes、GPU 驱动程序或模型服务器。对于需求是“训练并暴露一个模型”的团队来说，与自己动手搭建基于 ECS/EC2 的推理服务相比，SageMaker 几乎总是开销最小的答案。

SageMaker Savings Plans 承诺在 1 年或 3 年内，对符合条件的组件（Studio、训练、处理、实时推理）进行每小时一定金额的消费，从而获得最高 64% 的按需折扣。它们在实例系列、大小、区域和组件之间具有灵活性——但不包括 Ground Truth、存储或数据传输的费用。当基线机器学习用量可预测时，应使用 Savings Plans；将突发性的训练任务留在 Spot 实例上运行，以实现复合节省。

托管式 AI 服务与自定义 ML 对比

Amazon Rekognition（图像/视频：对象和场景检测、人脸分析、内容审核）、Textract（OCR 加表单和表格提取）和 Comprehend（NLP：实体识别、情感分析、PII 检测、自定义分类）通过简单的 API 提供了预训练模型。Comprehend 的 DetectEntities API 会返回带类型的实体，其中包括 COMMERCIAL_ITEM 类别——这非常适合从食谱文本中提取配料名称并将其输入 DynamoDB 进行查找，整个过程无需训练数据、无需托管，并采用按请求付费的定价模式：

aws comprehend detect-entities \
    --language-code en \
    --text "Combine 2 cups flour, 1 tsp salt, and 3 eggs..."

一个常见的失败模式是过度设计——在托管服务已经能以极低的运营成本满足需求的情况下，仍然启动 SageMaker 训练任务、使用 Ground Truth 标记数据并托管端点。只有当针对特定领域数据的准确性显著更高时，或者当所需实体类型与托管服务的模式不匹配时（即便如此，Comprehend 自定义分类/实体识别仍比直接使用 SageMaker 更便宜），或者当延迟和数据驻留限制要求使用私有模型时，自定义 ML 才是合理的选择。

HPC 存储与网络：FSx for Lustre 和 EFA

紧密耦合的 HPC 工作负载——例如计算流体动力学 (CFD)、分子动力学、地震成像、大规模训练——有两个不可或缺的要求：极低的节点间通信延迟和高吞吐量的共享存储。

Elastic Fabric Adapter (EFA) 是一种网络接口，可用于特定的 EC2 实例系列（hpc7a、hpc6id、c6in、p4d/p5 等）。它使用操作系统旁路 (OS-bypass) 技术的 Libfabric 库绕过内核 TCP/IP 协议栈，使 MPI 和 NCCL 能够在数百个节点间实现微秒级延迟。EFA 要求实例位于同一可用区内，并且为了获得最大带宽，应位于集群置放群组 (cluster placement group) 中。

FSx for Lustre 是一个托管的并行文件系统，可提供数百 GB/s 的吞吐量和亚毫秒级延迟。它与 S3 原生集成：一个 FSx 文件系统可以链接到一个 S3 存储桶，使 S3 对象能以 POSIX 文件的形式呈现，而写入 Lustre 的结果也可以导出回 S3。持久性 SSD (Persistent SSD) 部署类型适合长期存在的暂存空间；暂存 2 (Scratch2) 类型更便宜，适合临时性作业数据。

用于 HPC 的错误模式是使用 EFS。EFS 基于 NFS，针对大量小型客户端执行通用文件 I/O 进行了优化；它无法维持一个 500 节点 MPI 作业所需的聚合吞吐量或元数据 IOPS，并且其多可用区设计也增加了延迟。使用标准的 ENA 而不是 EFA 会将 MPI 的延迟限制在 TCP 的水平，这会将重度依赖 allreduce 操作的运行时间增加数倍。正确的组合是在集群置放群组中使用启用了 EFA 的实例，并挂载 FSx for Lustre，同时将 S3 作为链接到该文件系统的持久冷存储。

← 数据库与缓存 · 所有领域 · 应用集成、消息传递与流处理 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →