Say Hello to the Data Cloud

Am letz­ten Diens­tag, den 02.06.2020, hat Snow­flake die neue Data Cloud prä­sen­tiert und wäh­rend eines Online-Auf­trit­tes vor­ge­stellt. Wäh­rend die­ser Prä­sen­ta­tion wur­den neue Fea­tures ange­kün­digt, wel­che in den nächs­ten Wochen und Mona­ten ver­öf­fent­licht wer­den sollen.

Vom leich­ten Schnee­sturm zum Blizzard

Snow­flake hat in den letz­ten Jah­ren ein unglaub­li­ches Wachs­tum erlebt und ist an den aktu­el­len Ent­wick­lun­gen im Bereich des Data Ware­housing stark betei­ligt. Workloads sind von einer Grö­ßen­ord­nung von eini­gen Tera­byte auf Peta­byte gewach­sen und Clou­dan­bie­ter wie Snow­flake haben es mög­lich gemacht, dass Jobs, wel­che in einem on-pre­mise Sys­tem meh­rere Stun­den benö­tig­ten, nun in weni­gen Minu­ten in der Cloud erle­digt sind.

Zur­zeit umfasst Snow­flake eige­nen Anga­ben nach mehr als 4.000 aktive Accounts, wovon allein im letz­ten Jahr 2.000 hin­zu­ge­kom­men sind. In die­sen 4.000 Accounts arbei­ten jeden Monat mehr als 100.000 aktive Nut­zer, wel­che über 450.000.000 (450 Mil­lio­nen) Jobs pro Tag aus­füh­ren. Um die­sem Ansturm gerecht zu wer­den, wird Snow­flake immer wei­ter ver­bes­sert und um sinn­volle Funk­tio­nen ergänzt.

Die Data Cloud

Wäh­rend der Prä­sen­ta­tion wurde die Data Cloud von Snow­flake vor­ge­stellt. Die Data Cloud soll eine neue Art des Den­kens ansto­ßen. Durch die frü­he­ren Ent­wick­lun­gen im Bereich Data Ware­housing, haben sich viele Daten­ban­ken zu soge­nann­ten Data Silos ent­wi­ckelt, wel­che es nur schwer ermög­li­chen, neue Jobs zu imple­men­tie­ren oder neue Daten zu inte­grie­ren (geschweige denn Daten aus die­sem Silo zu lesen), wes­we­gen sie auch den Spitz­na­men Data Bun­ker erhal­ten haben. Die Vision von Snow­flake ist dem ent­ge­gen­ge­setzt: Jeder Snow­flake-Account ist mit einem Silo ver­gleich­bar. Im Gegen­satz zu den älte­ren Silos besitzt aber jeder Snow­flake-Account die Mög­lich­keit, seine Daten zu tei­len und ande­ren Snow­flake-Nut­zern Zugriff zu gewäh­ren. Prin­zi­pi­ell ist dies auch in älte­ren Sys­te­men wie Hadoop oder SQL Ser­ver zumin­dest intern mög­lich. Da in Snow­flake alle Kun­den, abge­se­hen von Vir­tual Private Snow­flake Kun­den, auf der­sel­ben Infrastruktur lau­fen, ist das Data­sha­ring in Snow­flake auch mit Exter­nen in Sekun­den möglich.

Sha­ring ist in Snow­flake sowohl in einem Ver­hält­nis von einem Pro­du­zen­ten und einem Kon­su­men­ten mög­lich, aber auch meh­rere Kon­su­men­ten kön­nen die Daten eines Pro­du­zen­ten erhal­ten bezie­hungs­weise vice versa meh­rere Pro­du­zen­ten einen Kon­su­men­ten mit Daten belie­fern. Dies geschieht natür­lich alles mit den nöti­gen Sicher­heits­maß­nah­men, wel­che von Snow­flake getrof­fen wer­den und von dem Pro­du­zen­ten regu­liert wer­den kön­nen. Wäh­rend des Shares wer­den keine Daten kopiert, sodass das Sha­ring ledig­lich auf einer vir­tu­el­len Ebene geschieht. Ände­run­gen an dem ursprüng­li­chen Daten­satz wer­den hier­bei ohne Ver­zö­ge­run­gen in dem Account des Kon­su­men­ten erfasst und ein­ge­ar­bei­tet, sodass Kon­su­men­ten immer mit dem aktu­ells­ten Daten­satz arbei­ten kön­nen. Dies ermög­licht ein fle­xi­ble­res Ver­ar­bei­ten der Daten, wel­ches mit klas­si­schen Data Silos nicht mög­lich wäre. Wäh­rend der Arbeit mit Daten ist die Aktua­li­tät eben die­ser von höchs­ter Rele­vanz, denn nur so kön­nen Data Sci­en­tists aktu­elle Modelle ent­wi­ckeln, wel­che die Qua­li­tät der Geschäfts­ent­schei­dun­gen erhöht. Basie­rend auf die­sem Kon­zept hat Snow­flake den Data Mar­ket­place erschaf­fen. Hier kön­nen Daten von Unter­neh­men ange­fragt wer­den, um diese wei­ter zu ver­ar­bei­ten und auch in ihre eigene Daten­bank ein­zu­flech­ten zu kön­nen. Ein belieb­ter Anbie­ter hier­von ist Star­schema. Star­schema stellt Daten zur Aus­brei­tung des Covid-19 Virus bereit. Diese Daten­sätze kön­nen, wie oben erwähnt, in die eige­nen Daten­sätze inte­griert, wei­ter­ver­ar­bei­tet und ana­ly­siert wer­den. So ist zum Bei­spiel eine Ana­lyse des eige­nen Geschäfts hin­sicht­lich der Aus­wir­kun­gen, die das Coro­na­vi­rus hatte, mög­lich. Summa Sum­ma­rum lässt sich die Data Cloud als Denk­an­satz ver­ste­hen, in wel­chem Daten nicht fest und ungreif­bar, son­dern fle­xi­bel und leicht nutz­bar sind. Wei­ter­hin sol­len Daten sich ein­fach in Jobs inte­grie­ren las­sen und leicht abruf­bar sein. Dies wird in der Data Cloud mit einem hohen Maß an Sicher­heit und einer, durch die freie Ska­lier­bar­keit von Snow­flake gege­be­nen, hohen Wirt­schaft­lich­keit gepaart.

Neue Fea­tures

Neben der Data Cloud wur­den in der Prä­sen­ta­tion auch einige neue Fea­tures vor­ge­stellt, wel­che die sechs „Key-Workloads“, Data Engi­nee­ring, Data Lake, Data Ware­house, Data Sci­ence, Data Appli­ca­tion, Data Exch­ange, wei­ter ver­bes­sern und ver­net­zen soll. Diese neuen Fea­tures wer­den von Snow­flake in drei grund­sätz­li­che Kate­go­rien auf­ge­teilt: „Core Plat­form Lea­der­ship“, „Exten­si­ble Data Pipe­lines“ und „Data Cloud Content“.

Snow­sight

In den Bereich der „Core Plat­form Lea­der­ship“ fällt bei­spiels­weise das Fea­ture Snow­sight. Snow­sight soll, zusätz­lich zu einem gra­fisch auf­be­rei­te­ten Inter­face, die Arbeit von Data Ana­lysts und Engi­neers leich­ter machen. Fea­tures, die in Snow­sight ent­hal­ten sind, sind bei­spiels­weise eine Auto-com­plete Funk­tion und die Mög­lich­keit Sche­mata gezielt zu durch­su­chen, was das Schrei­ben von Queries ver­ein­fa­chen soll. Des wei­te­ren wer­den Charts und Dash­boards hin­zu­ge­fügt, wel­che die visu­elle Ana­lyse der Daten in Snow­flake selbst ermög­licht und einen leich­te­ren Zugang zu den Daten gewährt.

Trans­pa­rent Mate­ria­li­zed View Usage

Ein Mate­ria­li­zed View in Snow­flake ist ein Daten­satz, auf wel­chen bereits eine Query ange­wandt und des­sen Resul­tat gespei­chert wurde. Sie wur­den ein­ge­führt, um die Per­for­mance von anknüp­fen­den Queries zu erhö­hen, da sich so die Not­wen­dig­keit des Aus­füh­rens der ursprüng­li­chen Query erüb­rigt und somit sowohl Zeit als auch Com­pute-Res­sour­cen gespart wer­den kön­nen. In Snow­flake war es aller­dings bis­her so, dass wenn man eine Mate­ria­li­zed View ver­wen­den wollte, diese expli­zit in der Query genannt wer­den musste. Dies soll sich ändern: In Zukunft soll Snow­flake auto­ma­tisch erken­nen kön­nen, ob eine Mate­ria­li­zed View einer Tabelle exis­tiert, wel­che die Geschwin­dig­keit der Query erhöht und ver­wen­det diese dann auto­ma­tisch. Dies bewirkt, dass Daten­mo­delle und Queries bei der Ana­lyse nicht geän­dert wer­den müs­sen, wenn man sich dazu ent­schei­det, zur Ver­bes­se­rung der all­ge­mei­nen Per­for­mance eine Mate­ria­li­zed View zu verwenden.

Search Opti­miza­tion Service

Search Opti­miza­tion Ser­vice ist ein neues Fea­ture in Snow­flake, wel­ches die Per­for­mance von Fil­ter-Abfra­gen ver­bes­sern soll. Dies war bis­her in Snow­flake nur über Clus­te­ring mög­lich, was die Anord­nung der Micro­par­ti­ti­ons ver­än­dert hat und somit die Per­for­mance auf Queries die den Clus­te­ring-Key beinhal­tet hat, stark ver­bes­serte. Das Ein­füh­ren eines Clus­te­ring-Keys wurde von Snow­flake aller­dings erst ab einer Grö­ßen­ord­nung von über 1TB emp­foh­len und war mit zusätz­li­chen Kos­ten ver­bun­den. Search Opti­miza­tion Ser­vice soll eine Alter­na­tive zum Clus­te­ring-Key dar­stel­len. Die­ses Fea­ture muss expli­zit für Tabel­len akti­viert wer­den. Search Opti­miza­tion Ser­vice stellt pre-com­pu­ted Infor­ma­tio­nen zu einer Tabelle bereit, ähn­lich wie es Mate­ria­li­zed Views tun, und erhöht so die Per­for­mance von Fil­ter-Abfra­gen. Diese vor­be­rei­te­ten Infor­ma­tio­nen wer­den bei Aktua­li­sie­rung der Daten eben­falls geup­dated. Wäh­rend einer Demons­tra­tion des Ser­vices wurde in einer Tabelle mit 28 Mil­li­ar­den Rei­hen nach einer E‑Mail-Adresse gefil­tert. Zum Ver­gleich wurde die Query ein­mal auf einem XXLARGE Ware­house ohne Search Opti­miza­tion aus­ge­führt und ein­mal auf einem XSMALL Ware­house, aller­dings mit Search Opti­miza­tion. Obwohl die Abfrage mit Search Opti­miza­tion mit einem deut­lich klei­ne­ren Ware­house statt­fand, hat die Query ledig­lich 3,9 Sekun­den gedau­ert. Auf dem 32-mal grö­ße­ren XXLARGE Ware­house ohne Search Opti­miza­tion benö­tigte die Query ganze 37 Sekun­den und hat somit unge­fähr 9,5‑mal so lange gedau­ert. Diese Zeit-und-Res­sour­cen­er­spar­nis resul­tiert in einer Kos­ten­er­spar­nis für den Kun­den. Es wird aller­dings nicht expli­zit genannt, wel­che zusätz­li­chen Kos­ten durch die Ver­wen­dung der Search Opti­miza­tion ent­ste­hen. Snow­flake emp­fiehlt die Ver­wen­dung des Search Opti­miza­tion Ser­vices ab einer Tabel­len­größe von 100GB und einer Menge von min­des­tens 100.000 bis 200.000 ver­schie­de­nen Werten.

Stär­ken wer­den wei­ter ausgebaut

Eine von Snow­flakes gro­ßen Stär­ken ist der Ein­satz von SQL-Code. Snow­flake unter­stützt bereits eine Viel­zahl von SQL-Befeh­len und wird sein Reper­toire in Zukunft wei­ter ver­grö­ßern. Wei­ter­hin sol­len zusätz­li­che Daten­ty­pen, wie bei­spiels­weise der Geo­gra­phy Data­type, neue Win­dow­func­tions und neue Ope­ra­to­ren hin­zu­ge­fügt wer­den. Außer­dem möchte Snow­flake seine Fähig­keit zur Migra­tion von einer bereits bestehen­den Platt­form ver­bes­sern. Dies ist ein wei­te­rer Grund, einen Umzug nach Snow­flake in Erwä­gung zu zie­hen, wel­cher die in dem Blog­bei­trag „Why migrate to Snow­flake?“ bereits vor­ge­stell­ten Gründe ergänzt. Wei­ter­hin soll in den nächs­ten Mona­ten „SQL Stored Pro­ce­du­res“ zu Snow­flake hin­zu­ge­fügt wer­den, was die Auto­ma­ti­sie­rung von Pro­zes­sen inner­halb von Snow­flake wei­ter vor­an­treibt. Der Unter­schied zu den bis­he­ri­gen Stored Pro­ce­du­res liegt hier­bei in der Spra­che. Stored Pro­ce­du­res in Snow­flake waren bis­her nur in Java­Script mög­lich, sodass die SQL-Befehle in Java­Script ein­ge­bet­tet wer­den muss­ten. Die­ser Umweg wird nun bei zukünf­ti­gen Pro­jek­ten nicht mehr nötig sein.

Dyna­mic Data Masking

Data Gover­nance lässt sich in zwei Teile auf­tei­len: Der eine Teil beinhal­tet die Kennt­nis über seine Daten und der andere Teil das Manage­ment eben jener. Zur Ver­bes­se­rung des eige­nen Data Manage­ments und zur Erhö­hung der Sicher­heit der Daten, hat Snow­flake das „Dyna­mic Data Mas­king“ ein­ge­führt. Mit­tels die­ses neuen Fea­tures kann man ein­zel­nen Spal­ten einer Tabelle eine spe­zi­elle Policy hin­zu­fü­gen, wel­che die Anzeige die­ser Spalte beein­flusst. Dies erlaubt es die Daten in die­ser Spalte für gewis­sen Per­so­nen­grup­pen unkennt­lich zu machen. Ein Bei­spiel hier­für wären E‑Mail-Adres­sen oder Tele­fon­da­ten von Kun­den, wel­che für den Ver­triebs­be­reich einer Firma von Rele­vanz sind, aller­dings bei­spiels­weise für das Data Sci­ence Team nicht sicht­bar sein dür­fen. Mit­tels des neuen Data Mas­kings kann man dem Ver­trieb die nöti­gen Rechte gewäh­ren bezie­hungs­weise dem Data Sci­ence Bereich diese ent­zie­hen, ohne eine Kopie der Tabelle vor­zu­neh­men und somit höhere Spei­cher­kos­ten zu gene­rie­ren. Hier­bei muss man anmer­ken, dass wenn eine Policy für die Anony­mi­sie­rung von Daten getrof­fen wird, die dar­un­ter lie­gen­den Daten ent­we­der voll­stän­dig sicht­bar, teil­weise mas­kiert oder ganz mas­kiert sind. Der Default-Wert hier­bei ist voll­stän­dig mas­kiert, sodass die Sicht­bar­keit bezie­hungs­weise die par­ti­elle Sicht­bar­keit der Daten expli­zit den ein­zel­nen Rol­len zuge­wie­sen wer­den muss. Die Policy wird auto­ma­tisch auf Klone der Tabelle ange­wandt, sodass das Data Mas­king nicht mit­tels Zero-Copy-Clo­ning umgan­gen wer­den kann. Außer­dem kann das Mas­king auch auf Snow­flakes Vari­ant Data­type ange­wandt wer­den und in Data Shares inte­griert werden.

Bei­spiel für ein SELECT * State­ment auf eine Tabelle mit anony­mi­sier­ten Spal­ten im neuen User Inter­face. Hier­bei ist zu sehen, dass der Rolle „Ana­lyst“ (rechts oben) die Sicht auf die Spal­ten LAST_NAME und STREETADRESS voll­stän­dig ver­wehrt bleibt. Die Spalte EMAIL hin­ge­gen ist nur teil­weise für diese Rolle anonymisiert.*

Externe Funk­tio­nen und Programmiersprachen

Neben der Inte­gra­tion von SQL Stored Pro­ce­du­res hat Snow­flake ange­kün­digt, wei­tere Pro­gram­mier­spra­chen für UDFs zu unter­stüt­zen. So soll bei­spiels­weise Java als Mög­lich­keit ange­bo­ten wer­den. Außer­dem soll das Impor­tie­ren exter­ner Funk­tio­nen ermög­licht wer­den. Dies erlaubt es, Funk­tio­nen, die bei­spiels­weise in AWS Lambda mit Python geschrie­ben wor­den sind, nach Snow­flake zu migrie­ren und dort zu benut­zen. Snow­flake arbei­tet außer­dem daran, Module aus bekann­ten Pro­gram­mier­spra­chen zukünf­tig in Snow­flake nutz­bar zu machen. Dies lässt erah­nen, dass zukünf­tig Module wie Python Pan­das in Snow­flake aus­führ­bar sind und deren Funk­ti­ons­um­fang genutzt wer­den kann. All­ge­mein eröff­net dies die Mög­lich­keit, bereits vor­han­de­nes Know-How in Java oder Python nach Snow­flake zu trans­por­tie­ren und dort aus­zu­nut­zen, was ein höhe­res Maß an Fle­xi­bi­li­tät mit sich bringt.

Fazit

Wie ein­gangs erwähnt, wer­den die vor­ge­stell­ten Fea­tures in den nächs­ten Wochen bezie­hungs­weise Mona­ten ver­öf­fent­licht. Die meis­ten Fea­tures befin­den sich der­zeit noch in einer inter­nen Test­phase (bei­spiel­weise das Data Mas­king), einige andere sind aller­dings bereits ver­füg­bar, wie zum Bei­spiel der Data Mar­ket­place oder befin­den sich in einer öffent­li­chen Pre­view. Ins­ge­samt sieht man, dass die Ent­wick­lung von Snow­flake noch längst nicht sta­gniert und bis­he­rige Schwä­chen, wie bei­spiels­weise die bis­he­rige Ver­wen­dung der Mate­ria­li­zed Views und die feh­lende Auto-Ver­voll­stän­di­gung in der WebUI,  auf wel­che wir von saracus Con­sul­ting auch wäh­rend unse­rer Semi­nare zum Thema Snow­flake ange­spro­chen wur­den, zukünf­tig aus­ge­bes­sert und die bereits vor­han­de­nen Stär­ken wei­ter aus­ge­baut wer­den. Neben den Neue­run­gen in Snow­flake selbst wird es inter­es­sant sein, die Ver­än­de­run­gen in den ver­schie­de­nen Part­ner-Tools wie bei­spiels­weise Matil­lion zu beob­ach­ten, da diese die Funk­tio­na­li­tät von Snow­flake aus­nut­zen und somit auch von den Neue­run­gen pro­fi­tie­ren können.