Snowflake 101

Er Snowflake konkurransedyktig? 

I de fleste diskusjoner jeg har hatt rundt Snowflake, oppstår spørsmålet: “Hvordan kan Snowflake konkurrere med de største skyaktørene som Microsoft Azure og Amazon AWS?”. Dette er en misforståelse. Snowflake konkurrerer overhodet ikke mot Microsoft og Amazon sine skytjenester, men heller mot de respektive datavarehus- og/eller database-tjenestene. Snowflake kommer ikke inn istedenfor Azure og AWS, men i TILLEGG til disse plattformene.

Arkitektur

Da Snowflake sin arkitektur er det mest unike ved Snowflake, er det dette vi vil fokusere på i denne artikkelen. Snowflake er en hybrid av Shared Disk- og Shared Nothing-arkitektur. Det kan også kalles “multi cluster shared data”-arkitektur.

Shared Disk Architecture vs. Shared Nothing Architecture

Shared disk - Alle ressurser bruker samme lagringssystem/disk. Hensikten med dette var for å ha data på én sentral plass, og tilgjengeliggjøre den for flere databaser. Dette gjør at alle ressurser er 100% avhengig av dette lagringssystemet, feiler det, så feiler alle ressurser. Den kan ikke skaleres mer enn disken. Hvis man skal skalere (vertikalt), blir det dyrt.

Det er også utfordringer med “data concurrency”, som krever kompleks håndtering av lesing og skriving fra de forskjellige datanodene samtidig. Det er denne komplekse logikken som hovedsaklig skaper en flaskehals for Shared Disk-arkitekturen.

Shared nothing - Arkitekturen er delt inn i noder. Hver node har sin del av data, sammen med databehandlingsressurser. Derfor oppstår ikke samme problem med avhengighet, er det en node som feiler så skaper ikke det problem for andre noder. Den kan skaleres horisontalt, ved å legge til flere noder.

Derimot kan ikke lagringsplass og databehandlingsressurser skaleres separat. Hvis data skal bli delt mellom nodene, må CPU, minne og disk lagring bli delt på tvers av nodene. Dette fører til uønsket mengder av overhead. Det er også vanskelig å finne riktig balanse mellom lagring og databehandlingsressurser, noe som kan føre til at ressurser til tider kan være ubrukt og unødvendig.

Snowflakes arkitektur

Snowflake er en hybrid mellom Shared Disk og Shared Nothing. Lagring og kalkuleringsressurser er separert, noe som fører til at disse kan skaleres separat og er helt uavhengige. Figuren under viser hvordan de tre lagene er bygd opp.

Cloud service layer - Dette er hjernen til Snowflake, alle interaksjoner med Snowflake skjer via dette laget. Den tar seg av aktiviteter som autentisering, tilgangskontroll og kryptering. Hver gang en bruker prøver å logge inn via Snowflake sitt brukergrensesnitt (Snowsight) vil "Cloud service layer" ta seg av den forespørselen. Når brukeren skriver en SQL-spørring vil den også bli behandlet av "Cloud service layer", samt optimalisering og hurtigminne av spørringer.

Compute layer - Snowflakes kalkuleringslag blir kalt "virtual warehouse", eller det virtuelle varehuset. Disse er dynamiske inndelinger av kalkuleringsressurser, bestående av CPU, minne og hurtigminne. Et virtuelt varehus er nødvendig for å kunne gjøre de aller fleste operasjoner i Snowflake.

Snowflakes arkitektur tillater separasjon av lagring og databehandling, som betyr at ethvert virtuelt varehus kan få tilgang til de samme dataene som et annet, uten noen problem eller innvirkning på ytelsen til de andre varehusene. Dette er fordi hvert av Snowflakes virtuelle varehus opererer uavhengig og den deler ikke databehandlingsressurser med andre virtuelle varehus.

Forskjellige størrelser av virtuelle varehus kan bli satt opp før å møte behov. Snowflake opererer med tradisjonelle t-skjorte-størrelser på sine størrelser av virtuelle varehus, fra X-Small til 4X-Large. Størrelsen tilsier hvor mange servere det virtuelle varehuset har. Figuren over viser hvordan inndelingen av virtuelle varehus.

Data Storage layer - “Data lagrings”-laget er bygd oppå Azure, Amazon og Google Cloud (Azure Blob/S3/GCP Bucket). Kan lagre strukturert, semi-strukturert og ustrukturert data. Når data blir lastet inn i Snowflake, blir det omorganisert til et komprimert, kolonnebasert format, og lagret og vedlikeholdt i Snowflakes database.

Data lagret i Snowflakes databaser vil alltid være komprimert og kryptert. Snowflake tar seg av å administrere alle aspekter av hvordan data lagres. Snowflake organiserer automatisk lagrede data i mikropartisjoner, en optimalisert, uforanderlig og komprimert kolonnebasert format som er kryptert med AES-256-kryptering.

Nå kommer vi til de første særegne funksjonene Snowflake har, “Zero-copying” og “Time Travel”.

“Zero-copying”

“Zero-copying” er en funksjon der en kan kopiere et øyeblikksbilde av en Snowflake-database, et skjema eller en tabell med all tilhørende data. Det spesielle er at det ikke er påfølgende kost for å endre på det kopierte objektet, kun når disse endringene gjøres på det originale objektet. Dette er mulig da “Zero-copying” er utelukkende en metadata-operasjon i Snowflake. Eksempel på bruk av “Zero-copying” er for å ha separate utviklings- og testmiljø. Endringer kan da gjøres i disse miljøene, og kosten kommer først når endringene blir satt i det originale objektet (produksjonsmiljøet).

“Time Travel”

“Time Travel” er noe selvforklarende. Kort fortalt er “Time travel” et fancy ord for versjonskontroll på databaser, tabeller og skjemaer. Det gir mulighet til å rulle tilbake til tidligere versjoner av databaser, tabeller eller skjemaer. Det fungerer veldig likt som å ta backup av objekter, og det gir mulighet endre på operasjoner som ble gjennomført ved en feil, eller for å redde objekter som har blitt slettet. Hvor langt du kan rulle tilbake avhenger av noen variabler, blant annet hvilket abonnement du har.

Noen egne Snowflake funksjoner

Snowsight

Snowsight er brukergrensesnittet hvor du mest sannsynlig vil jobbe med Snowflake. Denne kobler du til via nettleseren din. Det skal nevnes at det også finnes andre måter, som SnowSQL (CLI client), python tilkoblinger og andre bibliotek for å jobbe mer Snowflake.

I Snowsight vil du kunne gjøre SQL-spørringer, legge til og endre på brukere og roller, endre på databaser, tabeller og skjemaer, og mye annet. Det er også mulig å laste opp og ned åpne data via "Marketplace". Her kan kjente selskap laste opp åpne data, slik at hvem som helst kan bryne seg på data med bare et par tastetrykk og ha en lokal versjon tilgjengelig.

Snowpark

Snowpark er Snowflakes svar på notebook-miljøer. Snowpark støtter utvikling i Java, Scala og Python. Snowpark støtter DataFrame via et API. Det gir også utviklere mulighet til å ha tilgang på data i Snowflake direkte i applikasjonen, i motsetning til å for eksempel flytte data lokalt for å kjøre eksperiment på data via jupyter notebooks.