[Sponsored Post] 23. Januar 2018

HTAP – Hybrid Transactional and Analytics Processing

HTAP: Eine Architektur, die Transaktionsverarbeitung und analytische Anwendungen vereinigt. © Sergey Tarasov / Fotolia.com — © Sergey Tarasov / Fotolia.com

Online Transaction Processing (OLTP) und Online Analytical Processing (OLAP) werden in gängigen Architekturen häufig getrennt. Ursache hierfür sind die unterschiedlichen Systemanforderungen. Doch ist auch eine Vereinigung aus OLTP und OLAP in einem System möglich. Dies spart Kosten und Ressourcen. Dr. Andreas Weininger zeigt mögliche Lösungen für ein Hybrid Transactional and Analytics Processing (HTAP).

Was versteht man unter "Hybrid Transactional and Analytics Processing" – kurz HTAP? Gartner bietet laut Wikipedia folgende Definition:

"Hybrid transaction/analytical processing (HTAP) is an emerging application architecture that "breaks the wall" between transaction processing and analytics. It enables more informed and "in business real time" decision making"

Es geht also darum, eine Architektur zu schaffen, die die beiden wichtigsten Datenbank-Anwendungen – nämlich die Transaktionsverarbeitung und analytische Anwendungen – vereinigt. Das Ziel dabei ist es, verbesserte und schnellere Geschäftsentscheidungen weitgehend in Echtzeit zu ermöglichen. Um das Ziel von HTAP zu verstehen, betrachten wir zunächst aber, was mit Transaktionsverarbeitung (häufig auch "Online Transaction Processing" (OLTP)) und mit analytischer Verarbeitung gemeint ist, wieso das nicht schon immer integriert wurde und was sich geändert hat, dass HTAP jetzt aktuell zu einem großen Thema wird.

Im Anschluss untersuchen wir, welche Ansätze es gibt, um die Anforderungen an ein HTAP-System zu erreichen, wobei wir uns dann schwerpunktmäßig auf einige besonders interessante Ansätze konzentrieren.

Was ist mit Transaction Processing und OLTP gemeint?

Ursprünglich war mit Transaktionsverarbeitung tatsächlich häufig eine Anwendung wie die Verarbeitung von Banktransaktionen gemeint. Bald verschob sich aber die Bedeutung von Transaktionen in Richtung Datenbanktransaktionen. Und damit waren Operationen auf Datenbanken gemeint, die folgende Eigenschaften erfüllen:

Atomarität (atomicity), d. h. der Zustand einer Datenbank nach Ausführung einer Transaktion ist, als ob die Operation entweder ganz oder gar nicht ausgeführt wurde.
Konsistenz (consistency), d.h. eine Datenbank, die sich in einem konsistenten Zustand befindet, ist auch nach Ausführung der Transaktion weiter in einem konsistenten Zustand.
Isolation (isolation), d. h. auch wenn mehrere Transaktionen gleichzeitig ausgeführt werden, ist der Effekt einer einzelnen Transaktion der gleiche, als wenn diese nur für sich ausgeführt worden wäre.
Dauerhaftigkeit (durability), d. h. das Ergebnis bleibt dauerhaft bestehen.

Diese Eigenschaften, die mit dem Anfangsbuchstaben der englischen Worte als ACID abgekürzt werden, stehen aber gar nicht im Fokus, wenn hier über Transaktionsverarbeitung gesprochen wird. Denn zum einen wünscht man häufig auch bei analytischer Verarbeitung diese ACID-Eigenschaften, zum anderen gibt es Systeme, die im Folgenden zur Transaktionsverarbeitung gezählt werden, die aber nicht unbedingt diese ACID-Eigenschaften garantieren.

Was sind die relevanten Eigenschaften eines Transaktionsverarbeitungssystems?

Zum einen repräsentiert der Datenbankzustand den aktuellen Zustand von Geschäftsprozessen und nicht deren Historie.
Sehr häufig werden einzelne Datenbanksätze geändert (Einzelsatz-Inserts, -Updates und -Deletes)
Ebenso häufig beziehen sich Selektionen auf einzelne Datenbanksätze.
Die Aggregation von Daten ist eher selten.
Sehr viele Benutzer greifen gleichzeitig auf das Transaktionsverarbeitungssystem zu.
Und erwarten dabei gleichzeitig sehr kurze Antwortzeiten typischerweise im Subsekunden-Bereich.
Auch an die Verfügbarkeit des Systems werden sehr hohe Anforderungen gestellt. Häufig wird erwartet, dass das System 24/7 zur Verfügung steht.
Häufig wird ein Datenbank-Schema in der dritten Normalform verwendet.

Diese Eigenschaften findet man nicht nur bei traditionellen Systems of Record [1], die mit traditionellen relationalen Datenbanksystemen implementiert sind, sondern auch bei Systems of Engagement [2] für die häufig dokumentenorientierte NoSQL-Systeme [3] verwendet werden.

Welche Eigenschaften zeichnen im Gegensatz dazu die analytische Verarbeitung aus?

Nicht einzelne Datensätze werden verarbeitet, sondern Aggregation und Gruppierung von vielen Daten überwiegt.
Abfragen sind komplexer als bei der Transaktionsverarbeitung und obwohl viele Sätze verarbeitet werden, werden typischerweise nur wenige Spalten der Sätze in einer einzelnen Abfrage verwendet.
Die Daten liegen typischerweise nicht in dritter Normalform vor, sondern es wird ein sogenanntes Star- oder Snowflake-Schema verwendet.
Statt nur des aktuellen Stands eines Geschäftsprozesses wird seine gesamte Historie gespeichert.
Meist werden auch die Daten aus mehreren Quellensystemen – häufig Transaktionsverarbeitungssystemen – zusammengeführt.
Um die Daten zusammenzuführen, ist eine so genannte ETL-(Extraktion/Transformation/Laden) Verarbeitung notwendig.

Analytische Systeme wollen eine einheitliche konsistente Sicht auf all die Daten aus den unterschiedlichen Quellsystemen bieten (Single Point of Truth). Typische Systeme für analytische Verarbeitung sind Data Warehouses und Data Lakes. Um den Gegensatz zu OLTP zu betonen, spricht man häufig auch von Online Analytical Processing (OLAP).

OLTP vs. OLAP: Wieso hat man in der Vergangenheit verschiedene Systeme für Transaktionsverarbeitung und analytische Verarbeitung verwendet?

Dafür gibt es verschiedene Gründe:

Die unterschiedlichen Verfügbarkeits- und Desaster-Recovery-Anforderungen von Transaktionsverarbeitung und analytischer Verarbeitung, wobei die Anforderungen typischerweise bei der Transaktionsverarbeitung deutlich höher sind, als bei einer analytischen Verarbeitung. Man könnte natürlich sagen, dass man die Anforderungen auf dem Niveau der Transaktionsverarbeitung – also auf dem höheren Niveau – vereinheitlicht. Der Nachteil dieses Ansatzes ist aber, dass damit auch deutlich höhere Kosten verbunden sind, da analytische Systeme wegen der Historie, die sie halten, auch deutlich größer sind, als die Transaktionsverarbeitungssysteme.
Abfragen haben auch unterschiedliche Prioritäten: Langlaufende analytische Abfragen haben häufig eine niedrigere Priorität als kurze OLTP-Abfragen, bei denen die Benutzer eben auch ein ganz anderes Antwortzeitverhalten erwarten.
Diese Systeme werden auch von unterschiedlichen Benutzern mit unterschiedlichen Anforderungen genutzt. Während Transaktionsverarbeitungsnutzer normalerweise feste statische Anwendungen mit feststehenden Abfragen benutzen und selbst typischerweise auch keine tiefergehenden Datenbankkenntnisse besitzen, findet man bei analytischer Verarbeitung häufig Benutzer, die ihre eigenen Ad hoc-Abfragen erstellen.
Auch die Anforderungen bezüglich Sicherheit im Allgemeinen und Datensicherheit im Besonderen sind sehr unterschiedlich: Während es für die operativen transaktionsverarbeitenden Systeme besonders wichtig ist, dass alle Daten wie zum Beispiel Kreditkartennummern vollständig und korrekt vorliegen, dürfen solche Daten in analytischen Systemen häufig nur pseudonymisiert oder anonymisiert vorgehalten werden.

Deshalb hat man in den vergangenen Jahrzehnten die Daten aus den operativen transaktionsverarbeitenden Systemen extrahiert und in separaten analytischen Systemen – typischerweise den so genannten Data Warehouses – gespeichert. Auf diese Art war es möglich, für jede der beiden Anforderungen das jeweils optimale System zu entwickeln.

Aber auch der Ansatz, Transaktionsverarbeitung von analytischen Systemen zu trennen, hat gewisse Nachteile:

Es müssen mehrere Kopien der Daten gehalten werden. Dies bedeutet, dass nicht nur zusätzliche Kosten für Speicherplatz entstehen, sondern auch, dass die Gefahr besteht, dass diese verschiedenen Kopien nicht mehr konsistent sind.
Auch ist eine Folge dieser Trennung, dass analytische Abfragen auf älteren Daten arbeiten, als die in der Transaktionsverarbeitung verfügbaren. Es ist zwar möglich, das zeitliche Delta zu verkleinern, seine Existenz ist aber eine inhärente Folge dieses Ansatzes.
Der Hauptnachteil ist aber der große Aufwand für die Implementierung der ETL-Verarbeitung, um die Daten aus den transaktionsverarbeitenden Quellsystemen in das analytische System zu bekommen. Dies wirkt sich in zweierlei Hinsicht aus:
- Zum einen fallen hohe Kosten für die Pflege der ETL-Verarbeitung an.
- Zum anderen stehen Daten aus neuen Datenquellen erst nach Entwicklung der entsprechenden ETL-Prozesse zur Verfügung, was eine große zeitliche Verzögerung bedeuten kann.

OLTP und OLAP in einer Datenbank: Lösungen

Um diese Nachteile zu vermeiden, kam deshalb der Wunsch nach HTAP-Systemen auf, die analytische und Transaktionsverarbeitung in einem System vereinen. Man kann sich natürlich die Frage stellen, weshalb dieser Wunsch nicht schon viel früher aufkam. Es gibt dafür im wesentlichen zweierlei Gründe: Zum einen gibt es viel mehr Geschäftsprozesse, bei denen das Ergebnis von Analysen als sofortiges Feedback benötigt wird, um steuernd eingreifen zu können. Außerdem hat man oft den Effekt, dass der Wert von Daten im Lauf der Zeit abnimmt. Zum andern hat es technologische Fortschritte wie beispielsweise die In-Memory-Verarbeitung von Daten gegeben, die es einfacher machen, HTAP-Systeme zu implementieren.

Nichts desto weniger müssen auch diese neueren HTAP-Ansätze Probleme lösen, wie sie schon oben genannt wurden, wenn man OLTP und OLAP in einem System gemeinsam betreiben möchte: Dazu gehören etwa unterschiedliche optimale Speicherformate (zeilenorientierte Speicherung für OLTP-Systeme versus spaltenorientierte Speicherung für OLAP-Systeme) und unterschiedliche optimale Hilfsstrukturen wie Indizes, die in einem Fall notwendig oder empfehlenswert sind, im anderen Fall überflüssig oder schädlich.

Welche unterschiedlichen Lösungsansätze gibt es für HTAP?

Ein Ansatz, vor allem, um das Problem der veralteten Daten bei analytischen Abfragen zu adressieren, ist zwar, weiter zwei Kopien für Transaktions- und analytische Verarbeitung bestehen zu lassen, gleichzeitig aber die Aktualisierungsrate zu erhöhen. Dies kann etwa dadurch passieren, dass die Ladefrequenz des Data Warehouses deutlich erhöht wird, beispielsweise indem man die ETL-Prozesse statt einmal täglich alle 5 Minuten laufen lässt. Dies kann noch weiter verbessert werden, indem die Daten ins Data Warehouse nicht mit Lade-Kommandos geladen werden, sondern indem man die Daten aus den transaktionsverarbeitenden Quellsystemen per (log-basierter) asynchroner Replikation zum Data Warehouse bringt.

Ein anderer Ansatz besteht darin, die Verarbeitung von analytischen Abfragen in transaktionsorientierten Systemen zu verbessern. Dies kann durch die Integration eines Akzelerators für analytische Abfragen geschehen. Diesen Ansatz verfolgt IBM beispielsweise bei Db2 für zOS mit dem IBM Db2 Analytics Accelerator (IDAA) [4] und bei Informix mit dem Informix Warehouse Accelerator (IWA) [5].

Auch der umgekehrte Ansatz wird angewandt – nämlich bei einem für analytische Anwendungen optimierten System die OLTP-Verarbeitung zu verbessern. Dieser Ansatz wird etwa bei der HTAP-Initiative für Db2 with BLU Acceleration verfolgt.

IBM Queryplex

Im Folgenden sollen aber zwei ganz neue Ansätze betrachtet werden. Der eine Ansatz besteht darin, die gesamten transaktionsverarbeitenden Systeme zu einem analytischen System zusammenzufassen. Ein Ansatz dieser Art ist IBM Queryplex [6]. Die Grundidee ist dabei, die Daten aus den transaktionsverarbeitenden Systemen nicht in ein zentrales System zu bringen, sondern die vielen operativen Transaktionssysteme gemeinsam für analytische Abfragen zu nutzen. Im Gegensatz zu traditioneller Datenföderation werden die beteiligten transaktionsverarbeitenden Systeme als ein großer Parallelrechner, der an der Abarbeitung von analytischen Abfragen arbeitet, betrachtet. Dieser Ansatz bietet sich etwa an, wenn die transaktionsverarbeitenden Systeme die Daten schneller erzeugen, als sie zu einem zentralen analytischen System (etwa wegen fehlender Netzwerkbandbreite) übertragen werden können. Ein Anwendungsfall ist etwa ein IoT-System, das aus Hunderttausenden oder Millionen von Edge Devices besteht, die Sensordaten sammeln und speichern. Häufig haben diese Systeme durchaus noch freie CPU Zyklen, die für zusätzliche analytische Workload genutzt werden können und gleichzeitig aber häufig eine beschränkte Netzwerkbandbreite zur Cloud bzw. zu zentralen Systemen. Ein anderer Anwendungsfall ist ein Transaktionsverarbeitungssystem, das aus vielen einzelnen Systemen für unterschiedliche Mandanten besteht, bei dem die Transaktionsverarbeitung typischerweise immer nur für den einzelnen Mandanten passieren soll, analytische Auswertungen aber gleichzeitig auf allen Mandanten erfolgen sollen.

Das folgende Bild veranschaulicht wie die Verarbeitung bei Queryplex erfolgt.

Abb. 1: Knoten für Transaktions- und analytische Verarbeitung. © Dr. Andreas Weininger

Der Queryplex-Koordinator erhält eine analytische Anfrage, verteilt diese anhand der bei ihm gespeicherten Metadaten an die einzelnen Knoten, die sowohl die Transaktionsverarbeitung als auch die analytische Verarbeitung machen. Während der Abarbeitung eine Abfrage arbeitet jeder Knoten an einer Teilaufgabe und diese Knoten tauschen untereinander Teilergebnisse aus, so dass der Koordinator selbst nur für die Rückgabe des Gesamtergebnisses zuständig ist.

IBM Db2 Event Store

Der andere Ansatz, der hier besprochen werden soll, ist der vom IBM Db2 Event Store [7] verfolgte. Die Grundidee von Event Store ist zunächst, ein sehr performantes und hochverfügbares System zur Transaktionsverarbeitung zu haben, die Event Store Engine. Diese bietet auch Unterstützung für analytische Abfragen an. Gleichzeitig werden die Daten in einem externen Format abgelegt, auf das auch andere analytische Werkzeuge zugreifen können. Die Abbildung gibt einen grundsätzlichen Überblick über die Architektur von Event Store.

Abb. 2: Überblick über die Architektur von Event Store. © Dr. Andreas Weininger

Transaktionsverarbeitung (OLTP) im IBM Db2 Event Store

Betrachten wir nun zunächst die Transaktionsverarbeitungsseite. Das besondere des Event Store ist, dass nur neue Daten eingefügt werden, aber keine Update-Operationen durchgeführt werden. Der zum Beispiel im Scala oder Python geschriebene Client kann eine API nutzen um entweder einzelne Sätze oder mehrere Sätze als Batch synchron oder auch asynchron einzufügen. Die Event Store Engine ist in Spark implementiert und darauf ausgelegt, mehr als eine Million Insert-Operationen pro Knoten durchzuführen. Die Daten und ein darauf zeigender Index werden zunächst im Hauptspeicher gehalten. Jeder Knoten schreibt sein eigenes lokales Log, das typischerweise auf SSD-Speicher liegt. Um die von einer Transaktionsverarbeitung gewünschte Hochverfügbarkeit zu implementieren replizieren sich die drei Event Store Engines die Daten gegenseitig. In regelmäßigen Zeitabständen werden die Daten aus dem Hauptspeicher auf den externen Speicher geschrieben. Dieser externe Speicher kann mithilfe von GlusterFS [8] als hochverfügbarer verteilter Speicher zur Verfügung gestellt werden, um auch auf Ebene des externen Speichers die entsprechende Hochverfügbarkeit zu bieten. Die Daten werden dabei im Apache Parquet-Format [9] geschrieben, einem offenen, spaltenorientieren Datenformat, das auch von anderen Werkzeugen genutzt werden kann.

Analysen (OLAP) mit Spark SQL

Als nächstes betrachten wir nun die Analyseseite. Auch hier kann man eine API nutzen um Abfragen gegen den Event Store abzusetzen. Um etwa mit Spark SQL auf die Tabellen im Event Store zugreifen zu können, muss zunächst eine Event Store Spark-Session geöffnet werden. In der Session wird zunächst die Methode open_datebase (in Python bzw. openDatabase in Scala) aufgerufen, um die Datenbank zu öffnen. Als nächstes kann die Methode loadEventTable genutzt werden, um eine DataFrame-Referenz auf die jeweilige Tabelle im Event Store zu erzeugen. Auf diese kann dann wiederum ein temporärer View erzeugt werden, dessen Name dann in Spark SQL in einer Abfrage genutzt werden kann. Mit der Methode setQueryReadOption kann davor der Isolation-Level festgelegt werden. Damit ist es möglich, zu bestimmen, ob man etwa den letzten konsistenten Snapshot oder auch zusätzlich alle neuen, danach angefallenen Daten sehen möchte. Wenn man beides haben möchte – einen konsistenten Snapshot und alle aktuellen Daten –, dann ist auch das möglich: Dann wird ein neuer konsistenter Snapshot direkt vor der Ausführung der Abfrage erzeugt, was natürlich eine kleine zeitliche Verzögerung bedeutet. Damit erlaubt der Db2 Event Store gleichzeitig Transaktionsverarbeitung und Abfragen auf den allerneuesten Daten. Im Gegensatz zu einer Lambda-Architektur [10] wird aber keine doppelte Datenhaltung benötigt und die Handhabung ist viel einfacher. Sollten bei einer Abfrage ein oder mehrere Knoten nicht verfügbar sein, so wird die Abfrage von den verbleibenden Knoten beantwortet, solange eine (konfigurierbare) Mindestanzahl davon existiert.

Da die Daten als konsistenter Snapshot im hochverfügbaren und verteilten gemeinsamen externen Speicher im Parquet-Format vorliegen, kann zusätzlich noch mit anderen Werkzeugen, die das Parquet-Format verstehen, darauf zugegriffen werden. Ein wichtiges Werkzeug in diesem Zusammenhang ist IBM Db2 Big SQL [11], das es erlaubt, extrem performant mit Standard SQL mit dem vollen Db2-Sprachumfang auf diese Daten zuzugreifen und gleichzeitig per Datenföderation diese Daten mit Daten aus anderen Datenquellen zu verknüpfen.

Der Db2 Event Store-Ansatz erlaubt also gleichzeitig eine Transaktionsverarbeitung, die auch für die höchsten Raten an anfallenden Insert-Operationen (wie sie z. B. bei Internet of Things durch Millionen von Sensoren anfallen können) ausgelegt ist, die für eine Transaktionsverarbeitung erwartete Hochverfügbarkeit bietet, ohne für den analytischen Teil dafür außergewöhnliche Kosten zu verursachen, und gleichzeitig analytische Abfragen ermöglicht, die auch die allerneuesten Daten miteinbeziehen kann. Damit sind analytische Abfragen möglich, die direktes Feedback zur Steuerung von Geschäftsprozessen in Echtzeit ermöglichen.

Wer Db2 Event Store und seinen neuen Ansatz zur Lösung des HTAP-Problems selbst ausprobieren möchte, für den steht eine kostenlose Version zum Download bereit [12].

Quellen