Spark SQL Datenherkunft: Spaltenherkunft für Spark Pipelines

Spark SQL Datenherkunft ist die Spaltenübersicht, die zeigt, wie Daten durch Ihren Spark SQL-Code fließen: welche Quellspalten jede Tabelle speisen, die von einem Spark SQL-Code geschrieben wird. CREATE TABLE ... AS SELECT oder EINFÜGEN ÜBERSCHREIBENund durch welche temporären Ansichten, Verknüpfungen, Funktionen und Filter auf dem Weg dorthin verwendet werden. Gudu SQLFlow Diese Zuordnung wird durch statisches Parsen Ihres Spark-SQL-Codes mit einem speziellen Spark-Dialektparser erstellt – kein Cluster muss instrumentiert, kein Listener angehängt und kein Joblauf erforderlich. SQL-Code einfügen, Herkunftsdiagramm erhalten.

Laufzeit-Listener vs. statisches Parsing: Zwei Wege, um die Spark-Herkunft zu ermitteln

In der Spark-Welt gibt es zwei grundlegend verschiedene Ansätze zur Abstammung, und die meisten Teams benötigen letztendlich beide.

Laufzeit-Abstammung Der von OpenLineage und seiner Spark-Integration verfolgte Ansatz fügt der Spark-Session einen Listener hinzu und sendet bei jeder Jobausführung Lineage-Ereignisse. Er ist in dieser Hinsicht wirklich gut: Er protokolliert, was wann und auf welchen Datensätzen tatsächlich ausgeführt wurde – mit Metadaten auf Laufzeitebene, die eine statische Analyse nicht erfassen kann. Wenn Sie sich fragen: „Welche Daten hat die Pipeline letzte Nacht verarbeitet?“, liefert die Laufzeit-Lineage die Antwort.

Statische Abstammungslinie Der Ansatz von SQLFlow analysiert den SQL-Text selbst und leitet die Herkunft aus dem Code ab, ähnlich wie ein Compiler. Dadurch wird alles abgedeckt, was die Laufzeiterfassung strukturell nicht leisten kann:

• SQL-Anweisungen, die Sie noch nicht ausgeführt haben. Eine neue Pipeline in einem Pull Request, ein von einem anderen Team übernommenes Skript, ein Rückstand an vierteljährlich geplanten Jobs – keines dieser Elemente löst Laufzeitereignisse aus, bis es ausgeführt wird, möglicherweise gegen Produktionsdaten.
• Code-Review. Die Prüfer können den vollständigen Abhängigkeitsgraphen einer Änderung auf Spaltenebene einsehen, bevor sie diese genehmigen, anstatt die Auswirkungen erst nach der Bereitstellung zu entdecken.
• Migrationsprüfungen. Wenn Sie Workloads auf Spark migrieren – üblicherweise von Hive –, benötigen Sie den Abhängigkeitsgraphen von gesamte Die Codebasis umfasst auch Jobs, die nur am Monatsende ausgeführt werden. Die statische Analyse liest sie in einem Durchgang komplett ein.

	Laufzeit-Listener (OpenLineage)	Statische Analyse (SQLFlow)
Abstammung erfasst	Pro Joblauf, während er ausgeführt wird	Aus dem SQL-Text, bevor irgendetwas ausgeführt wird
Erfordert	Listener in der Spark-Sitzung konfiguriert; Jobs müssen ausgeführt werden	Die SQL-Dateien sowie optionale Schema-Metadaten
Umfasst nicht ausgeführten Code	Nein – kein Lauf, keine Veranstaltung	Ja – Pull Requests, Backlogs, selten ausgeführte Jobs
Laufzeitmetadaten (Zeitpunkt, Versionen)	Ja	Nein – nur auf Codeebene
Typische Verwendung	Betriebliche Beobachtbarkeit von Live-Pipelines	Folgenabschätzung, Code-Review, Migrationsprüfungen, Compliance-Dokumentation

Diese beiden Aspekte ergänzen sich, anstatt miteinander zu konkurrieren. Die Laufzeit-Herkunftsanalyse zeigt Ihnen, was passiert ist; die statische Herkunftsanalyse zeigt Ihnen, was der Code bewirkt. Die Exportadapter von SQLFlow für DataHub, Microsoft Purview und OpenMetadata ermöglichen es Ihnen, die statisch abgeleitete Herkunftsanalyse im selben Katalog wie Ihre Laufzeitereignisse zu speichern, sodass die beiden Ansichten nebeneinander angezeigt werden.

Beispiel: Eine temporäre Ansichtskette in ein CTAS

Das Muster, das einfache Lineage-Tools in Spark SQL überfordert, ist die temporäre View-Kette. Notebooks und Jobs führen routinemäßig Logik-Staging durch TEMPORÄRE ANSICHT ERSTELLEN ODER ERSETZEN Schritte vor einem letzten CREATE TABLE ... AS SELECTHier ein kurzes, aber realistisches Beispiel:

CREATE OR REPLACE TEMP VIEW clean_events AS SELECT CAST(event_time AS TIMESTAMP) AS event_ts, user_id, lower(event_name) AS event_name, amount FROM raw.events WHERE event_date >= date_sub(current_date(), 30); CREATE OR REPLACE TEMP VIEW user_daily AS SELECT user_id, to_date(event_ts) AS event_day, SUM(amount) AS daily_spend FROM clean_events WHERE event_name = 'purchase' GROUP BY user_id, to_date(event_ts); CREATE TABLE analytics.user_spend_30d USING PARQUET AS SELECT u.user_id, u.segment, d.event_day, d.daily_spend FROM user_daily d JOIN dim.users u ON u.user_id = d.user_id;

Fragen Sie: „Woher kommt das?“ analytics.user_spend_30d.daily_spend „Woher kommt das?“ und die ehrliche Antwort erfordert die Auflösung zweier Sichtebenen: tägliche Ausgaben Ist SUMME(clean_events.amount), Und clean_events.amount Ist Rohereignisse.MengeSQLFlow führt genau diese Auflösung durch und rendert die gesamte Kette. Rohereignisse.Menge durch clean_events Und Benutzer_täglich in den Finaltisch, mit dem SUMME Die Aggregation ist an der Kante angehängt, an der sie stattfindet.

Es erfasst auch das, was die meisten Tools völlig auslassen: indirekte AbstammungDie Spalten Ereignisdatum, Ereignisnameund der Join-Schlüssel Benutzer-ID erscheinen nie in tägliche AusgabenDoch alle drei beeinflussen seinen Wert – ändern Sie den 30-Tage-Filter oder den 'kaufen' Prädikat und jede Zahl in der Ausgabe ändert sich. SQLFlow modelliert dies als separaten, umschaltbaren Beziehungstyp, sodass Sie entweder den reinen Datenfluss oder die gesamte Auswirkungsfläche anzeigen können. Für eine Überprüfung von Schemaänderungen ist die Auswirkungsfläche die relevanteste Ansicht.

Spark SQL-Konstrukte, die SQLFlow auflöst

SQLFlow liefert einen Spark-SQL-Dialektparser mit – einen von 39 dialektspezifischen Parsern, keine generische ANSI-Grammatik mit hinzugefügten Spark-Schlüsselwörtern. Speziell für Spark SQL verarbeitet er Anweisungen, die eine Herkunftsangabe enthalten:

• CREATE TABLE ... AS SELECT (CTAS) — das Arbeitspferd der Spark-Batch-Pipelines; jede Ausgabespalte wird über die vollständige SELECT-Anweisung bis zu ihren Quellen zurückverfolgt.
• EINFÜGEN IN Und EINFÜGEN ÜBERSCHREIBEN — einschließlich der Zuordnung der Spaltenpositionen zwischen der SELECT-Liste und dem Schema der Zieltabelle.
• TEMPORÄRE ANSICHT ERSTELLEN ODER ERSETZEN — Temporäre Ansichten werden aufgelöst und verkettet, sodass die Datenherkunft durch die Staging-Ebenen fließt, anstatt dort anzuhalten.
• CTEs, Unterabfragen und WÄHLEN * — Spaltenreferenzen werden über Common Table Expressions und verschachtelte Unterabfragen aufgelöst, und Sternausdrücke werden zu realen Spalten erweitert, wenn Schema-Metadaten verfügbar sind.
• Funktionen, Typumwandlungen und Mengenoperatoren — Die Herkunftsnachweise jeder Ausgabespalte dokumentieren, welche Transformationen sie durchlaufen hat, so tägliche Ausgaben ist nicht nur „von Betrag“, sondern „von Menge über SUMME“.

Under the hood this is the General SQL Parser engine — a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect test fixtures. Lineage quality is a parsing problem before it is anything else, and that corpus is what keeps edge-case Spark syntax from silently producing wrong edges.

Wo die Datenherkunft von Spark SQL in Ihre Architektur passt

Spark existiert selten isoliert. Seine Tabellen befinden sich üblicherweise in einem Hive-Metastore, und ein zunehmender Anteil der Spark-Workloads läuft auf Databricks. SQLFlow behandelt diese als erstklassige, separat geparste Dialekte:

• Sie möchten Hive-Jobs zu Spark migrieren? Analysieren Sie die bestehenden HQL-Abfragen mit dem Hive-Datenherkunftsparser und die neu geschriebenen Jobs mit dem Spark-Parser zu vergleichen und die beiden Abhängigkeitsgraphen zu vergleichen, um sicherzustellen, dass bei der Übersetzung nichts verloren gegangen ist.
• Läuft es auf Databricks? Databricks-Datenherkunftsparser behandelt den Databricks SQL-Dialekt, der sich vom Open-Source Spark SQL in einer Weise unterscheidet, die mit einer einzigen gemeinsamen Grammatik nicht adäquat erfasst wird.
• Gemischte Umgebungen? SQLFlow analysiert alle 39 unterstützten Dialekte in einem einzigen Herkunftsverzeichnis, sodass ein Spark-Job, der eine von einem Snowflake-Task erzeugte Tabelle liest, als ein durchgehender Graph dargestellt wird. Siehe die Überblick über SQL-Datenherkunftstools um das Gesamtbild zu erhalten.

Die Eingabemöglichkeiten sind flexibel: SQL-Code einfügen, Dateien hochladen, Metadaten über JDBC abrufen oder ein dbt-Manifest für dbt-on-Spark-Projekte importieren. Die Ausgabe besteht aus einem interaktiven, erweiterbaren Diagramm sowie Exporten in den Formaten JSON, CSV und PNG und einer REST-API zur Automatisierung – beispielsweise zur Analyse der SQL-Änderungen in einem Pull Request als CI-Schritt.

Bereitstellung und Skalierung

SQLFlow Cloud bietet eine kostenlose Version für die interaktive Nutzung; die Premium-Version kostet $49,99/Monat. Teams, deren SQL-Datenbank das Netzwerk nicht verlassen darf, können dies nutzen. SQLFlow vor Ort — Docker oder Kubernetes, Air-Gap-fähig, 1.500 TP/Monat oder einmalig 4.800 TP pro ausgewähltem Datenbanktyp. SQLFlow führt in jedem Fall ausschließlich eine statische Analyse des SQL-Codes durch: Es liest niemals die Zeilen Ihrer Tabellen. Enterprise-Implementierungen scannen Datenbanken mit über 100 Datenbanken und mehr als einer Million Spalten im Batch-Verfahren mit inkrementellen Scans und einem persistenten Lineage-Repository.

Häufig gestellte Fragen

Benötige ich einen laufenden Spark-Cluster, um die Herkunft der Daten zu ermitteln?

Nein. SQLFlow analysiert den Spark SQL-Text statisch. Sie können ein Skript analysieren, das noch nie irgendwo ausgeführt wurde – beispielsweise einen Pull Request, eine Lieferantenlieferung oder einen Migrations-Backlog – und erhalten dieselbe Spaltenhistorie wie bei Produktionscode.

Worin unterscheidet sich dies von der Spark-Integration von OpenLineage?

OpenLineage erfasst die Codeherkunft zur Laufzeit über einen Listener in der Spark-Session – ideal, um die tatsächliche Ausführung laufender Jobs zu beobachten. SQLFlow leitet die Codeherkunft direkt aus dem SQL-Code ab und erfasst somit auch nicht ausgeführten Code. Es unterstützt zudem die Überprüfung vor dem Zusammenführen und Migrationsaudits und benötigt keinen Clusterzugriff. Die beiden Lösungen ergänzen sich: SQLFlow kann neben der Laufzeit-Codeherkunft auch Daten in DataHub, Purview oder OpenMetadata exportieren.

Kann SQLFlow die Herkunft von Prozessen über temporäre Sichten nachverfolgen?

Ja. Ketten von TEMPORÄRE ANSICHT ERSTELLEN ODER ERSETZEN Die Anweisungen werden von Anfang bis Ende aufgelöst, sodass eine Spalte in einem finalen CTAS über jede Staging-Ansicht bis zur physischen Quelltabelle zurückverfolgt werden kann, wobei die Funktionen und Aggregationen in jedem Schritt angewendet werden.

Ist Databricks SQL hier dasselbe wie Spark SQL?

Nein – SQLFlow analysiert sie mit separaten Dialektparsern. Databricks SQL verfügt über eigene Syntaxerweiterungen und somit über eine eigene Grammatik. Wenn Sie Databricks verwenden, nutzen Sie den Databricks-Dialekt; für Open-Source-Spark, EMR oder selbstverwaltete Cluster verwenden Sie den Spark-SQL-Dialekt.

Kann SQLFlow meine Daten lesen?

Nein. Es analysiert SQL-Code und optional Schema-Metadaten (Tabellen- und Spaltendefinitionen). Auf die Zeilendaten wird niemals zugegriffen. Bei einer On-Premise-Lösung verbleibt selbst der SQL-Text innerhalb Ihres Netzwerks.

Welche Kosten entstehen durch die Spark SQL-Lineage mit SQLFlow?

SQLFlow Cloud ist kostenlos; die Premium-Version kostet $49,99/Monat. Die On-Premise-Version kostet $500/Monat oder einmalig $4.800 pro ausgewähltem Datenbanktyp und kann auf zwei Servern installiert werden. Siehe Preisgestaltung für weitere Details.