In die­sem Bei­trag wer­den anhand des von der Exa­solDB zur Ver­fü­gung gestell­ten Fea­tures „Vir­tual Sche­mas“ ver­schie­dene Use Cases dar­ge­stellt und wel­che Her­aus­for­de­run­gen und Chan­cen diese mit sich bringen.

Das Lesen von exter­nen Daten ist eine Stan­dard­tech­nik aus dem Data Ware­housing, die eine nicht zu unter­schät­zende Nische dar­stellt. Kon­kret han­delt es sich um einen Read-Only Zugriff via SQL- Abfra­gen auf Tabel­len, deren Spei­cher­orte außer­halb des Daten­bank­sys­tems lie­gen, auf dem die Abfrage abge­setzt wurde.

Das macht es unter Ande­rem mög­lich eine Sicht auf Daten zu erlan­gen, ohne res­sour­cen­las­tige Pro­zesse zur Daten­mi­gra­tion zu implementieren.

Vor­teile gegen­über der klas­si­schen Daten­in­te­gra­tion in ein neues Sys­tem sind, wie im vor­he­ri­gen Satz schon ange­deu­tet, auf ETL-Pro­zesse ganz ver­zich­ten zu kön­nen und sowohl eine dop­pelte Daten­hal­tung als auch zusätz­li­chen Spei­cher­ver­brauch zu vermeiden.

Ein signi­fi­kan­ter Nach­teil die­ser Tech­nik wie­derum besteht in der Per­for­mance der ein­zel­nen Abfra­gen. Diese fällt auf­grund von zusätz­li­chen Arbeits­schrit­ten deut­lich schlech­ter aus. Des Wei­te­ren ist zu beach­ten, dass es sich hier nur um einen lesen­den Zugriff han­delt. Schrei­b­ope­ra­tio­nen wie insert, update & delete sind nicht möglich.

Exa­sol und Vir­tual Schemas

Die Exa­solDB ist eine Ana­ly­se­da­ten­bank, deren Stärke ist, große Abfra­gen in kür­zes­ter Zeit durch­zu­füh­ren. Ihre Fähig­kei­ten große Daten­men­gen zu im- oder expor­tie­ren, darf den­noch nicht außer Acht gelas­sen werden.

Mit den soge­nann­ten Vir­tual Sche­mas bie­tet die Exa­sol Daten­bank ein Fea­ture an, mit dem es unkom­pli­ziert mög­lich ist sich externe Daten aus­ge­ben zu lassen.

Bei Vir­tual Sche­mas han­delt es sich um logi­sche Ein­rich­tun­gen ähn­lich zu gewöhn­li­chen Daten­bank­sche­mas. In die­sen wer­den Tabel­len­struk­tu­ren, so genannte Vir­tual Tables, zum Lesen der exter­nen Daten ange­legt. Auf­grund der ähn­li­chen Hand­ha­bung zu Daten­bank­sche­mas sind Ver­knüp­fun­gen zu sche­ma­frem­den Tabel­len via Joins oder Uni­ons mög­lich. Dar­über hin­aus spielt es keine Rolle, ob die zu ver­knüp­fen­den Tabel­len aus einem Daten­bank­schema oder einem Vir­tual Schema stammt. Des Wei­te­ren hat jedes Vir­tual Schema sein eige­nes Rights Manage­ment. Daten oder Tabel­len, die durch ein Vir­tual Schema gele­sen wer­den sol­len, kön­nen dabei aus rela­tio­na­len Daten­ban­ken stam­men wie zum Bei­spiel einem Ora­cle RDBMS oder auch aus Ama­zon S3 Buckets außer­halb eines RDBMS. Letz­te­res funk­tio­niert aller­dings nur, wenn die Daten in dem For­mat PARQUET oder JSON gespei­chert sind.

Im Gegen­satz zu ähn­li­chen Tech­ni­ken in ande­ren Daten­ban­ken, fal­len für die Nut­zung von Vir­tual Sche­mas keine wei­te­ren Kos­ten an.

Für die Ein­rich­tung eines Vir­tual Sche­mas stellt Exa­sol in Ihrer Doku­men­ta­tion ein gene­rel­les „Koch­re­zept“ zur Ver­fü­gung. Egal ob aus einer frem­den Daten­bank oder einem Ama­zon S3 Bucket gele­sen wer­den soll, ist ein Vir­tual Schema in drei bis vier Schrit­ten ein­ge­rich­tet. Alle nöti­gen Infor­ma­tio­nen zu Ein­rich­tung befin­den sich unter:

Vir­tual Schema User Guide | Exa­sol DB Documentation

Mit den bereit­ge­stell­ten Import-Mög­lich­keit der Exa­solDB las­sen sich außer­dem ver­schie­denste Daten­quel­len mit einer Data Inges­tion-Stra­te­gie mit der Hilfe von Vir­tual Sche­mas importieren.

Use cases

Auf den ers­ten Blick würde man zu dem Schluss kom­men, dass sich der Ein­satz eher auf Proof of Con­cepts (POC), Mini­mum Via­ble Pro­ducts (MVP) oder Lösun­gen, bei denen die Per­for­mance zunächst zweit­ran­gig beschränkt ist.

Nut­zen und Mög­lich­kei­ten gehen aller­dings weit dar­über hin­aus. Es wer­den im Fol­gen­den einige Use Cases vorgestellt.

Data Inges­tion

 Das Prin­zip der Data Inges­tion beruht auf der Idee, ver­schie­dene Daten­quel­len an einer Stelle zu zen­tra­li­sie­ren. Wie schon im vor­he­ri­gen Kapi­tel ange­ris­sen sind Data Inges­tion-Stra­te­gien der ver­mut­lich am häu­figs­ten auf­tre­tende Use Case von Vir­tual Schema.

Ver­ein­facht gesagt wer­den anstelle von resour­cen­las­ti­gen ETL-Pro­zes­sen über meh­rere Anwen­dun­gen hin­weg, die Ergeb­nis­menge der Abfrage aus den Vir­tual Sche­mas her­aus via Import-State­ment in die vor­ge­se­hene Ziel­ta­belle auf der Exa­solDB hineingeschrieben.

Vor Allem wenn die Daten aus ver­schie­de­nen Sys­te­men kom­men, kann durch die Nut­zung der vir­tu­el­len Sche­mas Kom­ple­xi­tät ver­ein­facht werden.

Bewirt­schaf­tung ohne Vir­tual Schemas

Bewirt­schaf­tung mit Vir­tual Schemas

His­to­ri­sie­rungs­stra­te­gien

Unter­neh­men ste­hen häu­fig vor der Her­aus­for­de­rung, eine Daten­stra­te­gie für Ihr Data Ware­house zu ent­wi­ckeln, die über Last sowie Hal­tungs­dauer und Archi­vie­rung ent­schei­det. Für den Fall, dass bereits archi­vierte Daten noch ein­mal zum Ver­gleich her­an­ge­zo­gen wer­den müs­sen, bie­tet auch hier eine Tech­nik zum Aus­le­sen exter­ner Daten­quel­len eine Lösung mit wenig Aufwand.

Archi­vierte Daten wer­den auf­grund der unre­gel­mä­ßi­gen Abfrage in der Regel außer­halb von rela­tio­na­len Daten­ban­ken auf­be­wahrt zum Bei­spiel in S3-Buckets.

Mit­hilfe der Vir­tual Schema las­sen sich die Daten ohne große Pro­bleme mit den aktu­el­len Daten inner­halb der Daten­bank bei Bedarf vergleichen.

Im unten ste­hen­den Code Bei­spiel wird ein Ver­gleich von Ver­kaufs­zah­len gezeigt. Dabei wer­den aktu­elle Zah­len und Zah­len vor 10 Jah­ren ver­gli­chen. Die älte­ren Daten wer­den dabei aus einem Vir­tual 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

;

Daten­aus­tausch inner­halb stra­te­gi­scher Partnerschaften

Inner­halb von Fir­men­ko­ope­ra­tio­nen ist der Aus­tausch von Daten ein wich­ti­ger Bestand­teil. Ver­schie­dene Ansätze sind unter ande­rem den Mit­ar­bei­tern des Koope­ra­ti­ons­part­ners mit­tels ein­ge­rich­te­ten User Zugriff auf ent­spre­chende fir­men­in­terne Daten zu gewähr­leis­ten. Je nach Anzahl an neuen Usern und Umfang der Berech­ti­gun­gen kann die Ver­wal­tung die­ser große Auf­wände berei­ten. Auch hier bie­tet das Lesen exter­ner Daten­quel­len eine ein­fach umzu­set­zende Lösung.

Hier reicht es auch dem Koope­ra­ti­ons­part­ner die für den Daten­aus­tausch vor­ge­se­he­nen Tabel­len, samt Tabel­len­de­fi­ni­tion und wei­tere tech­ni­sche Infor­ma­tio­nen, zu nen­nen, damit der Koope­ra­ti­ons­part­ner den Zugriff bei sich im Sys­tem ein­rich­ten kann. Auf­wände für ein umfang­rei­ches Berech­ti­gungs­kon­zept fal­len dabei ganz weg.

Schwä­chen

Nach­dem ein paar span­nende Use Cases für Vir­tual Sche­mas vor­ge­stellt wur­den, wer­den im Fol­gen­den einige Nach­teile ange­spro­chen. Diese sind eher gene­rel­ler Natur und stel­len für alle Anwen­dungs­zwe­cke eine Her­aus­for­de­rung dar.

Ver­füg­bar­keit & Wartbarkeit

Damit ein Vir­tual Schema eine fremde Tabelle lesen kann, benö­tigt es unter ande­rem Infor­ma­tio­nen zu den Spal­ten, Daten­ty­pen, der Daten­größe der Tabelle und, falls es sich bei der exter­nen Quelle um eine Daten­bank han­delt, den JDBC-Treiber.

Falls in den exter­nen Sys­te­men Ände­run­gen an Tabelle oder Trei­ber vor­ge­nom­men wer­den, müs­sen diese eben­falls in dem Vir­tual Schema nach­ge­zo­gen wer­den. Ansons­ten besteht die Gefahr, dass das Vir­tual Schema nicht in der Lage ist, die Daten zu lesen.

Per­for­mance

Die Per­for­mance der Abfra­gen ist weit­aus schwä­cher. Wäh­rend ein­fach gehal­tene Sel­ect-State­ments mit einer akzep­ta­blen Per­for­mance lau­fen, ist bei kom­ple­xen SQLs mit meh­re­ren Joins Vor­sicht gebo­ten. Unter ande­rem besteht die Gefahr in einen Time­out-Feh­ler zu rennen.

Fazit

Alles in allem hat das Lesen von exter­nen Daten einige span­nende Anwen­dungs­fälle. Im Fall der vor­ge­stell­ten Use Cases, allen voran der Data Inges­tion-Stra­te­gie, sollte ihr Poten­zial nicht außer Acht gelas­sen werden.

Trotz­dem kommt diese Tech­nik auf­grund der Nach­teile wie der schlech­te­ren Per­for­mance, Wart­bar­keit oder auch ihrer Ver­füg­bar­keit zu kurz. Eine Mög­lich­keit sie popu­lä­rer zu machen, wäre diese, wie bei den Exa­sol Vir­tual Sche­mas, in jeder Lizenz mit anzubieten.