3. 性能优化基础
性能优化不是“凭感觉调参”，而是一条从指标定义到观测工具、再到基准测试与瓶颈定位的闭环。在 AWS 数据平台上，这条闭环尤其重要：数据管道、查询引擎、存储层和网络层彼此耦合，任何一个环节的延迟都可能被上游放大。本节先把“看什么、用什么看、怎么比、怎么找”四件事讲清楚。
一、先定义指标：延迟、吞吐、并发与资源利用率
性能指标必须可量化、可对比、可归因。数据平台最常用的四类指标如下：
- 延迟（Latency）：一次请求从发出到返回的耗时。要区分 P50、P90、P99，平均值会掩盖长尾。例如 Athena 查询 P50 为 2.1s、P99 为 18s，说明少数复杂查询拖慢了整体体验。
- 吞吐（Throughput）：单位时间处理的数据量或请求数，如 Glue 作业每秒写入 S3 的 MB 数、Kinesis 每秒记录数。
- 并发（Concurrency）：同时执行的查询、作业或分片数。并发升高时延迟通常非线性上升，需找到拐点。
- 资源利用率：CPU、内存、磁盘 IOPS、网络带宽、DPU/ACU 等。利用率不是越低越好，而是要与延迟目标匹配。
定义指标时要写清观测对象、时间窗口、聚合方式。例如“Redshift 集群 5 分钟平均 CPU 利用率”与“单条查询的 P99 执行时间”是两个不同层面的指标，不能混用。建议为每个关键链路设定目标值（SLO），如“报表查询 P95 < 5s”“每日 ETL 在 06:00 前完成”，后续所有优化都围绕这些目标判断是否达标。
二、监控工具：CloudWatch 看资源与趋势，X-Ray 看调用链
CloudWatch 是 AWS 的指标与日志中枢。它擅长回答“资源层面发生了什么”：
- 指标（Metrics）：如
AWS/Glue的glue.driver.aggregate.bytesRead、AWS/Redshift的CPUUtilization、AWS/Lambda的Duration与ConcurrentExecutions。 - 日志（Logs）：通过 CloudWatch Logs Insights 对 Glue、Lambda、EMR 日志做聚合查询，定位报错与慢步骤。
- 告警（Alarms）：对 P99 延迟、队列积压、错误率设置阈值，触发 SNS 通知或自动扩缩容。
X-Ray 则回答“一次请求在分布式链路中慢在哪”。它通过 trace 把 API Gateway、Lambda、DynamoDB、S3 等调用串成时间线，展示每个子段的耗时与状态。典型用法是：当用户反馈“报表打开慢”，先用 CloudWatch 确认整体延迟升高，再用 X-Ray 找到具体是哪个下游调用（如某个 Lambda 冷启动或某次 S3 列出操作）贡献了主要耗时。
三、基准测试：建立可复现的对比基线
没有基线的优化是盲目的。基准测试的核心是固定输入、固定环境、重复测量、记录分布。以 Glue 作业为例，一个可复现的基准测试应包含：
- 固定数据集：同一份 Parquet 数据、相同分区结构、相同文件数量与大小。
- 固定资源配置：Worker 类型（如 G.1X）、Worker 数量、并发度、Spark 参数。
- 固定测量方式：记录作业总时长、各 stage 耗时、shuffle 读写量、输入输出字节数。
- 重复运行：至少 3 次，取中位数并记录波动范围，排除冷启动与缓存干扰。
例如，某 Glue 作业在 10 个 G.1X Worker 下运行 3 次，总时长分别为 412s、398s、405s，中位数 405s；将 Worker 提升到 20 个后，中位数降至 236s，但 shuffle 读写量未明显下降，说明瓶颈在并行度而非单节点算力。这样的对比才有决策价值。
基准测试还要区分冷启动与热运行。Lambda、Athena 等无服务器服务首次调用可能包含初始化开销，若只测一次，容易把冷启动误判为常态性能。
四、瓶颈定位思路：从症状到根因的收敛路径
瓶颈定位建议遵循“先分层、再分位、后归因”的顺序：
- 分层：把链路拆成计算、存储、网络、元数据四层，逐层看指标。计算层看 CPU/内存/GC，存储层看 IOPS/吞吐/延迟，网络层看带宽与跨区流量，元数据层看 Glue Catalog、Hive Metastore 调用。
- 分位：不要只看平均值。P99 高而 P50 正常，通常是少数大查询、热点分区或长尾任务导致。
- 归因：结合 X-Ray trace、Spark UI stage 详情、Redshift 的
STL_QUERY/SVL_QUERY_SUMMARY，找到具体算子、具体分区或具体 SQL。
常见瓶颈模式与判断依据：
| 症状 | 可能瓶颈 | 验证方式 |
|---|---|---|
| 查询 P99 高、P50 正常 | 数据倾斜或热点分区 | 查看分区大小分布、Spark stage 的 task 耗时差异 |
| 吞吐上不去、CPU 不高 | 存储 IOPS 或网络带宽受限 | 看 S3 请求延迟、EBS 吞吐、跨 AZ 流量 |
| 并发升高后延迟陡增 | 连接池、队列或元数据锁竞争 | 看 JDBC 连接数、Glue Catalog 调用延迟 |
| 作业总时长波动大 | 冷启动、资源争抢或数据量变化 | 对比多次运行的输入字节数与启动阶段耗时 |
定位到瓶颈后，优化动作才有方向：数据倾斜用加盐或预聚合，IOPS 不足用更大卷或更多分片，元数据竞争用缓存或减少小文件。每次优化后都要回到同一基准测试，确认指标改善且没有引入新的长尾。
把上述四步串起来，就形成了可重复的性能优化工作流：先用 CloudWatch 和 X-Ray 建立可观测性，再用基准测试固定对比条件，最后按“分层—分位—归因”的顺序定位瓶颈，优化后回到同一基准复测。这样每一次调整都有数据支撑，而不是依赖经验猜测。