Trino- und Presto-Datenherkunft: Spaltenherkunft in föderiertem SQL

Trino-Datenherkunft ist die Spaltenübersicht, die den Datenfluss durch Trino (und Presto) SQL darstellt: welche Quellspalten in welchen Katalogen welche Ausgabespalten speisen und welche Joins, Funktionen und Filter verwendet werden. Da Trino eine föderierte Abfrage-Engine ist, kann eine einzelne Anweisung aus verschiedenen Quellen lesen. Bienenstock, PostgreSQL, Und Eisberg Kataloge gleichzeitig – daher muss eine genaue Herkunftsbestimmung jede Spalte auf ihren vollständig qualifizierten Eintrag auflösen. catalog.schema.table.column Identität, nicht nur ein Tabellenname. Gudu SQLFlow Dies geschieht mithilfe von speziellen Dialektparsern für Trino und Presto.

Warum die Föderation die Datenherkunft von Trino erschwert

In einem herkömmlichen Data Warehouse ist die Herkunftsnachverfolgung innerhalb einer einzigen Datenbank geregelt: Jede Tabelle in einer Abfrage gehört zum selben System, und ein zweiteiliger Name wie Bestellungen ist eindeutig. Trino widerspricht dieser Annahme. Sein einziger Zweck besteht darin, Daten zusammenzuführen. über Systeme – eine Hive-Tabelle auf S3, eine operative PostgreSQL-Datenbank und eine Iceberg-Lakehouse-Tabelle können alle im selben System erscheinen WÄHLEN.

Dadurch entstehen drei Probleme, mit denen die meisten Lineage-Tools nur schlecht umgehen können:

• Namenskonflikte in verschiedenen Katalogen. hive.sales.orders Und postgresql.sales.orders Es handelt sich um unterschiedliche physische Tabellen in verschiedenen Systemen. Die Datenherkunftsanalyse, die den Katalogqualifizierer entfernt, führt sie zu einem einzigen Knoten zusammen – und jede darauf basierende Folgewirkungsanalyse ist fehlerhaft.
• Teilqualifikation. In realen Abfragen werden dreiteilige Namen selten überall explizit ausgeschrieben. Sie basieren auf dem Standardkatalog und -schema der Sitzung, Aliasen und VERWENDEN Aussagen. Der Resolver muss die vollständige Identität jeder Spaltenreferenz aus diesem Kontext rekonstruieren.
• Systemgrenzen überschreiten in einer Aussage. Ein IN DEN EISBER EINFÜGEN.... eine Datenbewegung, die Daten aus Hive und PostgreSQL auswählt. zwischen drei Systemen In einer einzigen Aussage ausgedrückt. Die Herkunft auf Tabellenebene zeigt Ihnen die betroffenen Systeme; nur die Herkunft auf Spaltenebene zeigt Ihnen, welche PostgreSQL-Spalte in welcher Iceberg-Spalte gelandet ist.

Der semantische Resolver von SQLFlow behält die vollständige catalog.schema.table.column Pfad auf jedem Knoten im Abstammungsgraphen, sodass katalogübergreifende Spalten getrennt und von Anfang bis Ende nachvollziehbar bleiben.

Ein praktisches Beispiel: Iceberg-Ziel, Hive- und PostgreSQL-Quellen

Hier ein typischer föderierter Schreibvorgang – Erstellung einer Kundenwerttabelle in einem Iceberg-Katalog aus einer betriebsbereiten PostgreSQL-Datenbank, die mit der Hive-Bestellhistorie verknüpft ist:

INSERT INTO iceberg.analytics.customer_value SELECT c.customer_id, lower(c.email) AS email, sum(o.order_total) AS lifetime_value, count(*) AS order_count FROM postgresql.crm.customers AS c JOIN hive.sales.orders AS o ON c.customer_id = o.customer_id WHERE o.order_status = 'COMPLETED' GROUP BY c.customer_id, lower(c.email);

Führen Sie dies mit SQLFlow und dem ausgewählten Trino-Dialekt durch. Das Diagramm zeigt dann die Ausgabe pro Spalte:

Zielspalte (iceberg.analytics.customer_value)	Quelle Spalte	Beziehung
Kunden-ID	postgresql.crm.customers.customer_id	Direkt, Durchleitung
E-Mail	postgresql.crm.customers.email	Direkt, über untere()
Lebensdauerwert	hive.sales.orders.order_total	Direkt, über Summe()
Anzahl der Bestellungen	hive.sales.orders Zeilen	Direkt, über zählen(*)
alle Spalten	hive.sales.orders.order_status	Indirekt (WHERE-Filter)
alle Spalten	o.customer_id / c.customer_id	Indirekt (Verknüpfungsbedingung, Gruppierung nach)

Beachten Sie die letzten beiden Zeilen. Bestellstatus landet nie in der Ausgabe, aber die Art und Weise, wie es befüllt wird, ändert jede Zahl in KundenwertSQLFlow modelliert dies als indirekte (Einfluss-)AbstammungslinieEs handelt sich um einen separaten, umschaltbaren Beziehungstyp neben dem direkten Datenfluss. Die meisten Datenherkunftstools unterscheiden nicht zwischen diesen beiden Aspekten. Genau diese Information benötigen Sie jedoch, bevor Sie eine Filterspalte in einer gemeinsam genutzten Hive-Tabelle bearbeiten.

Trino und Presto sind unterschiedliche Dialekte – SQLFlow analysiert beide.

Trino entstand aus Presto (als PrestoSQL) und wurde 2020 umbenannt; seitdem haben sich die beiden Dialekte auseinanderentwickelt. SQLFlow wird ausgeliefert. separate dialektspezifische Parser für Trino und für PrestoUnter den 39 unterstützten Dialekten befindet sich keine generische ANSI-Grammatik mit Kompatibilitätskennzeichen. Wenn in Ihrer Umgebung PrestoDB neben einem neueren Trino-Cluster betrieben wird, wählen Sie den passenden Dialekt pro Quelle aus, und beide werden korrekt geparst.

Die Parser stammen vom General SQL Parser (GSP), einem kommerziellen SQL-Compiler-Frontend, das seit Mitte der 2000er-Jahre entwickelt und anhand von rund 13.600 dialektspezifischen Testdaten validiert wurde. GSP erstellt ein vollständiges semantisches Modell jeder Anweisung und löst Spaltenreferenzen mithilfe von CTEs, Unterabfragen, Sichten und anderen Methoden auf. WÄHLEN * Expansion – und ihr Datenflussanalysator extrahiert die Quell-Ziel-Beziehungen. Die Sternexpansion ist in Trino wichtiger als fast überall sonst: WÄHLEN * Bei einem föderierten Join werden Spalten aus mehreren Systemen abgerufen, und für die korrekte Erweiterung werden die Schema-Metadaten jedes Katalogs benötigt, die SQLFlow zusammen mit dem SQL-Code einlesen kann.

Wie man Trino-Herkunftsinformationen mit SQLFlow generiert

1. Sammeln Sie die SQL-Anweisungen. Einzelne Abfragen einfügen, ETL-Skriptdateien hochladen und Definitionen anzeigen oder Metadaten über JDBC abrufen. Für eine umfassende Abdeckung des gesamten Immobilienbestands bietet sich Grabit/ an.SQLFlow-Ingester Das Dienstprogramm extrahiert Metadaten im Batch-Verfahren.
2. Wähle den Dialekt. Je nach Quelle Trino oder Presto verwenden. Enthält dieselbe Pipeline auch Hive-DDL- oder Spark-SQL-Jobs, analysieren Sie jeden in seinem eigenen Dialekt; SQLFlow unterstützt alle, und in Unternehmensumgebungen werden die Ergebnisse in einem persistenten Herkunftsarchiv gespeichert.
3. Erkunden und exportieren. Verfolgen Sie beliebige Spalten in der interaktiven Diagrammstruktur vorwärts oder rückwärts, aktivieren oder deaktivieren Sie die indirekte Datenherkunft und exportieren Sie die Daten als JSON, CSV oder PNG – oder fragen Sie den Graphen über die REST-API ab. Seit Version 8.2.3 können Sie auch Fragen in natürlicher Sprache stellen („Welche Iceberg-Tabellen hängen von … ab?“). postgresql.crm.customers.emailJede Tabelle und Spalte in der Antwort der KI wird vor der Anzeige anhand des analysierten Diagramms validiert.

Im Enterprise-Maßstab durchsucht SQLFlow im Batch-Verfahren Bestände von mehr als 100 Datenbanken und über einer Million Spalten, führt inkrementelle Scans durch, verwaltet ein persistentes Herkunftsarchiv und exportiert die Daten nach DataHub, Microsoft Purview und OpenMetadata – so landet die Trino-Herkunft in dem Katalog, den Ihr Team bereits verwendet.

Statische SQL-Analyse vs. Laufzeit-Ereignisherkunft

Eine weitere gängige Methode zur Ermittlung der Trino-Ablaufverfolgung ist die Laufzeiterfassung: Dabei werden die Abfrageereignisse der Engine abgefangen und die Ablaufverfolgung für jede ausgeführte Anweisung ausgegeben (so funktioniert das OpenLineage-Ökosystem). Die Laufzeiterfassung zeichnet sehr gut auf, was tatsächlich ausgeführt wurde, inklusive des realen Sitzungskontexts. Ihre Schwäche liegt in der Abdeckung und Tiefe: Sie erfasst nur Abfragen, die während des Erfassungszeitraums ausgeführt wurden, und erfordert die Instrumentierung jedes Clusters.

Die statische Analyse, der Ansatz von SQLFlow, analysiert den SQL-Code selbst. Dies umfasst geplante Jobs, die noch nicht ausgeführt wurden, Ansichtsdefinitionen und Repository-Code, der sich in der Überprüfung befindet – und benötigt keinen Agenten im Cluster und liest niemals Tabellenzeilendaten. In regulierten Umgebungen On-Premise-Edition (Docker/Kubernetes) hält sogar den SQL-Text innerhalb Ihres Netzwerks. Viele Teams nutzen beides: Laufzeitereignisse für die Betriebsüberwachung und statische Analysen für eine umfassende Folgenabschätzung vor der Bereitstellung.

Herkunft im restlichen Stack

Trino ist selten die ganze Geschichte. Die abgefragten Hive-Tabellen wurden üblicherweise von Hive- oder Spark-Jobs geladen, und die Ergebnisse fließen oft in nachgelagerte Data Marts ein. SQLFlow analysiert diese Ebenen mit derselben Engine – siehe die entsprechenden Anleitungen. Hive-Datenherkunft Und ClickHouse-Datenherkunftoder das vollständige Überblick über SQL-Datenherkunftstools Alle 39 Dialekte werden abgedeckt. Da jede Ebene im persistenten Herkunftsarchiv analysiert wird, lässt sich eine Spalte vom Spark-Job, der die Hive-Tabelle geschrieben hat, über die föderierte Trino-Abfrage bis zum Iceberg-Ziel verfolgen.

Häufig gestellte Fragen

Unterstützt SQLFlow sowohl Trino als auch Presto?

Ja. Trino und Presto sind zwei der 39 dialektspezifischen Parser von SQLFlow. Wählen Sie den Dialekt, der zu Ihrer Engine passt. Wenn Sie beide Parser verwenden, analysieren Sie jede Datenquelle mit ihrem jeweiligen Dialekt.

Kann SQLFlow die Herkunft über Trino-Kataloge hinweg nachverfolgen?

Ja. SQLFlow löst jede Spalte in ihre vollqualifizierte catalog.schema.table.column-Identität auf, sodass eine Abfrage, die Hive-, PostgreSQL- und Iceberg-Kataloge verknüpft, eine Herkunftsnachverfolgung erzeugt, die die Spalten jedes Systems getrennt hält – auch bei INSERT-Anweisungen, die Daten zwischen Katalogen verschieben.

Benötigt SQLFlow Zugriff auf meinen Trino-Cluster oder meine Daten?

Nein. SQLFlow führt eine statische Analyse von SQL-Code durch und verwendet optional Schema-Metadaten zur Namensauflösung und Erweiterung von SELECT *. Es liest niemals Tabellenzeilen und benötigt keinen Agenten im Cluster. Die On-Premise-Edition hält den SQL-Text vollständig innerhalb Ihres Netzwerks.

Was zeigt SQLFlow für Spalten in WHERE- und JOIN-Klauseln an?

Sie erscheinen als indirekte (Auswirkungs-)Herkunft: ein separater Beziehungstyp für Spalten, die das Ergebnis beeinflussen, ohne direkt in der Ausgabe zu erscheinen. Sie können die indirekte Herkunft im Diagramm ein- und ausschalten – eine Unterscheidung, die die meisten Herkunftsanalyse-Tools gar nicht vornehmen.

Kann ich die Trino-Herkunft in meinen Datenkatalog exportieren?

Ja. Enterprise-Implementierungen umfassen Exportadapter für DataHub, Microsoft Purview und OpenMetadata sowie JSON- und CSV-Export und eine REST-API für benutzerdefinierte Integrationen.

Wie viel kostet SQLFlow?

SQLFlow Cloud ist kostenlos; die Premium-Version kostet 1 TP3T49,99/Monat. SQLFlow On-Premise kostet 1 TP3T500/Monat oder einmalig 1 TP3T4.800 pro ausgewähltem Datenbanktyp und kann auf zwei Servern installiert werden. Siehe Preisgestaltung für weitere Details.