Episoden er transkribert av kunstig intelligens, feil vil forekomme.

00:00 --> 01:08

Hei, og velkommen til Plattformpodden, en podkast om applikasjonsplattformer og timene som lager dem. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg som vanlig Audun Fauchald Strand, og i sesong tre av Plattformpodden utforsker vi dataplattformer. Men før vi introduserer dagens gjester, Audun, nå som du har blitt direktør i Nav og bruker enda mer av din tid. Hvilke forhold har du til notater? Jeg er veldig glad i konseptnotater, men jeg har aldri i hele mitt voksne liv klart å ta notater og gjøre andre ting samtidig. Og siden jeg er så glad i å gjøre andre ting, så har jeg nesten aldri klart det. Jeg hadde to uker på universitetet som jeg hadde gode fargekoordinerte notater. Men det døde på seg fordi det var for ambisiøst. Så akkurat nå i dag Jeg skulle ønske jeg var flinkere til å gjøre notater. Hva med deg, Kristian? Tar du med notater? Det går litt i perioder, men det er ikke sjelden jeg leser dem.

01:08 --> 02:25

Bare det å skrive ned øker hukommelsen og muligheten for å huske det. Ellers er jeg veldig glad i lister. Subset av notater, tenker jeg. Gjøremål er jeg veldig fan av. Det må ned i enten en notatblokk eller en to do-liste. Men nok om lister. I dag er vi så heldige å ha med oss Eirik Folkestad og Rasmus Næs, som jobber i en norsk startup som har slått gjennom internasjonalt med sin digitale notatblokk. I 2021 lanserte de Ubegrenset lagring gjennom sin egen skylagringstjeneste, og i 2022 feiret de én millioner solgte enheter. I år feirer Remarkable ti år, og har lansert Remarkable Pro med farger. Vi lever virkelig i det 21. århundret. Eirik, kan ikke du fortelle litt om hvorfor du begynte i Remarkable, og hva du jobber med? Jeg begynte å jobbe i Remarkable fordi jeg så Remarkable som et av få norske produkter med enormt globalt potensial. Jeg er vant til å ta notater, det er produkt for meg,

02:25 --> 03:32

så da syns jeg det var kult å starte det selskapet. Rasmus, hva med deg? Hvorfor begynte du i Remarkable? Det virket jo veldig spennende å være med i en norsk startup, eller jeg vil si det er mer en scaleup nå, som driver med hardware. Du har jo noen andre norske selskaper, men det er få av dem. Og jeg som har jobbet mer i mediebransjen osv., så det blir spennende å hoppe inn i dette. Jeg er da data engineer i Dataplattform, sammen med Eirik. Så vi jobber mer på dataflyten som skjer oppe i skyen, men produktet har et veldig stort potensial, som Eirik er inne på. Kanskje en av dere kan begynne med å gi et overblikk over hvordan plattformen ser ut? Hvilken teknologi brukes, hvilken sky lever han av? Hva er det liksom ... Ja, jeg kan jo starte litt med det. Vi har jo da bygget en dataplattform, som da er en plattform ...

03:32 --> 04:53

Lignende en applikasjonsplattform, men mer spesifikt for å gjøre noe med data. Så det vil da si gjøre noe som bidrar til at man drar verdi ut av det man gjør. Ut av det man har av data. Og ... det vi gjør er jo egentlig alt på sky. Vi bruker CloudRun fra GCP, bruker mye Google Cloud Platform. Tilgjør mye av datauthenting og dataeksport igjen, altså ut fra plattformen. Og der vi lagrer data, er da i Bigquery, som er da Google Cloud Platform sitt datavarehus. Eller analytisk database, da. Og det er liksom essensen, kanskje, av det vi som jobber med data inn og ut fra Bigquery, men vi bruker da forskjellige verktøy for å gjøre dette, da. Hvilke typer verktøy da? Vi bruker mye debeta. Vi bruker mye DBT for å gjøre transformasjoner oppå dataene vi har i Bigquery. Dette er da et state of the art-verktøy, egentlig, for det som er mest brukt i dag.

04:53 --> 06:11

Det er det som betegnes som kanskje den mest ... En av de mer moderne måtene å jobbe med data på. Og det som er kult, er at det gjør at vi går fra å ... Være data engineers, til å være data engineers som ... Støtter opp under data analysts, som da kan gjøre transformasjoner oppå dataene. Der hvor vi tidligere hadde gjort den jobben. Men hvilke data er det som ligger her? Er det i forbindelse med skylagringstjenesten dere har? Eller er det bruksdata fra enhetene, eller er det internt for utvikling og bedriften? Altså data snakker vi om her. Dette er utelukkende bedriftsdata. Brukernes data er jo veldig personlige, så de er vi ikke borti i det hele tatt. Men vi er jo et globalt selskap som selger i nesten ... Om ikke hele verden, så selger vi i alle verdensdeler i hvert fall. Så det er mye data fra bl.a. logistikk og salgstall osv., så alt dette må inn gjennom vår plattform.

06:11 --> 07:20

Nei, altså bare litt som det Eirik sa, egentlig, bare en annen måte å si det på. Det er jo også det at før så jobbet Data Engineers, så skulle man både lage Ingest og Eksport og Transform. Og det var en overwhelming job, da. For i tillegg så måtte du ha det menekunnskap om dataene for å kunne lage nyttige transformer. Men det vi klarer med det oppsettet vi har nå, er jo i større grad å At vi tar oss av den tekniske plattformen, og at domenekunnskapen i større grad faller av på analystene, som vi da har et krav om at må kunne SQL og kunnskap om dataene sine, domenekunnskap, og også å snakke med folk i businessen. Så de sitter et hakk tettere på folk som har behov for innsikt osv. For da lurer altså de analystene, hvilke verktøy er det dere tilbyr til de som ... Altså hvilke funksjoner? Ja, det er jo da ... Vi snakket om at vi har jo satt opp disse cloud runene. Det er da Manage Kubernethus, for de som ikke vet det.

07:20 --> 08:49

Og etter det er gjort, så vil analysene jobbe med den dataen, slik som den ser ut nesten fra API eller filer som SV4 eller hva enn det skal være. Som er fra verden der ute? Ja. Fra våre partnere, bl.a. som ... For eksempel Logistikkpartner og sånt. Og ... hva var spørsmålet? Hvilke funksjoner tilbyr dere? I hodet mitt er det deploy og monitorering og sånn. Men hva er det en dataplattform tilbyr av den type verktøy som dataanalyser bruker? Ja, ikke sant. Og etter at vi har hentet inn denne dataen, vil dataanalysene jobbe med ... Jobbe med DBT oppå Big Query, som gjør at de gjør transformasjoner på dataen og klarer å dra innsikt ut av rådata. Og så vil jo dette være presentert opp i et BI-verktøy etterpå. Vi ønsker at mest transformasjoner gjøres i Big Query med DBT, for da kan det brukes i andre ting også senere. Det gir veldig mening. Og så, mens BI-verktøy, slik som ... Vi bruker da Looker. Her gjør man da rapportering i dashboard og andre typer dashboard.

08:49 --> 10:14

Eller så har vi andre BI-lignende verktøy også, som brukes kanskje til logistikk. Hvor mange er det som jobber med denne plattformen, og hvor mange jobber i Remarkable? Vi er jo ca. 500 stykk i Remarkable nå, så det er ganske mange. I Dataplattformteamet er vi da seks personer. Og Data and Insight, det er på en måte ... Dataplattformteamet er sentralt i datainnsiktsavdelingen. Da er vi 16 stykk, da. Det er jo da data-analystene, typisk. Er alle de i Oslo og Norge, eller er det en sånn ...? Alle er i Oslo, utenom at vi har én som jobber remote fra London per nå. Hvordan er ellers arbeidsformen i teamet? Når dere starter dagen, hva skjer? Er det noen ritualer, eller ...? Det første vi gjør, er å sjekke alerts, da. Plattformens ansvar er å sørge for at både dataene kommer på plass, og at transformasjonsjobbene ikke feiler. Det ansvaret er delvis vårt, for hvis det er feil med dataene,

10:14 --> 11:34

altså dataintegritetsfeil, så faller det ofte på de med domenkunnskapsfeil. Men vi må sørge for at DBT funker som det skal på Bickery, og også det siste steget, altså Lucre osv. Så det er det første. Utover det så jobber vi jo agilt og har et sånt give aboard. Og jobber vel ... Vi prøver jo på en måte å fokusere på plattformarbeid og tenke langsiktig og bygge gode abstraksjoner. Både ... Både for dataanalystene, som er en enhetskundegruppe, men også for oss selv. Kanskje i motsetning til tradisjonelle abplikasjonsplattformer, vi er også våre egne kunder. For vi er ikke store nok til å bare lage plattform. Vi lager verktøy for oss selv også. Så har vi også en idé om å ha litt mer embedded ML, Engineers, Data Engineers. Det er to målgrupper her, Engineers og Data Analyst, så man må tenke litt med to hatter av og til. Så det å tenke langsiktig, hva innebærer det, det er vel egentlig at vi f.eks. det siste året har vi jobbet mye med å bruke Go for å lage mer robuste ingesters fra restapier fra tredjeparter, f.eks.

11:34 --> 12:47

Der hadde vi noe i Python før som var ikke godt nok. Det tar tid å skrive god go-kode, men nå begynner ting å fungere veldig mye bedre og er veldig mye lettere å vedlikeholde. Det er en prioritering vi kan ta når vi tenker plattform, å bare fikse data inn, på en måte. Det ble også en naturlig overgang der fra det å ta enda ... Eller gjøre disse data ingestene på nytt. Fordi tidligere så var det en funksjon som bare var drevet av oss, det å hente data. Og så har vi tenkt litt mer at data-analystene skal også bli enablet til å kunne gjøre dette selv, med konfigurasjon. Men det stiller også andre krav til hvordan vi har laget disse ingestene, så de kan være mer generelle. Og da var det en strategi for rett og slett å enable de, da. Ingestene dere lager når dere bruker GoFriend fra en idé, kjører dere i applikasjonsplattformen, ikke sant?

12:47 --> 13:51

Er det Cloudrun, eller er det det som også er applikasjonsplattformen? Eller kjører dere de tingene selv? De kjører vi selv. Vi er egentlig ikke så på applikasjonsplattformen sånn som resten av selskapet som jobber med applikasjon er. Vi styrer med vårt, egentlig. Vi har egne områder. Men vi bruker mange av verktøyene som applikasjonsplattformen, eller "cloud services", som vi kaller det. Internally Remarkable. Vi bruker mange av de tjenestene som de tilbyr. Det er typisk Atlanterhavs. Vi er veldig fan av Cloudrun. Det er noen kumuletisk-klustre på plattformen, men vi har ikke sett behovet for å hoppe inn der. Så Cloudrun gir oss stort sett det vi vil ha. Så da tar vi det selv. Men hvis vi begynner helt i starten, for disse dataene kommer vel da noen ganger fra eksterne leverandører, men kanskje også fra teamene deres ...

13:51 --> 15:03

Tradisjonelt sett så er det ofte vanskelig å hente dataene fra team som beveger seg fort, du får ofte sugerørne i basen-problematikk. Og i hvert fall her i Nav så har vi jobba en del med å få de til å tenke mer produkt på dataene de tilbyr, sånn at de tar mer ansvar. Det som tilbys, gir mening for analyse og den type ting. Tenker dere noe av det samme? Vi har veldig lyst til å gjøre det sånn, men så har det seg slik at vi har organisert på en måte som gjør det litt vanskelig for henne nå, men jeg regner med at vi beveger oss mot det. Men vi gjør jo da mye av innhentingen rett og slett fra disse eksterne partnerne rett ut, ikke gjennom team internt, selv om vi henter noe data derfra. Det blir sikkert mer og mer, men det er også derfor vi også har endt opp med å gjøre ... Jeg vet ikke om vi skal begynne å snakke om datamesh nå. Det var i sjelen i tankene, at vi skulle ha datamesh, som er å distribuere eierskap for data, og da er du ansvarlig for å levere det til.

15:03 --> 16:26

Konsumenter, og sørge for at det er oppe og tilgjengelig hele tiden. Men vi har jo da ... Vi startet med å bygge plattformen litt ... Litt med tanke på dataverse, men så har vi endt opp med å egentlig ta mer eierskap på teamet selv til disse innhentingene. Og så har vi mer data analysts som jobber ut mot resten av selskapet igjen. Vi prøver å tenke litt mesh ut, altså etter transformen. Men inn i rålaget, som vi kaller det, der er det jo mest av at vi bare scraper operasjonelle data, og tilgjengeliggjør dem for analyseinnsikt. Det er andre jusskretser også, men ... Da får dere ganske mye ustrukturert eller rådata som kanskje ikke passer helt. Men har dere da i plattformen også noen verktøy for å skjønne de dataene? Sånn datakvalitet, eller hvordan liksom få metadata med et kjempestort datasett? Har dere den type verktøy òg? Der har faktisk Binker en del innebygget, som rapporter på datakvalitet og sånn. Men vi har også et eksternt verktøy som heter Synk. Som er da en SAS som den heter.

16:26 --> 17:33

Som vi har inngått partnerskap med. Som tar seg av ... Datakvalitetsmonitorering. Og så har vi da også tester i DBT, som er da du kan kjøre tester opp og ... Mot de rådata som kommer inn, på en måte? Ja. Så da kan vi passe på at det skal se ut sånn som vi har lyst. Vi har også dodja den litt i plattformen. Vi sier til analysen at dere må dokumentere. Når dere tar det fra Rå til første laget, hvor vi sender ting inn som Jason-typen ... Det er en egen kolonnetype i Big Query som de plukker til feltene, og da må de dokumenteres. Så dette overlater vi da til domenekspertene i sine respektive felter. Men vi stiller krav om at alt skal dokumenteres, men de er veldig gode til å følge det. Så blir det dokumentert inni Big Query, eller inni ...? Ja, stemmer. Så da kan du gå inn i Big Query-konsollen, og så ser du det der, og så ser man det vel også inni DPT, da. Så da har dere tester som beskriver antakelse om den rådataen,

17:33 --> 18:49

og hvis de feiler, så feiler testene, og da klarer dere å oppdage det tidlig i flyten? Det er et godt spørsmål. Det tok meg litt tid å skjønne forskjellen på en enhetstest og en datatest. Av og til er det litt overlapp, men ofte er det jo to helt forskjellige ting. Enhetstester er jo ... Jeg skulle ønske det var mye lettere å lage enhetstester på SQL, for ofte kan queryene bli ganske komplekse, og hvordan kan du teste alle HQ-ester, vi skulle gjerne hatt bedre støtte for det, det har kommet i DBT 1.8 nå, så kanskje vi kan begynne mer med det. Dette er litt uvant i arbeidsklyten til dataanalystene, men på sikt kanskje, men iallfall datatester, det går da mer på at man kan sette krav om at denne kolonnen skal ikke ha noen "knows". Så du tester data, setter på data? Ja, du tester dataintegriteten, da. Så hvis denne kolonnen er populært, så må også den, den og den være populært. Hvis ikke, så slenges det en feil som de får i sin kanal. Da må de gå og sjekke opp dette. Det fungerer ordentlig ganske bra, det var mitt inntrykk. Det kan bli ganske mange datatester som feiler, men på sikt klarer de å få det frikta opp.

18:49 --> 20:03

Det er også mye fordi vi har laget en analyseplattform først og fremst. Så i noen tilfeller er det greit at man får en warning, som det heter, i større grad enn en feil, som gjør at dersom en datatest feiler, så er det ikke nødvendigvis at det er noe feil med dataen, men det er greit å vite om man kanskje håndterer dataen annerledes enn det man trodde. Men så har du andre tilfeller der hvor du ikke vil bryte kontrakten du har, da. Med konsument av den tabellen du produserer. Den tabellen du produserer til slutt. Da må du ... Da vil du heller kaste en feil, ikke sant? Og da vil du ikke sørge for at det propagerer videre ut fra dataplattformen. Og transformasjonslaget, som også er SQL, det kjører deg egentlig i BigFair, du husker aldri hva dette er bygd, datasett i datasett eller Table 311? For BigFair er det i gamle dager prismodellen at du betaler det for data lest i en spørring. Er det mye ... Tenker dere mye på penger når dere gjør dette? Siden det er tett kobla og ting dere gjør, mot så mye det koster?

20:03 --> 21:11

Vi har tatt det litt sånn idrativt, faktisk. Vi har tatt ... Det er mer den veien at vi har ikke brydd oss om penger i starten. Fordi det er gjort ... Det var ikke så mye penger! Men det var ikke så dyrt å kjøre queries i starten fordi vi hadde ikke så mye data. Nå som vi begynner å få mye mer data, så har vi også da gradvis mer tatt ... Hva skal vi si ... Tatt grep. Rett og slett gjort noe med setupet vårt. Og det kommer vi til å gjøre i økende grad framover. Er det noen måte de kan se hvor mye penger de bruker? Eller er det liksom bare sentralisert? Du får noe som heter Bites Build, som du i hvert fall kan se det på. Vi kommer til å sammenstille i større grad framover, da. Det er kun inne i big cree-konsollen, men ofte når vi kjører en stor lastejobb ... Hvis du gjør en committe inn mot en PR, så kjører de alltid en ny transform. Da er det ikke så veldig transparent.

21:11 --> 22:19

Så når vi har tianvister som sender en masse committes hver dag, så kan fort den regningen bli ganske høy. Men det er veldig behagelig med Det er veldig behagelig med Infinite Compute og sånn ... Big Cree er en lang, kul form for magi? Det virker som det bare er én kjempestor datamaskin der borte. Andre skyldhumører er også tilgjengelige. Så vi prøver å sette oss langt og ikke gjøre brukeropplevelsen for anlystene som de stort sett er fornøyd med, og gjøre den dårligere iallfall. Men vi må nok se på noen kostnadsbesparingsteknikker etter hvert. Du sa du hadde tenkt i mer produkt ut av plattformen. Hvordan gjør dere det? Det er jo det vi har begynt med. Fordi produkt ut i første omgang var jo da rett ut til BI-verktøy. For å lage dashboards, som nevnt. Men så er det jo det å få innsikt tilbake igjen til applikasjonsplattformen. At man tilgjengeliggjør noen API-er eller tabeller eller ...

22:19 --> 23:35

Piler skal jo være nødvendig. Eller prediksjoner for noe. Det tilgjengeliggjøres for applikasjoner å bruke. Så det er ett steg videre. Finnes det noe sted i plattformen hvor dere har konseptet produkt, eller er det fortsatt bare en tabell og noen må finne det i Big Grey? Det er mer konseptuelt, som du er inne på, at det er en tabell alle mellomstegene også. Eller tabeller i DBU. Men vi har en "naming convention", og her kan du forvente at dette er et dataprodukt. Ja, jeg er enig. Vi kaller jo egentlig alt som er ut dataprodukt nå, men vi gjør et skille på det som er et analytisk dataprodukt, som går mest i rapportering, og det som eventuelt kan serve av operasjonelle behov. De stiller forskjellige krav til både datakvalitet og opp-tid osv. om en rapport. Hvis en rapport brekker i Luckers, så er ikke det like farlig som om operasjonelle behov ikke dekkes. Så vi har ikke så veldig mange operasjonelle behov gjennom den plattformen nå, men vi har ambisjoner på sikt om å kunne støtte det.

23:35 --> 24:57

Nå har vi vært litt nevnt av maskinlæring. Tilrettelegge for trening av maskinlæringsagent? Ville det falt under deres bord, eller? Ja, i hvert fall. Mye av det. Ikke nødvendigvis det som skjer på Remarkable-tabletten, men mer det som skjer rundt. Riktig, riktig. Så ja. Vi kan jo på sikt kanskje understøtte noe i softwaren vi har, f.eks. Jeg vil se for meg at nirvana er jo når man klarer i større grad å bruke dataene, ikke bare til rapporter, men få det inn til det operasjonelle og bli enda mer datadrevet. Kan du si at det er vårt nirvana også? Vi utvikler et oppsett for trening av ML-modeller. Vi har ikke så mye kjørende ennå, men det vi har sett etter at LLM kom, er at du kan kjøre zero shot predictions. Det har vi klart å sette opp én jobb som funker bra bare gjennom DBT. DBT gjør et kall til en modell, eller et kall til en LLM fra Bigcree, og så kan vi få sentiment fra ting, uten noe trening involvert.

24:57 --> 25:58

Vi bare velger en GMini-modell. For en stakkars direktør som er back-in-utvikler, hva er zero shot production? Det er jo det at du ikke trenger å trene modellen. Zero shot er vel at du sier: Her er en tekst, kan du gi meg sentimentet på denne? Hvis du har, hva heter det neste da? A few shot, kanskje? Du kan gi noen eksempler. Her er ti eksempler på hva som er ... Dette er sentiment negativ, og dette er positiv. Hva vil du si at denne teksten er? Det er bare prompt engineering på et vis. Den som kjører nå, er vel en fue shot med noen eksempler, og så har det vist seg å fungere relativt bra. Men det mest elegante er at det bare kan gå rett inn i DBT-stacken, og ingenting av den ML-overheaden som gjør man til ... Det er ofte veldig mye overhead og treningspipeline og alt det greiene der. Er sentimentanalyse et reelt eksempel? Er det for en type reviews, eller kan hva ...?

25:58 --> 27:22

Egentlig akkurat det. Det gir veldig mening å se hva vi kan forbedre oss på, eller hva kundene ønsker seg. Det er en lettere måte å gjøre den biten på, som tidligere har vært gjort manuelt. Ikke bare sentiment, men at du får: Hva er det folk har lyst på i features? Det kan du finne ut av. Og siden vi bruker, som Rasmus nevnte, at vi får brukt DBT ... Siden vi har Bigquery ML, som er noe Bigquery har, så du kan gjøre SQL-spørringer direkte med en maskinlæringsmodell på data ... Det gjør at vi har et veldig enkelt oppsett og kan itererere veldig fort. Og så trenger man bare å gjøre det mer avansert ved behov. Per nå får vi dekket ganske mange use cases bare ved å bruke Debutae og Binkery sammen. Du får sikkert gode integrasjoner med Gemini, som er Googles AI-tjeneste. Vil du tippe at det er mye integrasjonsmuligheter der rundt Binkery? Selve administrasjonen de tilbyr, er at det er en tabell som du deployer som heter Gemini 1,5, f.eks. Og så bare gjør du på en måte SQL Carris-moten. Det er så dydig å spise sånn SQL i verden! Alt er tabelling, uansett hvor du lager en tabell!

27:22 --> 28:34

Men det som igjen er tilbake til alt det er SQL, det er jo faktisk et litt sånn ... Målet vi egentlig har, er å tilby mange av tjenestene våre, der du interagerer med dem via SQL eller konfigurasjon, som gjør at vi igjen gjør det enklere for Data Analyst å gjøre litt mer komplekse jobber. Nå har vi sagt DBT mange ganger, min forståelse er at det er et rammeverk som strømler uniformer og forenkler og legger på masse utafor, men som gjør det bedre å jobbe med SQL. Ja, det stemmer. Det står for Data Build Tool, og du bygger tabeller via DBT, du kan teste tabeller via DBT, du kan bygge dokumentasjon rundt tabeller i DBT, og pga. Big Ramel kan vi også gjøre en maskin. Maskinlæring gjennom DBT. Og det det gir oss, er at du kan, eller essensen av det, er at du kan templete serier med SQL-spørringer som skal skje etter hverandre. Og da vil DBT orkestrere i hvilken rekkefølge det skjer, uten at du trenger å forholde deg så mye til det.

28:34 --> 29:36

Så det forenkler definitivt ut en rekke med SQL-transformasjoner etter hverandre. Nå tenkte jeg først på om det er noe skaleringsproblem ... Men alt det bare gjøres i Big Cry, og da er det ikke skaleringsproblem. Det første som skjer når DBT kjører, er å kompilere SQL. Så det er python-ginja-templating av SQL, som gjør at du kan skrive litt mer dry. Ikke den beste syntaksen, men det hjelper. Det er tross alt SQL-syn. Den tar dette og kompilerer til ren Big Cry-SQL, som da kjører Big Cry på vanlig måte. Så definerer du om denne SQL-en skal generere et view eller en tabell, eller noe som heter incremental table, som på en måte bygger bare siste last opp på en tabell som allerede eksisterer. Er det her disse enhetstestene kommer inn? At du lager enhetstester for endringene av disse ginger-templetene? Ikke enhetstestene, men datatestene.

29:36 --> 30:44

Etter at du materialiserer tabellen, så sjekker den integriteten, eller reviewet, kan også være. Du kjører igjen spørringen, og så tester man om alle dataene er som forventet. Kan man også teste transformasjonen? Eller gjør man det ved å kjøre datatester før og etterpå? Transformasjonen gjør du ved unit-test. Ja, der har vi det. Har vi for lite av. Anlystenes vanlige flyt er å teste, altså manuelt. Man kompilerer til SQL og tester inn i konsollen, så får man den til å se ut som man vil. Stort sett er de fornøyd med den flyten. De dukker jo opp, bugs, men da fikser man dem når de oppstår. Unnskyld uttrykket, vanlig kode. Så er testing lettere når det ikke er sideeffekter. Dette er inputen, dette er outputen. Det er veldig naturlig for SQL. Det bør jo ligge til rette for at den type testing bør være ganske enkelt. Det er helt klart derfor jeg tror også DBT la det til nå nylig,

30:44 --> 31:58

som en sånn ... Inkludert i DBT. For det har vært noen småprosjekter som du kan installere mer sånn ... Noen ildsjeler har lagt ut på GitHub, som er pakker du kan installere i DBT. Men det har vært litt komplisert å bruke tidligere, etter vår erfaring. Så det er veldig velkomment at det har blitt en del av DBT nå. Vi har noen enestester, men det er vi som eier. F.eks. på GDPR-håndtering og sånn, hvor det er viktig at ting må funke akkurat som forventa. Der har vi lagt enestester. Det funker bedre enn ikke, men er ikke perfekt. Men det er jo generelt sett bra at de gode praksisene ... Gode praksisene fra softwareutvikling i større grad treffer også denne delen av softwareutvikling. Det er en økende trend i data engineering-spacet og egentlig dataspace. Det at det meste lærer litt tregt, men det kommer seg, og kommer seg med å følge etter software engineering best practices. Det er noe med målgruppen her også, for Data Analyst...

31:58 --> 33:25

Det med enestester var already i begynnelsen. Du må ha brent deg et par ganger før du skjønner hvorfor det innommer. Det er nok en kulturting der også. Det tar jo tid å skrive gode tester. Om det tar helt av, vet jeg ikke, men det er bra at det er støtte. Så bruker vi det ved behov. Så får vi se om vi skal kreve det av analysene på sikt. Da kjører dere på med et par programmering, og så tar dere alle tingene sakte, men sikkert. Da blir det bra til slutt. Du sa i stad at du sa "commit" på PR. Hvordan er den flyten når du jobber? Der SQL-en ligger, og så ... Hva skjer når de committer på PR, da? Det som skjer, er at vi har ... Vi prøver jo egentlig å følge litt sånn CICD, slik du har det i software engineering-verdenen. Generelt. Så når du oppretter en PR mot main-branchen, så vil det da bygges og testes det du har, mot eksisterende data. I dataplattformen. Og så dersom det passerer, så må du selvfølgelig også få godkjent PR. Det er jo ålreit. Og så dersom det er tilfellet, så kan du merge the main.

33:25 --> 34:43

Og da vil det da bygges ... Til vårt dev-miljø, som vi har litt flytende, men det kan vi komme tilbake til. Og så, dersom det går fint, så bygges det bare i prod. automatisk. Og det funker ganske ålreit. Hver committee kjører en kommando som heter DBT-bil, som bare bygger alle modellene på nytt inne i et midlertidig PR-datasett. PR-datasett i Big Rey. Så det er veldig lett å gå inn i konsollen og sjekke at resultatet er som forventet også. Men ... Jeg legger til én ting bare også. Sorry. Vi har også ... Kort fortalt så kjører vi trunk-based litt flyt, egentlig. Som jeg ser som i hvert fall den vinnende strategien for ... Softwareutvikling. Er dataflyten batch-basert, eller er det event-basert? Reagerer dere på ny rad, eller ny fil, på en måte? Her i dag er det mest batch, definitivt. Nesten utelukkende.

34:43 --> 35:54

Hele DBT og big career-jobben er batch. Den er skritulert, og den trigges også av kommits. Men vi har noe ... Vi har noen lastejobber inn i Raw, altså laget før transformasjonen, som kan være event-basert. Hvis Dragon Droppers, CSV-er og sånn, så trigger det inn just umiddelbart. Da kan det være at det kommer masse committer inn, mens man egentlig ikke vet om det funker, før batchen kjører, på en måte? Nei, du vil jo ha ... Det ville ha gått gjennom hele Dev til Prod. Innimellom funker det først i Prod. Ja, det kan faktisk skje der, fordi du får inn noe data som du ikke forventer. Men der har vi jo faktisk implementert noe som Rasmus så vidt var inne på her nå. Vi har implementert en løsning for å lese inn CSV-er som noen laster opp, for det er der vi så det var mest behov for litt kvalitetskontroll! Så der har vi noe som gjør en sjekk på CSV-en, at den ser ut som den skal. I henhold til et skjema som vi har.

35:54 --> 37:03

Det har vi bl.a. implementert via DuckTV, ganske stilig. Da fikk vi bruk for det. Og ... ja, da gjøres det en validering på den filen, og dersom det funker, så blir det lastet opp i Bigory til rådatatabellen vår. Ellers så vil du da få en melding på Slack om at du gjorde en forferdelig jobb med den CSV-en. På en hyggelig måte. Ja, på en hyggeligere måte. Men sånn logistikk ... Har dere jobbet med det før? Eller var det liksom det å ... Nå jobber jo ikke dere med logistikk, men mye av det er logistikkdata. Var det nytt for deg? 100 % nytt for meg, men ... Noen overraskende ... For dette er jo helt magisk for meg, som bare får noe i posten når jeg trenger det. Men dere ser jo hvordan dette nettverket kanskje oppfører seg, da. Ja, vi jobber jo ikke med det direkte, men ... Vi får jo dataene fra det!

37:03 --> 38:21

Og så har vi som sagt Data Analyst som sitter med det her. Og noe vi har bidratt med fra Data-plattformen, eller Data Insight, er jo å lage noe som vi har kalt Cost-to-Serve, som er et dataprodukt for å kunne bryte ned kostnad ved et salg i et land. Versus andre land, f.eks. Kan du få den innsikten ut fra det, da. Ja. Og det har visstnok bidratt til at man finner ut at det er noen land det er veldig dyrt å sende til, selv om vi tar samme sum for det, da. Hva er den store variabelen, da? Shipping, eller er det andre ting? Shipping har vært en stor ting der, ja. Nei, vi er iallfall ikke den rette til å svare på det, men det kommer litt inn på det som ... Kanskje vi falt litt inn i den tankegangen? Det er viktig at vi ikke påtar oss å kunne dataene, menekunnskapen. Det er veldig behagelig når jeg setter opp en ingest, og så bryr jeg meg ikke om noen ting hva som står i dataene. Det eneste som spinner rolle, er at de skal komme dit hver eneste dag.

38:21 --> 39:30

Shipping og logistikk er noe som går tilbake til så lenge mennesker har eksistert her. Det må jo være mye gamle systemer på mottakssiden. Jeg hørte at det var Excel for disse store shippingportene. Det må være en utfordring å integrere med mye av disse eksterne systemene. Det er kanskje mye av det som vi har klødd oss i hodet for noen ganger, at det er veldig mye som gjøres via CSV og eksempeliv og e-post. Det er ikke lenge siden vi slutta med disken. Men vi trives best på vårt team ved å bygge rør, istedenfor innholdet i rørene. Så vi bygger pipelines. Men hvordan kommuniserer dere med brukerne deres? Data Analyst, hvordan finner dere ut hva de trenger, og hvordan kan dere si nei til dem på en hyggelig måte når de har lyst på ting? Vi har jo gjort det ganske simpelt, egentlig. Vi har kanaler for feature requests og feedback, og så har vi jevnlige møter med dem også.

39:30 --> 40:40

Så kan de bare huke tak i oss hvis det skulle være noe. Så tar vi jo vurdering, eller vi prioriterer, og vurderer det som kommer, da. Det er ikke alt vi ønsker å gjøre, men vi vil kanskje gjøre det, men på en annen måte enn de foreslår, fordi det går mer mot det. Den langsiktige visjonen vi har. Tett dialog med analystene, som er vår primærklient, det er veldig viktig. Ofte så vet ikke de helt hva de vil ha. Så vi setter oss ned og prøver å ha en produkttak på hvordan dere kan være fornøyd med det her. Så en litt sånn itterativ prosess, og stort sett så blir de fornøyde. Det kan jo ta litt tid å lage det, men vi lander vel på at det stort sett er verdt investeringen. Vi ser på oss som et produktorientert team, og tenker på det som våre kunder. Men vi er også kunder av vårt eget produkt, så det er jo ganske fint. Da får vi også kjenne litt på smertene innimellom, vi også. Så da gjør vi det enda enklere å gjøre de endringene som trengs

40:40 --> 41:28

for å gjøre produktene bedre. Det jeg har tenkt mye på i det siste, er det å lage en plattform som lages på den samme verktøystacken som de som bruker plattformen. Det gir jo en stor mulighet i at du liksom skjønner det mer, men også kanskje en fare for at du blir mer lukka, og blir enda mer til å løse dine egne problemer, og kanskje ikke så var for de andres problemer. Både fordi du jobber med andre ting, men også kanskje fordi kompetanse og erfaring er veldig forskjellig. For plattformgjengen blir jo liksom eksperter, og tenker at alle skjønner jo hvordan vi skal bruke det her, for det gjør jo vi. . Mens de som bruker plattformen, kanskje egentlig ikke er så interessert i å skjønne alle tingene enn de har noen faktiske problemer de skal løse.

41:28 --> 42:52

Absolutt. Man legger jo kanskje merke til bedre når det er litt vel mange steg i prosessen for å sette opp en ingest for en dataanalyst, f.eks. Men vi har jo prøvd å legge oss på det å gå litt sånn ... Det eneste du skal trenge, er konfigur. Bare sånn ett sted. Da er vi på et ganske godt sted, da. Ja, f.eks. så lar vi analystene kunne sitte i terraform og deploye en ny ingest fra et nytt øyepunkt. Gitt at abserksjonen er overkommelig for dem, da. Men det er jo alltid en sånn ... Som du var inne på, da. Hvor man skal legge abserksjonen, hvor abstrahert skal det være? Det er alltid vanskelig. Det tar lang tid å lage noe som har veldig høy abserksjon. Men det er den dialogen vi har, og en vurdering av våre egne prioriteringer. Men vi begynner å gå inn på havnen ... Han sa terraform! Hvordan bruker du terraform? Vi bruker jo terraform til å ... Vi lager terraform-moduler. Som skal være enkle å bruke. Så enkle at ... Så enkle at data-analysene kan konfigurere en terraform-modul ...

42:52 --> 43:58

Hva er det som deployes med terraform? Hva som deployes? Det er cloud-infrastruktur for en reform. Så de slipper å konfigurere det. De forholder seg ikke til det nivået. Denne ingesten skal hete det og det. Endepunkter for hvor de skal hente data fra. Så bruker vi da Atlantis, som er noe Cloud Services-teamet gir oss. Så det er sånn de deployer ... Da må jeg spørre, disse endepunktene, ligger alle åpent på nett uten noe autentisering? Hvordan håndterer dere hvis de trenger dette? Bruker de andre passordet for å få kontakt med dette endepunktet, eller er ikke det et issue? Jo, da bruker vi egentlig ... Secret Manager i GCB. De legger inn Secret der, og når de legger konfigureren på enden, refererer de til den security-planen. Og det er der Atlantis kommer inn, som kjører den terraform-planen.

43:58 --> 45:18

Så de slipper å ha tilgang til å kjøre Terraform Apply selv. Men da kan du få lov å gå inn! Men da går vi inn for havnen i denne shipping-episoden! Vi kan shippe denne episoden! Men før vi avslutter, så har vi ett spørsmål som vi spør alle gjestene våre. Og det er om dere kan fortelle om en gang ting ikke gikk helt etter planen, og hva dere lærte av det. Jeg kan jo ... Det er mer en sånn arkitekturfeil, kan du si. Eller flaw. Det handler om datamesh. Rett og slett, er at vi hoppet jo godtroende inn med begge beina i starten. Ikke begge beina, men vi tenkte vi skulle være mer distribuert enn vi har endt opp med å være. Så vi hadde tilrettelagt mye for distribuert eierskap, da. Men vi har egentlig endt opp som et mer sentralisert team, som har ansvar for ansvar for nesten alle data ingestene, sånn at ting funker. Ikke innholdet, som sagt, men bare at det er oppe og går.

45:18 --> 46:39

Her hadde vi egentlig planer om at de skulle ligge mer distribuert hos, i hvert fall i første omgang, en data engineer som kanskje sitter nærmere de med behovet, de med den kunnskapen. Men det har vi da ikke gjort, så da har vi endt opp mer med å ta det... Vi dealer med det, og så enabler vi heller data-analystene så mye vi kan, for å ikke bli en flaskehals. Det er derfor vi ønsker å flytte eierskapet til data-analystene, så de er nærmere og vet hva som skal til med riktige data. Vi hadde en lærdom at det lønner seg å kunne tilrettelegge for at man også gjør feil. Så vi prøver å gjøre alt vi tilbyr av funksjonalitet, sånn OD-basert som mulig, at vi bare kan bytte det ut dersom det ikke funker, da. Selv om du er enklere, bare gjør det riktig første gang. Når du hadde begynt med det, hadde det vært så mye lettere å lage plater. Da er det en god nummer to å ikke gjøre samme feilen to ganger. Veldig spennende å høre. Og før vi runder av:

46:39 --> 48:10

Er det ellers noe dere vil legge til? Vi kan jo begynne med deg, Erik. Nei, altså vi er i stor grad veldig fornøyd med det vi har laget. Vi har en veldig velfungerende dataplattform som gjør det den skal. Data-analystene er glade, og vi fortsetter å forbedre de tingene som kanskje ikke fungerer så bra. Og vi gleder oss også til å komme oss videre fra å bare kunne tilby analyse, til å kunne bidra mer inn i andre organisasjoners behov. Hva med deg, Rasmus? Det er litt det samme. Vi tenker at nå begynner de fleste å bli ganske fornøyd med slikt. På dataklattformen begynner de å nærme seg modne nok til å servere mer operasjonell og ML, som ofte er et operasjonelt behov: Maskinlæring. Så vi håper å få det opp på det nivået hvor det kan kjøre og gå. På en trygg måte. Det er en ambisjon. Tusen takk til Eirik Folkestad og Rasmus Næs fra Remarkable for at dere har vært med oss her i studiet i dag, og for det som absolutt kan betegnes som en norsk suksess. Audun, hva har vært høydepunktet ditt i denne episoden?

48:10 --> 49:17

Jeg syns det er før og på samme tema, men at det er veldig morsomt å se hvor likt det er med utfordringer på plattformsida, selv om det er verktøyene som er ganske forskjellige, og problemene som skulle løse seg forskjellig, så er det ganske mange av de samme utfordringene med å holde kontakt med brukeren. Det er nok mer å lære på tvers av applikasjon og dataplattform enn jeg trodde før. Hva med deg, Ann Tristan? Det er spennende å høre om bruk av Google Cloud. Det er ikke ofte det er mye andre plattformer. Jeg syns det er utrolig gøy. Og så stopper jeg ikke å bli overrasket av hvor allsidig SKL er, og hvor mye det er brukt i dag, og fortsetter å være relevant. Den dag i dag, da. Med det avslutter vi denne episoden av Plattformpodden med Hans Kristian Flåtten og Audun Faukast Strand. Teknisk produsent er som vanlig Tore Græsdal. Nyeste episoder finner du alltid på plattformpodden.no eller i din lokale podkastapp.

49:17 --> 49:32

Følg oss gjerne på LinkedIn, tips en kollega og få en fin e-post fra Audun i retur. Ha det bra!