AWS 数据分析与数据湖 - Athena、Glue、Lake Formation、Redshift 的集成生态系统
梳理 AWS 由 Athena、Glue、Lake Formation、Redshift、Amazon Quick（原 Amazon QuickSight）构成的集成数据分析栈的组成，并结合与 Azure Synapse Analytics / Microsoft Fabric 及 GCP BigQuery 的具体差异，解析选型的着眼点。
数据分析基础设施所需的「集成」含义
现代数据分析基础设施仅靠单一查询引擎无法完成。需要能够以一致的体验构建和运维数据收集、编目、转换、存储、查询、可视化和访问控制这一系列流水线。AWS 在提供构成这一流水线的各专业服务的同时，构建了它们紧密协作的集成生态系统。用 Athena 执行即席查询，用 Glue 进行数据 ETL，用 Lake Formation 统一管理访问控制，用 Redshift 执行大规模分析，用 Amazon Quick 的 BI 功能（Quick Sight，原 Amazon QuickSight）进行可视化。各服务独立演进，同时以 S3 为数据湖核心进行集成，这正是 AWS 数据分析战略的核心。
以 S3 为中心的数据湖架构
AWS 数据分析生态系统的中心是 S3。S3 作为数据湖的存储层，可以无差别地存储结构化数据、半结构化数据和非结构化数据。支持 Parquet、ORC、Avro、JSON、CSV 等多种格式。成本优化可以使用 S3 Intelligent-Tiering，但前提是在存储时指定 Intelligent-Tiering 存储类，或通过生命周期配置迁移现有对象，并不会仅因为数据放入 S3 就自动应用。此外，它会按对象收取监控和自动化费用，小于 128 KB 的对象不在生命周期迁移的范围内，即使手动迁移也始终按频繁访问层的费率计费（截至 2026 年 8 月，官方文档所述条件）。Glue Data Catalog 是管理 S3 上数据元数据的目录服务，可被 Athena、Redshift Spectrum、EMR 作为共用目录引用。Lake Formation 是构建在 Glue Data Catalog 之上的访问控制层，统一管理表级、列级和行级的细粒度访问权限。这种「S3 + Glue Data Catalog + Lake Formation」三层结构构成了 AWS 数据湖的基础。将数据汇聚到 S3，用目录管理元数据，用 Lake Formation 管控访问权限，这种明确的职责分离在大规模环境中实现了有效治理。这一三层结构如今仍是有效的基础，但在其之上又叠加了「湖仓一体」层，这是当前一代的形态（截至 2026 年 8 月）。Amazon SageMaker 的湖仓架构使 S3 数据湖和 Redshift 数据仓库可以通过同一个目录来访问，并通过遵循 Apache Iceberg 开放标准，让包括 Athena 和 Redshift Spectrum 在内的 Iceberg 兼容引擎引用同一份数据。查询执行时的权限检查由 Lake Formation 负责，Iceberg REST API 接口作为 Glue Data Catalog 的一部分提供，因此现有的「S3 + 目录 + Lake Formation」资产可以直接沿用。以表格式为前提的存储有 Amazon S3 Tables，可在表桶中将表创建为 S3 的一等资源，由 S3 自动处理 Iceberg 元数据维护、压缩（compaction）以及旧快照的过期。此外，来自运营数据库和业务应用的数据摄取可通过 zero-ETL 集成近实时完成，自行搭建 ETL 流水线的前提也在逐渐弱化。新建设计时，先决定是从把文件放入原生 S3 并用 Athena 读取的形式起步，还是从一开始就以表格式为前提，可以减少后续的返工。
Athena 与 Redshift - 两种查询引擎的选用
AWS 提供 Athena 和 Redshift 两种数据分析查询引擎选择。Athena 是直接对 S3 上的数据执行 SQL 查询的无服务器服务。无需基础设施预置，按扫描数据量计费，最适合即席查询和数据探索。Redshift 是 PB 级数据仓库，可对大量数据高速执行复杂分析查询。Redshift Serverless 也实现了免预置使用，但本质上面向大规模常态化分析工作负载。通过 Redshift Spectrum，可从 Redshift 集群直接查询 S3 上的数据，实现热数据放在 Redshift、冷数据放在 S3 的混合架构。通过这两种引擎的灵活选用，可根据工作负载特性实现最优性价比。
与 GCP BigQuery 的对比
GCP 的 BigQuery 是作为无服务器数据仓库被广泛使用的服务。存储与计算分离、基于 Slot 的自动扩缩、在 SQL 中训练 ML 模型（BigQuery ML）等，作为单一服务的完成度极高。BigQuery 的优势在于「一个服务能做很多事」。AWS 的方式是将 Athena、Redshift、Glue、Lake Formation 作为独立服务提供，根据组织需求进行组合。两者的差异并非优劣，而是体现在计费模式和配置粒度上。BigQuery 的计算费用有两种模式可选：按查询处理的字节数计费的「按需」模式，以及以 Slot（虚拟 CPU）为单位预留处理能力的「容量」模式（截至 2026 年 8 月，官方价格页面所述）。AWS 侧同样的角色分散在多个服务中，因此需要按工作负载选用计费模式各不相同的引擎：就地扫描 S3 上数据的 Athena 按扫描数据量计费，Redshift Serverless 按处理量以 RPU 计费，预置型 Redshift 则按节点运行时长计费。选型的着眼点在于运维方针的差异：是希望集中到一个服务来统一运维和计费，还是希望按工作负载分别选择引擎和计费模式进行优化。
与 Azure 分析服务（Synapse Analytics 与 Microsoft Fabric）的对比
Azure Synapse Analytics 是将数据仓库、数据湖、数据集成和 BI 整合到一个工作区的服务。通过 Synapse Studio 统一开发环境，可一站式操作 SQL 池（数据仓库）、Spark 池（大数据处理）、Data Explorer（日志分析）和流水线（ETL）。把握官方文档中可以确认的具体差异，会让对比更容易（截至 2026 年 8 月）。Synapse SQL 有两种资源模型：预先预留资源的专用（dedicated）SQL 池，以及无需预留即可查询存储上文件的无服务器 SQL 池；流水线使用与 Azure Data Factory 相同的数据集成引擎，可连接 90 多种数据源。Data Explorer 在文档中定位为预览。此外，Microsoft 在 Synapse 之外还提供 Microsoft Fabric，这是一个以 SaaS 形式提供的分析平台，它以 OneLake 这一单一逻辑数据湖（构建在 Azure Data Lake Storage Gen2 之上）作为整个租户的共用存储，其数据仓库在分离计算与存储的同时，以开放的 Delta Lake 格式原生保存数据。使用 OneLake 快捷方式，可以不复制而直接引用 Amazon S3 或 Google Cloud Storage 上的数据，治理则由 Microsoft Purview 承担。与 AWS 相比的结构性差异在于，AWS 以 S3 这一通用对象存储作为共用的存放位置并在其上组合专业服务，而 Fabric 则让各工作负载共享平台方提供的 OneLake。与其问哪一方更优，不如将其视为设计出发点的差异更为务实：是希望自行设计并管控共用存储和目录，还是希望顺应平台预先提供的逻辑数据湖。
数据分析基础设施设计指南
利用 AWS 数据分析生态系统的基本方针是以 S3 为数据湖核心，根据工作负载选用查询引擎。探索性即席查询用 Athena，常态化大规模分析用 Redshift，实时流式分析用 Amazon Managed Service for Apache Flink（原 Kinesis Data Analytics），与机器学习流水线联动用 SageMaker。用 Glue 自动化数据 ETL，用 Lake Formation 实现列级访问控制，用 Amazon Quick 为业务用户构建仪表板。
总结
AWS 的数据分析生态系统是 Athena、Glue、Lake Formation、Redshift、Amazon Quick 等专业服务以 S3 为中心集成，并在其上叠加 Iceberg 兼容湖仓层的架构。GCP 的 BigQuery 将功能集中在一个服务中，并提供按需与容量两种计费模式供选择。Azure 则提供两种选择：Synapse Analytics 的统一工作区，以及以 OneLake 为共用逻辑数据湖的 SaaS 产品 Microsoft Fabric。选择数据分析基础设施时，应结合自身的运维体制，从以下着眼点进行评估：是集中到一个服务统一运维和计费，还是按工作负载分别选择引擎；是自行设计共用存储和目录，还是顺应平台的前提；以及在何处管控列级和行级的访问控制。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。