Hvordan endre og administrere parameterinnstillinger i datalagring

I enhver dataplattform er det viktig å forstå hvordan parametere kan styres og endres for å tilpasse ytelsen og bruken av systemet. Parametere i en datalagrings- eller databaseplattform kan deles inn i tre hovedkategorier, avhengig av om de gjelder for hele kontoen, spesifikke sesjoner eller for enkelte objekter i systemet. Disse parameterne er grunnleggende for hvordan systemet reagerer på forespørsler, hvordan det håndterer sesjoner, og hvordan det administrerer objekter som databaser eller lagringsenheter.

Konto-parametere er innstillinger som gjelder for hele kontoen og påvirker plattformens globale oppførsel. Disse parameterne er ofte definert ved kontoen opprettes, og de gir administratoren kontroll over systemets bredere funksjonalitet. Konto-parametere er effektive for å tilpasse hvordan data behandles på tvers av forskjellige brukere og sesjoner, og de gir et overordnet nivå av kontroll over systemet.

Sesjons-parametere utgjør den største gruppen og er vanligvis spesifikke for en sesjon, en bruker eller et sett med brukere på konto-nivå. Disse parameterne har en mer direkte påvirkning på hvordan en enkelt forespørsel eller interaksjon behandles i systemet. De kan justere hvordan spesifikke forespørsler håndteres, hvilke ressurser som benyttes, og kan tilpasses for å optimalisere ytelsen for bestemte typer arbeid eller arbeidsflyter. Sesjons-parametere er essensielle når man arbeider med varierende arbeidsmengder som krever forskjellige ressursinnstillinger.

Objekt-parametere er de som er knyttet til spesifikke objekter i systemet, som databaser eller datavarehus. Slike parametere kan også settes på kontonivå for å gi bredere kontroll, men de har som hovedmål å styre spesifikke objekter og deres individuelle oppførsel. For eksempel kan parametere relatert til en database sette restriksjoner på hvor mye minne som skal allokeres eller definere hvordan spesifikke spørringer skal håndteres innenfor den databasen.

Ved å forstå hvordan disse parameterne fungerer og hvordan de kan endres, kan man bedre tilpasse og optimere systemets oppførsel, noe som er essensielt for å maksimere både ytelsen og ressursbruken i enhver dataplattform.

Det er også viktig å merke seg at de fleste systemer tillater en form for parameter-arv. Det betyr at når du endrer parametere på et høyere nivå, som for eksempel på kontonivå, kan disse endringene automatisk arves av alle sesjoner og objekter under den kontoen, med mindre de har blitt spesifikt overstyrt på lavere nivåer. Denne arvingen er et viktig aspekt å forstå for å unngå utilsiktede konsekvenser av endringer i parameterinnstillingene.

Hvordan Snowflake muliggjør sikker datadeling gjennom delte visninger og materialiserte visninger

I dagens data-drevne verden er effektiv og sikker datadeling essensielt for å drive beslutningstaking og forbedre forretningsprosesser. Snowflake, en ledende skybasert dataplattform, tilbyr kraftige verktøy for å dele data på en sikker og skalerbar måte. Gjennom funksjoner som delte objekter og sikre visninger gir Snowflake en fleksibel løsning for å distribuere data mellom ulike brukere og organisasjoner, samtidig som det opprettholdes strenge sikkerhetsnivåer.

En viktig del av Snowflakes datadeling er muligheten til å bruke både vanlige og materialiserte visninger. En vanlig visning er en lagret spørring som fungerer som en virtuell tabell, hvor resultatene fra en underliggende spørring hentes hver gang visningen blir spurt. Dette sikrer at dataene alltid er oppdaterte. På den andre siden lagrer en materialisert visning resultatene av spørringen som en fysisk tabell. Denne tabellen oppdateres automatisk av Snowflake når det skjer endringer i de underliggende datatabellene, noe som gir betydelig raskere ytelse, spesielt når komplekse eller hyppig etterspurte data skal aksesseres. Det er en viss forsinkelse i hvor raskt materialiserte visninger oppdateres, ettersom de ikke blir oppdatert i sanntid. Dette gjør at valg av visningstype, enten vanlig eller materialisert, avhenger av behovene til applikasjonen, og en balansering av nødvendigheten for ferske data mot viktigheten av rask spørringsytelse.

Deling av data i Snowflake kan implementeres gjennom delte objekter. Et delt objekt fungerer som en container som inneholder referanser til spesifikke datavisninger, tabeller eller databaser som skal deles med eksterne forbrukere. Ved å bruke en delt visning som en del av et delt objekt, kan en produsent sikre at bare nødvendige data blir delt, samtidig som de opprettholder kontroll over tilgangen og sikkerheten til dataene.

For eksempel, i et scenario hvor en produsent ønsker å dele informasjon om aksjemarkedsdata med en ekstern forbruker, kan de opprette et delt objekt som inkluderer en sikker visning av aksjedataene. Produsenten kan deretter tildele spesifikke privilegier, som å gi leseadgang til visningen, men ikke til de underliggende tabellene. Dette gir en presis kontroll over hvilke data som er tilgjengelige for forbrukeren, og forhindrer tilgang til sensitive detaljer som kan være skjult i de underliggende datatabellene.

En viktig aspekt ved datadeling i Snowflake er bruken av SQL-kommandoer for å administrere delte objekter og privilegier. For å opprette og administrere delte objekter, benytter man kommandoer som create share, grant usage, og show grants, som lar brukere tildele og vise tilganger knyttet til spesifikke deler av databasen. Når forbrukeren har tilgang til et delt objekt, kan de opprette sine egne databaser fra delte visninger og bruke disse dataene til videre analyser.

Ettersom Snowflake også tilbyr funksjoner som automatisk skalering, kan systemet håndtere varierende arbeidsbelastninger uten at det kreves manuell inngrep. Dette er spesielt nyttig i scenarier der store mengder data skal deles mellom organisasjoner, ettersom det sikrer effektiv håndtering av databehov uten at ytelsen reduseres.

Snowflake gjør det mulig å balansere behovet for rask datatilgang med sikkerheten og personvernet som kreves i dagens digitale landskap. Gjennom sikre visninger og delt objektstyring kan både produsenter og forbrukere av data nyte godt av både ytelse og sikkerhet, samtidig som de bevarer kontrollen over dataene de deler.

Hvordan integrere Apache Iceberg med Snowflake for datahåndtering

Apache Iceberg er et kraftig verktøy for moderne datahåndtering, og det gir mange fordeler for dataingeniører og analytiske arbeidsbelastninger. Blant de viktigste funksjonene finner vi skjemautvikling, skjulte partisjoner, partisjonutvikling og muligheten for tidsreise. Selv om Snowflake tilbyr lignende funksjoner, er mange av disse skjult under overflaten, og Iceberg presenterer en mer åpen og strukturert tilnærming til håndtering av store mengder data. I denne sammenhengen er det verdt å utforske hvordan Apache Iceberg kan benyttes sammen med Snowflake for optimal databehandling og spørring.

Apache Iceberg strukturerer data ved hjelp av flere nøkkellag. Først og fremst finnes det et kataloglag, som refererer til den nåværende metadatafilen. Metadataene består av tre filtyper: metadatafiler, manifestfiler og manifestlister. Metadatafilene inneholder informasjon om tabeller, inkludert skjema, partisjoner, snapshots og lagringsplasseringer. Manifestfilene oppbevarer metadata om filene, som statistikk og radantall, mens manifestlistene inneholder manifestfiler per snapshot. Selve datalaget er der de faktiske dataene lagres, og gir et strukturert og effektivt grunnlag for databehandling.

Katalogens rolle i denne sammenhengen er avgjørende. En katalog har som hovedmål å svare på spørsmålet om hvor data er lagret. I tillegg til katalogens funksjon som en referanse for metadata, gjør den det mulig å bruke ulike dataverktøy på tvers av systemer. Apache Iceberg-kataloger kan implementeres på flere måter, inkludert REST API, Hive Metastore, JDBC, og mer. En av de mest populære implementasjonene er AWS Glue-katalogen, som tilbyr en administrert Hive Metastore og sporer metadata på tvers av ulike AWS-tjenester som Athena, Glue og Redshift Spectrum.

Snowflake har nylig annonsert støtte for integrasjon med Apache Polaris-katalogen, som er en åpen kildekode-katalog for Apache Iceberg. Denne katalogen implementerer Icebergs REST API og muliggjør sømløs interoperabilitet på tvers av forskjellige plattformer som Apache Doris, Apache Flink, Apache Spark, StarRocks og Trino. Dette gjør det mulig å håndtere Iceberg-tabeller og metadata på en effektiv måte og åpner for to alternativer: enten bruke en administrert Iceberg-katalog i Snowflake, eller benytte en ekstern Iceberg-katalog.

En viktig fordel ved integrasjonen mellom Snowflake og Apache Iceberg er muligheten til å bruke Iceberg-formatet på data som er lagret i eksterne lagringskontoer, uten å måtte laste inn dataene i Snowflake. Før denne integrasjonen var det mulig å bruke eksterne tabeller i Snowflake for å utføre spørringer, men med Polaris-katalogen kan man nå utføre spørringer på Iceberg-data uten å måtte laste dem inn i systemet.

For å komme i gang med å bruke Iceberg i Snowflake, kan man opprette en Iceberg-tabell ved å bruke Python og Jupyter Notebook. Dette krever at man setter opp et virtuelt miljø og installerer nødvendige avhengigheter som findspark, jupyter og pyspark. Deretter kan man bruke SnowSight for å opprette nødvendige objekter i Snowflake, inkludert lagring, roller, databaser og brukere. Når dette er gjort, kan man begynne å bruke Iceberg-tabellen i kombinasjon med eksterne volumer, som for eksempel AWS S3, for lagring av data i Iceberg-format.

Den største fordelen ved å bruke Iceberg med Snowflake er fleksibiliteten i hvordan data kan lagres og behandles. Det gir muligheten til å bruke kraften til både Snowflake og Apache Iceberg uten å måtte flytte dataene mellom systemene. Dette gjør det enklere å håndtere store datamengder på tvers av ulike plattformer og skaper et sømløst arbeidsmiljø for dataingeniører og analytikere.

Det er også viktig å merke seg at integrasjonen mellom Snowflake og Iceberg ikke bare handler om lagring og spørring av data, men også om hvordan man kan utnytte funksjoner som tidsreise. Ved hjelp av tidsreise kan brukere enkelt navigere gjennom historiske versjoner av dataene, noe som er spesielt nyttig for å spore endringer og feilsøke problemer i databehandlingen. Dette gir et ekstra lag av fleksibilitet og kontroll over dataene som er lagret i Iceberg-formatet.

Hvordan bygge en analytisk løsning med åpne kildekodeverktøy og Snowflake

For større bedrifter med etablerte datateam kan en løsning som kombinerer Matillion ETL og Tableau være et ideelt valg. Dette alternativet krever imidlertid et betydelig budsjett for lisensiering, noe som gjør det mindre praktisk for små bedrifter eller startups. Disse er ofte begrenset av budsjett og ser etter åpne kildekodealternativer som kan gi dem mer fleksibilitet uten høye kostnader.

I den forrige beskrivelsen håndterte Matillion ETL både datainntak og transformasjon. Nå deler vi disse oppgavene, og ser på hvilke verktøy som er best egnet til hver av disse oppgavene.

En oversikt over tilgjengelige åpne kildekodeverktøy for ulike oppgaver er som følger:

• Datainntak: Airbyte, Meltano, Python-kode

• Datatransformasjon: dbt Core, Python-biblioteker, Apache Spark

• Dataorkestrering: Apache Airflow, Prefect, Dagster, Luigi, cron

• Forretningsanalyse (BI): Metabase, Redash, Apache Superset

Det finnes mange åpne kildekodeverktøy på markedet, og Python kan også brukes for å lage spesialtilpassede verktøy. Denne tilnærmingen er imidlertid ikke alltid skalerbar, og vedlikehold av slike løsninger kan være utfordrende. Dette kan ofte ende opp som et antipattern, der verktøyene er for spesifikke og vanskelig å oppdatere. Hver tilnærming har sine egne fordeler og ulemper, og før man velger teknologi er det viktig å gjennomføre en Proof of Concept (PoC). PoC-en hjelper med å identifisere hvilke verktøy som er mest passende for organisasjonens behov.

PoC-resultatene bør dokumentere de viktigste beslutningene, inkludert valg av verktøy, kostnader, tidsbruk, samt andre relevante faktorer. Dette dokumentet vil hjelpe med å ta informerte beslutninger og sikre godkjenning fra ledelsen.

En enkel løsning kan bygges med dbt Core og Snowflake, men det finnes flere alternativer for hvordan slike åpne kildekodeløsninger kan settes opp i produksjonsmiljøer. Mange av disse alternativene er koblet til administrerte Kubernetes-klynger eller container-tjenester som tilbys av sky-leverandører som AWS, Azure eller Google Cloud. En enkel oversikt over en mulig arkitektur for løsningen finner vi i figur 9-9.

Airflow, et Python-basert orkestreringsverktøy, er et populært alternativ for å kjøre data pipelines. Airflow bruker såkalte Directed Acyclic Graphs (DAG) for å strukturere og eksekvere jobber og prosesser. Dette verktøyet kan også settes opp lokalt via forskjellige metoder, inkludert Helm-verktøy for Kubernetes.

Når det gjelder BI, er Metabase et SQL-basert verktøy som kan kobles til Snowflake. Metabase kan kjøres i en Docker-container for enkel distribusjon og administrasjon.

Fordelene med dbt er flere:

• Den gir et forenhetlig SQL-rammeverk

• Den muliggjør forretningslogikk i SQL

• Den støtter kontinuerlig integrasjon og distribusjon (CI/CD), enhetstesting, versjonskontroll og pre-commit

• Lett å lære og vedlikeholde

• Gjenbrukbare kodebiter ved hjelp av Jinja-makroer

• Mulighet for å skrive leverandøruavhengige SQL-spørringer

Men det er også visse utfordringer ved bruken av disse åpne kildekodeverktøyene. For eksempel, selv om verktøy som dbt kan være kraftige, kan de være vanskelige å skalere når man arbeider med store datamengder eller i et produksjonsmiljø med komplekse krav. Det er også viktig å være klar over at dette kan kreve betydelig teknisk kompetanse, spesielt når det gjelder manuell konfigurasjon og feilsøking.

For å sette opp et dbt-prosjekt, kan man klone prosjektet fra GitHub, konfigurere de nødvendige avhengighetene og deretter begynne å bygge sine egne datamodeller. Dbt bruker SQL til å beskrive transformasjonene, som deretter utføres på Snowflake. I dbt-prosjektene finner vi flere komponenter:

• dbt_project.yml: Hovedkonfigurasjonsfilen

• Models folder: Inneholder dbt-modeller (SQL-transformasjoner)

• profiles.yml: Definerer tilkoblingen til Snowflake

For å komme i gang med dbt, er det viktig å ha en fungerende Snowflake-konto, installere nødvendige biblioteker, og sette opp prosjektet i riktig struktur. Etter installasjon og konfigurering kan transformasjonene utføres med dbt, og resultatene vil lagres i Snowflake.