Mikä on Apache Iceberg ja sen rooli Snowflake-ympäristössä?

Apache Iceberg tarjoaa monia etuja data-insinööreille ja analytiikkatehtäville. Se tukee muun muassa skeeman kehitystä, piilotettuja osioita, osion kehitystä ja aikamatkustusta, joiden avulla voidaan hallita ja kysellä suuria tietomääriä dynaamisesti ja tehokkaasti. Vaikka Snowflake tarjoaa samankaltaisia ominaisuuksia, ne ovat yleensä piilotettuja järjestelmän taustalle, kun taas Apache Iceberg tuo nämä ominaisuudet selkeämmin esille ja tarjoaa laajemman hallinnan tietojen kehitykselle.

Katalogin päätehtävä on vastata kysymykseen siitä, mistä tiedot löytyvät. Apache Icebergin dokumentaation mukaan "katalogit hallinnoivat taulujen kokoelmaa, jotka yleensä ryhmitellään nimistön mukaan." Katalogin vastuulla on seurata taulun nykyistä metadataa, joka saadaan katalogilta taulua ladattaessa. Icebergin katalogeilla on useita implementointivaihtoehtoja: REST API, Hive Metastore, JDBC ja Nessie, joka käyttää Git-tyyppistä versionhallintaa.

Snowflake on ilmoittanut Apache Polaris -katalogin integroinnista, joka on avoimen lähdekoodin ja täysimittainen katalogi Apache Icebergille. Polaris toteuttaa Icebergin REST API:n ja mahdollistaa saumattoman yhteensopivuuden monen eri alustan kanssa, kuten Apache Doris, Apache Flink, Apache Spark, StarRocks ja Trino. Polaris tarjoaa kaksi vaihtoehtoa: Snowflaken hallinnoima Iceberg-katalogi tai ulkoinen Iceberg-katalogi. Tämä lisää monipuolisuutta ja joustavuutta, kun käytetään dataa Apache Iceberg -muodossa ulkoisista tallennustileistä ilman, että dataa tarvitsee ladata Snowflakeen.

Snowflake ja Apache Iceberg yhdessä mahdollistavat datan käytön Iceberg-muodossa ulkoisissa tallennustileissä. Tämä voi olla erityisen hyödyllistä, koska ennen Polaris-katalogin käyttöönottoa Snowflake tuki vain ulkoisia tauluja, jotka vaativat tietojen lataamista Snowflakeen. Polaris-katalogin avulla ulkoisten taulujen ominaisuus on edelleen käytettävissä, mutta se mahdollistaa myös Apache Icebergin tiedon kyselyn ilman datan fyysistä siirtämistä Snowflakeen.

Lähdetäänpä tarkastelemaan, miten voimme luoda Snowflake-ympäristössä Iceberg-taulun. Tämä tehdään usein Pythonin ja Jupyter Notebooksin avulla. Asennamme tarvittavat riippuvuudet Conda-ympäristössä ja luomme projektin, joka sisältää kaikki tarvittavat konfiguraatiot. Tämän jälkeen voimme Snowflaken käyttöliittymässä (SnowSight) luoda tarvittavat objektit, kuten varaston, roolin ja tietokannan, jotka mahdollistavat Iceberg-taulujen käsittelyn.

Tämän lisäksi Snowflaken ulkoisen tallennusratkaisun määrittäminen AWS S3:lle on olennainen osa prosessia. S3:lle luodaan ulkoinen tilavuus, joka toimii tietojen säilytyspaikkana. AWS Identity and Access Management (IAM) -politiikkoja ja rooleja tarvitaan, jotta Snowflake voi käyttää ja hallita näitä ulkoisia resursseja.

Lisäksi on tärkeää huomata, että Snowflake ja Apache Iceberg eivät ole pelkästään käytännön työkaluja, vaan ne tarjoavat myös kehittyneitä toimintoja, kuten aikamatkustuksen ja skeeman kehityksen, jotka tekevät datan hallinnasta entistä joustavampaa. Näiden työkalujen avulla voidaan säilyttää ja hallita suuria tietomääriä dynaamisesti ja samalla varmistaa, että tiedot pysyvät organisaation tarpeiden mukaisina myös ajan myötä.

Kuinka käyttää Apache Iceberg -tietokannan hallintaa Snowflakessa ja yhdistää ulkoinen laskenta

Apache Icebergin integrointi Snowflakeen tuo merkittäviä etuja datan hallintaan, erityisesti suurten tietomäärien kanssa työskenneltäessä. Snowflaken ja Apache Icebergin yhteistyö mahdollistaa datan tehokkaan käsittelyn ja analysoinnin ilman, että joudutaan luopumaan skaalautuvuudesta ja joustavuudesta. Tässä tarkastellaan, kuinka luoda ja hallita Iceberg-tauluja Snowflakessa sekä käyttää ulkoista laskentaa, kuten Apache Sparkia, tehokkuuden parantamiseksi.

Yksi ensimmäisistä askelista on määrittää luottamussuhteet Snowflaken ja Apache Icebergin välillä. Snowflaken käyttöoikeusprofiilin (ARN) määrittäminen on olennainen osa tätä prosessia. Esimerkiksi ARN voi näyttää seuraavalta: "STORAGE_AWS_IAM_USER_ARN":"arn:aws:iam::881490105466:user/a98t0000-s". Snowflakessa voit avata roolin, kuten "jumpstart-iceberg-role", ja tarkistaa luottamussuhteet valitsemalla "Trust relationships" -välilehden. Täällä määrität, että ulkoinen ID vastaa nimeäsi ja liität oikean ARN:n. Tämän jälkeen voit siirtyä itse taulun luomiseen Snowflakeen.

Taulun luominen tapahtuu yksinkertaisella SQL-kyselyllä. Esimerkissä luodaan "customer_iceberg" -taulu, joka sisältää useita kenttiä, kuten asiakastunnisteen, nimen, osoitteen ja niin edelleen. Taulun luomisessa käytetään Snowflake-hallittua luetteloa (catalog) ja määritetään ulkoinen tallennuspaikka, kuten S3-tilavuus (iceberg_lab_vol), jonka avulla taulu linkitetään ulkoisiin tietoihin.

Yksi suurista eduista Apache Icebergin käytössä on sen kyky käsitellä dataa suuremmassa mittakaavassa, verrattuna perinteisiin ulkoisiin tauluihin, kuten Parquet- tai JSON-muotoihin tallennettuun dataan. Iceberg tarjoaa tehokkaamman tavan hallita suuria tietomääriä, mutta on tärkeää huomata, että tämä ei välttämättä tuo suoraa kustannussäästöä, vaan todellinen säästö saavutetaan ulkoisen laskennan, kuten Apache Sparkin, Trinon, DuckDB:n tai ClickHouse:n avulla.

Apache Spark on yksi yleisesti käytettävistä työkaluista ulkoisessa laskennassa. Tämä mahdollistaa datan kyselyn suorittamisen myös silloin, kun käytetään laajempia laskentatehoja. Esimerkiksi, jos käytetään Conda-ympäristöä, voidaan käynnistää Jupyter Notebook Apache Sparkin avulla. Tähän ympäristöön liitetään Snowflaken luettelo ja AWS-ympäristömuuttujat, kuten Snowflaken URI, rooli, käyttäjätunnus ja salasanat, sekä AWS:n tunnistetiedot.

Kun ympäristö on määritetty, voidaan luoda yhteys Snowflakeen ja suorittaa SQL-kyselyjä Apache Sparkilla. Esimerkiksi, voidaan tarkastella kaikkia käytettävissä olevia tauluja ja luokkia, käyttää tauluja tietojen tarkasteluun tai suoraan tehdä SQL-kyselyjä Spark SQL -komennolla. Tämä mahdollistaa joustavan ja skaalautuvan tavan työskennellä datan kanssa, erityisesti suurten ja monimutkaisten datasetien parissa.

On myös tärkeää huomioida, että Iceberg-taulujen tietojen lukeminen ei ole aivan suoraviivaista ilman oikeanlaista luetteloa ja yhteyksiä. Tämän vuoksi, kun haluat käyttää Apache Icebergiä, sinun tulee varmistaa, että käytössä on oikeat metadatat ja yhteydet.

Iceberg ja Snowflake tarjoavat siis joustavan ja tehokkaan ratkaisun suurten datamäärien käsittelyyn. Hyödyntämällä Apache Sparkin kaltaisia ulkoisia laskentateknologioita, voidaan saavuttaa parempia suorituskyky- ja kustannustehokkuusetuja verrattuna perinteisiin menetelmiin.

Miten optimoida varastoinnin kokoonpanoa ja tietojen lukemista Snowflakessa?

Tietojen luku ja varastointitehokkuus Snowflakessa perustuvat sen mikropartitionointijärjestelmään ja valinnaiseen klusterointiin. Nämä ominaisuudet yhdessä mahdollistavat pienemmän skannattavan datan määrän kyselyissä, parantaen suorituskykyä ja vähentäen laskentakustannuksia.

Mikropartitionointi on automaattinen prosessi, jossa Snowflake jakaa tietokannan taulut pieniksi, peräkkäisiksi varastoyksiköiksi, jotka sisältävät yleensä 50–500 Mt pakattua dataa. Kunkin partitiotiedon mukana kulkee laaja metatieto, kuten sarakkeiden minimi- ja maksimiarvot, nolla-arvojen määrät ja muuta vastaavaa. Snowflake käyttää näitä metatietoja ohittaakseen tarpeettomat partitiot kyselyjen suoritusvaiheessa. Tämä prosessi, joka tunnetaan partitiopuunauksena, tapahtuu automaattisesti ilman erillistä konfigurointia.

Suuremmissa tauluissa, joissa suorituskyky on kriittinen, voidaan määrittää klusterointiavain, joka vaikuttaa siihen, miten tiedot fyysisesti järjestetään mikropartitioihin. Klusterointiavain kannattaa valita sarakkeista, joita käytetään usein suodattimissa, liitoksissa tai GROUP BY -lauseissa, kuten esimerkiksi transaction_date tai region_id. On kuitenkin vältettävä korkean kardinaalisuuden sarakkeiden, kuten UUID:iden ja yksilöllisten tunnisteiden, käyttöä klusterointiavainena, sillä ne voivat johtaa tehottomiin tai epäoptimaalisiin klusterointeihin.

Klusteroinnin tehokkuutta voidaan tarkastella suorittamalla SQL-komento SELECT SYSTEM$CLUSTERING_INFORMATION('taulun_nimi'), joka palauttaa tietoja, kuten klusterointisyvyyden. Jos syvyys on korkea, se voi viitata siihen, että klusterointi on heikentynyt ajan myötä uusien tietojen lisäämisen tai päivitysten vuoksi. Tällöin taulun tiedot voidaan uudelleenjärjestää komennolla ALTER TABLE RECLUSTER.

Tietojen lataaminen järjestyksessä klusterointiavain-sarakkeiden mukaan voi parantaa kyselyjen suorituskykyä, koska se varmistaa, että samankaltaiset tiedot tallentuvat samaan mikropartitioon. Tämä lähestymistapa tunnetaan luonnollisena klusterointina ja sitä voidaan soveltaa käyttämällä SORT BY -lausetta COPY INTO -komennossa tai esilajittelemalla tiedot ETL/ELT-prosessissa. Esimerkiksi myyntidatan lajittelu alueen ja tilauspäivämäärän mukaan takaa, että kyselyt, jotka suodattavat näitä sarakkeita, skannaavat vähemmän mikropartitioita ja palauttavat tulokset nopeammin.

Suuret tietoaineistot, kuten aikaleimat, tapahtumat ja faktataulut, hyötyvät erityisesti klusteroinnista, koska ne voivat vähentää tiettyjen aikarajoitteiden tai muiden osajoukkojen suodattamisen kustannuksia. Tällöin on suositeltavaa käyttää ajankohtaista, päivämäärään tai aikaleimaan perustuvaa klusterointia.

Tiedon tallennuksessa kannattaa noudattaa parhaita käytäntöjä. Varastoi vain tarvitsemasi tiedot ja hyödynnä Snowflaken pakkausominaisuuksia tallennuskustannusten vähentämiseksi.

FAIL-SAFE on seitsemän päivän palautusjakso TIME TRAVELin päätyttyä, ja se on suunniteltu katastrofipalautukseen. Fail-safe-tilassa olevat tiedot ovat vain Snowflake-tuen saatavilla, ja niistä voi aiheutua lisäkustannuksia.

Tietojen käsittelyn optimointi kyselyjen suorituskyvyn parantamiseksi on tärkeää, jotta voidaan vähentää suoritusaikoja ja varmistaa resurssien tehokas käyttö. Snowflake tarjoaa useita työkaluja, kuten Query Profile, kyselyjen suoritusprofiilien analysointiin. Tärkeimpänä tavoitteena on tunnistaa pullonkaulat, kuten suuret taulujen skannaukset tai tehottomat liitokset.

Myös materiaalisoidut näkymät (materialized views) voivat olla hyödyllisiä, sillä ne mahdollistavat usein kyselytulosten esilaskemisen ja tallentamisen. Näin voidaan nopeuttaa seuraavien kyselyjen suorittamista. Erityisesti suurille tietoaineistoille, jotka vaativat nopeaa hakua, kannattaa hyödyntää hakualgoritmien optimointipalveluja, kuten search optimization service.

Erityisesti iteroivien kyselyjen osalta kannattaa välttää epäoptimaalisia tekniikoita, kuten *SELECT * -lauseita, ja valita tarkasti ne sarakkeet, joita todella tarvitaan. Tämä vähentää tiedonsiirron ja prosessoinnin ylikuormitusta.

Lopuksi on tärkeää huomioida myös kyselyhistorian tarkastelu pitkään kestävien kyselyiden osalta. Tällöin voidaan tunnistaa kyselyt, jotka tarvitsevat optimointia ja kehittää suorituskykyä entisestään.