Hos altfor mange datateam ser ingestionlaget omtrent slik ut: én notebook per datasett, én pipeline per kilde, og en vedlikeholdsbyrde som vokser proporsjonalt med antall integrasjoner. Etter hvert som teamet skalerer, er det ikke uvanlig å ha 30–50 notebooks som er 90% identiske, men med noe ulike løsninger ut ifra hvem på teamet som bygde integrasjonen. Her er også servernavn, API-endepunkter, tabeller og SQL-spørringer hardkodet inn slik at det er vanskelig å få oversikt over ulike parameterne som styrer den faktiske integrasjonen. Når noe feiler i produksjon, og du som Data Engineer må inn i koden for å debugge blir standardspørsmålet: "Okey, hvordan var det vi hadde løst det her?". Dette skaper store kognitive laster vi gjerne kunne vært foruten.

Når man jobber med data som endrer seg over tid, er det helt naturlig å ville beholde historikken. Dette er kjernen i det som kalles Slowly Changing Dimensions type 2 (SCD2), som er en måte å sørge for at vi alltid kan se hvordan en rad så ut før, samtidig som den oppdateres med ny informasjon.

Du sitter på tredje møte denne uken og prøver for n'te gang å forklare dataanalytikerene at dataene de trenger ligger i sølvlaget, og at de derfor har ansvaret for å foredle dem videre i gull. Frustrasjonen stiger - hvorfor føles det som en evig kamp å få dem til å forstå? Eller kanskje du og teamet ditt sitter fast i en diskusjon om hvilken transformasjon som egentlig hører til sølv, og hvilken som må vente til gull? Eller så har du en irreversibel schemaendring på et viktig datasett, og du lurer på hvordan du skal versjonere det uten å miste oversikt, da utbryter en på teamet: "Hva med pre-silver?"

dbt (data build tool) er et verktøy som virkelig har skutt fart de siste årene, og det er ikke rart. Endelig har vi fått et verktøy som gjør det enkelt å versjonere, dokumentere, teste og release data ved hjelp av SQL. Eller?

Dersom du har lagt en strategi for hvordan din bedrift kan bli mer datadreven: Gratulerer, du har allerede kommet lenger enn de fleste! I altfor lang tid har de fleste bedrifter sagt at de skal satse på å bli mer datadrevne uten at de egentlig forstår helt hva det innebærer. Det holder dessverre ikke å ansette et team av data scientists og tro at man har klart det. Uten en mer helhetlig tilnærming til en datadrevet transformasjon, er man dømt til å mislykkes.