3. AWS数据平台核心服务验收要点

数据平台验收不是把控制台里能点的按钮点一遍，而是围绕“数据能否按约定被可靠地写入、加工、查询、流动和授权”建立可复现的验证证据。S3、Glue、Redshift、Kinesis、Lake Formation 这五类服务分别承担存储底座、批处理编排、数仓计算、流式接入和权限治理职责，验收时应先明确每项服务的功能边界，再为关键路径设定可量化的性能基线。以下内容中的参数、阈值和结果均为教学示例或合理假设，不代表任何真实生产环境的实测结论。

一、S3：存储底座的功能与性能验收

S3 的验收重点不是“桶能创建”，而是版本控制、生命周期、加密、事件通知、跨区域复制和访问日志是否按设计生效。功能验收可先验证桶策略与 Block Public Access 的组合效果：创建一个测试桶，开启版本控制与 SSE-KMS 加密，上传一个 1 MB 对象后覆盖同名对象，确认版本列表中出现两个版本，且删除标记可被恢复。随后配置一条生命周期规则，例如“前缀 tmp/ 下对象在 30 天后转 IA、90 天后过期删除”，用 aws s3api get-bucket-lifecycle-configuration 核对规则是否落盘。

性能基线建议围绕小文件与大文件分别建立。示例目标可设为：单线程上传 1000 个 4 KB 小文件，平均每秒完成 80～120 个；单对象 1 GB 上传在 100 Mbps 带宽下耗时约 80～100 秒。若使用 aws s3 cp 多线程传输，可观察 --cli-read-timeout 与并发数对吞吐的影响。验收时记录 P50、P95 延迟和失败重试次数，而不是只看一次成功上传。事件通知可用 s3:ObjectCreated:* 触发 Lambda 或 SQS，确认消息在 1～3 秒内到达，作为后续 Glue 或 Kinesis 联动的输入信号。

二、Glue：批处理作业的功能与性能验收

Glue 验收要覆盖 Crawler、Data Catalog、Job 书签和作业参数四部分。功能上，先让 Crawler 抓取一个包含 dt=2025-01-01/ 分区的 S3 前缀，确认 Catalog 中表的分区列被正确识别为 dt，且分区元数据可被 Athena 或 Redshift Spectrum 查询。随后运行一个 Spark Job，读取该表并写入 Parquet 目标表，开启 Job Bookmark，重复运行两次，第二次应只处理新增文件。若第二次仍全量扫描，说明书签未生效或输入路径未按分区组织。

性能基线建议以“单位 DPU 处理量”和“作业总时长”双指标记录。示例：10 个 DPU 处理 20 GB Parquet 数据，做一次过滤加聚合，目标耗时 8～12 分钟；若超过 20 分钟，应检查是否发生小文件过多、数据倾斜或 shuffle 分区过大。可在 Job 参数中设置 --conf spark.sql.shuffle.partitions=200，并观察 CloudWatch 中 glue.driver.aggregate.numCompletedTasks 与 executor 数量。验收时还要确认失败重试次数、超时时间和并发上限是否符合设计，避免作业互相抢占 DPU。

三、Redshift：数仓查询与加载性能验收

Redshift 的功能验收包括集群可连接、数据库与 Schema 创建、COPY 加载、WLM 队列和快照恢复。加载验收可用一条 COPY 命令从 S3 导入 100 GB 示例数据，观察 STL_LOAD_ERRORS 是否为空，并用 SELECT COUNT(*) 核对行数。分布键选择直接影响性能：若按 user_id 分布，而查询常按 dt 过滤，则可能出现数据倾斜。可用 SVV_TABLE_INFO 查看 skew_rows，示例目标为倾斜率低于 1.5。

查询性能基线建议选取 5～10 条代表性 SQL，记录冷启动与热缓存下的 P50、P95。示例目标：对 1 亿行事实表做按天聚合，P95 不超过 3 秒；若超过 8 秒，应检查排序键、zone map 和 WLM 队列并发。WLM 可配置为“ETL 队列 4 槽、BI 队列 2 槽”，验收时同时发起 6 个查询，确认 ETL 与 BI 互不阻塞。快照恢复也要验证：手动创建快照后恢复到新集群，确认表结构与数据行数一致。

四、Kinesis 与 Lake Formation：流接入与权限治理验收

Kinesis 验收关注分片吞吐、保留周期和消费者延迟。示例：创建 4 个分片的 Data Stream，保留 24 小时，用 PutRecord 持续写入 1000 条/秒，观察 PutRecord.Success 与 PutRecord.Latency，目标 P95 低于 120 ms。消费者侧用 KCL 或 Lambda 读取，检查 GetRecords.IteratorAgeMilliseconds 是否持续增长；若迭代器年龄超过 60 秒，说明消费速度跟不上写入。还要验证分片扩缩容后数据不丢失，以及保留周期到期后旧记录被清理。

Lake Formation 的验收核心是“权限是否按最小化原则生效”。先注册 S3 数据位置，再用 LF-Tags 给表打上 domain=finance、sensitivity=high，然后给分析角色授予仅 domain=finance 且 sensitivity=low 的 SELECT 权限。验收时用该角色查询，确认只能看到允许列，未授权列返回权限错误；再撤销授权，确认 30 秒内查询被拒绝。跨账户共享场景还要验证资源链接和接受方 Catalog 可见性。若权限未生效，优先检查 IAM 与 Lake Formation 的双层授权是否冲突，以及数据位置是否已注册。

五、验收闭环与常见失败判断

把五类服务串起来看，一条典型链路是：Kinesis 接收实时事件，S3 落地原始数据，Glue 按分区清洗并写入 Parquet，Redshift 或 Spectrum 对外提供查询，Lake Formation 控制谁能看到哪些列。验收时应至少跑通一条端到端路径，并记录每一跳的延迟与失败重试。常见失败包括：S3 事件通知未触发导致 Glue 未启动；Glue 书签未生效导致重复处理；Redshift COPY 因列数不匹配进入 STL_LOAD_ERRORS；Kinesis 分片数不足导致写入限流；Lake Formation 未注册数据位置导致查询报 AccessDenied。对每个失败点，都应能定位到具体服务、具体配置项和具体日志，而不是只记录“验收不通过”。

最终交付的验收结论应区分“功能通过”和“性能达标”两类。功能通过表示行为符合设计，性能达标表示在约定数据量与并发下满足基线。两者都通过，才能认为该服务具备进入生产交付的条件。