Effiziente ETL in einer analytischen Datenbank?

Kürzlich habe ich an einem POC gearbeitet, bei dem nicht standardmäßig gedacht werden musste. Die Herausforderung bestand darin, dass der use case des Kunden nicht nur High-Performance erforderte, sondern auch ein gesundes Maß an ETL (Extrahieren, Transformieren und Laden). Genauer gesagt bestand die Anforderung in ELT (oder sogar ETLT, wenn wir ganz genau sein wollen).

Warum "könnte" dies ein Problem gewesen sein? Analytische Datenbanken und die ETL-Verarbeitung passen in der Regel nicht gut zusammen. Letztere ist eher zeilenorientiert, während die typische analytische Datenbank Daten lieber "stückweise" verarbeitet. Analytische Datenbanken sind in der Regel in der Lage, Daten in großen Mengen mit sehr hoher Geschwindigkeit zu laden, bieten aber in der Regel nur einen bescheidenen zeilenweisen Durchsatz.

Ein weiteres typisches Merkmal ist die Verwendung von Schreibsperren auf Tabellenebene, d. h. die Serialisierung von Schreibtransaktionen auf jeweils eine. Dies wird allgemein akzeptiert, da die Anwendungsfälle für analytische Datenbanken eher Abfragen als jede Art von Transaktionsverarbeitung betreffen. Wenn jedoch eine Form von ETL erforderlich ist, ist dies vielleicht noch problematischer als der zeilenweise Durchsatz, da der Designer und das Ladetool diese Eigenschaft berücksichtigen müssen. Der Designer muss oft "durch Reifen springen", um herauszufinden, wie er die Daten so in die analytische Datenbank bekommt, dass die anderen Teammitglieder sie verstehen und das Tool sie liefern kann.

Ich stelle hier die Weichen für die "große Enthüllung", dass die Actian Vector Processing Datenbanken nicht unter diesen Nachteilen leiden. Sie können sowohl High-End analytische Funktionen liefern als auch "OLTP Funktionen" in der Art der HTAP (Hybrid Transactional/Analytical Processing) Technologien anbieten.

Beachten Sie die Anführungszeichen um " Funktionen" - nur um das klarzustellen, wir bei Actian würden diese nicht als High-Performance bezeichnen, wir sagen nur, dass die Funktionen (Sperren auf Zeilenebene und gleichzeitige Tabellenänderungen) vorhanden sind, obwohl die Datenbank eine spaltenbasierte in-memory ist.)

Wie auch immer man sie betrachtet, es waren diese Funktionen , die es uns ermöglichten, die Ziele des Kunden zu erreichen - wenn auch mit ein wenig Überredungskunst. Im weiteren Verlauf dieses Beitrags beschreibe ich die Schritte, die wir durchlaufen haben, und die Ergebnisse, die wir erzielt haben. Wenn Sie noch kein Nutzer von Actian Vector oder Actian Vector in Hadoop (VectorH) sind, dann können Sie den Beitrag überspringen, aber wenn Sie die Technologie bereits nutzen, dann lesen Sie weiter.

Konfigurieren für ETL

Um auf den use case zurückzukommen: Die Anforderung dieses Kunden bestand darin, große Datenmengen aus verschiedenen Quellen parallel in dieselben Tabellen zu laden. Wir haben oben gesagt, dass wir " Funktionen" anbieten, aber die Standardkonfiguration ist eher auf eine Massenaktualisierung pro Tabelle ausgerichtet - wir mussten die Konfiguration ändern, um mehrere gleichzeitige Massenänderungen zu bewältigen.

ActianDatenbanken haben im Kern eine spaltenorientierte Architektur, und in allen Fällen wird der zugrunde liegende Spaltenspeicher in einer einzigen Transaktion geändert. Die Funktion der gleichzeitigen Aktualisierung beruht auf einer cleveren Technologie, die Aktualisierungen nahtlos und ACID-konform im Speicher puffert. Die Standardkonfiguration geht von einem kleinen Speichermodell aus und leitet daher große Änderungen direkt an den Spaltenspeicher weiter, während kleinere Aktualisierungen an den In-Memory-Puffer weitergeleitet werden. Die für den In-Memory-Puffer durchgeführten Wartungsvorgänge - wie das Flushen von Änderungen in den Spaltenspeicher - werden durch in der Konfiguration festgelegte Ressourcenschwellenwerte ausgelöst.

Hier kann es bei der Standardkonfiguration zu Problemen kommen - es entstehen Situationen, in denen große Aktualisierungen, die direkt an den Spaltenspeicher gesendet werden, mit der Wartungsroutine des in-memory kollidieren können. Damit dies gut funktioniert, müssen wir die Konfiguration anpassen, um der Tatsache Rechnung zu tragen, dass - mit ziemlicher Sicherheit - mehr Speicher vorhanden ist, als in der Standardkonfiguration angenommen wird. Vielleicht könnte der Installer diese Einstellungen entsprechend vornehmen, aber bei einer großen installierten Basis ist es sicherer, das Verhalten gleich zu halten, um die Beständigkeit zwischen den Versionen zu wahren.

Wir mussten also zwei Dinge tun: Erstens wollten wir alle Änderungen durch den in-memory leiten, und zweitens den in-memory groß genug konfigurieren, um die zu ladende Datenmenge zu bewältigen. Eine dritte Möglichkeit wäre gewesen, die Wartungsroutinen manuell zu gestalten und die Befehle zum Auslösen dieser Routinen in die ETL-Prozesse selbst einzubauen, um ihnen die vollständige Kontrolle darüber zu geben, was wann geschieht.

Das Routing aller Änderungen durch den in-memory erfolgt über die Einstellung insertmode. Eine Änderung dieser Einstellung bedeutet, dass Bulk-Operationen, die normalerweise direkt in den Spaltenspeicher gehen würden, nun über den in-memory laufen, so dass mehrere Bulk-Operationen gleichzeitig durchgeführt werden können.

Die Dimensionierung des in-memory ist einfach eine Frage der Anpassung der Schwellenwerte an den verfügbaren Speicher oder, wie oben vorgeschlagen, der vollständigen Kontrolle des ETL-Prozesses.

In der folgenden Tabelle werden die Konfigurationsoptionen beschrieben, die sich auf den Prozess auswirken:

Um den Wartungsprozess manuell auszulösen, führen Sie ihn aus:

modify <table> to combine

Wenn Sie mehr technische Details über die Implementierung dieser Verarbeitung erfahren möchten, finden Sie hier einen Knowledge-Base-Artikel:

Ergebnisse

Der anfängliche Ladevorgang der Kundendaten dauerte - mit der Standardkonfiguration - etwa 13 Minuten. Mit einigen Anpassungen der Speicherparameter, um die Wartungsroutine weniger häufig aufzurufen, sank diese Zeit auf knapp über 9 Minuten. Die Umstellung auf in-memory (zu diesem Zeitpunkt immer noch ein einzelner Datenstrom) brachte die Nadel auf knapp unter 9 Minuten. Dies war ein interessanter Aspekt der Tests - das Routing aller Daten durch den in-memory verlangsamte den Prozess nicht, sondern verbesserte die Zeit, wenn auch nur um einen kleinen Faktor.

Sobald die Daten über den in-memory geladen waren, konnte das Laden in parallelen Streams erfolgen. Das Endergebnis war, dass die Daten in etwas mehr als einer Minute über acht parallele Ströme geladen werden konnten. Dies war ein erfreuliches Ergebnis, wenn man bedenkt, dass das bestehende - OLTP-basierte - System des Kunden über 90 Minuten benötigte, um die gleichen Daten mit zehn parallelen Streams zu laden.

Schlussfolgerung

Analytische Datenbanken sind in der Regel mit Herausforderungen konfrontiert, wenn sie versuchen, Daten über herkömmliche ETL-Tools und -Methoden zu laden - sie zeichnen sich durch eine geringe zeilenweise Verarbeitungsgeschwindigkeit und vor allem durch Schreibsperren auf Tabellenebene aus.

Actians Vektorverarbeitungsdatenbanken verfügen über eine innovative Technologie, die es ihnen ermöglicht, diese Probleme zu vermeiden und "OLTP-Fähigkeiten" zu bieten. Obwohl sie nicht auf OLTP-Anwendungsfälle abzielen, ermöglichen diese Fähigkeiten den ActianDatenbanken die gleichzeitige Nutzung von Hochleistungslasten und damit eine gute Leistung für ETL-Workloads.

KB Artikel lesen

Über Actian Corporation

Actian macht Daten einfach. Unsere Datenplattform vereinfacht die Verbindung, Verwaltung und Analyse von Daten in Cloud-, Hybrid- und lokalen Umgebungen. Mit jahrzehntelanger Erfahrung in den Bereichen Datenmanagement und -analyse liefert Actian leistungsstarke Lösungen, die es Unternehmen ermöglichen, datengesteuerte Entscheidungen zu treffen. Actian wird von führenden Analysten anerkannt und wurde für seine Leistung und Innovation mit Branchenpreisen ausgezeichnet. Unsere Teams präsentieren bewährte Anwendungsfälle auf Konferenzen (z. B. Strata Data) und tragen zu Open-Source-Projekten bei. Im ActianBlog behandeln wir Themen wie Echtzeit-Dateneingabe, Datenanalyse, Data Governance, Datenmanagement, Datenqualität, Datenintelligenz und KI-gesteuerte Analysen.