versionierte Data-Lake-Tabellen in LakeFS und Trino / Sudo Null IT News

Mannschaft VK-Cloud hat bereits einen Artikel über die Bereitstellung eines lokalen Datenstapels mit dem Tool Everything Bagel übersetzt. Jetzt übersetzen wir den zweiten Teil, in dem wir in der Praxis analysieren, wie Abfragen auf gegabelten LakeFS-Daten durch den verteilten Abfragemechanismus von Trino ausgeführt werden.


Übertragen der Pipeline auf Docker-Rails

Ich erinnere mich noch an die Zeiten, als mein Unternehmen auf neue Technologien umgestiegen ist: Redis, Kafka, Spark, und um sie zu verstehen, lese ich diese Inschriften auf dem Bildschirm:


Downloadseiten für beliebte IT-Lösungen

Damals habe ich gar nicht darüber nachgedacht. Außerdem war ich stolz darauf, selbst herausfinden zu können, wie man moderne IT-Lösungen installiert und betreibt.

Dies ist zwar eine wertvolle Fähigkeit, aber aus Sicht des Unternehmens ist eine solche lokale Installation, die von jedem Entwickler einzeln manuell durchgeführt wird, eine fantastische Zeitverschwendung und als Folge eine Verringerung der Produktivität.

Vor allem, wenn es Verwirrung über kleine Details wie Release-Version und Abhängigkeiten gibt. Wie können Sie nachverfolgen, ob Sie den richtigen Weg verlassen haben? Wenn Sie beispielsweise eine JAR-Datei über Slack an einen Kollegen senden, haben Sie den Tiefpunkt erreicht.

Eine zivilisierte Art, lokale Installationen zu organisieren

Ein Ansatz zur Lösung dieses Problems besteht darin, den lokalen Installationsprozess zu standardisieren und zu vereinfachen.

In einem früheren Artikel

Ich habe darüber gesprochen, wie es mit Docker Everything Bagel funktioniert.

Kurz gesagt: Everything Bagel ist eine Docker-Compose-Umgebung, in der Sie verschiedene Technologien verwenden können, um mit einem einzigen Befehl mit Big Data zu arbeiten: MinIO, lakeFS, Hive, Spark und Trino. Mit den in Bagel implementierten Docker-Konzepten können Sie nahezu jede Datenpipeline lokal replizieren.


LakeS Docker Compose-Public-Environment-Diagramm

In diesem Artikel möchte ich das alles in Aktion zeigen. Folgend großartiges Beispiel von Brian Olsen von Starburst zeigen wir Ihnen, wie Sie Trino verwenden, um Daten auf verschiedenen Zweigen von lakeFS abzufragen.

Verbindung mit Trino Container mit Database Manager

Im vorherigen Artikel hatten wir Zeit, zum Trino-Container zu gehen und einige Abfragebefehle auszuführen, um zu zeigen, wie er funktioniert. Die Wahrheit ist jedoch, dass niemand Abfragen über die Befehlszeile ausführen möchte.

Verbinden wir zunächst den SQL-Client mit dem Trino-Container. Wie Brian werde ich das kostenlose DBeaver-Tool verwenden. Wählen Sie zunächst Neue Datenbankverbindung aus dem Dropdown-Menü Datenbank aus. In diesem Bildschirm befindet sich Trino im Bereich Hadoop/BigData:

Geben Sie bei ausgewähltem Trino-Astronautenhäschen die Verbindungsdetails ein:

Entsprechend Trino-Dokumentationsieht die JDBC-URL so aus:

jdbc:trino://{host}:{port}

Um Trino lokal in Docker auszuführen, führen Sie

host=localhost

und geben Sie diesem Container einen beliebigen Port (Bagel verwendet 8080).

Nachdem ich mich auf Trial-and-Error verlassen hatte, stellte ich fest, dass jede Zeichenfolge für den Benutzernamen funktionieren würde und das Feld „Passwort“ leer bleiben sollte. Jetzt können Sie sich verbinden!

Sie können sich auch mit UI lakeFS und MinIO verbinden. Navigieren Sie in einem Browser zu localhost:9001 für die MinIO-Benutzeroberfläche (Benutzername und Kennwort = minioadmin) und localhost:8000 für die lakeFS-Benutzeroberfläche (in Docker Compose sind die Anmeldeinformationen in den Umgebungsvariablen lakeFS-setup ausgeblendet).

Trino + SeeFS

Sobald die Verbindung hergestellt ist, können Sie Tabellen in Hive im Hauptzweig des LakeFS-Repositorys definieren und sie über die verteilte Abfrage-Engine von Trino abfragen. Mal sehen, wie es geht.

Schritt 1. Erstellen Sie ein Schema. Das Ergebnis ist ein separater Namensraum für neue Tabellen. Lassen Sie uns den Speicherort des Hauptzweigs von lakeFS angeben.

Schema s3.tiny erstellen mit (location = ‘s3a://example/main/tiny’);
Schritt 2. Erstellen Sie Tabellen im Schema.

Wir replizieren Kunden- und Auftragstabellen.

erstelle Tabelle s3.tiny.customer mit ( format=”ORC”, external_location = ‘s3a://example/main/tiny/customer’ ) as select * from tpch.tiny.customer;erstelle Tabelle s3.tiny.orders mit ( format=”ORC”, external_location = ‘s3a://example/main/tiny/orders’ ) as select * from tpch.tiny.orders;
Schritt 3. Anfragen schreiben!

Hier ist ein Beispiel für das Verbinden beider Tabellen für Bestellungen vor März 1995.

select orderkey, orderdate, shippriority from s3.tiny.customer c, s3.tiny.orders o where c.custkey = o.custkey and orderdate < date'1995-03-15' group by orderkey, orderdate, shippriority order by orderdate;

Was passiert, wenn ich einen neuen Zweig erstelle

Natürlich ist es cool, solche Abfragen an den Daten vorzunehmen, aber es ist eine Verschwendung des Potenzials von Everything Bagel. Anstatt nur eine Version der Daten verwenden wir den lakeFS-Zweig zu

eine neue Version erstellen

.

Lassen Sie uns zunächst einen neuen Zweig in lakeFS erstellen. Nennen wir es v2.


Erstellen eines neuen Zweigs auf der Registerkarte „Zweige“ des Beispiel-Repositorys

Bevor Sie die v2-Version der Tabellen abfragen, müssen Sie das Schema überschreiben, um auf den neuen Speicherort in S3 zu verweisen. Wie Sie unten sehen können, müssen Sie lediglich main durch v2 im Standortpfad ersetzen.

Schema s3.tiny_v2 erstellen mit (location = ‘s3a://example/v2/tiny’);

Schließlich müssen Sie die Tabellen im neuen Schema neu definieren. Dazu können Sie laufen

show create table s3.tiny.orders;

in der zuvor erstellten Tabelle und kopieren Sie dann die generierte DDL der Tabelle, wobei Sie den Zweignamen ersetzen.

So sieht es aus:

CREATE TABLE s3.tiny_v2.orders ( orderkey bigint, custkey bigint, orderstatus varchar(1), totalprice double, orderdate date, orderpriority varchar(15), clerk varchar(15), shippriority integer, comment varchar(79) ) WITH ( external_location = ‘s3a://example/main/tiny_v2/orders’, format=”ORC” );

Jetzt haben wir eine völlig unabhängige Version der Tabelle, in der wir beliebige Änderungen vornehmen können,

ohne die Version im Master-Zweig zu beeinflussen

und

ohne Daten zu duplizieren.

Warum es nötig sein könnte

Überlegen Sie, welche Datenblätter die am häufigsten verwendeten Assets in Ihrem Unternehmen darstellen. Sie haben sich während des Gebrauchs nicht verändert, oder? Oder nicht ganz richtig? Natürlich ändern sie sich ständig. Metrikdefinitionen werden aktualisiert, Spalten werden hinzugefügt und so weiter.

Angesichts der Abhängigkeiten zwischen den Tabellen ist es ein heikler und langwieriger Prozess, all diese Änderungen bereitzustellen, und zwar so, dass die Datennutzer nicht durch einen Unfall geschädigt werden.

Der Wechsel zu einem branchenbasierten Workflow vereinfacht die Bereitstellung, da beide Versionen einer Tabelle ohne unnötige Datenduplizierung nebeneinander existieren können (wichtig für große Tabellen). Darüber hinaus stehen Ihnen die git-Befehle zur Verfügung, die von lakeFS für das Lifecycle-Management verwendet werden.

Abschließend

Wenn Sie das nächste Mal etwas ändern wollen, halten Sie einen Moment inne. Widerstehen Sie der Versuchung, Daten zu kopieren. Passen Sie stattdessen den für Code verwendeten Workflow an und erstellen Sie einen neuen Datenzweig.

Der Effekt ist derselbe, aber Sie erhalten Quellcodeverwaltungsvorteile, die Sie auf andere Weise nicht erhalten können.

Versuchen Kubernetes as a Service auf der VK Cloud-Plattform. Wir geben neuen Benutzern 3000 Rubel Bonus für das Testen des Clusters oder anderer Dienste.
Was es sonst noch zu lesen gibt:

Similar Posts

Leave a Reply

Your email address will not be published.