Redshift-Datenherkunft: Automatisierte Spaltenherkunft aus Abfrageprotokollen

Redshift-Datenherkunft 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ührte SQL-Anweisung, und in Redshift wird jede Transformation als SQL-Anweisung ausgedrückt. Analysieren Sie diese Protokolle, und Sie können die vollständige Datenherkunft automatisch rekonstruieren. Genau das ist es, was Gudu SQLFlow Funktioniert: Es verarbeitet Redshift-Abfrageprotokolle nativ und wandelt die ausgeführten SQL-Anweisungen in interaktive, spaltenbasierte Herkunftsdiagramme um.

Warum Redshift keine integrierte Lineage-Ansicht hat

Die Redshift-Konsole und die Systemansichten sind für den Clusterbetrieb konzipiert, nicht für das Verständnis des Datenflusses. Sie können 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 übernommene Katalogabhängigkeitsverfolgung, die Redshift für eine seiner eigenen Funktionen nutzt, versagt: die späte Bindung von Ansichten (erstellt durch …). OHNE SCHEMABINDUNG) absichtlich keine Abhängigkeit von ihren zugrunde liegenden Tabellen aufzeichnen.

Was Redshift beibehält, ist das Rohmaterial: Systemtabellen wie beispielsweise STL_QUERYTEXT Und SYS_QUERY_HISTORY Der Text der ausgeführten 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: „Wo wird …?“ fact_orders.net_revenue „Woher stammen sie eigentlich?“ Diese Analyseebene ist ein SQL-Herkunftsanalyse-Tool.

Wie man die Datenherkunft von Redshift aus Abfrageprotokollen ermittelt

Die auf Abfrageprotokollen basierende Herkunftsanalyse bietet einen entscheidenden Vorteil gegenüber der reinen Analyse der Quellcode-Repositories: Sie erfasst, was tatsächlich ausgeführt wurde. Geplante ETL-Prozesse, Ad-hoc-Backfills, Anweisungen von BI-Tools und Orchestratoren, einmalige Korrekturen, die von einem SQL-Client ausgeführt wurden – all dies landet im Abfrageverlauf, unabhängig davon, ob es in der Versionskontrolle gespeichert ist. Der Workflow mit SQLFlow:

1. Ausgeführte SQL-Anweisungen sammeln. 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 über SQLFlow, ebenso wie eingefügtes SQL, hochgeladene Dateien und Live-Metadaten über JDBC.
2. Mit einem Redshift-spezifischen Parser analysieren. SQLFlow analysiert jede Anweisung mit einem dedizierten Redshift-Dialektparser – einem von 39 dialektspezifischen Parsern, nicht mit einer generischen ANSI-Grammatik – und löst jede Spaltenreferenz über CTEs, Unterabfragen, Sichten und auf. WÄHLEN * Erweiterung.
3. Verschmelzen und erkunden. Die Herkunft jeder Anweisung wird in einem Diagramm zusammengeführt, das Sie interaktiv analysieren, dessen Verlauf Sie von jeder Spalte aus vor- oder nachverfolgen und als JSON, CSV oder PNG exportieren oder abfragen können. SQLFlow REST-API.

Da es sich um eine statische Analyse von SQL-Text handelt, liest SQLFlow niemals die Zeilen Ihrer Tabellen. Es benötigt lediglich den SQL-Code und optional Schema-Metadaten, um mehrdeutige Verweise aufzulösen.

Ein praktisches Beispiel: INSERT … SELECT mit einer Fensterfunktion

Hier ist ein Beispiel für eine Anweisung, die ein echtes Redshift-Abfrageprotokoll füllt – eine Aggregation mit einer Fensterfunktion, die eine Berichtstabelle lädt:

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);

Aus dieser einzelnen Anweisung extrahiert SQLFlow die Spaltenherkunft in zwei verschiedenen Kategorien:

Zielspalte	Direkte Quellen	Indirekte (Auswirkungs-)Quellen
Kunden-ID	orders.customer_id	Bestellungen.Status (WO)
Bestellmonat	orders.order_date über DATE_TRUNC	Bestellungen.Status
monatlicher Umsatz	Bestellungen.Betrag über SUMME	Bestellungen.Status, orders.customer_id, orders.order_date (GRUPPE DURCH)
Umsatzrang	Bestellungen.Betrag über SUMME Dann RANK() ÜBER	orders.order_date (PARTITION BY), Bestellungen.Status

Beachten Sie die zweite Kategorie. Bestellungen.Status Die Werte landen nie in der Ausgabe, doch die Art der Befüllung ändert jede Zahl in der Zieltabelle. SQLFlow modelliert dies. indirekte Abstammung Spalten, die über 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 „Welche Berichte lesen diese Spalte?“ und „Welche Berichte werden von dieser Spalte beeinflusst?“ ausmacht.

Redshift-spezifische Konstrukte sind immer noch einfach SQL.

Spätbindende Ansichten

Spätbindende Sichten sind das Standardmuster in Redshift, um Sichten von zugrunde liegenden Tabellen zu entkoppeln, und sie sind systembedingt für katalogbasierte Abhängigkeitsabfragen unsichtbar. Für einen SQL-Parser ist eine spätbindende 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äuft. OHNE SCHEMABINDUNG.

DISTKEY, SORTKEY und DISTSTYLE

Verteilungs- und Sortierschlüssel beeinflussen die Performance, nicht den Datenfluss. Eine Tabelle, die mit DISTKEY(customer_id) SORTKEY(order_date) Die Tabelle behält dieselbe Herkunft wie jede andere Tabelle; SQLFlow analysiert das Redshift-DDL, erfasst die Tabelle und ihre Spalten, und die physischen Optimierungsklauseln werden ohne Beeinträchtigung des Graphen weitergeleitet. Ihre Herkunft bleibt korrekt, unabhängig davon, ob eine Tabelle … DISTYLE ALL, SOGAR, oder SCHLÜSSEL.

Redshift ist nicht PostgreSQL.

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 parser — 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.

Möglichkeiten, Redshift-SQL in SQLFlow einzuspeisen

Eingang	Was es dir gibt
Redshift-Abfrageprotokolle	Die Herkunft jeder abgegebenen Erklärung – das vollständige, wahrheitsgetreue Bild
Live-Metadaten über JDBC	DDL- und Ansichtsdefinitionen werden direkt aus dem Cluster abgerufen.
Hochgeladene SQL-Dateien	ETL-Skripte und Repositories wurden als Batch analysiert
Eingefügter SQL-Code	Sofortige Herkunftsbestimmung für eine einzelne Anweisung im Browser
DBT-Manifest	Spaltenbasierte Herkunftsnachverfolgung in dbt-Modellen, die in Redshift erstellt werden

Im Enterprise-Maßstab scannt SQLFlow im Batch-Verfahren Bestände von mehr als 100 Datenbanken und über einer Million Spalten, führt inkrementelle Scans durch, pflegt ein persistentes Herkunftsarchiv und exportiert Daten nach DataHub, Microsoft Purview und OpenMetadata – so dass die Redshift-Herkunftsdaten in den bereits laufenden Katalog einfließen können, anstatt in einem weiteren Datensilo zu liegen.

Wie verhält sich dieser Ansatz zu anderen?

Open-Source-Parser wie zum Beispiel sqllineage Und sqlglot Sie eignen sich gut, um die Herkunft einzelner, wohlgeformter Anweisungen zu extrahieren, und für einige wenige saubere Abfragen mögen sie ausreichend sein. Die Lücke entsteht jedoch bei einem produktiven Redshift-Log: Tausende von Anweisungen, Redshift-spezifische Syntax, aufeinander geschichtete Ansichten, WÄHLEN * Dies erfordert Schema-Metadaten zur Erweiterung und indirekte Herkunftsinformationen über Filter und Fensterpartitionen. Katalogbasierte Plattformen eignen sich hervorragend zur Organisation und Verwaltung von Metadaten über viele Systeme hinweg; für tiefgreifende SQL-Analysen benötigen sie in der Regel eine spezialisierte Herkunfts-Engine – weshalb SQLFlow Exportadapter für DataHub, Purview und OpenMetadata bereitstellt, anstatt mit diesen zu konkurrieren.

Wenn Sie Redshift zusammen mit anderen Data Warehouses betreiben, wird dieselbe Engine mit demselben Ansatz für alle verwendet – siehe Snowflake-Datenherkunft aus dem Abfrageverlauf, was ähnlich wie die protokollbasierte Datenerfassung von Redshift funktioniert. Und für regulierte Umgebungen SQLFlow vor Ort läuft in Docker oder Kubernetes innerhalb Ihres Netzwerks, sodass Ihr SQL-Text Ihre Infrastruktur niemals verlässt.

Häufig gestellte Fragen

Kann SQLFlow die Daten in meinem Redshift-Cluster lesen?

Nein. SQLFlow führt 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.

Woher stammt das Redshift-SQL?

Unabhängig davon, wo Ihre ausgeführten 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 über JDBC abgerufen werden. Die Redshift-Abfrageprotokollaufnahme ist ein nativer SQLFlow-Input, sodass die Herkunft der Anweisungen genau dem entspricht, was tatsächlich im Cluster ausgeführt wurde.

Stellen späte Bindungen von Ansichten ein Problem für die Abstammungsanalyse dar?

Sie umgehen die katalogbasierte Abhängigkeitsverfolgung, da Redshift systembedingt keine Abhängigkeiten für sie speichert. Für 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.

Zeigt SQLFlow an, welche Spalten die Ergebnisse nur über Filter beeinflussen?

Ja. SQLFlow unterscheidet zwischen direkter Datenherkunft (Daten, die tatsächlich in eine Ausgabespalte fließen) und indirekter Datenherkunft (Spalten, die über WHERE-, JOIN-, GROUP BY- und Window-Partition-Klauseln wirken) und ermöglicht es Ihnen, jede einzelne im Diagramm unabhängig voneinander umzuschalten.

Wie viel kostet SQLFlow?

SQLFlow Cloud ist kostenlos; Premium-Konten kosten $49,99/Monat. SQLFlow On-Premise kostet $500/Monat oder einmalig $4.800 pro ausgewähltem Datenbanktyp und kann auf zwei Servern installiert werden. Jeder weitere Datenbanktyp kostet $100/Monat oder einmalig $1.000.