# 关于监控 Amazon Glue 流式传输作业
<a name="glue-streaming-monitoring"></a>

监控流式处理作业是构建 ETL 管道的关键部分。除了使用 Spark UI 之外，您还可以使用 Amazon CloudWatch 来监控各项指标。以下是 Amazon Glue 框架发出的流式处理指标列表。有关所有 Amazon Glue 指标的完整列表，请参阅[使用 Amazon CloudWatch 指标监控 Amazon Glue](https://docs.amazonaws.cn/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html)。

Amazon Glue 使用结构化流式处理框架处理输入事件。您可以直接在代码中使用 Spark API，也可以利用 `GlueContext` 提供的 `ForEachBatch` 发布这些指标。要了解这些指标，我们需要先了解 `windowSize`。

**windowSize**：`windowSize` 是您提供的微批次间隔。如果指定的窗口大小为 60 秒，则 Amazon Glue 流式处理作业将等待 60 秒（如果届时上一批次还未完成，则会等待更长时间），然后才会从流式处理数据源批量读取数据，并应用 `ForEachBatch` 中提供的转换。这也称为触发间隔。

我们详细看一下这些指标，以了解运行状况和性能特征。

**注意**  
这些指标每 30 秒发出一次。如果 `windowSize` 少于 30 秒，则报告的指标就是一个聚合。例如，假设 `windowSize` 为 10 秒，并且对于每个微批次，您稳定处理 20 条记录。在这种情况下，为 numRecords 发出的指标值为 60。  
如果没有可用的数据，则不会发出指标。此外，对于使用者滞后指标，必须启用该功能才能获取相关指标。

## 如何获得最佳性能
<a name="glue-streaming-monitoring-performance"></a>

Spark 会尝试为每个分片创建一个任务，以便从 Amazon Kinesis 流中读取数据。每个分片中的数据成为一个分区。然后，它将根据每个工作线程上的内核数量（每个工作线程的内核数量取决于您选择的工作线程类型 `G.025X`、`G.1X` 等），在执行程序/工作线程中分配这些任务。但任务的分配方式是不确定的。所有任务均在各自的内核上并行执行。如果分片数量多于可用的执行程序内核数量，任务就会排队。

您可以使用上述指标和分片数量的组合，为执行程序配置稳定的负载，并留出一定的突发空间。建议您运行几次作业迭代，以确定工作线程的大致数量。对于不稳定/突发的工作负载，您也可以通过设置自动扩缩和最大工作线程来实现。

根据业务的 SLA 要求设置 `windowSize`。例如，如果您的业务要求处理后的数据不能滞后超过 120 秒，那么将 `windowSize` 设置为至少 60 秒，这样使用者的平均滞后就会少于 120 秒（参阅上文有关使用者滞后的部分）。从那里开始，根据分片的 `numRecords` 和数量，规划 DPU 中的容量，确保 `batchProcessingTimeInMs` 在大部分时间里都低于 70% 的 `windowSize`。

**注意**  
热分片会导致数据倾斜，这意味着某些分片/分区比其他分片/分区大得多。这可能会导致一些并行运行的任务耗时更长，造成任务滞后。因此，在上一批任务全部完成之前，下一批任务无法启动，这将影响 `batchProcessingTimeInMillis` 和最大滞后。