Amazon DEA-C01: 数据查询和分析 — 学习指南

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

属于 Amazon Data Engineer Associate DEA-C01 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

此领域涵盖设计、调优和运维 AWS 服务，以支持对大型数据集的分析查询和商业智能 (BI)。它专注于 Athena、Redshift、OpenSearch 和 QuickSight 之间经济高效、高性能的查询模式，以及它们如何与 S3、Glue 和事务性存储协同工作。要精通此领域，需要权衡存储格式、分区、计算类型和数据位置，以最大限度地减少扫描字节数和网络倾斜，同时提供低延迟的洞察。

Amazon Athena 查询优化

Athena 的定价基于扫描的字节数，因此物理数据布局和元数据是主要的调优手段。使用带有压缩的列式格式（Parquet 或 ORC）（Parquet 使用 Snappy，Zlib/ORC 选项）来减少数据大小和 CPU 消耗。按高基数、查询过滤的列（如日期、地区）对数据进行分区，并在 Glue Data Catalog 中注册分区。典型模式：

将数据写入 S3 的路径，如 s3://bucket/events/date=2026-08-02/，并使用 Glue 爬网程序或 MSCK REPAIR TABLE 来填充分区。
使用

undefined

来强制执行列式压缩。

通过引用分区键的 WHERE 子句使用投影和分区裁剪，以避免扫描不需要的分区。

当查询需要与事务性存储进行连接时，使用 Athena 联合查询（Lambda 连接器）来执行与 RDS、DynamoDB 或 Redshift 的跨源连接。连接器被部署为 Lambda 函数并在 Athena 中注册为数据源；例如，控制台流程：Athena > 数据源 > 连接器 > 新建。决策标准：

当 RDS/DynamoDB 中的数据量适中，或当将一个小的维度表连接到一个大的 S3 数据集时，使用联合查询。
对于重复的重度连接，将操作数据提取并物化到 S3（Parquet 格式），将连接成本转移到单个 ETL 过程，并使用 Athena 进行重复读取。

Amazon Redshift 查询调优和分布

Redshift 的性能取决于分配样式和排序键，以最大限度地减少数据移动并启用区域映射。使用以下决策点选择 DIST 样式：

DISTKEY (KEY)：当在连接大型表时使用高基数的连接键时非常有用；如果两个表共享相同的 DISTKEY，则可以避免数据重分布。
ALL：将一个小的维度表复制到所有节点，以避免连接时的网络洗牌。
EVEN：对于不可预测的工作负载或没有好的键存在时，这是默认选项；可以避免热点。
AUTO：如果您没有明确的指导，让 Redshift 根据表大小和工作负载进行选择。

在用于范围过滤器或 ORDER BY 的列上定义 SORTKEY，以启用区域映射并减少磁盘读取。常用操作命令：

undefined

定期使用 VACUUM 和 ANALYZE：

undefined

；监控 SVV_TABLE_INFO 和 STL_QUERY 的倾斜和分布指标。 Redshift Spectrum 允许您通过 Glue Data Catalog 查询 S3 外部表。使用以下命令创建外部 schema：

undefined

Spectrum 与原生 Redshift 的决策标准：

对于存储在 S3 中的不常查询的大型冷数据或分层数据架构，使用 Spectrum。
将热点、频繁连接的数据集保留在 Redshift 内部以获得高性能；当与 Spectrum 连接时，选择 DISTKEY 以将连接键并置，或使用重分布来最小化网络 I/O。

用于日志分析的 Amazon OpenSearch Service

OpenSearch 针对摄取和快速的即席日志分析进行了优化；其索引和集群配置决定了吞吐量和成本。索引设计和生命周期：

使用像 logs-YYYY.MM.DD 这样的索引模式，并使用索引模板来设置 index.number_of_shards（小索引：1个分片；大索引：多个分片，每个大小约 10–50 GB）和 index.number_of_replicas 以实现可用性。
配置索引生命周期策略 (ILM)，将索引在热、温、冷和 UltraWarm 层之间转换以控制成本；UltraWarm 降低了存储历史数据的热节点存储成本。分片和副本会影响查询和索引性能：
更多的分片可以增加并行度，但也会增加开销；根据堆内存和 CPU 调整每个节点的分片数。
副本可以提高读取吞吐量和容错能力；根据查询并发性和 SLA 设置副本数。操作命令和控制台模式：
使用 OpenSearch Dev Tools（或 curl）来 PUT 索引模板和 ILM 策略，并使用集群健康 API 进行监控。分配节点属性并使用分片分配感知来防止热点。决策标准：
当对历史日志的查询延迟要求可以容忍更高的读取延迟以换取更低的存储成本时，选择 UltraWarm。
将最近的索引保留在热节点上，以支持快速聚合和仪表板。

用于 BI 和可视化的 QuickSight

QuickSight 提供快速仪表板，具有两种主要的提取模式：SPICE（内存中）和直接查询。SPICE 为仪表板提供亚秒级性能，适用于重复读取；直接 SQL 查询（到 Athena、Redshift、RDS）更适用于非常大的数据集或频繁变化的数据。关键配置和最佳实践：

在控制台中创建数据集：新数据集 > 选择源（Athena/Redshift/RDS/OpenSearch）> 导入到 SPICE 或使用直接查询。
对于每日/近实时需求，使用计划的 SPICE 刷新；通过时间戳分区配置增量刷新以限制数据移动。安全与治理：
通过 QuickSight 用户/组映射和数据集规则实施行级安全。
对于跨账户数据访问，部署 IAM 角色和基于资源的权限，以便 QuickSight 可以代入。决策标准：
对于具有许多并发查看者和可预测刷新窗口的仪表板，使用 SPICE。
当数据新鲜度至关重要或 SPICE 容量受限时，使用直接查询；结合计算字段和参数以获得交互式用户体验。

常见陷阱与决策标准

Athena 按扫描的数据量计费 — 务必根据查询谓词进行分区，并以列式格式 (Parquet/ORC) 存储，同时使用压缩 (Snappy/Zlib) 以减少扫描的字节数。
在低基数列上使用 Redshift DISTKEY 会导致数据倾斜 — 应为 DISTKEY 选择高基数的连接键，或对小型维度表使用 DISTSTYLE ALL。
Redshift Spectrum 外部表需要 Glue Data Catalog — 确保目标区域已启用 Glue，并且 IAM 角色允许 Redshift 访问该数据目录。
OpenSearch 分片数量和大小的设置错误 — 避免过多的小分片；将分片大小设置为几十 GB，并使用 ILM 将旧索引移动到 UltraWarm 以节省成本。
批量加载后忘记在 Redshift 上运行 RUN ANALYZE/VACUUM — 应定时执行 ANALYZE 和 VACUUM 以刷新统计信息并回收磁盘空间，从而优化查询计划。
QuickSight SPICE 容量溢出和数据陈旧 — 规划 SPICE 容量，使用增量刷新，或针对实时需求切换到直接查询。

实践问题：用例场景

Acme Retail 需要每日 BI 报告，该报告需结合 Amazon RDS 中的交易订单、S3 中的点击流事件以及 DynamoDB 中的用户个人资料，同时有成本限制，并要求针对近期数据的仪表盘刷新延迟在亚分钟级别。

将 S3 中的点击流数据转换为按日期分区的 Parquet 格式，使用 Snappy 进行压缩，并通过 Crawler 在 AWS Glue 中注册元数据。
使用 Athena 对 S3 进行即席查询，并部署用于 RDS 和 DynamoDB 的联合查询连接器以执行小维度连接；如果查询重复执行，则将频繁的连接结果物化为 Parquet。
为繁重的分析型连接预置 Redshift：将聚合后的快照加载到 Redshift 中，在高基数的 customer_id 上设置 DISTKEY，并在 order_date 上定义 SORTKEY；使用 Spectrum 处理 S3 中的冷历史数据。
使用每日索引模式将应用程序日志摄取到 OpenSearch；应用 ILM 策略将近期索引保留在热节点上，并将较旧的索引移动到 UltraWarm 以节省成本。
构建 QuickSight 仪表盘：将近期的聚合数据导入 SPICE，并设置计划的增量刷新，以实现亚分钟级的感知响应速度；并使用直接查询获取始终最新的指标。

理由：此方法通过分区和列式格式最大限度地降低了 Athena 的扫描成本，通过适当的分布键和排序键减少了 Redshift 的网络数据重排 (shuffle)，使用 Spectrum 避免了在 Redshift 中存储冷数据，应用 OpenSearch ILM 优化了存储成本，并利用 SPICE 实现响应迅速的仪表盘，同时通过直接查询保持关键指标的实时性。

← 数据编排和工作流管理 · 所有领域 · 数据安全、治理和合规 →

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