Organiser les datasets dans les Lakeflow pipelines
Utilisez les Lakeflow pipelines pour traiter d'un à plusieurs centaines de datasets dans un seul pipeline. Déterminez quels datasets doivent être regroupés en fonction du domaine, de la cadence et des dépendances, et divisez le travail en pipelines distincts lorsque la propriété, la latence ou le Monter en charge diffèrent.
Présentation
Une décision qui n’apparaît jamais dans un tutoriel devient importante dans les vrais déploiements : quelles tables doivent être ensemble dans le même pipeline, et quand quelque chose devrait-il être un pipeline à part entière ? Se tromper est l’une des façons les plus courantes dont les équipes se mettent dans une impasse. Le mode d’échec classique consiste à tout mettre dans un seul énorme pipeline, puis à rencontrer des problèmes d’échelle, de concurrence et de rayon d’explosion qui sont douloureux à résoudre.
Il n’y a pas de réponse unique, mais des forces claires tirent dans chaque direction et il existe une contrainte forte qu’il convient de connaître avant de concevoir.
Consignes
Regrouper les ensembles de données par domaine, cadence partagée et dépendance, puis les diviser aux frontières de propriété, de couche et de latence. Gardez confortablement le nombre de dataset mises à jour indépendamment dans un pipeline en dessous du plafond des mises à jour parallèles.
Connaissez la limite de concurrence avant de concevoir
Une seule mise à jour de pipeline déclenchée exécute au maximum 16 mises à jour de dataset en parallèle . C'est la surprise la plus courante pour les équipes qui mettent tout dans un seul pipeline : une fois que vous avez plus d'environ 16 datasets qui pourraient autrement s'exécuter simultanément, les datasets supplémentaires se mettent en file d'attente derrière les 16 premiers au lieu de s'exécuter en parallèle, de sorte que le temps de mise à jour total s'allonge même si du compute est disponible. Si vous avez des dizaines de datasets indépendants et que le temps de mise à jour réel vous importe, c'est une raison suffisante pour ne pas tous les entasser dans un seul pipeline.
Ce qui appartient au même pipeline
Gardez les datasets ensemble lorsqu’ils partagent une structure ou une planification :
- Des datasets qui forment une chaîne de dépendances ou un domaine logique, comme les tables bronze, argent et Gold pour les ordres. Maintenir un graphe acyclique orienté connecté (DAG) permet au pipeline de le planifier, de le checkpointer, puis de le refresh complètement en tant qu’unité cohérente, et de garder la lignée lisible. Voir Charge et données de processus de manière incrémentale avec les Lakeflow pipeline flows.
- Les datasets qui partagent les mêmes exigences de fraîcheur et la même cadence d'exécution, comme par exemple les éléments qui doivent être mis à jour ensemble, sur le même Trigger, dans la même limite de transaction.
- Datasets suffisamment petits dans l'ensemble pour que le Graphe entier tienne confortablement sous le plafond de mise à jour parallèle et refresh dans un délai acceptable.
Ce qui doit figurer dans un pipeline distinct
Séparez les datasets lorsqu'ils diffèrent en termes de propriété, de couche ou de latence :
- Différents domaines ou équipes. Une propriété distincte doit généralement signifier des pipelines distincts, afin qu'une modification ou une défaillance d'une équipe ne bloque pas celle d'une autre.
- Les couches que vous souhaitez Monter en charge ou planifier indépendamment. Une division largement recommandée est de séparer l’ingestion (bronze) de la transformation (argent et or) en pipelines distincts, afin qu’une ingestion lente ou défaillante ne retarde pas la transformation et que chacun puisse compute selon ses propres besoins.
- Différents profils de latence. Un stream continu à faible latence ne doit pas partager un pipeline avec un agrégat batch quotidien. Voir Mode de pipeline déclenché ou continu.
- Des ensembles de données qui vous font dépasser la limite de mise à jour parallèle et qui, autrement, seraient mis en file d'attente.
Pour exécuter un ensemble de jeux de données isolément, considérons un pipeline autonome. See Standalone pipelines vs. LakeFlow Pipelines.
Une règle générale pratique
Don't default to one monolithic pipeline, and don't shatter every table into its own pipeline either. Regroupez par domaine + cadence partagée + dépendance , divisez selon les limites de propriété, de couche et de latence , et maintenez le nombre de datasets pouvant être mis à jour indépendamment pour un seul pipeline confortablement en dessous du plafond de mise à jour parallèle. En cas de doute, préférez une poignée de pipelines de taille moyenne alignés sur des domaines plutôt qu'un pipeline géant. Il est bien plus facile de Merge deux petits pipelines ultérieurement que de découper un monolithe déjà en production.
Limitations
- Une seule Triggered update exécute au maximum 16 updates de dataset en parallèle. Les datasets au-delà de ce plafond se mettent en file d’attente plutôt que de s’exécuter simultanément, donc un pipeline avec des dizaines de datasets indépendants peut mettre plus de temps à se mettre à jour même lorsque le compute est disponible.
- La division en plusieurs pipelines entraîne une perte de visibilité de bout en bout. Lorsque vous effectuez une séparation, appuyez-vous sur les tables système (
system.lakeflow.pipelines,system.lakeflow.job_run_timeline) et orchestrez les éléments ensemble avec un Lakeflow Job afin de conserver une vue unique de bout en bout de l'ensemble du flux. Voir Exécuter des pipelines dans un workflow.