{"id":6764,"date":"2026-07-12T02:08:07","date_gmt":"2026-07-12T10:08:07","guid":{"rendered":"https:\/\/www.gudusoft.com\/duckdb-data-lineage\/"},"modified":"2026-07-12T02:08:07","modified_gmt":"2026-07-12T10:08:07","slug":"duckdb-data-lineage","status":"publish","type":"page","link":"https:\/\/www.gudusoft.com\/de\/duckdb-datenherkunft\/","title":{"rendered":"DuckDB-Datenherkunft: Spaltenbasierte Herkunftsanalyse f\u00fcr In-Process-Analysen"},"content":{"rendered":"

DuckDB-Datenherkunft<\/strong> ist die Spaltenebene-Abbildung, die zeigt, wie Daten durch Ihre DuckDB SQL-Abfrage flie\u00dfen: welche Parquet-Dateien und Quelltabellen jede abgeleitete Tabelle speisen und welche Joins, Casts, Filter und Aggregationen durchgef\u00fchrt werden. Gudu SQLFlow<\/strong> Erstellt diese Zuordnung automatisch: Es analysiert Ihre DuckDB-Skripte mit einem speziellen DuckDB-Dialektparser und rendert ein interaktives Herkunftsdiagramm, ohne eine einzige Abfrage auszuf\u00fchren oder Ihre Daten zu ber\u00fchren.<\/p>\n\n\n\n

\n\n

Probieren Sie es jetzt aus:<\/strong> F\u00fcgen Sie eine beliebige DuckDB-Abfrage in die folgende Zeile ein: kostenloser Online-SQL-Lineage-Visualisierer<\/a>W\u00e4hlen Sie den DuckDB-Dialekt aus und erhalten Sie innerhalb von Sekunden ein Spalten-Herkunftsdiagramm. F\u00fcr die Einzelnutzung gibt es eine kostenlose Version.<\/p>\n\n<\/div><\/div>\n\n\n\n

Warum DuckDB-Pipelines eine echte Herkunftsgeschichte verdienen<\/h2>\n\n\n\n

DuckDB hat sich still und leise zu einer ernstzunehmenden Dateninfrastruktur entwickelt. Es f\u00fchrt die Transformationsschicht in dbt-duckdb<\/code> Projekte, lokale Analysen, die sp\u00e4ter ins Data Warehouse \u00fcbertragen werden, sind in Anwendungen und Notebooks eingebettet und dienen zunehmend als Rechenkern f\u00fcr Parquet-Data-Lakes. Die SQL-Abfragen in diesen Pipelines treffen \u00e4hnliche Entscheidungen wie die SQL-Abfragen im Data Warehouse: Sie berechnen Ums\u00e4tze, filtern Kunden und erstellen die Tabellen, die ein Dashboard ausliest.<\/p>\n\n\n\n

Dennoch wird bei DuckDB-Projekten \u00fcblicherweise nicht die strenge Datenherkunftsanalyse eines Data Warehouse angewendet. Dies hat einen strukturellen Grund: Die meisten Tools zur Datenherkunftsanalyse setzen einen Datenbankserver voraus. Laufzeitprotokollbasierte Datenherkunftsanalyse sammelt Abfrageprotokolle von einer zentralen Engine; katalogbasierte Plattformen durchsuchen die Metadaten eines Servers. DuckDB ist jedoch ein In-Process-System: Oftmals gibt es keinen Server, keine gemeinsame Abfragehistorie und keinen zu installierenden Katalogagenten. Die Transformationslogik befindet sich im In-Process-Prozess. .sql<\/code> Dateien, DBT-Modelle und Skripte wurden in ein Repository eingecheckt.<\/p>\n\n\n\n

Daher ist die statische SQL-Analyse die naheliegende und oft einzige Methode, um die Datenherkunft von DuckDB nachzuverfolgen. SQLFlow analysiert den SQL-Text selbst, sodass die Funktionsweise unabh\u00e4ngig davon ist, ob der SQL-Code auf einem Laptop, in einem CI-Job oder innerhalb eines Anwendungsprozesses ausgef\u00fchrt wird.<\/p>\n\n\n\n

Wie SQLFlow die Datenherkunft von DuckDB erstellt<\/h2>\n\n\n\n

SQLFlow basiert auf Allgemeiner SQL-Parser (GSP)<\/a>DuckDB ist ein kommerzielles SQL-Compiler-Frontend, das seit Mitte der 2000er Jahre entwickelt und anhand von rund 13.600 SQL-Testdateien pro Dialekt validiert wurde. 39 Datenbanken mit einem dialektspezifischen Parser<\/a> \u2014 keine generische ANSI-Grammatik, der die Syntax von DuckDB nachtr\u00e4glich hinzugef\u00fcgt wurde. Die Pipeline:<\/p>\n\n\n\n

  1. Aufnehmen.<\/strong> F\u00fcgen Sie DuckDB-SQL ein, laden Sie Ihre Skriptdateien hoch oder importieren Sie ein dbt-Manifest aus einem dbt-duckdb<\/code> Projekt.<\/li>\n
  2. Analysieren und aufl\u00f6sen.<\/strong> GSP erstellt ein vollst\u00e4ndiges semantisches Modell jeder Anweisung und l\u00f6st jede Spaltenreferenz mithilfe von CTEs, Unterabfragen, Sichten und W\u00c4HLEN *<\/code> Erweiterung.<\/li>\n
  3. Datenfluss extrahieren.<\/strong> Der Datenflussanalysator protokolliert f\u00fcr jede Ausgabespalte genau, welche Quellspalten sie speisen und welche Funktionen, Typumwandlungen, Verkn\u00fcpfungen und Mengenoperatoren verwendet werden.<\/li>\n
  4. Visualisieren und exportieren.<\/strong> Navigieren Sie durch das interaktive Diagramm, verfolgen Sie jede Spalte stromaufw\u00e4rts oder stromabw\u00e4rts und exportieren Sie das Diagramm als JSON, CSV oder PNG oder rufen Sie es \u00fcber die REST-API ab.<\/li><\/ol>\n\n\n\n

    Beispiel: Herkunftsnachweis mittels read_parquet() und CTAS<\/h2>\n\n\n\n

    Das typische DuckDB-Muster ist CREATE TABLE AS SELECT<\/code> Dateien direkt lesen \u2013 kein Zwischenspeichern, die Parquet-Dateien Sind<\/em> Die Quelle. Ein typischer Reporting-Build:<\/p>\n\n\n\n

    CREATE TABLE reporting.daily_revenue AS SELECT CAST(o.order_ts AS DATE) AS order_date, c.region AS region, SUM(o.amount) AS revenue, COUNT(DISTINCT o.customer_id) AS buyers FROM read_parquet('lake\/orders\/*.parquet') AS o JOIN dim_customers AS c ON o.customer_id = c.customer_id WHERE o.status = 'completed' GROUP BY 1, 2;<\/code><\/pre>\n\n\n\n
    Der DuckDB-Parser von SQLFlow versteht read_parquet()<\/code> Da es sich um eine Tabellenquelle handelt, wird der Parquet-Pfad im Herkunftsdiagramm als tats\u00e4chlicher Knoten und nicht als unaufgel\u00f6ster Funktionsaufruf angezeigt. Aus dieser einen Anweisung wird Folgendes extrahiert:<\/p>\n\n\n\n