{"id":6752,"date":"2026-07-12T02:06:16","date_gmt":"2026-07-12T10:06:16","guid":{"rendered":"https:\/\/www.gudusoft.com\/redshift-data-lineage\/"},"modified":"2026-07-12T02:06:16","modified_gmt":"2026-07-12T10:06:16","slug":"redshift-data-lineage","status":"publish","type":"page","link":"https:\/\/www.gudusoft.com\/de\/datenlinie-der-rotverschiebung\/","title":{"rendered":"Redshift-Datenherkunft: Automatisierte Spaltenherkunft aus Abfrageprotokollen"},"content":{"rendered":"

Redshift-Datenherkunft<\/strong> Die Datenflusstabelle ist die spaltenbasierte Abbildung, die den Datenfluss durch Ihren Amazon Redshift-Cluster darstellt: welche Quelltabellen und -spalten die jeweiligen Zieltabelle, Ansichten und Berichte speisen und welche Transformationen dabei stattfinden. Redshift selbst speichert keine solche Abbildung, protokolliert aber jede ausgef\u00fchrte SQL-Anweisung, und in Redshift wird jede Transformation als SQL-Anweisung ausgedr\u00fcckt. Analysieren Sie diese Protokolle, und Sie k\u00f6nnen die vollst\u00e4ndige Datenherkunft automatisch rekonstruieren. Genau das ist es, was Gudu SQLFlow<\/a> Funktioniert: Es verarbeitet Redshift-Abfrageprotokolle nativ und wandelt die ausgef\u00fchrten SQL-Anweisungen in interaktive, spaltenbasierte Herkunftsdiagramme um.<\/p>\n\n\n\n

\n\n

Probieren Sie es in 30 Sekunden:<\/strong> F\u00fcgen Sie eine beliebige Redshift-Abfrage in die folgende ein: kostenloser SQLFlow-Lineage-Visualisierer<\/a>W\u00e4hlen Sie den Redshift-Dialekt aus und sehen Sie sofort das Spalten-Historiendiagramm. Die Cloud-Edition bietet ein kostenloses Kontingent.<\/p>\n\n<\/div><\/div>\n\n\n\n

Warum Redshift keine integrierte Lineage-Ansicht hat<\/h2>\n\n\n\n

Die Redshift-Konsole und die Systemansichten sind f\u00fcr den Clusterbetrieb konzipiert, nicht f\u00fcr das Verst\u00e4ndnis des Datenflusses. Sie k\u00f6nnen zwar die Abfrageleistung, das Verhalten der Warteschlange und Tabellenstatistiken untersuchen, aber Redshift stellt keine Verbindung zwischen Ausgabespalten und den Quellspalten her, aus denen sie stammen. Selbst die von PostgreSQL \u00fcbernommene Katalogabh\u00e4ngigkeitsverfolgung, die Redshift f\u00fcr eine seiner eigenen Funktionen nutzt, versagt: die sp\u00e4te Bindung von Ansichten (erstellt durch \u2026). OHNE SCHEMABINDUNG<\/code>) absichtlich keine Abh\u00e4ngigkeit von ihren zugrunde liegenden Tabellen aufzeichnen.<\/p>\n\n\n\n

Was Redshift beibeh\u00e4lt, ist das Rohmaterial: Systemtabellen wie beispielsweise STL_QUERYTEXT<\/code> Und SYS_QUERY_HISTORY<\/code> Der Text der ausgef\u00fchrten Anweisungen wird gespeichert, und die Audit-Protokollierung kann jede Abfrage zur Langzeitarchivierung in S3 archivieren. Die gesamte SQL-Historie ist vorhanden. Was fehlt, ist die Analyseebene, die Tausende dieser Anweisungen liest und die Frage beantwortet: \u201eWo wird \u2026?\u201c fact_orders.net_revenue<\/code> \u201eWoher stammen sie eigentlich?\u201c Diese Analyseebene ist ein SQL-Herkunftsanalyse-Tool.<\/p>\n\n\n\n

Wie man die Datenherkunft von Redshift aus Abfrageprotokollen ermittelt<\/h2>\n\n\n\n

Die auf Abfrageprotokollen basierende Herkunftsanalyse bietet einen entscheidenden Vorteil gegen\u00fcber der reinen Analyse der Quellcode-Repositories: Sie erfasst, was tats\u00e4chlich ausgef\u00fchrt wurde. Geplante ETL-Prozesse, Ad-hoc-Backfills, Anweisungen von BI-Tools und Orchestratoren, einmalige Korrekturen, die von einem SQL-Client ausgef\u00fchrt wurden \u2013 all dies landet im Abfrageverlauf, unabh\u00e4ngig davon, ob es in der Versionskontrolle gespeichert ist. Der Workflow mit SQLFlow:<\/p>\n\n\n\n

  1. Ausgef\u00fchrte SQL-Anweisungen sammeln.<\/strong> Anweisungstexte werden aus den Systemtabellen von Redshift oder aus den Audit-Logs, die Redshift in S3 schreibt, extrahiert. Die Erfassung von Redshift-Abfrageprotokollen erfolgt nativ \u00fcber SQLFlow, ebenso wie eingef\u00fcgtes SQL, hochgeladene Dateien und Live-Metadaten \u00fcber JDBC.<\/li>\n
  2. Mit einem Redshift-spezifischen Parser analysieren.<\/strong> SQLFlow analysiert jede Anweisung mit einem dedizierten Redshift-Dialektparser \u2013 einem von 39 dialektspezifischen Parsern, nicht mit einer generischen ANSI-Grammatik \u2013 und l\u00f6st jede Spaltenreferenz \u00fcber CTEs, Unterabfragen, Sichten und auf. W\u00c4HLEN *<\/code> Erweiterung.<\/li>\n
  3. Verschmelzen und erkunden.<\/strong> Die Herkunft jeder Anweisung wird in einem Diagramm zusammengef\u00fchrt, das Sie interaktiv analysieren, dessen Verlauf Sie von jeder Spalte aus vor- oder nachverfolgen und als JSON, CSV oder PNG exportieren oder abfragen k\u00f6nnen. SQLFlow REST-API<\/a>.<\/li><\/ol>\n\n\n\n

    Da es sich um eine statische Analyse von SQL-Text handelt, liest SQLFlow niemals die Zeilen Ihrer Tabellen. Es ben\u00f6tigt lediglich den SQL-Code und optional Schema-Metadaten, um mehrdeutige Verweise aufzul\u00f6sen.<\/p>\n\n\n\n

    Ein praktisches Beispiel: INSERT \u2026 SELECT mit einer Fensterfunktion<\/h2>\n\n\n\n

    Hier ist ein Beispiel f\u00fcr eine Anweisung, die ein echtes Redshift-Abfrageprotokoll f\u00fcllt \u2013 eine Aggregation mit einer Fensterfunktion, die eine Berichtstabelle l\u00e4dt:<\/p>\n\n\n\n

    INSERT INTO analytics.customer_monthly_rank (customer_id, order_month, monthly_revenue, revenue_rank) SELECT o.customer_id, DATE_TRUNC('month', o.order_date) AS order_month, SUM(o.amount) AS monthly_revenue, RANK() OVER ( PARTITION BY DATE_TRUNC('month', o.order_date) ORDER BY SUM(o.amount) DESC ) AS revenue_rank FROM sales.orders o WHERE o.status = 'complete' GROUP BY o.customer_id, DATE_TRUNC('month', o.order_date);<\/code><\/pre>\n\n\n\n
    Aus dieser einzelnen Anweisung extrahiert SQLFlow die Spaltenherkunft in zwei verschiedenen Kategorien:<\/p>\n\n\n\n
    \n
    Zielspalte<\/th>Direkte Quellen<\/th>Indirekte (Auswirkungs-)Quellen<\/th><\/tr><\/thead>
    Kunden-ID<\/code><\/td>orders.customer_id<\/code><\/td>Bestellungen.Status<\/code> (WO)<\/td><\/tr>\n
    Bestellmonat<\/code><\/td>orders.order_date<\/code> \u00fcber DATE_TRUNC<\/code><\/td>Bestellungen.Status<\/code><\/td><\/tr>\n
    monatlicher Umsatz<\/code><\/td>Bestellungen.Betrag<\/code> \u00fcber SUMME<\/code><\/td>Bestellungen.Status<\/code>, orders.customer_id<\/code>, orders.order_date<\/code> (GRUPPE DURCH)<\/td><\/tr>\n
    Umsatzrang<\/code><\/td>Bestellungen.Betrag<\/code> \u00fcber SUMME<\/code> Dann RANK() \u00dcBER<\/code><\/td>orders.order_date<\/code> (PARTITION BY), Bestellungen.Status<\/code><\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n
    Beachten Sie die zweite Kategorie. Bestellungen.Status<\/code> Die Werte landen nie in der Ausgabe, doch die Art der Bef\u00fcllung \u00e4ndert jede Zahl in der Zieltabelle. SQLFlow modelliert dies. indirekte Abstammung<\/strong> Spalten, die \u00fcber WHERE-, GROUP BY- und JOIN-Bedingungen sowie Fensterpartitionen wirken, werden als separater, umschaltbarer Beziehungstyp behandelt. Die meisten Datenherkunftsanalyse-Tools unterscheiden nicht zwischen diesen Spalten, obwohl dies den Unterschied zwischen \u201eWelche Berichte lesen diese Spalte?\u201c und \u201eWelche Berichte werden von dieser Spalte beeinflusst?\u201c ausmacht.<\/p>\n\n\n\n
    Redshift-spezifische Konstrukte sind immer noch einfach SQL.<\/h2>\n\n\n\n
    Sp\u00e4tbindende Ansichten<\/h3>\n\n\n\n
    Sp\u00e4tbindende Sichten sind das Standardmuster in Redshift, um Sichten von zugrunde liegenden Tabellen zu entkoppeln, und sie sind systembedingt f\u00fcr katalogbasierte Abh\u00e4ngigkeitsabfragen unsichtbar. F\u00fcr einen SQL-Parser ist eine sp\u00e4tbindende Sicht jedoch lediglich eine Sichtdefinition: SQLFlow analysiert die SELECT-Anweisung der Sicht und verbindet ihre Ausgabespalten wie bei jeder anderen Sicht mit ihren Quellen, sodass die Datenherkunft direkt durchl\u00e4uft. OHNE SCHEMABINDUNG<\/code>.<\/p>\n\n\n\n
    DISTKEY, SORTKEY und DISTSTYLE<\/h3>\n\n\n\n
    Verteilungs- und Sortierschl\u00fcssel beeinflussen die Performance, nicht den Datenfluss. Eine Tabelle, die mit DISTKEY(customer_id) SORTKEY(order_date)<\/code> Die Tabelle beh\u00e4lt dieselbe Herkunft wie jede andere Tabelle; SQLFlow analysiert das Redshift-DDL, erfasst die Tabelle und ihre Spalten, und die physischen Optimierungsklauseln werden ohne Beeintr\u00e4chtigung des Graphen weitergeleitet. Ihre Herkunft bleibt korrekt, unabh\u00e4ngig davon, ob eine Tabelle \u2026 DISTYLE ALL<\/code>, SOGAR<\/code>, oder SCHL\u00dcSSEL<\/code>.<\/p>\n\n\n\n
    Redshift ist nicht PostgreSQL.<\/h3>\n\n\n\n
    Redshift stammt zwar von PostgreSQL ab, unterscheidet sich aber in Syntax und Verhalten erheblich. Daher verwendet SQLFlow einen eigenen Redshift-Parser, anstatt den vorhandenen wiederzuverwenden. PostgreSQL-Abstammung<\/a> parser \u2014 each of the 39 supported dialects gets its own grammar, validated against a corpus of roughly 13,600 per-dialect SQL test fixtures built up over two decades of commercial parser development.<\/p>\n\n\n\n
    M\u00f6glichkeiten, Redshift-SQL in SQLFlow einzuspeisen<\/h2>\n\n\n\n
    \n
    Eingang<\/th>Was es dir gibt<\/th><\/tr><\/thead>
    Redshift-Abfrageprotokolle<\/td>Die Herkunft jeder abgegebenen Erkl\u00e4rung \u2013 das vollst\u00e4ndige, wahrheitsgetreue Bild<\/td><\/tr>\n
    Live-Metadaten \u00fcber JDBC<\/td>DDL- und Ansichtsdefinitionen werden direkt aus dem Cluster abgerufen.<\/td><\/tr>\n
    Hochgeladene SQL-Dateien<\/td>ETL-Skripte und Repositories wurden als Batch analysiert<\/td><\/tr>\n
    Eingef\u00fcgter SQL-Code<\/td>Sofortige Herkunftsbestimmung f\u00fcr eine einzelne Anweisung im Browser<\/td><\/tr>\n
    DBT-Manifest<\/td>Spaltenbasierte Herkunftsnachverfolgung in dbt-Modellen, die in Redshift erstellt werden<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n
    Im Enterprise-Ma\u00dfstab scannt SQLFlow im Batch-Verfahren Best\u00e4nde von mehr als 100 Datenbanken und \u00fcber einer Million Spalten, f\u00fchrt inkrementelle Scans durch, pflegt ein persistentes Herkunftsarchiv und exportiert Daten nach DataHub, Microsoft Purview und OpenMetadata \u2013 so dass die Redshift-Herkunftsdaten in den bereits laufenden Katalog einflie\u00dfen k\u00f6nnen, anstatt in einem weiteren Datensilo zu liegen.<\/p>\n\n\n\n
    Wie verh\u00e4lt sich dieser Ansatz zu anderen?<\/h2>\n\n\n\n
    Open-Source-Parser wie zum Beispiel sqllineage<\/code> Und sqlglot<\/code> Sie eignen sich gut, um die Herkunft einzelner, wohlgeformter Anweisungen zu extrahieren, und f\u00fcr einige wenige saubere Abfragen m\u00f6gen sie ausreichend sein. Die L\u00fccke entsteht jedoch bei einem produktiven Redshift-Log: Tausende von Anweisungen, Redshift-spezifische Syntax, aufeinander geschichtete Ansichten, W\u00c4HLEN *<\/code> Dies erfordert Schema-Metadaten zur Erweiterung und indirekte Herkunftsinformationen \u00fcber Filter und Fensterpartitionen. Katalogbasierte Plattformen eignen sich hervorragend zur Organisation und Verwaltung von Metadaten \u00fcber viele Systeme hinweg; f\u00fcr tiefgreifende SQL-Analysen ben\u00f6tigen sie in der Regel eine spezialisierte Herkunfts-Engine \u2013 weshalb SQLFlow Exportadapter f\u00fcr DataHub, Purview und OpenMetadata bereitstellt, anstatt mit diesen zu konkurrieren.<\/p>\n\n\n\n
    Wenn Sie Redshift zusammen mit anderen Data Warehouses betreiben, wird dieselbe Engine mit demselben Ansatz f\u00fcr alle verwendet \u2013 siehe Snowflake-Datenherkunft<\/a> aus dem Abfrageverlauf, was \u00e4hnlich wie die protokollbasierte Datenerfassung von Redshift funktioniert. Und f\u00fcr regulierte Umgebungen SQLFlow vor Ort<\/a> l\u00e4uft in Docker oder Kubernetes innerhalb Ihres Netzwerks, sodass Ihr SQL-Text Ihre Infrastruktur niemals verl\u00e4sst.<\/p>\n\n\n\n
    H\u00e4ufig gestellte Fragen<\/h2>\n\n\n\n
    Kann SQLFlow die Daten in meinem Redshift-Cluster lesen?<\/h3>\n\n\n
    Nein. SQLFlow f\u00fchrt eine statische Analyse des SQL-Codes durch und liest optional Schema-Metadaten (Tabellen- und Spaltendefinitionen). Es liest niemals Tabellenzeilen. Bei der On-Premise-Edition bleibt sogar der SQL-Text innerhalb Ihres Netzwerks.<\/p>\n\n\n\n
    Woher stammt das Redshift-SQL?<\/h3>\n\n\n
    Unabh\u00e4ngig davon, wo Ihre ausgef\u00fchrten Anweisungen gespeichert sind: in den Systemtabellen des Redshift-Abfrageverlaufs, in den in S3 archivierten Audit-Logs, in Ihren ETL-Skript-Repositories oder in den DDL- und View-Definitionen, die live \u00fcber JDBC abgerufen werden. Die Redshift-Abfrageprotokollaufnahme ist ein nativer SQLFlow-Input, sodass die Herkunft der Anweisungen genau dem entspricht, was tats\u00e4chlich im Cluster ausgef\u00fchrt wurde.<\/p>\n\n\n\n
    Stellen sp\u00e4te Bindungen von Ansichten ein Problem f\u00fcr die Abstammungsanalyse dar?<\/h3>\n\n\n
    Sie umgehen die katalogbasierte Abh\u00e4ngigkeitsverfolgung, da Redshift systembedingt keine Abh\u00e4ngigkeiten f\u00fcr sie speichert. F\u00fcr die parserbasierte Herkunftsanalyse stellen sie kein Problem dar: SQLFlow analysiert die SQL-Definition der Ansicht direkt und verbindet ihre Spalten wie jede andere Ansicht mit ihren Quellen.<\/p>\n\n\n\n
    Zeigt SQLFlow an, welche Spalten die Ergebnisse nur \u00fcber Filter beeinflussen?<\/h3>\n\n\n
    Ja. SQLFlow unterscheidet zwischen direkter Datenherkunft (Daten, die tats\u00e4chlich in eine Ausgabespalte flie\u00dfen) und indirekter Datenherkunft (Spalten, die \u00fcber WHERE-, JOIN-, GROUP BY- und Window-Partition-Klauseln wirken) und erm\u00f6glicht es Ihnen, jede einzelne im Diagramm unabh\u00e4ngig voneinander umzuschalten.<\/p>\n\n\n\n
    Wie viel kostet SQLFlow?<\/h3>\n\n\n
    SQLFlow Cloud ist kostenlos; Premium-Konten kosten $49,99\/Monat. SQLFlow On-Premise kostet $500\/Monat oder einmalig $4.800 pro ausgew\u00e4hltem Datenbanktyp und kann auf zwei Servern installiert werden. Jeder weitere Datenbanktyp kostet $100\/Monat oder einmalig $1.000.<\/p>\n\n\n\n
    \n\n
    Sehen Sie sich jetzt Ihre Redshift-Abstammungslinie an.<\/h2>\n\n\n
    F\u00fcgen Sie eine Redshift-Abfrage in den kostenlosen Visualisierer ein oder sprechen Sie mit uns \u00fcber das Scannen Ihrer gesamten Abfragehistorie.<\/p>\n\n\n
    \n
    Testen Sie SQLFlow kostenlos<\/a><\/div>\n\n\n
    Fordern Sie eine Enterprise-Demo an<\/a><\/div>\n<\/div>\n\n<\/div><\/div>\n\n\n\n