Ein­füh­rung

Snow­flake ist eine Cloud-basierte Soft­ware-as-a-Ser­vice (SaaS) Lösung der Snow­flake Inc. aus San Mateo in Kali­for­nien, Ame­rika. Das Unter­neh­men wurde 2012 gegrün­det und ver­folgt das Ziel eine inno­va­tive Cloud-Daten­platt­form bereit­zu­stel­len. Diese legt den Fokus auf die vier in der nach­fol­gen­den Gra­fik sicht­ba­ren und für den Nut­zer opti­ma­len Ziele.

Ins­be­son­dere im Hin­blick auf ältere On-Premises Lösun­gen, offe­riert die Snow­flake Inc. eine grund­le­gend neu­ar­tige und anwen­der­freund­li­che Option. Bei der Ers­te­ren war noch die Anschaf­fung und War­tung der Hard- und Soft­ware not­wen­dig, was in zusätz­li­chen Aus­ga­ben für diese und zuge­hö­ri­ges Per­so­nal resul­tiert. Hier setzt die Idee des Cloud Com­pu­tings an und offe­riert dem Inter­es­sen­ten eine Lösung wel­che sich an des­sen zen­tra­lem Bedarf, dem Spei­chern und Bereit­stel­len der Daten, ori­en­tiert. Dabei ermög­licht die Snow­flake Platt­form, bei einer sin­gu­lä­ren Kopie der gespei­cher­ten Daten, das Ver­ar­bei­ten von mul­ti­plen Abfra­gen. Dar­über hin­aus steht dem Nut­zer hin­sicht­lich der Spei­cher- als auch Rechen­ka­pa­zi­tät eine nahezu unbe­grenzte Ska­lier­bar­keit zur Ver­fü­gung. Dies wird ins­be­son­dere zukünf­ti­gen Ansprü­chen gerecht. Eben­falls wird sei­tens des Anbie­ters für die Ver­schlüs­se­lung und somit eine sichere Auf­be­wah­rung der Daten gesorgt. Snow­flake nutzt mit sei­ner Soft­ware kon­kret, abhän­gig von der Wahl des Nut­zers, die Hard­ware von Micro­soft Azure, Google Cloud oder Ama­zon AWS.

Archi­tek­tur

Die Archi­tek­tur der Snow­flake Cloud lässt sich prin­zi­pi­ell in drei eher abs­trakt zu sehende Schich­ten ein­tei­len. Die Abgren­zung unter­ein­an­der fin­det in ers­ter Linie auf funk­tio­na­ler Ebene und weni­ger auf Hard­ware­ebene statt. Dabei exis­tie­ren, sicht­bar in Abbil­dung 2, Data Sto­rage Layer, Com­pute Layer und Cloud Ser­vices Layer. Auf diese wird im Fol­gen­den nun genauer eingegangen.

Cloud Ser­vices Layer

Der Cloud Ser­vices Layer ist die über­ge­ord­nete Schicht, wel­che sich um mul­ti­ple ganz­heit­li­che Funk­tio­nen küm­mert. Dazu zählt unter ande­rem die Authen­ti­fi­zie­rung des Benut­zers und die Zugriffs­ver­wal­tung für Benut­zer und Roles. Dies fällt in der Snow­flake unter die Begriffe Authen­ti­ca­tion & Access Con­trol. Wei­ter­hin fin­det in die­sem Layer die Ver­wal­tung der Res­sour­cen, respek­tive der von Snow­flake genutz­ten Hard­ware statt. Der Kern für das Inter­agie­ren mit der Daten­bank ist die Daten­bank­ab­fra­ge­spra­che SQL. Auch die Snow­flake beinhal­tet dies­be­züg­lich einen Opti­mi­zer, wel­cher vom Nut­zer ein­ge­ge­bene Queries zer­legt und vor der Aus­füh­rung opti­miert. Dar­über hin­aus fin­det das Meta­da­ten-Manage­ment ebenso im Cloud Ser­vices Layer statt. In der Snow­flake spie­len Meta­da­ten eine zen­trale Rolle. Diese beinhal­ten Infor­ma­tio­nen auf Tabel­len­ebene als auch auf der Ebene der Micro Par­ti­ti­ons, auf die im letz­ten Abschnitt genauer ein­ge­gan­gen wird. Im Hin­blick auf die Tabel­len selbst beinhal­ten die Meta­da­ten bei­spiels­weise die Anzahl der Zei­len und die Tabel­len­größe in Bytes. Mit­tels der Gesamt­heit der Meta­da­ten wird unter ande­rem die Time Tra­vel Funk­tion ermög­licht, mit der der Nut­zer auf ältere Stände der Daten­bank zugrei­fen kann.

Com­pute Layer

Der zweite Layer, respek­tive Com­pute Layer dient zum Aus­füh­ren der Queries selbst. Hier­für wer­den durch die Snow­flake soge­nannte Vir­tual Warehou­ses bereit­ge­stellt. Der Ter­mi­nus ist eine pro­prie­täre Snow­flake Bezeich­nung, wel­che ein Clus­ter von Ser­vern mit dedi­zier­ter Hard­ware umfasst. Diese beinhal­tet die CPU, Memory und per­ma­nen­ten Spei­cher­platz. Warehou­ses kön­nen vom Benut­zer selbst in ihrer Größe alter­niert wer­den. Dies ist prin­zi­pi­ell in zwei Dimen­sio­nen mög­lich, der Ware­house Size und dem Clus­ter Count. Ers­te­res erhöht die Per­for­mance kom­ple­xer Queries und wird Scale Up genannt. Letz­te­res ver­bes­sert das Rech­nen meh­re­rer par­al­le­ler Queries und wird mit Scale Out bezeich­net. Die Warehou­ses star­ten mit der Größe extra small (XS) und einem Ser­ver pro Clus­ter. Mit jedem Schritt ver­dop­pelt sich des­sen Größe. Neben der ver­bes­ser­ten Leis­tung stei­gen die berech­ne­ten Kos­ten selbst­ver­ständ­lich pro­por­tio­nal. Der große Vor­teil des Ware­house Ansat­zes für den Nut­zer ist sowohl die ange­spro­chene Ska­lier­bar­keit in zwei Rich­tun­gen als auch die Option die Instan­zen zu pau­sie­ren. So ent­ste­hen bei­spiel­weise keine Kos­ten, solange ein Ware­house inak­tiv ist. Wäh­rend­des­sen kön­nen selbst­ver­ständ­lich auch keine Queries aus­ge­führt wer­den. Des Wei­te­ren tei­len sich Vir­tual Warehou­ses keine Res­sour­cen. Folg­lich beein­flus­sen diese sich nicht gegen­sei­tig im Hin­blick auf ihre Performance.

Data­base Sto­rage Layer

Daten wer­den durch die Snow­flake eben­falls per­ma­nent in der Cloud gespei­chert. Auch hier­über braucht sich der Anwen­der keine kon­kre­ten Gedan­ken machen, da dies auto­ma­tisch durch die Soft­ware geschieht. Tech­nisch gese­hen sind die Daten selbst­ver­ständ­lich auf der zugrun­de­lie­gen­den vom Nut­zer gewähl­ten Cloud gespei­chert. Dabei sind alle Daten, sowohl in Bewe­gung als auch in Ruhe, per­ma­nent ver­schlüs­selt. Auch dies über­nimmt die Soft­ware und geschieht voll­stän­dig auto­ma­tisch. Infor­ma­ti­ons­tech­nisch sind die Daten wei­ter­hin im Snow­flake eige­nen kolum­na­ren For­mat gespei­chert. Hier­bei greift die Soft­ware auf das Kon­zept der Micro­par­ti­ti­ons zu. Diese haben im unkom­pri­mier­ten Fall eine Größe von 50–500 MB und umfas­sen kom­pri­miert maxi­mal 16 MB. Dar­über hin­aus sind Micro­par­ti­ti­ons unver­än­der­bar. Das heißt des­sen Inhalt bleibt bestehen und wird auch beim Alter­nie­ren der Daten­bank nicht ver­än­dert. Der Nut­zer selbst hat beding­ten Ein­fluss auf die Par­ti­tio­nie­rung der Daten wäh­rend des erst­ma­li­gen Ladens in die Cloud. Dabei wird die Ord­nung der Daten in der Rei­hen­folge, in wel­cher sie in die Snow­flake gela­den wer­den, bei­be­hal­ten. Auch auf der Ebene der Micro­par­ti­ti­ons wer­den Meta­da­ten erho­ben, um die Query Per­for­mance signi­fi­kant zu ver­bes­sern. Diese umfas­sen des­sen Range, die Anzahl ver­schie­de­ner Werte und die Anzahl von Null Ein­trä­gen. Der Opti­mi­zer nutzt diese Meta­da­ten geschickt, um für eine spe­zi­fi­sche Query irrele­vante Micro­par­ti­ti­ons direkt aus­zu­schlie­ßen und somit die Lauf­zeit signi­fi­kant zu ver­bes­sern. Dies wird in der Snow­flake als Pru­ning bezeichnet.

Fazit

Ganz­heit­lich gese­hen baut die Snow­flake ent­spre­chend auf einer grund­le­gend neuen Archi­tek­tur auf, wel­che die teure Anschaf­fung einer On-Premises Lösung über­flüs­sig macht und nahezu alle damit ver­bun­de­nen tech­ni­schen und admi­nis­tra­ti­ven Fra­gen über­nimmt. Dadurch ergibt sich eine güns­tige, ska­lier­bare Cloud-Platt­form, wel­che aus­schließ­lich Kos­ten bei Benut­zung verursacht.