Mitä tapahtuu, kun kokenut Data Engineer pääsee syventymään Snowflake-pilvitietovarastoon? Plussia löytyi selvästi, mutta jotain kehitettävääkin vielä.
OMENAT JA APPELSIINIT PILVITIETOVARASTOINNISSA
Syksyn aikana olen päässyt tutustumaan Snowflake-pilvitietovarastoon tarkemmin. Kyseessä on SaaS-idealla tarjoiltu, aidosti pilvinatiivi ratkaisu tietovarastointiin. Oma taustani rakentuu pitkälti SQL Serverin ja sen kylkiäisten ympärille, joten on ollut vähintäänkin virkistävää päästä kokeilemaan uutta. Taustani vuoksi myös vertailu käyttämiini teknologioihin lienee luontevaa, vaikka SQL Serverin ja Snowflaken puntarointi on jo lähtökohtaisesti rinnastettavissa kuuluisaan omenien ja appelsiinien vertailuun: SQL Server on yleiskäyttöinen, jäsennellyn tiedon tallennusratkaisu, jolla voidaan usean muun käyttötapauksen lisäksi myös tehdä tietovarastointia, kun taas Snowflake on puhtaasti tietovarastoinnin ympärille rakennettu. Mutta koska vertailua kuitenkin tehdään, heitän minäkin lusikkani tähän soppaan.
ENSIVAIKUTELMA: IHANTEELLINEN ASENNUSPROSESSI
Aloitetaan Snowflaken “asennusprosessista”, josta ei juurikaan jää tarinaa kerrottavaksi jälkipolville – se kun on luokkaa minimaalinen: ei pohdintaa levyjen koosta, niiden rooleista tai muistakaan perinteisistä asetuksista. Ylipäätään kaikenlainen alustaan liittyvä säätö loistaa poissaolollaan. Entäpä taulujen indeksointi? Perinteisissä tietokannoissa (jollaiseksi SQL Server luokitellaan) taulujen indeksointi on yksi tärkeimmistä menetelmistä kyselyjen nopeuden ja suoritusaikojen johdonmukaisuuden takaamiseksi. Se on ihan oma taiteenlajinsa ja vaatii syvällistä paneutumista tietokantamoottorin ja sen toimintaperiaatteiden ymmärtämiseksi. Snowflakessa mutkat on vedetty suoriksi: indeksejä (eikä sitä myöten niiden säätöä) ei ole laisinkaan.
SNOWFLAKE ROKKAA AUTOMAATIOLLA JA VÄLIMUISTILLA
SQL Serverin lisäksi olen ollut mukana toteuttamassa tietovarastoratkaisuja myös Azure Synapsella, joka on Microsoftin vastine pilvitietovarastointiin. Sen nykyiseen versioon on lisätty paljon muitakin komponentteja varsinaisen tietokantamoottorin rinnalle mutta perinteinen tietovarasto itsessään on pysynyt hyvin pitkälti samana. Omasta näkökulmastani erottava tekijä Snowflakeen on se, että Synapsessa joutuu edelleen tekemään töitä sen eteen, että kyselyiden aiheuttama kuorma pysyy deterministisenä. Sekä taulujen indeksointiin että erityisesti statistiikkojen ylläpitoon täytyy paneutua, sillä muuten kyselyjen kestot voivat olla aivan jotain muuta kuin oletettua.
Entäpä tulosjoukon välimuisti? Tarkoitan tällä ominaisuutta, jossa kyselyiden tulokset tallennetaan väliaikaiseen muistiin myöhemmin hyödynnettäviksi. Ominaisuuden avulla lopputulos voidaan käydä noutamassa suoraan välimuistista, mikäli sama kysely ajetaan toisena ajanhetkenä uudestaan, ja aikaa säästetään reilusti. SQL Server toimii siten, että jo kertaalleen ajetun SQL-kyselyn uudelleensuoritus aiheuttaa siihen liittyvien tietorakenteiden uudelleenläpikäynnin. Se ei siis tallenna tulosjoukkoa välimuistiin, josta saman kyselyn uudelleensuoritukseen voitaisiin käydä poimimassa vastaus salamannopeasti. (Tarkennetaan sen verran, että SQL Serverissä itse asiassa on välimuisti, mutta se toimii eri lailla: sinne tallennetaan 8 kilotavun datalohkoja, jotka sisältävät tietokannan dataa. Ja näitä datalohkoja se käy läpi SQL-kyselyä suorittaessaan. Varsinaista tulosjoukon välimuistia ei siis löydy). Snowflakesta ominaisuus löytyy, ja sen ansiosta toistuvissa kyselyissä saavutetaan huomattava nopeusetu.
Luonnollisesti Snowflake kykenee myös havaitsemaan tilanteet, jolloin kysely on oikeasti suoritettava uudelleen. Metadatan perusteella tietokantamoottori pystyy päättelemään tapaukset, joissa kyselyn taustalla olevissa datoissa on tapahtunut muutoksia, jolloin kysely on ajettava uudestaan. Vastaavanlainen välimuistiominaisuus löytyy tosin myös SQL Serverin kilpailijasta, Oraclesta, sekä edellä mainitusta Azure Synapsesta, johon kyvykkyys tuotiin reilu vuosi takaperin.
SNOWFLAKE ON ROOLIPELAAJAN UNELMA
Vastaan on myös tullut ominaisuuksia, joiden parissa on tullut lähinnä raavittua päätä ja joista en suoraan sanottuna pidä. Yksi tällainen on jatkuva säätäminen eri roolien kanssa. SQL Serverissä käyttäjälle voidaan antaa useita eri rooleja, jolloin näistä tulevat oikeudet ikään kuin “kumuloituvat” käyttäjälle eli käyttäjä saa eri roolien kautta lisää oikeuksia. Snowflakessa tämä ei ole mahdollista, vaan käyttäjällä voi olla tiettynä ajanhetkenä käytössä vain yksi rooli kerrallaan. Näitä eri hattuja joutuu tarpeen mukaan vaihtelemaan mahdollisesti useastikin. Roolipelaajat tykkäävät. Hankalaa, sanon minä. Toinen outous liittyy oikeuksien antamisessa skeemoihin: Mikäli roolin haluaa jatkossa pääsevän käsiksi myös skeemaan luotaviin uusiin objekteihin, pitää tämä melko arkipäiväinen asia erityisesti huomioida oikeuksia roolille annettaessa. Muussa tapauksessa skeeman uudet objektit jäävät käyttäjältä saavuttamatta. Sinänsä aika pieniä nämä kohtaamani ”ongelmat” ja juontuvat lähinnä siitä, mihin olen itse aikaisemmin tottunut.
PÄHKINÄNKUORESSA
Vertailua voisi viedä vaikka miten paljon pidemmälle mutta tämä pintaraapaisu riittäköön tällä erää. Yhteenvetona todettakoon, että allekirjoittaneen kokemus Snowflakesta on toistaiseksi reilusti plussan puolella, enkä vaikuttavan ensikokemuksen perusteella jaksa uskoa sen jatkossakaan sulavan käsiini.
Jos organisaatiosi datan hallintaan menee liikaa aikaa, katso lisää Snowflaken hyödyistä ja varaa meiltä ilmainen koekäyttö tai demo. Asiantuntijamme auttavat mielellään valjastamaan pilven tehokkuuen datallesi.
Lue myös:
