2. AWS数据平台架构与可观测性挑战

要谈可观测性，先要把“被观测的对象”画清楚。AWS 数据平台很少是单一服务，而是由存储、计算、编排、消息、权限与网络共同拼装出的数据流系统。典型组合是：Kinesis Data Streams 或 MSK 承接实时事件，Lambda 做轻量转换，Glue 做批式 ETL 与元数据编目，EMR 跑 Spark 重计算，S3 作为数据湖底座，Redshift 承担数仓查询，Step Functions 或 Airflow（MWAA）负责编排。可观测性难点恰恰来自这些组件“各管一段”：每个服务都有自己的日志、指标和追踪，但数据从一端流到另一端时，责任边界和观测边界并不重合。

典型数据流与观测点分布

下面这张图把一条“流批一体”的典型链路展开，标出每一跳的观测载体与最容易出现的盲区。注意图中“观测点”指的是该环节原生可采集的信号，而不是已经配置好的告警。

批流一体带来的观测语义冲突

批处理与流处理的“健康”定义不同。批任务关心的是“这一轮是否在 SLA 前完成、产出分区是否完整”，流任务关心的是“消费延迟是否持续增长、是否有数据积压”。当两者共用同一套 S3 数据湖时，问题就出现了：Glue 作业写入的分区，可能被下游 Redshift Spectrum 或 EMR 读取；如果 Glue 作业失败但未触发告警，下游看到的只是“查询结果变少”，而不是“上游失败”。这就是典型的观测语义断层——上游的失败信号没有传递到下游的消费侧。

更隐蔽的是“静默失败”。例如 Lambda 函数因为下游 S3 权限被撤销而持续报错，但 Kinesis 的 IteratorAge 仍在增长，看起来只是“消费慢”；又比如 Glue 作业成功结束，但实际写入的记录数为 0，JobRunState 显示 SUCCEEDED，而数据质量指标无人校验。可观测性工程在这里要做的，不是增加更多仪表盘，而是建立跨服务的因果链：把“上游事件数 → 中间处理数 → 下游落库数”串成可对比的计数关系。

无服务器与多账户的观测盲区

无服务器组件（Lambda、Glue、Step Functions）把基础设施隐藏了，也把部分观测入口隐藏了。Lambda 的日志默认进 CloudWatch Logs，但每个函数的日志组是独立的；Step Functions 的执行历史保留时间有限（标准工作流 90 天，Express 工作流更短），如果不在执行时把关键状态导出，事后很难复盘。Glue 的 Spark UI 只在作业运行期间可访问，作业结束后日志中的 Stage 信息需要主动解析才能还原数据倾斜。

多账户场景进一步放大了难度。生产账户、数据账户、分析账户各自拥有独立的 CloudWatch 命名空间和 S3 桶。一个跨账户的 Glue 作业读取数据账户的 S3，写入分析账户的 Redshift，它的日志分散在三个账户中。如果没有集中化的日志归档（例如通过 CloudWatch Logs 订阅过滤到中央日志账户的 S3，再用 Athena 查询），排障时需要在多个控制台之间切换，时间成本极高。

可观测性难点归纳