1. 课程导入与全景认知

在开始任何具体的调优动作之前，我们需要先建立一张“地图”。AWS 数据平台不是一个单一产品，而是由存储、计算、集成、分析、治理五类服务拼装出来的系统。性能问题往往不是某个服务“慢”，而是数据在服务之间流动时出现了瓶颈；成本问题也很少是单价高，而是资源规格、数据布局、查询模式三者不匹配。本课程的目标，就是让你能同时看懂这两条线，并在它们冲突时做出有依据的取舍。

一、核心服务矩阵：先分清“存、算、流、治”

把 AWS 数据服务按职责归类，可以避免“用错工具”这类最常见的性能与成本双重浪费。下面这张图给出的是本课程后续会反复引用的服务矩阵与它们之间的数据流向关系。

图中实线是数据流，虚线是治理流。请特别注意 S3 的位置：它既是数据湖的底座，也是 Athena、EMR、Redshift Spectrum 的共同数据源。这意味着 S3 上的文件格式、分区方式、文件大小，会同时影响多个引擎的扫描量和运行时长。一个典型的反例是：把大量 5MB 以下的小文件直接堆在 S3 上，Athena 每次查询都要为海量小文件付出元数据开销，EMR 的 Spark 任务也会因 task 过多而调度变慢。仅把文件合并到 128MB～512MB 区间，往往就能让同一查询的扫描字节数下降、耗时缩短，而这一步不涉及任何代码逻辑改动。

二、性能与成本的权衡：三个真实存在的冲突点

性能与成本并非总是同向。理解下面三类冲突，是后续所有优化的判断基础。

• 计算规格与利用率：把 EMR 集群从 10 台 m5.xlarge 扩到 20 台，作业时间可能减半，但成本翻倍。若该作业每天只跑一次、且 SLA 允许 2 小时内完成，则扩容带来的收益可能无法覆盖成本。正确做法是先看 CloudWatch 中集群的 CPU 与内存利用率曲线，确认瓶颈是 CPU 还是 shuffle，再决定是加节点还是调分区。
• 存储格式与扫描量：同一份 1TB 的 CSV 与 Parquet（Snappy 压缩、按日期分区），Athena 扫描计费可能相差 5～10 倍。Parquet 列式存储让查询只读取涉及的列，分区裁剪让查询只读取相关日期。这是“零逻辑改动、纯格式收益”的典型场景。
• 查询引擎与并发：Redshift 适合高并发、结构化数仓查询，按节点小时计费；Athena 适合低频、探索式查询，按扫描字节计费。把每天执行上千次的固定报表放到 Athena，可能比放在 Redshift 上更贵；反之，把偶发的临时分析放到常驻 Redshift 集群上，则是为闲置资源付费。

三、治理框架：让优化结果可观测、可归因

没有治理，优化就无法持续。治理框架在本课程中聚焦四件事：权限、加密、可观测性、成本归因。权限与加密由 Lake Formation、IAM、KMS 承担，决定数据能否被安全访问；可观测性由 CloudWatch 指标、日志与 Glue 数据质量规则承担，决定你能否看到作业的 shuffle 溢出、失败重试、数据倾斜；成本归因由标签、Cost Explorer 与预算告警承担，决定你能否把账单拆到具体项目、作业和团队。

一个可落地的成本归因示例：为每个 Glue Job 和 EMR 集群统一打上 Project、Env、Owner 三个标签，并在 Cost Explorer 中按 Project 分组查看月度趋势。若某项目成本环比上升 30%，可进一步下钻到具体作业的 DPU 小时数或 EC2 实例小时数，定位是数据量增长还是资源浪费。没有标签，账单只是一堆无法归因的数字。

四、学习路径：从“看得见”到“调得动”

本课程后续章节按“认知 → 观测 → 优化 → 治理 → 复盘”推进。你不需要一次记住所有服务，但需要建立三个习惯：第一，任何优化前先拿到基线指标（扫描字节、运行时长、DPU 小时、CPU 利用率）；第二，每次只改一个变量并记录前后对比；第三，把有效改动沉淀为可复用的配置或脚本，而不是停留在一次性的控制台操作。

接下来，我们会从 S3 数据湖的存储布局开始，逐步进入计算引擎调优、查询优化、成本监控与治理落地。每一节都会给出可观察的指标、可复现的操作和可判断的结果，帮助你把“性能与成本”从两个抽象词，变成每天都能测量的具体数字。