ETL und ELT

Der Stern aus Lektion 4.13.1 wurde in einem Rutsch gefüllt, aus einer Datenbank, die stillstand. Im Betrieb ändert sich die Kladde jede Minute, und der Stern soll jede Nacht nachziehen, ohne jedes Mal alles neu zu lesen, ohne einen Termin zu verlieren und ohne einen doppelt zu zählen, wenn ein Lauf mittendrin abbricht. Diese Lektion baut diese Ladung. Ihre Regeln kennen Sie zum Teil schon: Idempotenz und Neustart aus dem Import in K3, mindestens einmal zugestellt aus Lektion 4.6.1, Nummern, die vor dem Festschreiben vergeben werden, aus Lektion 4.4.5.

ETL oder ELT

Beide Kürzel beschreiben dieselben drei Schritte in verschiedener Reihenfolge:

• ETL (extract, transform, load): Daten aus der Quelle lesen, unterwegs umwandeln, dann fertig in das Ziel laden. So arbeiteten klassische Data Warehouses, als Rechenleistung im Ziel teuer war.
• ELT (extract, load, transform): Daten zuerst roh in das Ziel laden, dann dort umwandeln, mit der Rechenleistung des Ziels. So arbeitet ein Lakehouse: Rohdaten landen in einer Schicht, Spark oder SQL formt daraus Schicht für Schicht den Stern.

ELT ist heute der Normalfall, weil die Rohdaten erhalten bleiben und sich eine Umwandlung jederzeit neu laufen lässt. Es gibt aber einen Grund, der ETL erzwingt, und er betrifft die Kladde: Was das Ziel nie sehen darf, muss vor dem Laden weg. Die buchende Person in appointments.Bookings gehört nicht in OneLake, auch nicht in eine Rohschicht, die „nur das Datenteam“ sieht. Die Ladung liest deshalb nur die Spalten, die der Stern braucht. Das ist eine Umwandlung vor dem Laden, und sie ist Datenschutz durch Technikgestaltung aus Lektion 4.8.3.