Mellan ert datateam och insikter behöver data transformeras, tvättas och kvalitetssäkras. Den uppgiften – mitt emellan datateam och analytiker – har länge saknat en tydlig ägare.
Som ett svar på detta problem har Analytics Engineering växt fram som en roll, och dbt som ett populärt verktyg. Här går vi igenom bägge två.
De senaste åren har många investerat tungt i sin data- och analyskapacitet. Data Engineers har anställt eller hyrts in, data pipelines har satts upp, data warehouses och datasjöar har fyllts med stora mängder data.
Alla har gjort sitt jobb. Nu har vi äntligen fått in datat. Koppla på något visualiseringsgräsnssnitt (Tableau verkar populärt) och börja analysera! Nu blir vi datadrivna! Nja, inte riktigt.
Resan mot den datadrivna, experimenterande och alltid lärande framtid som många företag drömmer om fastnar idag ofta mellan datateamet och konsumenterna (data analysts/scientists/datadrivna produkter).
Innan ert data är användbart för beslutsfattare, produkter och analyssugna anställda så behöver det i nästan alla intressanta fall transformeras och tvättas några gånger till. Det behöver anpassas till sin kontext, tillgängliggöras och kvalitetsäkras för att kunna skapa värde.
Utmaningar med hur vi jobbar med data idag
Rådata är inte redo att analyseras
För att göra vett av all det data ni sitter och trycker på behöver det tvättas, berikas och sammanställas. Denna uppgift läggs ofta på Data Engineers, men det blir snabbt uppenbart att detta inte genererar särskilt mycket värde per krona. De är lite för långt ifrån affären och träffar ofta bara halvrätt med aggregaten de tar fram. Alltid verkar det vara någon dimension eller mätetal som saknas. När ert data engineering-team redan har fullt upp börjar nu produktägare, analytiker, data scientists och andra ställa frågor som ert data ännu inte är redo att besvara.
Fråga: Ge mig alla användare som lämnat tjänsten senaste månaden.
Svar: Finns i (data)sjön.
Datatvätt är en stor tidstjuv
Det börjar nästan bli en truism att 80% av arbetstiden för en dataanalytiker/scientist går åt till att felsöka och tvätta data. Om det inte stämmer för er just nu så är risken stor att ni sitter med ett härke av schemalagda jobb som satts upp för att släcka akuta analysbränder och sedan ligger kvar. När något vill läggas till, ändras eller förklaras är det bara att hoppa ner i den algblommiga datasjön.
Genvägar blir senvägar
Det finns en uppsjö av vägar och verktyg för få mer effekt och kvalitet på sitt data. Som med mycket annat spelar vägvalen roll i er nuvarande och framförallt framtida förmåga att leverera värde. Det är en balansgång mellan snabbt värdeskapande hack och långsiktigt skalbara lösningar.
Helt riktigt börjar många med att investera i att fylla sina dataplattformar med data. Därefter förlitar man sig på att något hyfsat kraftfullt visualiseringsgränssnitt ska göra jobbet för att utvinna insikterna. Tyvärr blir så sällan fallet.
Många gånger uppstår interna slitningar mellan en verksamhet som vill ha insikter helst igår och datateam som vill bygga stabilt och skalbart.
I frustrationen av väntan börjar mer eller mindre data- och kontextkunniga personer lösa problem på sina egna sätt. Det sätts upp egna snurror, schemalagda jobb och aggregat både här och där runt ert data.
Det är en fantastisk insats som skapar bra med värde på kort sikt. Tyvärr kommer det med en kostnad på längre sikt. Nu sitter ni med utspritt, osammanhängande data som säger olika saker beroende på vem du frågar. Dessutom skapas ett personberoende där några få personer vet hur olika mätetal har hackats fram.
Så borde det såklart inte vara. Naturligtvis har detta varit ett hett diskuterat ämne bland datanördar de senaste åren.
Från Data Engineering till Analytics Engineering
Okej, så vi behöver hitta mer effektiva sätt att transformera vårt data så att fler kan använda det. Vi behöver dessutom göra det på ett stabilt och skalbart sätt. Hur gör vi då?
En lösning många vänder sig till är titta på hur liknande problem lösts inom traditionell utveckling. De flesta analytiker kan tillräckligt med SQL för att self serva de mest komplexa frågor.
Grundstenarna för att demokratisera data:
- Relevant och kontextanpassat
- Tillgängligt när affärskritiska beslut ska fattas
- Kvalitetssäkrat
- Sammanhängande och transparent över organisationen
Det är helt rätt att ta en lean approach och i vissa fall bygga snabba lösningar före skalbara modeller. Att helt ta bort snabba experiment är absolut inte vägen framåt. Nya idéer på mätpunkter och analyser ska självklart uppmuntras. Men så fort ni ser värde blir de två senare punkterna ovan kritiska för att möjliggöra återkommande värde på längre sikt.
Vill ni höra mer om hur ni sätter grundstenarna för att demokratisera ert data? Sajna upp på vårt webinar!
Kvalitet skapar tillit
Utan kvalitet på ert data tappas snabbt tilliten. Den blöta filten på ert datadrivna momentum är jobbig att få ogjord. Analytics engineering ser till att datat som ligger till grund för era rapporter, dashboards, analyser och machine learning är korrekt och kvalitetsäkrad.
Samarbeta för sammanhängande data
En analytics engineer samarbetar med både data engineers, scientists och analytiker på olika sätt. Med datateamet kan problem rörande infrastruktur och vilken data som samlas in diskuteras och optimeras. Med scientists och analytiker pushas hela tiden datats förmåga att driva affären framåt. Mer eller mindre tillsammans jobbar dessa två roller/funktioner för att kvalitetssäkra och finjustera transformationen av datat.
Ihop med data scientists och analytiker jobbar en analytics engineer för att översätta behov av datamodellering till best practices från mjukvarutveckling. Utöver det vill man hitta effektiviseringar i form av verktyg och gränssnitt för analytiker kan fokusera på värdeskapande insiktsjagande.
Du vill inte vara i sitsen där samma mätpunkt visas olika beroende på vem i organisationen du frågar. För att få sammanhängande data behöver ni samarbeta över organisationen. Genom att applicera det bästa i hur vi samarbetar inom ”vanlig” produktutveckling tas steg mot demokratiseringen av ert data och snabbare insikter.
Ett verktyg som täcker in och underlättar stora delar av luckorna analytics engineering vill lösa är dbt (data build tool). Flera av Significs kunder och (bolag som Hubspot, Gitlab och The Telegraph m.fl) använder sig av dbt.
dbt. Huh? Yeah. What is it good for?
Dbt är utvecklat av Fishtown Analytics och har de senaste 2-3 åren vuxit fram som det nya, heta inom det vi kallar analytics engineering. Vi på Signific som använt det kan bara stämma in i hyllningskören.
Den huvudsakliga funktionen av dbt är att ta kod, kompilera det till SQL och köra det mot er databas. Det låter i sig rätt basic, men det är mer till det.
Dbt tar ett närmast helhetsgrepp på T:et i ETL. Med dbt kan företag sätta upp transformationen av sitt data med queries. Därtill orkestreras flödet av queries på ett väldigt smidigt sätt. Det är ett relativt nytt verktyg, men över 300 företag (och flera Signific-kunder) drar redan nu nytta av fördelarna och möjligheterna dbt ger.
Testbar, versionshanterad och dokumenterad transformation
Något av det finaste med dbt är hur lätt det är att hantera transformationen som en riktigt produkt.
Med dbt’s så kallade models kan ni dela upp era jobb i en tydlig struktur. Hela er uppsättning versionshanteras som en vanlig kodbas. Det gör det mycket mer överskådligt och lättare att samarbeta än utspridda jobb och hacks som ofta är första lösningen.
Dbt erbjuder också möjligheter att sätta upp tester på ert transformationsflöde. När affärskritiska beslut ska fattas vill du vara säker på att datat knådats korrekt. När dashboarden eller grafen i presentationen visar felaktigt data är det redan försent. Dbt erbjuder färdiga tester för både ert schema och ett enkelt sätt att sätta upp mer konkreta datatester.
Strukturen och versionshanteringen skapar en mycket tydligare dokumentation över vad som finns och vad som gjort (om man sätter upp det rätt). En annan fin feature dbt erbjuder är att kunna generera en visualisering av ert transformationsflöde.
Samarbeta med SQL som gränssnitt
I och med att dbt bygger på att sätta upp SQL:er för er transformation minskas barriärer för samarbeten mellan datateam och övriga. SQL är något många analytiker och data scientists kan och så även utvecklare. Åtminstone till en grad där ni kan börja samarbeta, dela kunskap och bygga ihop.
Kraftfullt med er cloud platform
Som en användare av dbt fokuserar du främst på att bygga modeller (skriva queries) för att göra den transformation som passar ert data och affär. Du slipper skriva boilerplate-kod för att skapa tabeller och vyer. Även ordningen av exekveringen av era modeller löser dbt åt er.
Dbt tar era modeller och lägger det som objekt i ert data warehouse. Enkelheten och strukturen utan att tumma på kraften och skalbarheten ni får i molnet. Vi har själva främst kört dbt mot Google Cloud Platform och Big Query, men stöd finns även för Snowflake, Redshift, Postgres m.fl
Open Source
Som grädde på moset är dbt också open source. Det är alltså gratis att komma igång, men också lättillgängligt och ständigt utvecklande av Fishtown och andra contributors. Som sagt börjar allt fler bolag flytta över delar av sin transformation till dbt redan nu. Med allt fler användare och ett livligt community finns det fog för att tro att dbt är här för att stanna.
Nackdelar och alternativ
Självklart är dbt inte lösningen på alla era dataproblem. Det finns både nackdelar och andra alternativ.
Att det är SQL-baserat är i många fall en fördel, men kräver trots allt en relativt bra kunskap om just SQL för att lyckas. Även kunskaper om source control behövs för att få det att lira. Verktyg som Lookers PDT och Tableau möjliggör till viss del icke-SQL-kunniga att sätta upp delar av er transformation.
Det täcker också bara in T:et (Transformationen) i ETL. Ni behöver andra lösningar för både att extrahera och ladda in ert data ni knådat klart. Andra bolag och open source-alternativ börjar ploppa upp öven inom E:et och L:et, men dbt är inte ett av dom. Airbyte och Hightouch är två alternativ vi testar just nu, men det finns nästan lika många alternativ som det finns datahungriga bolag. Släng iväg ett mail till max@signific.se, på Linkedin eller kolla på vårt webinar!
Sugen på att prata mer om att demokratisera data, dbt eller något annat?