Jag och mina kollegor som är Data Engineers snackar samma språk. De som gör samma sak som jag förstår intentionen med min kod, och om någonting behöver justeras som påverkar leveransen är det ofta förstått varför, utan närmare förklaring. Men som nästan alla andra yrkeskategorier jobbar jag inte bara med mina gelikar; jag arbetar med en uppsjö andra roller såsom data arkitekter, analytiker, marknadsavdelningar, jurister, verksamhetsutvecklare, designers och projektledare. Jag är övertygad om att dessa roller, likt jag i min, letar efter sätt att lättare visa och demonstrera vad det är de egentligen vill säga.  

Klassiska utmaningar är klassiska av en anledning 

Data Engineers sitter väldigt nära verksamheten, samtidigt som vi har stenkoll på teknik. Vi inom Data & Analytics måste ha ett helhetsgrepp, våga vara nyfikna på andra områden än de som är specifikt våra, och lära oss mer för att få en så bra leverans som möjligt. Kort sagt så är samarbete både en möjlighet och en utmaning för oss som yrkesgrupp.  

Hos en av mina tidigare kunder stod vi inför en klassisk utmaning; vi saknade den tid som behövdes för att göra jobbet vi var där för att göra. Anledningen var också klassisk; verksamheten hade inte tillräcklig förståelse för vårt arbete, vilket resulterade i att utvecklingsteamet behövde arbeta med att förklara mer, samt lägga ner mer manuellt arbete för att ge en bättre förståelse för datakvalitén, hur man ska arbeta etc. Vi behövde bli mer agila som team. Därför introducerade vi DBT, eller Data Building Tool, för att förenkla processen, skapa mer värde och förbättra kommunikationen.  

Läs också: Säkerhet ett fortsatt säkert kort hos Google


Vad är DBT (Data Building Tool)?
 

DBT är ett open-source verktyg, eller ett transformeringsverktyg, som möter behoven från både utveckling och verksamhet. Det gör det lättare att förstå helheten av hur den övergripande arkitekturen ser ut. Dessutom kan en förstå alla data-set på ett bra sätt, samt förstå hur koden är uppbyggd. Du kan helt enkelt se hur olika delar påverkar och påverkas.  

Eftersom vi ofta arbetar med multidiciplinära team använder vi DBT för att tillsammans lösa hur vi ska transformera datan. När vi på Forefront Consulting använder GCP (Google Cloud Platform) som molnplattform laddar vi in datan (ofta med GCPs verktyg) till BigQuery, ett Data Warehouse från Google. Sedan modellerar vi datan med DBT inne i BiqQuery.  

DBT är designat för att lösa transformeringen i ett ETL (Extract Transform Load) flöde. Nedan är en skiss på hur ett DBT fungerar, och hur den senare kommer in i verksamheten via BI verktyg.  

Bildkälla: Github

Hos min tidigare nämnda kund brukade vi modellera datan i en Data Lake i stället för i ett Data Warehouse. Du behövde alltså kunna läsa och förstå koden för att förstå datan. Det var bland annat därför endast Data Engineers kunde vara med och utveckla, och allt arbete lades på dem. Med DBT på plats så spreds kunskaperna ut, och nu kunde äntligen Dataanalytiker och verksamheten arbeta tillsammans med Data Engineers – på riktigt. Idag bygger vi dataprodukter som är bättre kopplat till verksamheten än någonsin tidigare.  

  

Fem starka fördelar med DBT 

Det finns flera fördelar med att använda DBT i projekt där Data Engineers och verksamhet möts: 

  1. Det är lätt att använda och förstå datan för andra team än det faktiska datateamet.  
  2. Du får en bra översikt för datan: du kan bygga en datakatalog på en webbsida och se hur ser hur datan mellan olika data-set flödar 
  3. Enkelt att använda bra Software Engineering Practices, exempelvis modulär kod, versionshantering, automatiserad testning, continuous integration/continuous deployment (CI/CD) 
  4. Det är enkelt att återanvända och bygga modulär kod med Jinja. 
  5. Det är smidigt att bygga och ändra datamodeller eftersom ett DBT är kodbaserat, utvecklingsvänligt och gör att utvecklingen blir snabbrörlig och effektiv. 

 

Dela i dina sociala kanaler

Sebastian Ljungberg
Sebastian LjungbergData Engineer