Informationen zum Überwachen von AWS Glue-Streaming-Aufträgen
Die Überwachung Ihres Streaming-Auftrags ist ein entscheidender Teil des Aufbaus Ihrer ETL-Pipeline. Neben der Spark-Benutzeroberfläche können Sie auch Amazon CloudWatch verwenden, um die Metriken zu überwachen. Im Folgenden finden Sie eine Liste der Streaming-Metriken, die vom AWS Glue-Framework ausgegeben werden. Eine vollständige Liste aller AWS Glue-Metriken finden Sie unter Überwachen von AWS Glue mit Amazon-CloudWatch-Metriken.
AWS Glue verwendet ein strukturiertes Streaming-Framework, um die Eingabeereignisse zu verarbeiten. Sie können entweder die Spark-API direkt in Ihrem Code verwenden oder den von GlueContext bereitgestellten ForEachBatch nutzen, der diese Metriken veröffentlicht. Um diese Metriken zu verstehen, müssen wir zuerst windowSize verstehen.
windowSize: windowSize ist das Micro-Batch-Intervall, das Sie angeben. Wenn Sie eine Fenstergröße von 60 Sekunden angeben, wartet der AWS Glue-Streaming-Auftrag 60 Sekunden (oder mehr, wenn der vorherige Batch bis dahin noch nicht abgeschlossen ist), bevor er Daten in einem Batch aus der Streaming-Quelle liest und die in ForEachBatch angegebenen Transformationen anwendet. Dies wird auch als Auslöser-Intervall bezeichnet.
Schauen wir uns die Metriken genauer an, um die Zustands- und Leistungsmerkmale zu verstehen.
Anmerkung
Die Metriken werden alle 30 Sekunden ausgegeben. Wenn Ihre windowSize weniger als 30 Sekunden beträgt, handelt es sich bei den gemeldeten Metriken um eine Aggregation. Nehmen wir an, Ihre windowSize beträgt 10 Sekunden und Sie verarbeiten kontinuierlich 20 Datensätze pro Micro-Batch. In diesem Szenario wäre der ausgegebene Metrikwert für numRecords 60.
Eine Metrik wird nicht ausgegeben, wenn dafür keine Daten verfügbar sind. Außerdem müssen Sie im Falle der Metrik für die Verzögerung von Verbrauchern das Feature aktivieren, um Metriken für sie zu erhalten.
So erzielen Sie die beste Leistung
Spark wird versuchen, eine zu lesende Aufgabe pro Shard im Amazon-Kinesis-Stream zu erstellen. Die Daten in jedem Shard werden zu einer Partition. Anschließend werden diese Aufgaben auf die Executors/Worker verteilt, abhängig von der Anzahl der Kerne auf jedem Worker (die Anzahl der Kerne pro Worker hängt von dem von Ihnen gewählten Worker-Typ ab, G.025X, G.1X, usw.). Es ist jedoch nicht bestimmbar, wie die Aufgaben verteilt werden. Alle Aufgaben werden parallel auf ihren jeweiligen Kernen ausgeführt. Wenn es mehr Shards als verfügbare Executor-Kerne gibt, werden die Aufgaben in eine Warteschlange gestellt.
Sie können eine Kombination aus den oben genannten Metriken und der Anzahl der Shards verwenden, um Ihre Executors für eine stabile Last mit etwas Spielraum für Spitzenlasten bereitzustellen. Es empfiehlt sich, einige Iterationen Ihres Auftrags durchzuführen, um die ungefähre Anzahl der Worker zu ermitteln. Für einen instabilen/schwankenden Workload können Sie dasselbe tun, indem Sie Auto Scaling und maximale Worker einrichten.
Stellen Sie die windowSize gemäß den SLA-Anforderungen Ihres Unternehmens ein. Wenn Ihr Unternehmen beispielsweise verlangt, dass die verarbeiteten Daten nicht älter als 120 Sekunden sein dürfen, dann setzen Sie Ihre windowSize auf mindestens 60 Sekunden, so dass die durchschnittliche Verzögerung beim Verbraucher weniger als 120 Sekunden beträgt (siehe Abschnitt über die Verzögerung beim Verbraucher oben). Planen Sie von dort aus je nach numRecords und Anzahl der Shards die Kapazität in DPUs ein und stellen Sie sicher, dass Ihre batchProcessingTimeInMs in der Regel weniger als 70 % Ihrer windowSize beträgt.
Anmerkung
Hot Shards können zu Datenverzerrungen führen, was bedeutet, dass einige Shards/Partitionen viel größer sind als andere. Dies kann dazu führen, dass einige Aufgaben, die parallel ausgeführt werden, mehr Zeit benötigen und Nachzügleraufgaben verursachen. Dies hat zur Folge, dass der nächste Batch erst dann beginnen kann, wenn alle Aufgaben des vorherigen Batches abgeschlossen sind, was sich auf die batchProcessingTimeInMillis und die maximale Verzögerung auswirkt.
