Databricks-Datenherkunft ist die Spaltenebene-Abbildung, die den Datenfluss durch Ihren Spark SQL- und Delta Lake-Code darstellt: welche Quellspalten die einzelnen Zieltabelle in Ihren Bronze-, Silber- und Gold-Schichten speisen und welche Transformationen – Joins, Aggregationen usw. – durchgeführt werden. VERSCHMELZEN Logik – geschieht unterwegs. Unity Catalog erfasst automatisch die Herkunft von Workloads, die darüber laufen; Gudu SQLFlow Alles andere wird durch das Parsen des SQL-Codes selbst abgedeckt, wodurch es zum Werkzeug für Migrationen in Databricks, SQL-Abfragen außerhalb des Unity Catalog und Umgebungen wird, die sich über Databricks und andere Plattformen erstrecken.
Probieren Sie es in 30 Sekunden: Databricks einfügen VEREINIGEN IN oder Notebook-Abfrage in die kostenloser SQLFlow-Lineage-VisualisiererWählen Sie den Databricks-Dialekt aus und erhalten Sie sofort das Spalten-Herkunftsdiagramm. Kein Cluster- und kein Workspace-Zugriff erforderlich.
Wann benötigt man mehr als die Unity Catalog-Abstammung?
Unity Catalog ist in seiner Funktion wirklich hervorragend: Databricks erfasst die Herkunft von Abfragen und Jobs, die darüber ausgeführt werden, automatisch – ganz ohne zusätzliche Tools. Wenn sich Ihre gesamte Dateninfrastruktur in einem einzigen Databricks-Konto befindet und alle Workloads über Unity Catalog laufen, sollten Sie dort beginnen.
Die Lücke ist struktureller Natur, kein Fehler: Laufzeit-erfasste Herkunftsinformationen existieren nur für Code, der bereits in der erfassenden Umgebung ausgeführt wurde. Daher bleiben vier Situationen, in denen Teams stattdessen auf einen SQL-Parsing-Ansatz zurückgreifen:
- Bevor der Code auf Databricks ausgeführt wird. Sie migrieren von Oracle, Teradata oder SQL Server und benötigen den Abhängigkeitsgraphen des alten SQL-Systems – und des neu geschriebenen Databricks SQL-Systems –, bevor irgendetwas in der Produktion ausgeführt wird.
- SQL, das niemals auf den Unity-Katalog zugreift. Notebook-SQL, das in Dateien exportiert wurde, Skripte in einem Git-Repository, SQL, das von externen Schedulern oder ETL-Tools generiert wurde, Code in Arbeitsbereichen, die noch nicht auf Unity Catalog aktualisiert wurden.
- Plattformübergreifende Immobilien. Pipelines, die in SQL Server starten, in Databricks transformiert werden und in Snowflake enden, benötigen einen einzigen Datenherkunftsgraphen für alle drei Systeme. SQLFlow liefert dialektspezifische Parser für 39 Datenbanken – Databricks und Snowflake. Spark SQL darunter – so dass die gesamte Kette mit einem einzigen System analysiert wird.
- Herkunft in einem Katalog, den Sie bereits ausführen. Wenn Ihre Organisation DataHub, Microsoft Purview oder OpenMetadata anstelle der Databricks-Benutzeroberfläche verwendet, benötigen Sie eine Datenherkunftsfunktion, die den Export dorthin ermöglicht. SQLFlow enthält Exportadapter für alle drei Plattformen.
Die beiden Ansätze ergänzen sich. Der Unity Catalog zeigt Ihnen, was ausgeführt wurde; die statische SQL-Analyse zeigt Ihnen, was der Code bewirkt – einschließlich Code, der noch nicht ausgeführt wurde.
Wie SQLFlow Databricks-SQL analysiert
Gudu SQLFlow is an automated SQL-Datenherkunftstool built on the General SQL Parser, a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect test fixtures. It ships a dedicated Databricks dialect parser in the Spark SQL family — not a generic ANSI grammar — so Databricks-specific constructs are parsed as first-class syntax rather than approximated.
Die Analyse ist vollständig statisch. SQLFlow liest SQL-Text und optional Schema-Metadaten; es liest niemals die Zeilen in Ihren Delta-Tabellen, und mit der On-Premise-Edition Der SQL-Text selbst verlässt Ihr Netzwerk nie: Er wird auf Docker oder Kubernetes bereitgestellt und läuft isoliert. Für jede Anweisung erstellt der Parser ein vollständiges semantisches Modell und löst jede Spaltenreferenz mithilfe von CTEs, Unterabfragen, Sichten und mehr auf. WÄHLEN * Nach der Erweiterung extrahiert der Datenflussanalysator die Quell-Ziel-Beziehungen auf Spaltenebene.
Sie können SQL-Anweisungen in beliebiger Form in Ihrer Umgebung verarbeiten: eingefügte Anweisungen, hochgeladene Dateien, Datenbankmetadaten über JDBC oder ein dbt-Manifest für dbt-Projekte, die auf Databricks abzielen. Die Ausgabe ist ein interaktives, erweiterbares Diagramm sowie strukturierte Herkunftsdaten im JSON-, CSV-, PNG-Format oder als REST-API-Antwort.
Beispiel: Spaltenebene-Herkunft durch Delta-MERGE
VEREINIGEN IN ist das Arbeitspferd der Delta-Lake-Pipelines und eine Anweisung, bei der die Tabellen-Lineage nahezu nutzlos ist, da ein einzelner Merge-Vorgang Lesen, Abgleichen, Aktualisieren und Einfügen in einem Schritt durchführt. Betrachten wir beispielsweise einen Upsert auf der Gold-Ebene:
MERGE INTO gold.customer_ltv AS t USING ( SELECT o.customer_id, SUM(o.amount) AS lifetime_value, MAX(o.order_ts) AS last_order_ts FROM silver.orders o WHERE o.status = 'completed' GROUP BY o.customer_id ) AS s ON t.customer_id = s.customer_id WHEN MATCHED THEN UPDATE SET t.lifetime_value = s.lifetime_value, t.last_order_ts = s.last_order_ts WHEN NOT MATCHED THEN INSERT (customer_id, lifetime_value, last_order_ts) VALUES (s.customer_id, s.lifetime_value, s.last_order_ts);SQLFlow löst dies in präzise Beziehungen auf Spaltenebene auf. Gold.Kundenwert (Lebenszeitwert) leitet sich ab von Silberbestellungen Betrag durch SUMME(), sowohl über die AKTUALISIEREN und die EINFÜGEN Zweig. last_order_ts leitet sich ab von silver.orders.order_ts durch MAX()Der Unterabfragealias S wird aufgelöst; die Abstammungslinien verweisen auf die eigentliche Quelltabelle, nicht auf die Zwischentabelle.
Genauso wichtig ist, was SQLFlow als … klassifiziert. indirekte Abstammung: Silberbestellungen-Status landet nie im Ziel, aber WO Der Filter formt jeden zusammengeführten Wert, und Kunden-ID treibt beide an GRUPPE NACH und der Übereinstimmungsbedingung. SQLFlow modelliert direkten Datenfluss und indirekten Einfluss als unterschiedliche, separat umschaltbare Beziehungstypen. Die meisten Konkurrenzprodukte unterscheiden nicht so, und genau das brauchen Sie, wenn jemand fragt: „Wird die Änderung der Status „Vokabular-Break Customer LTV?“ Die ehrliche Antwort lautet: Ja, und nur eine auf die Auswirkungen abgestimmte Datenherkunft zeigt dies.
Migration zu (oder von) Databricks
Migration ist einer der häufigsten Gründe, warum Teams Databricks-SQL außerhalb der Plattform analysieren. Der Unity Catalog kann Sie bei der Migrationsplanung nicht unterstützen, da die benötigte Codeherkunft Code beschreibt, der noch nie auf Databricks ausgeführt wurde. Ein Parser-basierter Workflow hingegen schon.
- Kartieren Sie das Quellgebiet. Führen Sie die bestehenden SQL-Abfragen – Oracle, Teradata, SQL Server, einschließlich gespeicherter Prozeduren und des darin enthaltenen dynamischen SQL-Codes – mit SQLFlow aus, um den tatsächlichen Abhängigkeitsgraphen zu erhalten. So erkennen Sie, welche Codeabschnitte zuerst migriert werden sollten und welche nicht mehr benötigt werden.
- Überprüfen Sie die Neufassung. Analysieren Sie den neu geschriebenen Databricks-SQL-Code mit dem Databricks-Dialektparser und vergleichen Sie die Herkunftsdiagramme. Wenn sich die Datenquellen einer Zielspalte zwischen der Teradata-Version und der Delta-Version geändert haben, haben Sie einen Fehler in der Neuschreibung gefunden, bevor die Software ausgeliefert wird.
- Prüfen Sie, ob keine Daten verwaist sind. Nach der Umstellung werden beide Datenbankbestände per Batch-Scan überprüft – SQLFlow verarbeitet Datenbankbestände mit mehr als 100 Datenbanken und über einer Million Spalten mit inkrementellen Scans in ein persistentes Herkunftsarchiv.
Die gleiche dialektübergreifende Funktionalität funktioniert auch umgekehrt oder seitwärts: Wenn ein Teil Ihres Lagers stattdessen zu Snowflake migriert wird, Snowflake-Abstammungs-Workflow Da beide Plattformen die gleiche Engine verwenden, enden sie in einem vergleichbaren Diagramm.
Exportieren der Databricks-Datenherkunft nach DataHub, Purview oder OpenMetadata
Katalogbasierte Plattformen eignen sich gut zur Metadatenverwaltung, und viele Organisationen schreiben ein solches System für alle Datenplattformen vor. SQLFlow fungiert dabei als Lineage-Engine: Es analysiert SQL-Anweisungen, berechnet die Datenherkunft auf Spaltenebene und indirekt und leitet das Ergebnis über spezielle Exportadapter weiter. DataHub, Microsoft Purview und OpenMetadataJSON- und CSV-Exporte sowie eine REST-API decken alle kundenspezifischen Anforderungen ab.
Dies ist auch die praktische Lösung für das Problem der Multiplattform-Architektur: Die von zwei verschiedenen Extraktoren mit zwei unterschiedlichen Modellen erzeugten Herkunftsdaten lassen sich nur schwer zu einem einzigen Graphen zusammenführen. Ein einziger Parser, der einen Graphen für alle 39 Dialekte erzeugt und diesen in den bereits verwendeten Katalog exportiert, umgeht dieses Problem.
Möglichkeiten zur Ausführung
| Option | Am besten geeignet für | Anmerkungen |
|---|---|---|
| SQLFlow Cloud | Ich probiere es heute mit echtem Databricks SQL aus. | Kostenlose Version im Browser; Premium-Version $49,99/Monat |
| SQLFlow vor Ort | Regulierte Umgebungen; SQL muss intern bleiben. | Docker/Kubernetes-fähig, Air-Gap-fähig; $500/Monat oder $4.800 einmalig pro Datenbanktyp, installierbar auf zwei Servern |
| REST-API / CLI / Java-Bibliothek | Automatisierung der Herkunftsnachverfolgung in CI oder Ihrer eigenen Plattform | Gleiche Engine, ohne Benutzeroberfläche; einbettbares JavaScript-Widget mit einer API mit über 30 Methoden zum Rendern von Diagrammen in Ihrem Produkt |
Häufig gestellte Fragen
Ersetzt SQLFlow die Unity Catalog-Linie?
Nein, es ergänzt es. Unity Catalog erfasst automatisch die Herkunft von Workloads, die darüber ausgeführt werden. SQLFlow analysiert den SQL-Code statisch und deckt somit Code vor seiner Ausführung (Migrationen), SQL-Anweisungen außerhalb von Unity Catalog sowie Umgebungen ab, die sich über Databricks und andere Plattformen erstrecken. Anschließend exportiert es die Ergebnisse nach DataHub, Purview oder OpenMetadata.
Benötigt SQLFlow Zugriff auf meinen Databricks-Arbeitsbereich oder meine Daten?
Nein. SQLFlow führt eine statische Analyse des SQL-Codes durch und verwendet optional Schema-Metadaten zur Auflösung von Referenzen. Es liest niemals Zeilen aus Ihren Delta-Tabellen. Bei der On-Premise-Edition bleibt sogar der SQL-Text innerhalb Ihres Netzwerks.
Kann SQLFlow die Herkunft von MERGE INTO-Anweisungen nachverfolgen?
Ja. Für eine Delta VEREINIGEN INSQLFlow löst das Problem auf VERWENDUNG Die Unterabfrage ordnet jede Zielspalte ihren tatsächlichen Quellspalten zu, und zwar über beides: AKTUALISIEREN Und EINFÜGEN Zweige und klassifiziert Übereinstimmungsbedingungen und Filter als indirekte (Auswirkungs-)Linie.
Ist Databricks ein eigenständiger Dialekt von Spark SQL in SQLFlow?
Ja. SQLFlow listet Databricks und Spark SQL in seinen 39 unterstützten Dialekten separat auf, wobei jeder Dialekt seinen eigenen Parser aus der Spark-SQL-Familie verwendet. Wählen Sie Databricks für SQL-Abfragen, die mit Databricks erstellt wurden; es gibt auch einen dedizierten Parser. Spark SQL-Herkunftsseite für Open-Source-Spark-Workloads.
Funktioniert es mit dbt-Projekten auf Databricks?
Ja. Importieren Sie das dbt-Manifest, und SQLFlow erzeugt eine Spaltenherkunft über Ihre Modelle hinweg, indem es den Databricks-Dialekt zum Parsen des kompilierten SQL verwendet.
Was kostet 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. Weitere Informationen finden Sie unter [Link einfügen]. Preisseite.
Verfolgen Sie jetzt Ihre Databricks-Herkunft.
Fügen Sie eine Spark SQL-Abfrage oder eine Delta MERGE-Abfrage in den kostenlosen Visualisierer ein oder sprechen Sie mit uns über die Durchsicht eines gesamten Migrationsbestands.