Die Platt­form von Snow­flake unter­schei­det sich archi­tek­to­nisch von fast allen her­kömm­li­chen Daten­bank­sys­te­men und Cloud Data Warehou­ses. Snow­flake ver­fügt über voll­stän­dig getrennte Rechen- und Spei­cher­ka­pa­zi­tä­ten, und beide Ebe­nen der Platt­form sind nahezu augen­blick­lich elas­tisch. Mit Snow­flake ent­fällt die Not­wen­dig­keit, eine fort­schritt­li­che Res­sour­cen­pla­nung vor­zu­neh­men, sich mit Workload-Zeit­plä­nen her­um­zu­schla­gen und neue Workloads auf dem Sys­tem zu ver­hin­dern, weil man Angst vor Fest­plat­ten- und CPU-Limi­tie­run­gen hat. Als Cloud-Daten­platt­form kann Snow­flake nahezu sofort ska­liert wer­den, um geplan­tes, Ad-hoc- oder über­ra­schen­des Wachs­tum zu bewäl­ti­gen. Das bedeu­tet, dass Sie nicht für eine feste, begrenzte Menge an Spei­cher- und Rechen­leis­tung bezah­len müs­sen, son­dern dass die Menge an Spei­cher- und Rechen­leis­tung wächst und schrumpft, wenn sich Ihre Anfor­de­run­gen im Laufe der Zeit ändern.

Durch die Nut­zung eines Kern­prin­zips der Cloud kön­nen Elas­ti­zi­tät und Rechen­leis­tung im Laufe des Tages dyna­misch auf Arbeits­las­ten ska­liert wer­den, wenn der Bedarf an Gleich­zei­tig­keit oder roher Rechen­leis­tung schwankt, um die Nach­frage zu befrie­di­gen. Der Spei­cher­platz für Daten­ban­ken, Tabel­len und Meta­da­ten wird mit der Zeit wach­sen und schrump­fen. Es gibt einige Opti­mie­run­gen, die jeder Snow­flake-Kon­to­ver­wal­ter vor­neh­men sollte, und einige fort­schritt­li­chere Metho­den, die er in Betracht zie­hen sollte, wenn sein Snow­flake-Rechen­auf­wand wächst. Da Rechen­leis­tung und Spei­cher getrennt und elas­tisch sind, soll­ten diese Res­sour­cen auf Ver­brauch, über­ra­schen­des Wachs­tum und Res­sour­cen­ef­fi­zi­enz über­wacht werden.

Snow­flake ist stan­dard­mä­ßig prak­tisch unbe­grenzt, und Kon­toad­mi­nis­tra­to­ren kön­nen klei­nere Ein­schrän­kun­gen auf Konto- und Res­sour­cen­ebene ein­rich­ten, um sich gegen unse­riöse Benut­zer oder eine sub­op­ti­male Nut­zung von Res­sour­cen und Gut­ha­ben zu schüt­zen. So kön­nen sie bei­spiels­weise die Rechen­leis­tung auf der Ebene ein­zel­ner vir­tu­el­ler Lager­häu­ser, auf Benut­zer­ebene oder auf Konto- und Orga­ni­sa­ti­ons­ebene durch Res­sour­cen­mo­ni­tore pro­ak­tiv kon­trol­lie­ren. Benut­zer, Daten­ban­ken, Tabel­len, Abfra­gen und Workloads kön­nen über das ACCOUN­T_U­SAGE-Schema über­wacht wer­den, das allen Snow­flake-Kon­ten gemein­sam ist. Die fol­gende Abbil­dung zeigt den Sta­tus und die Grund­kon­fi­gu­ra­tion von vir­tu­el­len Lager­häu­sern in einem Konto:

Best Prac­tice #1: Auto-Sus­pend akti­vie­ren
Stel­len Sie sicher, dass alle vir­tu­el­len Lager­häu­ser auf auto­ma­ti­sche Aus­set­zung ein­ge­stellt sind. Auf diese Weise schal­tet Auto-Sus­pend Ihre vir­tu­el­len Lager aus, wenn sie mit der Ver­ar­bei­tung von Abfra­gen fer­tig sind, und stoppt so den Kre­dit­ver­brauch. Füh­ren Sie die fol­gende Abfrage aus, um alle vir­tu­el­len Lager zu ermit­teln, für die die auto­ma­ti­sche Aus­set­zung nicht akti­viert ist:

Best Prac­tice #2: Auto­ma­ti­sche Wie­der­auf­nahme akti­vie­ren
Stel­len Sie sicher, dass alle vir­tu­el­len Lager auf auto­ma­ti­sche Wie­der­auf­nahme ein­ge­stellt sind. Wenn Sie die auto­ma­ti­sche Unter­bre­chung imple­men­tie­ren und ent­spre­chende Time­out-Gren­zen fest­le­gen, ist die Akti­vie­rung der auto­ma­ti­schen Wie­der­auf­nahme ein Muss; andern­falls kön­nen die Benut­zer das Sys­tem nicht abfra­gen. Füh­ren Sie die fol­gen­den Schritte aus, um alle vir­tu­el­len Lager zu iden­ti­fi­zie­ren, die nicht auto­ma­tisch fort­ge­setzt wer­den, wenn sie abge­fragt werden:

Best Prac­tice Nr. 3: Ange­mes­sene Time­outs für Workloads fest­le­gen
Alle vir­tu­el­len Warehou­ses soll­ten eine für die jewei­lige Arbeits­last geeig­nete Zeit­über­schrei­tung haben:

Für Task‑, Daten­lade- und ETL/ELT-Warehou­ses sollte die Zeit­über­schrei­tung so ein­ge­stellt wer­den, dass sie sofort nach Abschluss been­det wird.
Für BI- und SEL­ECT-Query-Warehou­ses soll­ten Sie den Time­out für die Unter­bre­chung in den meis­ten Fäl­len auf 10 Minu­ten fest­le­gen, um die Daten­caches für den häu­fi­gen Zugriff durch End­be­nut­zer warm zu hal­ten.
Für DevOps‑, Data­Ops- und Data Sci­ence-Warehou­ses set­zen Sie die Zeit­über­schrei­tung für die Aus­set­zung auf 5 Minu­ten, da ein war­mer Cache für Ad-hoc- und sehr indi­vi­du­elle Abfra­gen nicht so wich­tig ist.
Hier ist eine Beispielkonfiguration:

Best Prac­tice Nr. 4: Zeit­über­schrei­tun­gen für Kon­to­aus­züge fest­le­gen
Ver­wen­den Sie die Para­me­ter STATEMENT_QUEUED_TIMEOUT_IN_SECONDS und STATEMENT_TIMEOUT_IN_SECONDS, um auto­ma­tisch Abfra­gen zu stop­pen, deren Aus­füh­rung zu lange dau­ert, ent­we­der auf­grund eines Benut­zer­feh­lers oder eines ein­ge­fro­re­nen Clus­ters. Pas­sen Sie Anwei­sun­gen auf Lager‑, Konto‑, Sit­zungs- und Benut­zer-Time­out-Ebene ent­spre­chend Ihrer Daten­stra­te­gie für lang lau­fende Abfra­gen an.

Hier ist ein Beispiel:

ALTER WAREHOUSE LOAD_WH SET STATEMENT_TIMEOUT_IN_SECONDS= 3600;rnSHOW PARAMETERS IN WAREHOUSE LOAD_WH;

Best Prac­tice Nr. 5: Erken­nen von Lagern, die vom Sie­ben-Tage-Durch­schnitt abwei­chen
Hier ein prak­ti­scher Tipp, der aus einer direk­ten Inter­ak­tion mit einem Kun­den stammt, der ein Lager auf eine grö­ßere Größe ein­ge­stellt hatte, um eine Auf­gabe zu erle­di­gen, es aber nicht so zurück­stellte, wie er es vor­ge­fun­den hatte. Ich erstellte für ihn die fol­gende Abfrage, die er jeden Mor­gen aus­füh­ren sollte, um die Nut­zung des Lager­kre­dits zu ermit­teln, die vom Sie­ben­ta­ges­durch­schnitt abweicht. Die fol­gende Abbil­dung zeigt die Ergeb­nisse der Aus­füh­rung der Abfrage.

Best Prac­tice Nr. 6: Über­wa­chen Sie Lager­häu­ser, die sich dem Schwel­len­wert für die Abrech­nung von Cloud-Ser­vices nähern
Die fol­gende Abfrage befasst sich mit Lagern, bei denen die Kos­ten für Cloud-Ser­vices einen hohen Pro­zent­satz der Arbeits­last aus­ma­chen. Für ein Konto ins­ge­samt (und außer­halb der ser­ver­lo­sen Funk­tio­nen) berech­net Snow­flake Cloud-Ser­vices nur dann, wenn sie 10 % des täg­li­chen Gut­ha­ben­ver­brauchs des vir­tu­el­len Lagers über­schrei­ten. Cloud-Ser­vices-Auf­ga­ben sind nütz­lich für Meta­da­ten-Ope­ra­tio­nen wie BI-Tool-Erken­nungs­ab­fra­gen, Heart­beat-Abfra­gen, SHOW-Befehle, Cache-Nut­zung und ver­schie­dene andere Ser­vice-Opti­mie­rungs­funk­tio­nen. Wenn Sie also an einem Tag 100 Rechen­gut­ha­ben ver­brau­chen, aber 15 zusätz­li­che Gut­ha­ben für Cloud-Dienste ver­wen­den (was unwahr­schein­lich ist), wer­den Ihnen für die­sen Tag wei­tere 5 Gut­ha­ben für die 5 Gut­ha­ben für Cloud-Dienste in Rech­nung gestellt, die über der 10 %-Grenze lagen. Das bedeu­tet, dass ins­ge­samt 105 Cre­dits für den Tag in Rech­nung gestellt wer­den, wobei Snow­flake 10 Cre­dits für die Nut­zung von Cloud-Diens­ten kos­ten­los zur Ver­fü­gung stellt. Mit­hilfe die­ser Abfrage kön­nen Sie her­aus­fin­den, wel­che Lager sich dem Schwel­len­wert von 10 % nähern oder ihn über­schrei­ten, sodass Sie dem nach­ge­hen können.

Best Prac­tice Nr. 7: Unge­nutzte Tabel­len löschen
Mög­li­cher­weise haben Sie unge­nutzte Tabel­len, die für eine Löschung in Frage kom­men. Stel­len Sie nur sicher, dass nie­mand diese Tabel­len abfragt. Viel­leicht soll­ten Sie sogar vor­schrei­ben, dass alle Tabel­len vor dem Löschen über­prüft wer­den müs­sen. (Wenn Sie Time Tra­vel ein­ge­rich­tet haben, kön­nen Sie die Löschung einer Tabelle rück­gän­gig machen, wenn Sie einen Feh­ler machen). Dies ist spe­zi­fisch für den Daten­bank­kon­text, also ach­ten Sie dar­auf, Tabel­len in allen Ihren Daten­ban­ken zu prü­fen. Ach­ten Sie auch auf Tabel­len, die nur in View-DDLs ver­wen­det wer­den. Hier ist eine Beispielabfrage:

Best Prac­tice Nr. 8: Berei­ni­gen Sie ruhende Benut­zer
Es ist eine gute Idee, ruhende Benut­zer oder Benut­zer, die sich nie bei Snow­flake ange­mel­det haben, aus Ihrem Konto zu löschen. Hier ist ein Bei­spiel, das eine Liste bei­der Arten von Benut­zern generiert:

Leit­plan­ken für die auto­ma­ti­sche Ska­lie­rung
Die tat­säch­li­che Nut­zung einer Daten­platt­form schwankt von Stunde zu Stunde, von Tag zu Tag und von Monat zu Monat erheb­lich. Stan­dard­mä­ßig ist Snow­flake so kon­zi­piert, dass es auto­ma­tisch ska­liert und maxi­male Leis­tung und Effi­zi­enz bie­tet. Für einige Arbeits­las­ten sind jedoch sta­ti­sche und gut vor­her­seh­bare Res­sour­cen bes­ser geeig­net, und Snow­flake kann leicht so kon­fi­gu­riert wer­den, dass die­ses kon­sis­tente Ver­brauchs­mo­dell für jeden Tag des Jah­res bereit­ge­stellt wird. Durch die Imple­men­tie­rung eini­ger Ein­schrän­kun­gen auf Konto- und Res­sour­cen­ebene kön­nen Admi­nis­tra­to­ren uner­war­tete Nut­zung durch unvor­sich­tige Benut­zer oder sub­op­ti­male Ska­lie­rungs­pro­file verhindern:

Best Prac­tice Nr. 9: Lager­häu­ser fin­den, die keine Res­sour­cen­mo­ni­tore haben
Res­sour­cen­mo­ni­tore sind eine groß­ar­tige Mög­lich­keit zur pro­ak­ti­ven Kon­trolle von Workload-Bud­gets und zur Ver­mei­dung uner­war­te­ter Res­sour­cen­spit­zen. Res­sour­cen­mo­ni­tore kön­nen dabei hel­fen, sowohl die Nut­zung durch Benut­zer als auch die Nut­zung von Ser­vice­kon­ten in Snow­flake zu über­wa­chen. Zunächst soll­ten Sie dedi­zierte vir­tu­elle Warehou­ses für jede Ihrer Lade‑, ELT‑, BI‑, Berichts- und Data Sci­ence-Workloads sowie für andere Workloads haben. Kon­ten und Warehou­ses kön­nen Gesamt‑, Jahres‑, Monats‑, Wochen- und Tages­kre­dit­kon­tin­gente haben.

Die fol­gende Abfrage iden­ti­fi­ziert alle Warehou­ses, die nicht über einen Res­sour­cen­mo­ni­tor verfügen:

Best Prac­tice #10: Res­sour­cen­mo­ni­tore anwen­den
Sie kön­nen die UI oder SQL ver­wen­den, um Ihre Res­sour­cen­über­wa­chungs­richt­li­nie anzu­wen­den. Basie­rend auf den Kon­to­ein­stel­lun­gen kön­nen Res­sour­cen­über­wa­chun­gen Sie benach­rich­ti­gen, wenn der Ver­brauch einen nied­ri­ge­ren Schwel­len­wert erreicht, und dann das Lager oder Konto bei einem höhe­ren Schwel­len­wert aussetzen.

Über­le­gun­gen zur Ressourcenüberwachung

• Wir emp­feh­len, die Über­wa­chung so ein­zu­stel­len, dass Sie benach­rich­tigt wer­den, wenn ein bestimm­ter Schwel­len­wert erreicht wird.
• Wenn sich der Ver­brauch dem maxi­ma­len Bud­get nähert, stel­len Sie den Res­sour­cen­mo­ni­tor so ein, dass er das Ware­house oder das gesamte Konto auto­ma­tisch aus­setzt, so dass Abfra­gen abge­schlos­sen wer­den kön­nen, aber zukünf­tige Anfra­gen ver­hin­dert werden.
• Res­sour­cen­mo­ni­tore kön­nen auch ver­wen­det wer­den, um alle der­zeit lau­fen­den Abfra­gen zu been­den und die Res­source oder das Konto sofort aus­zu­set­zen. Diese Ein­stel­lung ist in der Regel für Situa­tio­nen reser­viert, in denen eine feste Quote über­schrit­ten wird.
• Für Kun­den, die keine fes­ten Quo­ten fest­le­gen möch­ten, ist es immer eine gute Idee, Benach­rich­ti­gungs­mo­ni­tore für alle Warehou­ses ein­zu­rich­ten, falls die Nut­zung uner­war­tet stark ansteigt. Auf diese Weise erhal­ten alle Admi­nis­tra­to­ren inner­halb des Kon­tos eine E‑Mail oder eine Benach­rich­ti­gung auf dem Bild­schirm, wenn Schwel­len­werte erreicht werden.

Die fol­gende Abbil­dung zeigt den Kon­fi­gu­ra­ti­ons­bild­schirm für die Ressourcenüberwachung:

Bonus Best Prac­tice: BI-Part­ner-Dash­boards ver­wen­den
Als elfte Best Prac­tice kön­nen Sie als Bonus die Dash­boards nut­zen, die von den Snow­flake-Enthu­si­as­ten eini­ger unse­rer BI- und Ana­ly­se­part­ner erstellt wur­den, um die Snow­flake-Nut­zung zu über­wa­chen. Da die Nut­zung von Snow­flake über ein Stan­dard­schema an alle Kon­ten wei­ter­ge­ge­ben wird, han­delt es sich um Plug-and-Play-Dash­boards. Eine der bes­ten Eigen­schaf­ten von Snow­flake ist die gemein­same Nut­zung von Daten im Peta­byte-Maß­stab, um Pipe­lines der Nut­zungs­his­to­rie an alle Snow­flake-Kon­ten weiterzugeben. 

Tableau hat eine Reihe von Dash­boards zusam­men­ge­stellt, die die Kre­dit­nut­zung, die Leis­tung und die Benut­zer­ak­zep­tanz der Platt­form zei­gen. Das unten gezeigte Dash­board „Com­pute Cost Over­view“ kann ver­wen­det wer­den, um den Kre­dit­ver­brauch zu ver­ste­hen, die Bud­get­zu­wei­sung zu pla­nen und Spit­zen­aus­rei­ßer zu iden­ti­fi­zie­ren, um die Aus­wir­kun­gen von „Kauf­zei­ten“ zu redu­zie­ren. Das Enter­prise Ana­ly­tics-Team von Tableau nutzt diese Dash­boards, um neue Nut­zungs­mus­ter auf­zu­de­cken und die Effi­zi­enz der Lager­kos­ten zu optimieren.

Schluss­fol­ge­rung
Mit dem hoch­elas­ti­schen Rechen- und sekun­den­ge­nauen Abrech­nungs­mo­dell von Snow­flake soll­ten Account-Admi­nis­tra­to­ren die Nut­zung, das Wachs­tum und die Res­sour­cen­ef­fi­zi­enz lau­fend über­wa­chen, um sicher­zu­stel­len, dass sie den Leis­tungs­an­for­de­run­gen und Bud­gets ent­spre­chen. Auch wenn Snow­flake bei der auto­ma­ti­schen Opti­mie­rung der Res­sour­cen hel­fen kann, gibt es für Account-Admi­nis­tra­to­ren Mög­lich­kei­ten, ihre Bereit­stel­lung wei­ter zu opti­mie­ren, vor allem, wenn ihre Rechen­leis­tung wächst. Wir emp­feh­len diese grund­le­gen­den Best Prac­ti­ces für die Über­wa­chung und Opti­mie­rung von Res­sour­cen, um häu­fige Fall­stri­cke zu ver­mei­den, die leicht zu über­se­hen sind.

Quelle: Snow­flake

Erfah­ren Sie mehr über Lösun­gen im Bereich Snow­flake oder besu­chen Sie eines unse­rer kos­ten­lo­sen Web­i­nare.