I Snowflake er sikker datadeling en viktig funksjon som gir organisasjoner muligheten til å kontrollere hvem som får tilgang til hvilke data. Når det gjelder sikker datadeling, finnes det flere måter å organisere tilgang til tabeller på, men en av de mest effektive metodene er gjennom bruk av "secure views" (sikre visninger). Dette gir ikke bare et effektivt lag for tilgangskontroll, men gir også fleksibilitet til å dele bare de nødvendige delene av tabeller med bestemte brukere eller grupper. I denne artikkelen ser vi nærmere på hvordan man implementerer sikker datadeling ved å bruke sikre visninger.

For å dele en tabell sikkert i Snowflake, kan du følge flere trinn. Den første og viktigste oppgaven er å opprette en delingsobjekt ("share object") og legge til tabellen som skal deles. Dette kan oppnås ved å gi riktige tillatelser til de nødvendige ressursene. I neste steg kan du tildele visse brukerroller til et forbrukerkonto slik at de får tilgang til de relevante dataene. Når alt er på plass, kan du bruke en sikker visning for å filtrere dataene og sikre at bare autoriserte brukere har tilgang til de nødvendige radene i tabellen.

Hvordan implementere en sikker deling av tabeller

La oss se på hvordan man praktisk kan dele en tabell i Snowflake. For å gjøre dette, vil vi først logge på Snowflake-kontoen og opprette en database og et skjema for å lagre tabellen. Deretter oppretter vi en tabell kalt stocks_data med noen eksempeldata for aksjehandel. Når tabellen er opprettet og dataene er lagt til, kan vi begynne å dele tabellen.

  1. Opprett en delingsobjekt (share object):
    Først må vi opprette et delingsobjekt i Snowflake. Dette kan gjøres med følgende kommandoer:

    sql
    use role accountadmin;
create or replace share stocks_share;
show shares;

  2. Gi nødvendige tillatelser:
    Neste trinn er å tildele nødvendige tillatelser til databasene, skjemaene og tabellene som skal deles. Dette kan oppnås med disse kommandoene:

    sql
    grant usage on database samples to share stocks_share;

    
grant usage on schema samples.finance to share stocks_share;
grant select on table samples.finance.stocks_data to share stocks_share;

  3. Legg til forbrukerkontoen:
    Nå kan du legge til forbrukerkontoen som skal få tilgang til dataene. Dette gjøres med kommandoen:

    sql
    alter share stocks_share add accounts = <consumer_account>;

  4. Opprett en database i forbrukerkontoen:
    Forbrukeren kan deretter opprette en database basert på det delte objektet med følgende kommando:

    sql
    create database shared_db from share <share_name>;

  5. Spørring av den delte tabellen:
    Når forbrukeren har fått tilgang til den delte databasen, kan de begynne å spørring av tabellen:

    sql
    select * from SHARED_DB.Finance.STOCKS_DATA;

Deling av tabeller med en sikker visning

Noen ganger kan det være nødvendig å dele bare en del av dataene i en tabell. Dette kan være nødvendig hvis du ønsker å kontrollere hvilken informasjon en bruker eller gruppe kan se. Den beste praksisen her er å bruke sikre visninger (secure views). Slik kan man implementere sikker datadeling ved å bruke en visning:

  1. Legg til en gruppeskolonne i tabellen:
    Først legger vi til en ny kolonne som gjør det mulig å gruppere dataene for deling. Her deler vi for eksempel aksjehandeldataene i to grupper, GRP_1 og GRP_2, som representerer to forskjellige typer virksomheter som skal få tilgang til forskjellige sett med data.

    sql
    alter table samples.finance.stocks_data add column access_id string;

    
update finance.stocks_data set access_id = 'GRP_1' where id in (1,2,3,4);
update finance.stocks_data set access_id = 'GRP_2' where id in (5,6);
commit;

  2. Opprett en tilknytnings-tabell for tilgangskontroll:
    For å holde styr på hvilken bruker som har tilgang til hvilken gruppe (access_id), oppretter vi en ny tabell som inneholder tilgangsinformasjon.

    sql
    create or replace table samples.finance.access_map (

    
    access_id string,
    account string
);
insert into samples.finance.access_map values('GRP_1', current_account());

    
insert into samples.finance.access_map values('GRP_2', 'another_account');

    
    commit;

  3. Opprett en sikker visning:
    Deretter oppretter vi en sikker visning som kombinerer dataene fra stocks_data-tabellen og access_map-tabellen. Denne visningen begrenser tilgangen til dataene basert på brukerens konto og de spesifikke tilgangsgruppene.

    sql
    create or replace secure view samples.public.stocks as
select sd.symbol, sd.date, sd.time, sd.bid_price, sd.ask_price, sd.bid_cnt, sd.ask_cnt
from samples.finance.stocks_data sd
join samples.finance.access_map am on sd.access_id = am.access_id
and am.account = current_account();

  4. Gi riktige rettigheter til visningen:
    Til slutt gir vi de nødvendige tillatelsene til visningen, slik at de riktige brukerne kan få tilgang.

    sql
    grant select on samples.public.stocks to public;

Test av tilgang

Etter at alt er konfigurert, kan du teste tilgangskontrollen for både tabellen og visningen ved å kjøre forskjellige spørringer som viser de delte dataene, for eksempel:

sql
select count(*) from samples.finance.stocks_data;
select * from samples.finance.stocks_data;


select count(*) from samples.public.stocks;


select * from samples.public.stocks where symbol = 'TDC';

Det er viktig å merke seg at for å implementere sikker datadeling effektivt, må du sørge for at tilgangskontrollen er grundig og at gruppene for tilgang til dataene er riktig definert. Bruken av sikre visninger i kombinasjon med tilgangskontrolltabeller gir et kraftig verktøy for å håndtere deling av data på en sikker og kontrollert måte.

Hvordan bruke Apache Iceberg med Snowflake og eksterne beregningsressurser

Når man arbeider med store datamengder, er det avgjørende å ha en pålitelig og effektiv metode for å organisere og analysere data. Apache Iceberg er en moderne tabellformat som har blitt stadig mer populær for dataorganisering og behandling, spesielt i integrasjoner med skytjenester som Snowflake. Dette kapittelet gjennomgår hvordan man kan bruke Apache Iceberg i Snowflake, samt hvordan man kan kombinere det med eksterne beregningsressurser som Apache Spark for å forbedre ytelsen ved spørringer på store datasett.

Først, for å integrere Iceberg med Snowflake, må man sette opp en ekstern volumeressurs som kan lagre Iceberg-tabeller. Dette innebærer å definere en ekstern volum som peker til en lagringsplass som f.eks. en S3-bøtte, og deretter opprette en tabell i Snowflake. Eksempelet som benyttes for denne prosessen er et customer_iceberg-tabell, der data blir lastet inn fra et sample datasett og lagret i Iceberg-format.

Når tabellen er opprettet og dataene er lastet inn, er det mulig å bruke Snowflakes interne databehandlingsressurser til å spørre denne tabellen. En enkel SQL-spørring kan brukes til å hente data fra Iceberg-tabellen og gjøre sammenstillinger med andre datasett, som for eksempel å koble kunder med deres nasjonale informasjon. Dataene som lagres i Iceberg-formatet kan være i Parquet, som er et effektivt lagringsformat for analytiske spørringer.

Selv om Snowflake tilbyr en effektiv metode for å håndtere og spørrere Iceberg-tabeller, gir bruk av eksterne beregningsressurser som Apache Spark en merkbar ytelsesforbedring. Apache Spark gjør det mulig å håndtere store datasett mer effektivt, og kan kobles til Snowflake-katalogen ved hjelp av et sett med miljøvariabler. Med Apache Spark kan man kjøre SQL-spørringer mot Iceberg-tabeller på en måte som kan skalere mye bedre enn å bruke Snowflakes interne spørringsmekanismer alene.

For å gjøre dette, må man konfigurere miljøet sitt ved å sette opp nødvendige variabler, som Snowflake-katalogens URI, bruker- og passordinformasjon, samt tilgangslegitimasjon for AWS. Deretter kan man opprette en Spark-sesjon og konfigurere nødvendige innstillinger for å bruke Apache Iceberg som en datakatalog. Når Spark er konfigurert, kan man bruke Spark SQL til å spørrere Iceberg-tabellen direkte, noe som åpner opp for en mer fleksibel og kraftig spørringsmulighet enn den som tilbys av standard Snowflake-warehouse.

En viktig aspekt ved å bruke Iceberg-tabeller er at man ikke kan lese dem uten tilgang til katalogen. Iceberg krever at man har en fungerende katalog for å kunne utføre spørringer og få tilgang til metadata. Dette gjør at Iceberg-skjemadefinisjoner og tilknyttede dataressurser må administreres på en strukturert måte, noe som gir en ekstra lag av kompleksitet sammenlignet med tradisjonelle eksterne tabeller.

I praksis viser bruken av Apache Iceberg i et Snowflake-miljø at ytelsen kan forbedres betraktelig sammenlignet med eldre metoder som kun bruker Parquet- eller JSON-formatet for eksterne tabeller. Selv om det ikke nødvendigvis gir betydelige kostnadsbesparelser på kort sikt, kan overgangen til Iceberg ha stor betydning på lang sikt, spesielt når det gjelder dataintegrasjon og spørringshastigheter.

Det er også viktig å forstå hvordan metadata fungerer i Iceberg-systemet. Når data lagres i en S3-bøtte som en del av Iceberg-tabellen, blir metadata lagret separat og kan enkelt inspiseres for å forstå strukturen på dataene. Dette gir stor fleksibilitet når det gjelder håndtering og feilsøking av data.

I tillegg til Apache Spark, finnes det også andre eksterne beregningsressurser som kan kobles til Snowflake for å utføre spørringer mot Iceberg-tabeller, som Trino, DuckDB og ClickHouse. Hver av disse verktøyene har sine egne fordeler og kan være mer passende for spesifikke bruksområder, avhengig av datastørrelse og ønsket ytelse. Valg av ekstern beregningsressurs bør baseres på spesifikasjonene til prosjektet, samt de kravene som stilles til prosessering og skalerbarhet.

Det er også viktig å være oppmerksom på muligheten for å bruke flere skytjenester som Microsoft Azure og Google Cloud for å støtte Iceberg-baserte løsninger. Selv om dette kapittelet fokuserer på integrasjon med AWS, gir disse andre plattformene også støtte for Iceberg og kan brukes i samme sammenheng.

Til slutt er det verdt å merke seg at Iceberg fortsatt er et relativt nytt verktøy, og mens det gir betydelige fordeler i forhold til tradisjonelle datalagringsmetoder, er det fortsatt under kontinuerlig utvikling. Å holde seg oppdatert på de siste versjonene og funksjonene er avgjørende for å maksimere nytten av Iceberg i dataintegrasjon og analyseprosesser.

Hvordan optimalisere ytelse og overvåke kostnader i Snowflake

Snowflake er en kraftig plattform som gir muligheter for både datalagring og behandling, men for å oppnå både høy ytelse og kostnadseffektivitet, er det nødvendig å forstå og implementere en rekke optimaliseringsteknikker. For mange virksomheter er det avgjørende å finne en balanse mellom å oppnå raskere behandling av data og samtidig holde kostnadene nede.

En av de mest fundamentale teknikkene for å øke ytelsen er caching. Når en bruker kjører den samme spørringen flere ganger innen 24 timer, og de underliggende dataene ikke har endret seg, vil Snowflake returnere det cachelagrede resultatet umiddelbart. Dette reduserer den redundante beregningen og gir raskere responstider. Caching er en enkel, men effektiv måte å forbedre brukeropplevelsen og spare på beregningsressurser.

Rett størrelse på virtuelle datalager er også en avgjørende faktor for ytelsen. Valg av passende størrelse på et virtuell datalager er avhengig av kompleksiteten til spørringene og antallet samtidige brukere. For eksempel kan et XS- eller S-lager være tilstrekkelig for et marketingteam som kjører ad hoc-rapporter med lavt antall samtidige brukere. Derimot vil et L-lager være mer effektivt for nattlige batch-prosesser som ETL-operasjoner, hvor det er behov for mer prosessorkraft.

En annen viktig funksjon er auto-skalering. Ved å bruke auto-skalering kan man dynamisk justere størrelsen på datalagerkluster basert på brukerens behov. I løpet av arbeidstiden kan auto-skalering håndtere topper i brukeraktiviteten, mens man på kveldstid kan sette lageret i hvilemodus for å spare på kostnadene. Snowflake tilbyr også spesifikke funksjoner som kan forbedre ytelsen ytterligere, slik som Cluster size tuning, som gir bedre håndtering av samtidige forespørsler ved å øke størrelsen på klusteret.

I tillegg finnes det Query acceleration service (QAS), som er en valgfri funksjon som benytter kortvarige beregningsressurser for å akselerere behandling av store, komplekse spørringer. Dette er spesielt nyttig i dashbord eller miljøer med høy samtidighet. For minneintensive operasjoner, som maskinlæringsmodeller eller store in-memory datatransformasjoner, er Snowpark-optimaliserte lagre spesielt utformet for å gi mer minne per node og bedre håndtere slike arbeidsbelastninger.

Når man har optimalisert ytelsen, er det viktig å forstå hvordan man kan overvåke og administrere ressursforbruket. Dette omfatter både lagring og beregningsressurser. Snowflake gir administratorer mulighet til å overvåke bruken av kreditter og lagring i sanntid. Ressursmonitorer kan settes opp for å sende varsler ved økninger i bruken, og de kan automatisk sette et virtuelt lager på pause når det når et visst nivå. Ved hjelp av ressursmonitorer kan man unngå uventede kostnader og sørge for at systemet ikke overskrider budsjettene.

Kostnader for beregning er målt i kreditter, som er basert på hvor lenge det virtuelle lageret er i drift, mens lagringskostnader er basert på volumet av data som lagres i Snowflake. For å redusere kostnadene knyttet til beregning kan man aktivere auto-suspend og auto-resume, som automatisk setter lagrene på pause etter en viss inaktivitet. Dette reduserer den totale bruken av beregningsressurser og dermed kostnadene.

Lagringskostnader i Snowflake er basert på den gjennomsnittlige daglige lagringsplassen, og inkluderer filer lagret i Snowflake-stagingområdet, data i databaser og historiske data. En annen viktig faktor er tidssensitivt lagring. Data som ikke lenger er kritisk for daglige operasjoner kan flyttes til mer kostnadseffektive lagringsløsninger som Amazon S3, hvor man kan implementere livssykluspolitikk for data. Dette gir muligheten til å arkivere kald data og redusere kostnadene for lagring over tid.

Videre er det viktig å være oppmerksom på dataoverføring mellom regioner. Hvis du bruker ekstern lagring, som AWS S3 eller Azure Blob Storage, kan du bli belastet for dataoverføringer mellom regionene. Snowflake pålegger gebyrer for å laste ut data til ekstern lagring innen samme region eller mellom forskjellige regioner. Det er derfor viktig å ha kontroll på disse overføringene, spesielt hvis dataene er lagret i flere regioner.

En annen nøkkelfunksjon i Snowflake for å kontrollere kostnader er ressursmonitorer. Disse gir muligheten til å sette en øvre grense for hvor mye en datalager kan koste i løpet av en bestemt tidsperiode. Du kan også bruke ressursmonitorer til å motta varsler når kostnadene nærmer seg en grense. Dette er en effektiv måte å forhindre at uventede kostnader oppstår, og gir virksomheten en bedre oversikt over utgiftene.

I tillegg til ressursmonitorer tilbyr Snowflake en avansert funksjon kalt budsjetter, som gir en helhetlig oversikt over de forventede kostnadene på tvers av ulike kontoer og ressurser. Med budsjetter kan man sette et tak for kostnadene over ulike tidsperioder, overvåke faktisk forbruk mot det forventede, og motta varsler når forbruket er i ferd med å overskride budsjettet. Dette er spesielt nyttig for økonomi- og FinOps-team som ønsker å være proaktive i planleggingen av utgifter, snarere enn å reagere på et overskredet budsjett.

Det er viktig å forstå at Snowflake gir muligheter til å håndtere både kostnader og ytelse på en fleksibel måte. Gjennom riktig bruk av funksjoner som caching, auto-skalering, ressursmonitorer, og budsjettering kan man både oppnå optimal ytelse og samtidig sikre at kostnadene forblir innenfor de ønskede rammene.

Hvordan tilpasse datamigrasjon med den rette teknologien: En organisatorisk og teknisk tilnærming

Når man skal migrere til skyen, er det avgjørende å matche funksjonaliteten til dataene med den rette teknologien. Med det enorme utvalget av verktøy tilgjengelig på skyen, er det viktig å finne løsninger som best dekker behovene til organisasjonen. Datamigrasjon bør skje i faser, slik som prototype, læring og perfeksjon. Selv om tilnærmingen "lift and shift" kan virke raskere, gir den begrenset verdi på lang sikt for organisasjonens mål. Derfor er det å dele opp migrasjonen og gjøre justeringer underveis ("split and flip") den foretrukne metoden, da dette sikrer at man ikke ofrer langsiktig verdi for kortsiktig gevinst.

Migrasjonsprosessen kan deles opp i to hovedkategorier: den organisatoriske delen og den tekniske delen av migrasjonsprosjektet.

Organisatorisk del av migrasjonsprosjektet

Først og fremst er det viktig å dokumentere den eksisterende løsningen. Dette innebærer å kartlegge de nåværende brukerne, deres roller og tilganger, ettersom Snowflake bruker rollebasert tilgangskontroll. Dette gjør det mulig å replikere dataadgang og sikkerhetsstrategier som allerede er implementert i det gamle systemet. Spesiell oppmerksomhet bør rettes mot sensitive datasett, hvordan disse er sikret, samt hvor ofte sikkerhetsprosesser blir utført for å opprettholde et sikkert miljø i Snowflake. Det er også viktig å ha en eksisterende arkitekturdiagram for det gamle systemet.

Videre bør man etablere en migrasjonsstrategi. Det er viktig å lage en liste over alle prosesser som skal migreres, samt identifisere de som trenger refaktorering eller er ute av funksjon. Dette gir et klart bilde av hva som kreves og hjelper til med å lage et diagram for dataarkitekturen som kan presenteres for interessenter. Snowflake anbefaler minimal ombygging i den første fasen, med mindre det gamle systemet er utdaterte. Målet er å levere verdi raskt, og derfor bør man unngå å ha et "big bang"-tilnærming, men heller dele opp migrasjonen i mindre leveranser som gir organisasjonen mulighet til å starte overgangen til Snowflake raskere.

Et annet viktig aspekt er å dokumentere utviklings- og distribusjonsprosessene. Hvis organisasjonen ikke allerede benytter DevOps eller DataOps, kan dette være et godt tidspunkt å implementere disse prosedyrene. Dette vil bidra til å øke kvaliteten på den analytiske løsningen, ved at man kan etablere dev, QA og produksjonsmiljøer, samt metoder for kildekontroll og håndtering av distribusjonsendringer.

Prioritering av datasett for migrasjon er også viktig. I stedet for å starte med de mest komplekse datasettene, bør man begynne med et enkelt datasett som kan migreres raskt. Dette gir en solid grunnmur som kan gjenbrukes i senere faser av migrasjonen. Dokumentasjon av avhengigheter mellom datasettene er essensielt, og denne prosessen kan automatiseres for å redusere manuell innsats og gjøre det lettere å spore endringer gjennom hele migrasjonsprosjektet.

Teknisk del av migrasjonsprosjektet

Den tekniske delen av migrasjonen handler om selve implementeringen og de konkrete verktøyene som brukes. Dette inkluderer valg av dataplattform, som Snowflake, og nødvendige tilpasninger som kan være nødvendige for å få systemet til å fungere effektivt i det nye miljøet. I tillegg til de tekniske tilpasningene, er det viktig å forstå hvordan de eksisterende systemene, som ETL-jobber, jobbscheduleringssystemer og integrasjoner med andre verktøy, påvirkes av migrasjonen. Dette krever grundig testing og kvalitetssikring av løsningene før de rulles ut i produksjon.

Det er også viktig å etablere et sterkt migrasjonsteam. Typiske roller som er nødvendige for migrasjon inkluderer utviklere, kvalitetssikringspersonell, forretningsansvarlige, prosjektledere og scrum masters. Når man jobber med en Snowflake-løsningspartner, kan de også påta seg flere oppgaver, som design, dokumentasjon og opplæring.

En annen kritisk faktor er å definere klare tidsfrister og et realistisk budsjett. Dette er avgjørende for å sikre at migrasjonen gjennomføres innenfor de rammene som er satt av forretningsinteressenter. Det er viktig at tidsfrister og budsjetter justeres i samsvar med de faktiske behovene i prosjektet, og at de er realistiske i forhold til prosjektets omfang.

Det er også nødvendig å fastslå ønskede utfall av migrasjonen. Dette kan for eksempel innebære å skru av det gamle Oracle-datasystemet etter at migrasjonen er fullført. Migrasjonsutfallene bør dokumenteres tydelig og brukes til å vurdere om prosjektet har levert den verdien som var forventet, og om eventuelle mål er nådd.

I en vellykket migrasjon er det viktig å ha en kontinuerlig evaluering og en klar eskaleringsprosedyre for å håndtere eventuelle problemer som måtte oppstå. Dette sikrer at prosjektet holder seg på sporet og at nødvendige justeringer kan gjøres i tide.

Det er viktig å forstå at migrasjon til skyen ikke bare handler om tekniske tilpasninger, men også om en endring i tankesett og arbeidsprosesser. Denne prosessen kan være en mulighet for organisasjonen til å forbedre sine eksisterende arbeidsmetoder, implementere nye teknologier og metoder, og generelt forbedre kvaliteten på datahåndtering og analytiske løsninger.

Comment la modélisation numérique prédit-elle la déformation transitoire des échantillons soumis à une explosion sous-marine ?
Quel rôle jouent les documents classifiés dans l'affaire de la Mar-a-Lago ?
Comment revisiter une tarte classique : de la meringue à la crème