Organisieren Sie Datensätze über Lakeflow-Pipelines hinweg

Verwenden Sie Lakeflow-Pipelines, um in einer einzigen Pipeline zwischen einem und Hunderten von Datensätzen zu verarbeiten. Entscheiden Sie, welche Datensätze zusammengehören, basierend auf Domäne, Rhythmus und Abhängigkeiten, und teilen Sie die Arbeit in separate Pipelines auf, wenn Eigentum, Latenz oder Skalierung unterschiedlich sind.

Overview

Eine Entscheidung, die in einem Tutorial nie zur Sprache kommt, wird in realen Deployments wichtig: Welche Tabellen gehören zusammen in dieselbe Pipeline, und wann sollte etwas stattdessen eine eigene Pipeline sein? Wenn Teams hier einen Fehler machen, ist das eine der häufigsten Arten, wie sie sich selbst in eine Sackgasse manövrieren. Der klassische Fehlerfall besteht darin, alles in eine einzige riesige Pipeline zu kippen und später auf Probleme hinsichtlich Skalierbarkeit, Parallelität und Blast-Radius zu stoßen, deren Entladung mühsam ist.

Es gibt keine einzige richtige Antwort, aber es gibt klare Kräfte, die in jede Richtung ziehen, und eine harte Einschränkung, die man vor dem Entwurf kennen sollte.

Richtlinien

Gruppieren Sie Datensätze nach Domäne, gemeinsamer Frequenz und Abhängigkeit und teilen Sie sie an Eigentümer-, Schicht- und Latenzgrenzen. Halten Sie die Anzahl der unabhängig aktualisierbaren Datensätze einer einzelnen Pipeline bequem unter der Parallel-Update-Obergrenze.

Kennen Sie die Parallelitätsgrenze, bevor Sie Ihr Design erstellen

Ein einzelnes ausgelöstes Pipeline-Update führt höchstens 16 Datensatzupdates parallel aus. Das ist die häufigste Überraschung für Teams, die alles in eine Pipeline packen: Sobald man mehr als etwa 16 Datensätze hat, die sonst gleichzeitig laufen könnten, stehen die zusätzlichen hinter den ersten 16 in der Warteschlange, anstatt parallel zu laufen, sodass sich die gesamte Aktualisierungszeit verlängert, obwohl vorhandene Rechenleistung vorhanden ist. Wenn du Dutzende unabhängiger Datensätze hast und dir die Aktualisierungszeit an der Wanduhr wichtig ist, ist das allein schon ein Grund, sie nicht alle in eine Pipeline zu packen.

Was gehört in dieselbe Pipeline

Behalten Sie Datensätze zusammen, wenn sie Struktur oder Planung teilen:

  • Datensätze, die eine Abhängigkeitskette oder eine logische Domäne bilden, wie die Bronze-, Silber- und Goldtabellen für Aufträge. Durch die Aufrechterhaltung eines zusammenhängenden gerichteten azyklischen Graphen (DAG) kann die Pipeline diesen als kohärente Einheit planen, mit Checkpoints sichern und vollständig aktualisieren, wodurch die Herkunft der Daten nachvollziehbar bleibt. Siehe Daten mit Lakeflow-Pipeline-Abläufen inkrementell laden und verarbeiten.
  • Datensätze, die dieselbe Aktualitätsanforderung und dieselbe Ausführungsfrequenz haben, etwa solche, die gemeinsam aktualisiert werden sollten – durch denselben Trigger und innerhalb derselben Transaktionsgrenze.
  • Datensätze sind aggregiert klein genug, dass der gesamte Graph problemlos unter die Parallel-Update-Obergrenze passt und in einer akzeptablen Zeit aktualisiert wird.

Was gehört in eine separate Pipeline

Trenne Datensätze, wenn sie sich in Besitzer, Schicht oder Latenz unterscheiden:

  • Verschiedene Bereiche oder Teams. Separate Eigentümerschaft sollte in der Regel getrennte Pipelines bedeuten, sodass die Änderung oder das Scheitern eines Teams nicht das eines anderen blockiert.
  • Schichten, die du unabhängig skalieren oder planen möchtest. Eine weit verbreitete Empfehlung ist die Trennung der Dateneingabe (Bronze) von der Transformation (Silber und Gold) in separate Pipelines, sodass eine langsame oder fehlgeschlagene Dateneingabe die Transformation nicht aufhält und jede Pipeline ihre Rechenkapazität an ihre eigenen Anforderungen anpassen kann.
  • Unterschiedliche Latenzprofile. Ein kontinuierlicher Stream mit geringer Latenz sollte sich keine Pipeline mit einer einmal täglich ausgeführten Batch-Aggregation teilen. Siehe Ausgelöste vs. Continuous Pipeline-Modus.
  • Datasets, die die Grenze für parallele Aktualisierungen überschreiten und andernfalls in die Warteschlange gelangen würden.

Um einen Datensatz isoliert auszuführen, betrachten Sie eine eigenständige Pipeline. Siehe eigenständige Pipelines im Vergleich zu Lakeflow-Pipelines.

Eine praktische Faustregel

Verwenden Sie nicht standardmäßig eine einzige monolitische Pipeline, und zerlegen Sie auch nicht jede Tabelle in eine eigene Pipeline. Gruppieren Sie nach Domäne + gemeinsamem Aktualisierungsrhythmus + Abhängigkeit, trennen Sie an den Grenzen von Verantwortlichkeit, Schicht und Latenz, und halten Sie die Anzahl der unabhängig aktualisierbaren Datasets einer einzelnen Pipeline deutlich unter der Obergrenze für Parallelaktualisierungen. Im Zweifelsfall bevorzugen Sie eine Handvoll mittlerer Pipelines, die auf Domänen ausgerichtet sind, statt einer riesigen Pipeline. Es ist viel einfacher, zwei kleine Pipelines später zusammenzuführen, als einen Monolithen zu zerteilen, der bereits in Produktion ist.

Einschränkungen

  • Ein einzelnes ausgelöstes Update führt höchstens 16 Datensatz-Updates parallel aus. Datensätze oberhalb dieser Obergrenze werden in die Warteschlange gestellt, anstatt parallel ausgeführt zu werden, sodass eine Pipeline mit Dutzenden unabhängiger Datensätze länger für die Aktualisierung benötigen kann, selbst wenn Rechenkapazität verfügbar ist.
  • Bei der Aufteilung in mehrere Pipelines geht etwas End-to-End-Transparenz verloren. Stützen Sie sich bei der Aufteilung auf die Systemtabellen (system.lakeflow.pipelines, system.lakeflow.job_run_timeline) und koordinieren Sie die einzelnen Teile mithilfe eines Lakeflow-Jobs, damit Sie weiterhin eine einheitliche End-to-End-Übersicht über den gesamten Flow erhalten. Siehe Ausführen von Pipelines in einem Workflow.

Weitere Ressourcen

  • Last updated on