À propos de la surveillance de tâches de streaming AWS Glue
La surveillance de votre tâche de streaming est un élément essentiel de la création de votre pipeline ETL. Outre l’interface utilisateur Spark, vous pouvez également utiliser Amazon CloudWatch pour contrôler les métriques. Vous trouverez ci-dessous une liste des métriques de streaming émises par le cadre AWS Glue. Pour obtenir la liste complète de toutes les métriques AWS Glue, consultez la section Surveillance de AWS Glue avec des métriques Amazon CloudWatch.
AWS Glue utilise un cadre de streaming structuré pour traiter les événements d’entrée. Vous pouvez soit utiliser l’API Spark directement dans votre code, soit tirer parti du ForEachBatch fourni par GlueContext, qui publie ces métriques. Pour comprendre ces métriques, nous devons d’abord comprendre windowSize.
windowSize : windowSize est l’intervalle entre les microlots que vous indiquez. Si vous spécifiez une taille de fenêtre de 60 secondes, la tâche de streaming AWS Glue attendra 60 secondes (ou plus si le lot précédent n’est pas terminé d’ici là) avant de lire les données d’un lot à partir de la source de streaming et d’appliquer les transformations fournies dans ForEachBatch. Cet intervalle est également appelé intervalle de déclenchement.
Passons en revue les métriques plus en détail pour comprendre les caractéristiques de santé et de performance.
Note
Les métriques sont émises toutes les 30 secondes. Si votre windowSize est inférieure à 30 secondes, les métriques rapportées sont une agrégation. Supposons, par exemple, que votre windowSize soit de 10 secondes et que vous traitiez régulièrement 20 enregistrements par microlot. Dans ce scénario, la valeur métrique émise pour numRecords serait de 60.
Aucune métrique n’est émise si aucune donnée n’est disponible pour elle. De plus, dans le cas de la métrique de décalage du consommateur, vous devez activer la fonctionnalité pour obtenir des métriques correspondantes.
Comment obtenir les meilleures performances
Spark essaiera de créer une tâche par partition, à partir de laquelle lire, dans le flux Amazon Kinesis. Les données de chaque partition deviennent une partition. Il répartira ensuite ces tâches entre les programmes d’exécution/travailleurs, en fonction du nombre de cœurs de chaque travailleur (le nombre de cœurs par travailleur dépend du type de travailleur que vous sélectionnez, G.025X, G.1X, etc.). Cependant, la façon dont les tâches sont réparties n’est pas déterministe. Toutes les tâches sont exécutées en parallèle sur leurs cœurs respectifs. S’il y a plus de partitions que de cœurs de programme d’exécution disponibles, les tâches sont mises en file d’attente.
Vous pouvez utiliser une combinaison des métriques ci-dessus et du nombre de partitions pour fournir à vos programmes d’exécution une charge stable avec de la place pour les pics. Il est recommandé d’exécuter quelques itérations de votre tâche afin de déterminer le nombre approximatif de travailleurs. Pour une charge de travail instable/sujette aux pics, vous pouvez faire de même en configurant l’autoscaling et le nombre maximal de travailleurs.
Définissez la windowSize conformément aux exigences du SLA de votre entreprise. Par exemple, si votre entreprise exige que les données traitées ne soient pas obsolètes de plus de 120 secondes, réglez votre windowSize sur au moins 60 secondes afin que le décalage moyen du consommateur soit inférieur à 120 secondes (voir la section sur le décalage du consommateur ci-dessus). À partir de là, en fonction du numRecords et du nombre de partitions, planifiez la capacité en DPU en veillant à ce que votre batchProcessingTimeInMs soit inférieur à 70 % de votre windowSize la plupart du temps.
Note
Les partitions chaudes peuvent provoquer une asymétrie des données, ce qui signifie que certaines partitions sont beaucoup plus grandes que les autres. Certaines tâches exécutées en parallèle peuvent donc prendre plus de temps, ce qui peut entraîner des ralentissements. Par conséquent, le lot suivant ne pourra pas démarrer tant que toutes les tâches du précédent ne seront pas terminées, ce qui aura un impact sur le batchProcessingTimeInMillis et le décalage maximal.
