Q22 — AWS SAA-C03 第17章

第 22/89 题 | ← 返回第17章

Q1322. 一家公司有一个应用程序，可以扫描数百万台联网设备是否存在安全威胁，并将扫描日志推送到 Amazon S3 存储桶。每周共生成 70 GB 的数据，该公司需要存储 3 年的数据用于历史报告。该公司必须以最短的时间处理、聚合和丰富来自 Amazon S3 的数据，方法是执行复杂的分析查询和连接操作。聚合后的数据集会在 Amazon QuickSight 控制面板上进行可视化。解决方案架构师应该推荐什么方案来满足这些要求?

正确答案: A. 在 AWS Glue 中创建并运行 ETL 作业，以处理来自 Amazon S3 的数据并将其加载到 Amazon Redshift 中。在 Amazon Redshift 上执行聚合查询。

解析

为了在最短时间内处理、汇总和丰富每周 70 GB 的安全扫描日志（保留 3 年），并利用复杂的分析查询，最佳解决方案是:正确答案:A. 在 AWS Glue 中创建并运行 ETL 作业，以处理来自 Amazon S3 的数据并将其加载到 Amazon Redshift 中。在 Amazon Redshift 上执行聚合查询。为什么这是最佳解决方案?1. Amazon Redshift 针对复杂分析查询进行了优化 Redshift 是一个列式、PB 级数据仓库，专为快速聚合、连接和复杂分析而设计。它采用大规模并行处理（MPP）将查询分布到多个节点上，从而减少执行时间。最适合:大规模聚合（例如，GROUP BY、JOIN、WINDOW 函数）。历史数据报告（3 年数据 = 约 10 TB，可在 Redshift 中管理）。与 Amazon QuickSight 集成，用于仪表盘。2. AWS Glue 为结构化/半结构化数据提供高效的 ETL 服务 AWS Glue 是一种无服务器 ETL 服务，它:抓取 S3 数据以推断模式（或使用自定义模式）。对数据进行转换（例如，过滤、富集、归一化）。将其加载到 Redshift（或其他目标平台，如 S3、RDS 等）。最适合:实现从 S3 到 Redshift 的数据管道自动化。处理增量负载（例如，每日/每周更新）。3. QuickSight 与 Redshift 的集成Amazon QuickSight 可原生连接到 Redshift，实现快速仪表板，无需再次移动数据。Redshift 的列式存储和物化视图提高了可视化的查询性能。为什么其他方案并非最佳选择?B. 使用 Lambda + DynamoDB 进行聚合DynamoDB 是一个 NoSQL 数据库，它并非针对复杂的分析查询进行优化。局限性:不支持原生 JOIN 或 GROUP BY 操作。大规模分析成本高昂（扫描操作成本很高）。不适用于 3 年历史数据（10 TB 以上）。C. 使用 Lambda + Aurora MySQL 进行聚合Aurora MySQL 是一个事务型（OLTP）数据库，并非针对大规模分析而优化。局限性:对 10 TB 数据进行复杂连接/聚合时性能较差。与 Redshift 相比，用于分析工作负载的成本更高。不适用于列式存储（Redshift 更适合扫描）。D. 使用 AWS Glue + Athena 进行直接 S3 查询。部分正确，但并非最佳选择:重复的复杂聚合操作（Athena 每次都会扫描原始 S3 数据，导致成本高昂且延迟高）。没有物化视图（与 Redshift 不同，Redshift 可以缓存结果）。最适合:临时查询，而不是高性能仪表板。使用场景:如果公司只需要偶尔查询，Athena 就足够了，但对于每日/每周的聚合，Redshift 更好。针对此场景的最佳架构数据摄取:扫描日志存储在 Amazon S3（低成本、可扩展的对象存储）中。ETL:AWS Glue 处理和转换数据（例如，解析 JSON、过滤和丰富数据）。加载:Glue 将转换后的数据加载到 Amazon Redshift（针对分析进行了优化）。查询和可视化:Redshift 运行聚合操作，QuickSight 构建仪表板。成本与性能考量对于大规模分析而言，Redshift 比 DynamoDB/Aurora 更具成本效益。Athena 对于不频繁的查询更便宜，但对于重复扫描则很昂贵（10 TB 的数据?多次查询 = 高成本）。Glue ETL 是无服务器的，因此成本会随着使用量而增加。结论最佳解决方案是:使用（AWS Glue + Redshift）对 3 年的安全日志进行快速、可扩展的分析。其他选项要么缺乏分析性能（B、C），要么重复查询成本太高（D）。