In diesem Beitrag werden anhand des von der ExasolDB zur Verfügung gestellten Features „Virtual Schemas“ verschiedene Use Cases dargestellt und welche Herausforderungen und Chancen diese mit sich bringen.
Das Lesen von externen Daten ist eine Standardtechnik aus dem Data Warehousing, die eine nicht zu unterschätzende Nische darstellt. Konkret handelt es sich um einen Read-Only Zugriff via SQL- Abfragen auf Tabellen, deren Speicherorte außerhalb des Datenbanksystems liegen, auf dem die Abfrage abgesetzt wurde.
Das macht es unter Anderem möglich eine Sicht auf Daten zu erlangen, ohne ressourcenlastige Prozesse zur Datenmigration zu implementieren.
Vorteile gegenüber der klassischen Datenintegration in ein neues System sind, wie im vorherigen Satz schon angedeutet, auf ETL-Prozesse ganz verzichten zu können und sowohl eine doppelte Datenhaltung als auch zusätzlichen Speicherverbrauch zu vermeiden.
Ein signifikanter Nachteil dieser Technik wiederum besteht in der Performance der einzelnen Abfragen. Diese fällt aufgrund von zusätzlichen Arbeitsschritten deutlich schlechter aus. Des Weiteren ist zu beachten, dass es sich hier nur um einen lesenden Zugriff handelt. Schreiboperationen wie insert, update & delete sind nicht möglich.
Exasol und Virtual Schemas
Die ExasolDB ist eine Analysedatenbank, deren Stärke ist, große Abfragen in kürzester Zeit durchzuführen. Ihre Fähigkeiten große Datenmengen zu im- oder exportieren, darf dennoch nicht außer Acht gelassen werden.
Mit den sogenannten Virtual Schemas bietet die Exasol Datenbank ein Feature an, mit dem es unkompliziert möglich ist sich externe Daten ausgeben zu lassen.
Bei Virtual Schemas handelt es sich um logische Einrichtungen ähnlich zu gewöhnlichen Datenbankschemas. In diesen werden Tabellenstrukturen, so genannte Virtual Tables, zum Lesen der externen Daten angelegt. Aufgrund der ähnlichen Handhabung zu Datenbankschemas sind Verknüpfungen zu schemafremden Tabellen via Joins oder Unions möglich. Darüber hinaus spielt es keine Rolle, ob die zu verknüpfenden Tabellen aus einem Datenbankschema oder einem Virtual Schema stammt. Des Weiteren hat jedes Virtual Schema sein eigenes Rights Management. Daten oder Tabellen, die durch ein Virtual Schema gelesen werden sollen, können dabei aus relationalen Datenbanken stammen wie zum Beispiel einem Oracle RDBMS oder auch aus Amazon S3 Buckets außerhalb eines RDBMS. Letzteres funktioniert allerdings nur, wenn die Daten in dem Format PARQUET oder JSON gespeichert sind.
Im Gegensatz zu ähnlichen Techniken in anderen Datenbanken, fallen für die Nutzung von Virtual Schemas keine weiteren Kosten an.
Für die Einrichtung eines Virtual Schemas stellt Exasol in Ihrer Dokumentation ein generelles „Kochrezept“ zur Verfügung. Egal ob aus einer fremden Datenbank oder einem Amazon S3 Bucket gelesen werden soll, ist ein Virtual Schema in drei bis vier Schritten eingerichtet. Alle nötigen Informationen zu Einrichtung befinden sich unter:
Virtual Schema User Guide | Exasol DB Documentation
Mit den bereitgestellten Import-Möglichkeit der ExasolDB lassen sich außerdem verschiedenste Datenquellen mit einer Data Ingestion-Strategie mit der Hilfe von Virtual Schemas importieren.
Use cases
Auf den ersten Blick würde man zu dem Schluss kommen, dass sich der Einsatz eher auf Proof of Concepts (POC), Minimum Viable Products (MVP) oder Lösungen, bei denen die Performance zunächst zweitrangig beschränkt ist.
Nutzen und Möglichkeiten gehen allerdings weit darüber hinaus. Es werden im Folgenden einige Use Cases vorgestellt.
Data Ingestion
Das Prinzip der Data Ingestion beruht auf der Idee, verschiedene Datenquellen an einer Stelle zu zentralisieren. Wie schon im vorherigen Kapitel angerissen sind Data Ingestion-Strategien der vermutlich am häufigsten auftretende Use Case von Virtual Schema.
Vereinfacht gesagt werden anstelle von resourcenlastigen ETL-Prozessen über mehrere Anwendungen hinweg, die Ergebnismenge der Abfrage aus den Virtual Schemas heraus via Import-Statement in die vorgesehene Zieltabelle auf der ExasolDB hineingeschrieben.
Vor Allem wenn die Daten aus verschiedenen Systemen kommen, kann durch die Nutzung der virtuellen Schemas Komplexität vereinfacht werden.
Bewirtschaftung ohne Virtual Schemas
Bewirtschaftung mit Virtual Schemas
Historisierungsstrategien
Unternehmen stehen häufig vor der Herausforderung, eine Datenstrategie für Ihr Data Warehouse zu entwickeln, die über Last sowie Haltungsdauer und Archivierung entscheidet. Für den Fall, dass bereits archivierte Daten noch einmal zum Vergleich herangezogen werden müssen, bietet auch hier eine Technik zum Auslesen externer Datenquellen eine Lösung mit wenig Aufwand.
Archivierte Daten werden aufgrund der unregelmäßigen Abfrage in der Regel außerhalb von relationalen Datenbanken aufbewahrt zum Beispiel in S3-Buckets.
Mithilfe der Virtual Schema lassen sich die Daten ohne große Probleme mit den aktuellen Daten innerhalb der Datenbank bei Bedarf vergleichen.
Im unten stehenden Code Beispiel wird ein Vergleich von Verkaufszahlen gezeigt. Dabei werden aktuelle Zahlen und Zahlen vor 10 Jahren verglichen. Die älteren Daten werden dabei aus einem Virtual Schema gelesen.
CREATE Virtual SCHEMA Archive_retail_VS using adapter.S3_connect with
connection_name='S3_CONNECTION'
SQL_DIALECT='S3_DOCUMENT_FILES'
MAPPING = '/buckets/bucketfs1/docadapter/s3_mapping.json;
ALTER VIRTUAL SCHEMA Archive_retail_VS REFRESH;
with current_sales as (
Select sum(sales), products from retail.sales nws
where sales_year=year(current_date)
group by products
)
,
older_sales_10years as (
Select sum(sales), products from Archive_retail_VS.sales ols
where sales_year=year(current_date)-10
group by products
)
SELECT ols.products,ols.price,nls.price from older_sales_10year ols
join current_sales cus
ON ols.products=cus.products
;
Datenaustausch innerhalb strategischer Partnerschaften
Innerhalb von Firmenkooperationen ist der Austausch von Daten ein wichtiger Bestandteil. Verschiedene Ansätze sind unter anderem den Mitarbeitern des Kooperationspartners mittels eingerichteten User Zugriff auf entsprechende firmeninterne Daten zu gewährleisten. Je nach Anzahl an neuen Usern und Umfang der Berechtigungen kann die Verwaltung dieser große Aufwände bereiten. Auch hier bietet das Lesen externer Datenquellen eine einfach umzusetzende Lösung.
Hier reicht es auch dem Kooperationspartner die für den Datenaustausch vorgesehenen Tabellen, samt Tabellendefinition und weitere technische Informationen, zu nennen, damit der Kooperationspartner den Zugriff bei sich im System einrichten kann. Aufwände für ein umfangreiches Berechtigungskonzept fallen dabei ganz weg.
Schwächen
Nachdem ein paar spannende Use Cases für Virtual Schemas vorgestellt wurden, werden im Folgenden einige Nachteile angesprochen. Diese sind eher genereller Natur und stellen für alle Anwendungszwecke eine Herausforderung dar.
Verfügbarkeit & Wartbarkeit
Damit ein Virtual Schema eine fremde Tabelle lesen kann, benötigt es unter anderem Informationen zu den Spalten, Datentypen, der Datengröße der Tabelle und, falls es sich bei der externen Quelle um eine Datenbank handelt, den JDBC-Treiber.
Falls in den externen Systemen Änderungen an Tabelle oder Treiber vorgenommen werden, müssen diese ebenfalls in dem Virtual Schema nachgezogen werden. Ansonsten besteht die Gefahr, dass das Virtual Schema nicht in der Lage ist, die Daten zu lesen.
Performance
Die Performance der Abfragen ist weitaus schwächer. Während einfach gehaltene Select-Statements mit einer akzeptablen Performance laufen, ist bei komplexen SQLs mit mehreren Joins Vorsicht geboten. Unter anderem besteht die Gefahr in einen Timeout-Fehler zu rennen.
Fazit
Alles in allem hat das Lesen von externen Daten einige spannende Anwendungsfälle. Im Fall der vorgestellten Use Cases, allen voran der Data Ingestion-Strategie, sollte ihr Potenzial nicht außer Acht gelassen werden.
Trotzdem kommt diese Technik aufgrund der Nachteile wie der schlechteren Performance, Wartbarkeit oder auch ihrer Verfügbarkeit zu kurz. Eine Möglichkeit sie populärer zu machen, wäre diese, wie bei den Exasol Virtual Schemas, in jeder Lizenz mit anzubieten.