2. AWS存储与分析服务选型
在 AWS 上做数据建模与分析工程，最先遇到的不是“怎么写 SQL”，而是“数据放在哪、用什么算、谁来管权限”。AWS 把存储、计算、元数据、权限、流处理拆成了多个独立服务，每个服务只解决一类问题。选型的本质，是把业务的数据形态、延迟要求、并发规模和成本约束，映射到这些服务的核心定位上。本节先建立一张“服务定位地图”，再给出可操作的选型判断方法。
一、七个服务的核心定位
S3 是对象存储，是整个数据平台的地基。它不提供计算，只提供近乎无限的容量、11 个 9 的持久性和按量计费。数据以对象形式存放，通过前缀（prefix）模拟目录结构。S3 是所有其他服务的公共数据源和结果落点，也是数据湖的物理载体。
Glue 是无服务器数据集成与元数据服务。它包含三个关键部分：Data Catalog（统一元数据目录，表结构、分区、存储位置）、ETL 作业（基于 Spark 的 Serverless 转换）、Crawler（自动扫描 S3 推断 schema 并写入 Catalog）。Glue 的定位是“让数据可被发现、可被转换”，它本身不存储业务数据。
Athena 是基于 Trino/Presto 的交互式查询服务，直接对 S3 上的数据执行 SQL，无需加载数据。它按扫描数据量计费，适合临时分析、探索式查询和低频报表。Athena 依赖 Glue Data Catalog 获取表结构，是“数据湖上的 SQL 入口”。
Redshift 是云数据仓库，采用列式存储和 MPP（大规模并行处理）架构，数据需要先加载进集群。它适合高并发、低延迟、结构稳定的 BI 报表和复杂多表关联。Redshift Spectrum 可以外接 S3 数据，形成“热数据在仓库、冷数据在湖”的混合模式。
Kinesis 是流式数据服务，包含 Data Streams（自定义流处理）、Data Firehose（自动投递到 S3/Redshift/OpenSearch）和 Data Analytics（流上 SQL）。它解决的是“数据持续产生、需要秒级或分钟级处理”的场景，是实时链路的入口。
EMR 是托管 Hadoop/Spark 集群，提供对计算资源的完全控制。适合需要自定义 Spark 参数、使用 Hive/HBase/Presto 生态、或运行大规模批处理与机器学习特征工程的场景。EMR 比 Glue 更灵活，但也需要自己管理集群和调优。
Lake Formation 是数据湖权限治理层。它在 Glue Catalog 之上提供表级、列级、行级的细粒度访问控制，并支持跨账户共享。它不搬数据，只回答“谁能看哪张表的哪些列和行”。
二、选型判断：从数据形态到服务组合
选型可以按四个问题依次判断：数据是批还是流？查询是交互式还是高并发？数据是否已结构化？权限是否需要细粒度？下面的 SVG 用一张“数据流与选型关系图”把七个服务串起来，左侧是数据进入方式，中间是存储与元数据，右侧是消费方式，底部是治理层。
三、典型场景的服务组合
把上面的定位落到具体场景，选型会变得清晰。以下四类场景覆盖了大多数数据工程需求。
| 场景 | 数据形态 | 推荐组合 | 关键理由 |
|---|---|---|---|
| 日志探索分析 | S3 上 JSON/CSV，TB 级 | S3 + Glue Crawler + Athena | 无需加载，按扫描量付费，临时查询成本低 |
| 实时监控告警 | 持续产生的流数据 | Kinesis Data Streams + Lambda/Flink + S3 | 秒级延迟，流上计算，结果落 S3 供后续分析 |
| 企业 BI 报表 | 结构化、高并发查询 | Redshift + Glue ETL + S3 | 列式 MPP 支撑并发，Spectrum 外接冷数据 |
| 大规模特征工程 | PB 级、需自定义 Spark | EMR + S3 + Glue Catalog | 完全控制集群参数，适合复杂转换和 ML 特征 |
四、选型中的常见误区
第一个误区是“所有数据都进 Redshift”。Redshift 的存储和计算绑定，加载和扩容都有成本。如果数据只是偶尔查询，Athena 直接查 S3 更划算。判断标准是：查询频率高、并发高、延迟要求低（秒级以内）才值得进 Redshift。
第二个误区是“Glue 能替代 EMR”。Glue 的 Serverless Spark 适合中小规模、标准转换；当作业需要精细调优 executor 内存、使用自定义库、或单次处理 PB 级数据时，EMR 的灵活性和成本控制更好。两者不是替代关系，而是规模和控制力的取舍。
第三个误区是“Lake Formation 只是权限开关”。它真正的价值在于跨账户数据共享和列级/行级安全。例如，同一张订单表，财务账户只能看金额列，运营账户只能看自己区域的行，这些都可以在 Lake Formation 中集中定义，而不需要在每个查询引擎里重复配置。
五、一个可执行的选型检查清单
在实际项目中，可以用下面的清单快速过一遍，避免遗漏关键约束。清单中的参数是示例阈值，实际使用时根据业务调整。
选型检查清单（示例阈值）
1. 数据量级：< 1TB 且查询不频繁 → Athena；> 1TB 且高并发 → Redshift
2. 延迟要求：秒级 → Kinesis；分钟级 → Glue/EMR 批处理；小时级 → 任意
3. 数据格式：Parquet/ORC → 列式扫描效率高；JSON/CSV → 先 Glue 转换
4. 并发用户：< 10 → Athena；> 50 → Redshift 或 EMR + Presto
5. 权限粒度：表级 → Glue Catalog + IAM；列级/行级 → Lake Formation
6. 自定义计算：标准 SQL → Athena/Redshift；自定义 Spark → EMR
7. 成本敏感：按扫描量 → Athena；按集群时长 → Redshift/EMR
这张清单不是决策树，而是约束检查表。实际选型往往是多个服务的组合，例如“Kinesis 接入 → S3 存储 → Glue 转换 → Redshift 服务 BI → Lake Formation 治理”。理解每个服务的核心定位，就能在组合时知道谁负责什么，避免把计算压力放错层，也避免为不需要的能力付费。