Corriger les temps d'initialisation élevés dans les pipelines

Les pipelines peuvent contenir de nombreux datasets avec de nombreux flux pour les maintenir à jour. Les pipelines gèrent automatiquement les mises à jour et les clusters pour une mise à jour efficace. Cependant, la gestion d'un grand nombre de flux implique une certaine complexité, ce qui peut parfois entraîner des initialisations plus longues que prévu, voire des surcoûts de gestion pendant le traitement.

Si vous rencontrez des retards en attendant l'initialisation des pipelines Trigger, par exemple des temps d'initialisation supérieurs à cinq minutes, envisagez de diviser le traitement en plusieurs pipelines, même lorsque les datasets utilisent les mêmes données source.

remarque

Les pipelines déclenchés effectuent les étapes d'initialisation chaque fois qu'ils sont déclenchés. Les pipelines continus n'effectuent les étapes d'initialisation que lorsqu'ils sont arrêtés et redémarrés. Cette section est la plus utile pour l'optimisation de l'initialisation des pipelines déclenchés.

Quand envisager de fractionner un pipeline

Il existe plusieurs cas où le fractionnement d'un pipeline peut être avantageux pour des raisons de performance.

• Les phases INITIALIZING et SETTING_UP_TABLES prennent plus de temps que vous ne le souhaitez, ce qui affecte votre temps de pipeline global. Si cela dépasse 5 minutes, cela est souvent amélioré en divisant votre pipeline.
• Le Driver qui gère le cluster peut devenir un goulot d'étranglement lors de l'exécution de nombreuses tables de streaming (plus de 30-40) au sein d'un même pipeline. Si votre Driver ne répond pas, la durée de vos queries en streaming augmente, ce qui impacte la durée totale de votre mise à jour.
• Un pipeline Trigger comportant plusieurs Stream de tables de streaming pourrait ne pas être en mesure d'effectuer toutes les mises à jour de Stream parallélisables en parallèle.

Détails sur les problèmes de performance

Cette section décrit certains des problèmes de performance qui peuvent survenir lorsque de nombreuses tables et flux se trouvent dans une seule pipeline.

Goulots d'étranglement dans les phases INITIALIZING et SETTING_UP_TABLES

Les phases initiales de l'exécution peuvent constituer un goulot d'étranglement en termes de performances, selon la complexité du pipeline.

Phase d'initialisation

Au cours de cette phase, des plans logiques sont créés, y compris des plans pour la construction du graphe de dépendances et la détermination de l'ordre des mises à jour de la table.

Phase SETTING_UP_TABLES

Pendant cette phase, les processus suivants sont exécutés, basés sur les plans créés lors de la phase précédente :

• Validation et résolution du schéma pour toutes les tables définies dans le pipeline.
• Construire le graphe de dépendance et déterminer l'ordre d'exécution des tables.
• Vérifiez si chaque dataset est actif dans le pipeline ou s'il est nouveau depuis la dernière mise à jour.
• Créez des tables de streaming lors de la première mise à jour et, pour les vues matérialisées, créez des vues temporaires ou des tables de sauvegarde requises lors de chaque mise à jour du pipeline.

Pourquoi INITIALIZING et SETTING_UP_TABLES peuvent prendre plus de temps

Les pipelines volumineux avec de nombreux flux pour de nombreux datasets peuvent prendre plus de temps pour plusieurs raisons :

• Pour les pipelines avec de nombreux flux et des dépendances complexes, ces phases peuvent prendre plus de temps en raison du volume de travail à effectuer.
• Les Transformations complexes, y compris les Transformations Auto CDC, peuvent entraîner un goulot d'étranglement des performances en raison des Opérations requises pour matérialiser les tables en fonction des Transformations définies.
• Il existe également des scénarios où un nombre important de flux peut entraîner des lenteurs, même si ces flux ne font pas partie d'une mise à jour. À titre d'exemple, considérons un pipeline qui comporte plus de 700 flux, dont moins de 50 sont mis à jour pour chaque trigger, sur la base d'une configuration. Dans cet exemple, chaque exécution doit passer par certaines des étapes pour l'ensemble des 700 tables, obtenir les DataFrames, puis sélectionner celles à exécuter.

Goulots d'étranglement dans le Driver

Le driver gère les mises à jour lors de l'exécution. Il doit exécuter une logique pour chaque table, afin de décider quelles instances d'un cluster doivent gérer chaque flux. Lorsque vous exécutez plusieurs tables de streaming (plus de 30 à 40) au sein d'un seul pipeline, le Driver peut devenir un goulot d'étranglement pour les ressources CPU, car il gère le travail au sein du cluster.

Le driver peut également rencontrer des problèmes de mémoire. Cela peut se produire plus souvent lorsque le nombre de flux parallèles est de 30 ou plus. Il n'y a pas un nombre spécifique de flux ou de datasets qui peuvent causer des problèmes de mémoire du driver, mais cela dépend de la complexité des tâches exécutées en parallèle.

Les flux de streaming peuvent s'exécuter en parallèle, mais cela nécessite que le Driver utilise de la mémoire et du CPU pour tous les flux simultanément. Dans un pipeline à déclenchement, le Driver pourrait traiter un sous-ensemble de Stream en parallèle à la fois, pour éviter les contraintes de mémoire et de CPU.

Dans tous ces cas, le fractionnement des pipelines afin d'obtenir un ensemble optimal de flux dans chacun peut accélérer le temps d'initialisation et de traitement.

Compromis avec le fractionnement des pipelines

Lorsque tous vos flux se trouvent au sein du même pipeline, ce pipeline gère les dépendances pour vous. Lorsqu’il y a plusieurs pipelines, vous devez gérer les dépendances entre les pipelines.

• Dépendances : Vous pourriez avoir un pipeline en aval qui dépend de plusieurs pipelines en amont (au lieu d'un seul). Par exemple, si vous avez trois pipelines, pipeline_A, pipeline_B et pipeline_C, et que pipeline_C dépend à la fois de pipeline_A et de pipeline_B, vous souhaitez que pipeline_C ne soit mis à jour qu'après que pipeline_A et pipeline_B aient tous deux terminé leurs mises à jour respectives. Une façon de résoudre ce problème est d'orchestrer les dépendances en faisant de chaque pipeline une tâche dans un job avec les dépendances correctement modélisées, de sorte que pipeline_C ne soit mis à jour qu'après l'achèvement de pipeline_A et pipeline_B.

• Parallélisme Vous pouvez avoir différents flux au sein d'un pipeline qui prennent des durées très différentes à se terminer, par exemple si flow_A se met à jour en 15 secondes et que flow_B prend plusieurs minutes. Il peut être utile d'examiner les temps des queries avant de fractionner vos pipelines et de regrouper les queries plus courtes.

Planifier le découpage de vos pipelines

Vous pouvez visualiser la division de votre pipeline avant de start. Voici un Graphe d'un pipeline source qui traite 25 tables. Une seule source de données racine est divisée en 8 segments, chacun ayant 2 vues.

Après la division du pipeline, il y a deux pipelines. L'un traite la source de données racine unique, et 4 segments et vues associées. Le deuxième pipeline traite les 4 autres segments et leurs vues associées. Le deuxième pipeline s'appuie sur le premier pour mettre à jour la source de données racine.

Fractionner le pipeline sans refresh complet

Une fois que vous avez planifié votre division de pipeline, créez les nouveaux pipelines nécessaires et déplacez les tables entre les pipelines pour équilibrer la charge du pipeline. Vous pouvez déplacer des tables sans provoquer un refresh complet.

Pour plus de détails, consultez Déplacer des tables entre les pipelines.

Cette approche présente certaines limites :

• Les pipelines doivent être dans Unity Catalog.
• Les pipelines source et de destination doivent se trouver dans le même Workspace. Les déplacements inter-workspace ne sont pas pris en charge.
• Le pipeline de destination doit être créé et exécuté au moins une fois (même si l'exécution échoue) avant le déplacement.
• Vous ne pouvez pas déplacer une table d’un pipeline qui utilise le mode de publication default vers un autre qui utilise le mode de publication hérité. Pour plus de détails, consultez schéma LIVE (hérité).