Gjesteinnlegg: Verdien av metadata

Lær mer om metadata, hva slags typer metadata som finnes og hvordan det kan være et kraftig verktøy for å levere økt verdi, raskere, fra data!

Verdien av data - mindre jo mer man har?

Det er åpenbart at data gir verdi for selskaper som vet å utnytte dem. For noen selskaper, spesielt innenfor abonnementsdrevne bransjer med større grad av kommodifisering (mobil, bredbånd etc) er utnyttelse og forståelse av data helt avgjørende for å hente ut nødvendige marginer samt å kontrollere frafall og forstå hvilke kunder som er i risikosonen for å bytte til konkurrenten. Men - dette er slik det alltid har vært i disse bransjene, den eneste forskjellen er at modellene har flyttet fra Excel til skyen (en absolutt forbedring forsåvidt).

For alle andre selskaper er det også tilfellet at å bevege seg til skyen og bli datadrevet har mange fordeler. De siste årene har det kommet mange plattformer og ikke minst verktøy som gjør det veldig lett å komme i gang. Dessverre, vil noen kanskje si. For det er også veldig mye raskere å bygge dårlige og dyre ting. Med rammeverk som dbt er plutselig alle dataingeniører, men uten forståelse av grunnleggende prinsipper som modellering og normalisering.

For mye data?

Det er rett og slett for mye data tilgjengelig, uten den nødvendige kurateringen. Det hjelper ikke å slenge en katalog med søk på toppen hvis det er 10 tabeller som heter “customer”. Hvis man ikke har kontroll på dataen, definisjoner og kvalitet, så har det konsekvenser:

• Compliance/personvern blir utfordrende uten kontroll på hvor data flyter og er eksponert
• Redusert “time to insight” og tapte forretningsmuligheter
• Mangel på klare definisjoner av sentrale begreper og metrikker for selskapet
• Mangel på tillit til tilgjengelige data fører til økt bruk av Excel og “egne modeller” som igjen fører til en ond sirkel av mangel på klare definisjoner og metrikker siden data er spredd overalt
• Mangel på tillit undergraver ethvert forsøk på å bygge datakultur, uansett om man går for en sentralisert modell eller distribuert (data mesh o.l.)
• Det blir vanskelig å utnytte AI strategisk, siden de ovennevnte punktene er forutsetninger for å lykkes med AI (utover chatbots som ingen liker uansett)

Data som et produkt?

Så, datakvalitet handler altså ikke bare om at vi kan legge til tester på alle tabellene (med dbt er jo det enkelt). Nei, det vil nok først og fremst bare bli veldig dyrt. På samme måte, er datadrevenhet heller ikke bare å kvalitetssikre og tilgjengeliggjøre dataene. Hvis man drar en parallell over til produkter, og forsøker å definere hva et produkt er, så vil det være noe slikt som “noe som lever en form for verdi til noen”. Gode produkt-team forstår at for å levere verdi må man forstå hva som er verdifullt for brukeren gjennom kontinuerlig kvalitativ og kvantitativ analyse av brukerne og ikke minst hvordan produktet blir brukt, og i hvilken kontekst.

Hvis man ser for seg at data-team bygger data-produkter så er det ofte slående hvor atskilt de er fra resten av selskapet, og selskapets produkt og kunder. I tillegg til dette, og nå kommer vi frem til den mest positive siden av dette: det er allerede mengder av data om dataene tilgjengelig, eller metadata om du vil. Disse metadataene kan fortelle de som jobber med data mye om hvordan data blir brukt, av hvem og til og med bedre forståelse av friksjonspunkter og situasjoner som skaper frustrasjon for de på den “andre siden”. Dessverre blir metadata ofte liggende neglisjert! Mitt håp med denne artikkelen er at du kan med deg noen tips og triks som kan være relevant i din situasjon.

Hva er metadata?

Vi kan grovt sett dele metadata inn i følgende kategorier:

Grunnleggende metadata

1. Statisk
   • Datavarehus: Databaser, skjemaer, tabeller, kolonner, rapporter
   • Rapportering: Dashboard, visualiseringer etc
2. Dynamisk
   • Historikk og logger fra spørringer og dbt-kjøringer etc.

Avledet og beriket metadata

1. Prosesserte og strukturerte logger for å avdekke
   • Dataflyt (lineage) internt og mellom systemer (i.e Snowflake til PowerBI)
   • Tilgang (hvilke tabeller og kolonner blir aksessert)
   • Hvordan systemer i datamiljøet interagerer med hverandre (i.e Hvilke spørringer er manuelle vs fra PowerBI eller dbt)
   • Mønstre i datavarehuset (i.e hva er typisk oppdateringsfrekvens for en gitt tabell)
   • Lokalisere problematiske spørringer mtp kost/kjøretid
2. Aggregater
   • Kostnader
   • Kjøretid
   • Lagring

Hvilke problemer kan metadata løse?

Hvis vi går tilbake til problemene som ble diskutert tidligere, så kan man begynne å se konturene av et lys i tunnelen! Det er allerede mye man gjøre ved hjelp av metadata for å forbedre datakvalitet, fjerne støy og være mer proaktiv.

Adopsjon og bruk av dataprodukter

Hvis vi ser på tabeller og rapporter som dataprodukter (litt forenklet), så kan et data-team bruke aggregerte og deriverte metadata til å forstå hvem som bruker hva, og hvordan det blir brukt. Dette kan igjen brukes til å prioritere hvilke oppgaver som skal gjøres (feks en rapport som brukes av mange tar lang tid å laste inn og er dyr. Basert på datakildene så kan man sette opp et aggregat så man slipper å kombinere mange tabeller “on the fly” - noe som vil gi redusert kjøretid og lavere kost, samt en bedre opplevelse for sluttbrukerne, vinn-vinn).

Vær føre var - proaktiv tilnærming til endringer / migrasjoner

Ved å forstå dataflyt og bruk av data kan man forutsi hvordan endringer vil påvirke eksisterende prosesser (feks dbt modeller som er avhengig av en annen modell man vil gjøre en endring på), og systemer som feks PowerBI. Et annet viktig poeng er at man også kan forstå hvilke brukere som vil bli påvirket, noe som gjør det lettere for at data-team å kommunisere proaktivt om “nedetid” eller endringer som vil kreve tilpasning på brukersiden. Noen ganger er endringer nødvendig, men det er mye mindre stressende å eie kommunikasjonen versus å kontrollere en situasjon der noe har gått galt.

Fjerne ubrukt data og unødvendig prosessering

Tabeller som aldri blir brukt

• Ved å finne tabeller som aldri blir brukt kan man slette dem, og spare kostnader for lagring samt problemer med compliance/GDPR mtp på rettmessig bruk av data.

Jobber som skaper tabeller som aldri blir brukt

• Som regel vil ubrukte tabeller som ikke er et produkt av ad-hoc analyse (dette bør uansett gjøres i et skjema som automatisk sletter data etter i.e 7 dager) bli produsert med en viss frekvens, og hvis tabellene ikke blir brukt så følger det av logikk at en jobb som produserer tabellen også er ubrukelig og dermed kan stoppes.

Unødvendig prosessering

• Det er mye snakk om sanntid, men i de fleste tilfeller holder det å oppdatere data på en frekvens slik at gårsdagens data er tilgjengelig. Det er åpenbart at å kjøre en frekvens på én gang i timen versus en gang per døgn (hver 24 time), altså 24 ganger så mange jobber, vil gi en enorm forskjell i kostnad. Hvis man ikke er helt sikker på hvordan dette ser ut i selskapet så kan man for eksempel se på tilgangsmønsteret til en tabell for å forstå hvilket tidsrom den brukes og justere oppdateringstakten. Typiske lette optimaliseringer her vil også være å droppe kjøringer i helger og helligdager, når folk typisk ikke er på jobb uansett. Ved å gå fra 5 til 7 dager i uken der data kjøres har man plutselig en besparing på ca 28%. Hvis det faktisk er nødvendig med høy oppdateringstakt (1 gang per time eller mer), så kan man begrense oppdatering til innenfor normal arbeidstid. La oss si mellom 8:00-16:00, altså en besparelse på 16 timer per døgn, eller 66%.

Alarmer

Her er noen eksempler på alarmer som kan settes opp basert på metadata:

• Sen data (dbt-modellen pleide å bli oppdatert hver 24 time, nå har det gått 30 timer - dataene er utdaterte og dette må kommuniseres til selskapet)
• Endringer i kjøretid (en dbt-modell tok plutselig 3 timer å kjøre ift vanlig tid på 1 time)
• Endringer i volum (en dbt-modell vokste med 1.5M rader vs vanlig vekst på 100k)
• Endringer i kost (en dbt-modell ble plutselig dobbelt så dyr)
• Endringer i tilgangsmønstre (en bruker som vanligvis bruker noen få datasett begynner plutselig å aksessere en mengde tilsynelatende urelaterte data. Kanskje noe er galt?)

Finne duplikate avledede tabeller etc.

Ved å analysere dataflyt kan man finne duplikate tabeller og definisjoner. Siden data om kunder nødvendigvis må bygges av den samme grunndata, kan man starte i den ene enden og analysere hvordan dataen flyter gjennom forskjellige tabeller/dbt-modeller. Da blir blir ofte raskt klart at plutselig har flere modeller som modellerer samme definisjoner og metrikker, og man kan foreta nødvendig endringer. NB: Husk å følge rådene over slik at du kan gi beskjed til nødvendige brukere og forstå ringvirkningene ut mot andre systemer og prosesser!

Pii-sporing og compliance

Ved å analyse dataflyten fra ende-til-ende kan data-team raskt få oversikt over sensitive data og hvor disse flyter it et datamiljø. Dette er spesielt viktig hvis man opererer i en modell der mange har tilgang til data av nødvendighet, feks for kundesupport o.l. Det beste er selvfølgelig å begrense tilgang så mye som mulig fra starten, men av forskjellige grunner kan dette være vanskelig.

Avslutningsvis

Når alt kommer til alt, så handler datadrevenhet om kultur og mennesker. Det er ikke meningen å påstå at metadata er løsningen på alle disse problemene, snarere tvert imot. Men Ved å benytte seg av metadata som nevnt over, kan data-team selv bli mer data-drevne når det gjelder utvikling, prioriteringer og kommunikasjon med resten av organisasjonen - en forutsetning for suksess. Lykke til!

martin@alvin.ai