Etl står för extract, transform and load, alltså att extrahera, transformera och ladda data. Kanske kan man säga ”datatvätt” på svenska. Vad man än kallar arbetsuppgiften så är den ofta en nyckelaktivitet för att lyckas med dataanalys.

Det handlar om att jämka samman datakällor med olika struktur, vilket kan inkludera att aggregera data, och om att kontrollera och åtgärda datas kvalitet och slutligen att fysiskt få över data till lämpliga ställen för att göra analyser. Etl har utvecklats i takt med att relationsdatabaser och datalager (data warehouse) har vuxit fram och sedan länge varit etablerade tekniker på företag.

Källa: gigile
Källa: gigile


Men etl är viktigt också när nosql-databaser och datasjöar blir mer populära. En grundtanke med båda dessa lösningar är att man ska slippa bry sig så mycket om tvingande strukturer för hur data ska organiseras. Men någon typ av organisation av data krävs i stort sett alltid. Och arbetet med att kontrollera och åtgärda datakvalitet, eller med att överföra data försvinner inte heller.

Läs mer: Amazon brassar på med molnvariant av MySQL

Två grundproblem med etl är att det är en tids- och kompetenskrävande aktivitet. Det finns för få personer, som har ont om tid, som klarar av göra jobbet. Och tyvärr bidrar inte visuella verktyg till att förenkla på det sätt de borde, tycker Infoworlds krönikör Theo Vassilakis. Han är till vardags vd på big data-företaget Metanautix. Han kan naturligtvis misstänkas för att tala i egen sak, men lyfter ändå fram flera intressanta synpunkter i en krönika på Infoworld.

Han pekar ut det grundläggande problemet att det är svårt att förstå, underhålla, söka i och resonera om stora diagram med många pilar och rutor. Han tycker att det är lättare med textbaserade beskrivningar. Dessutom skapar många leverantörer egna lösningar för användargränssnitt. Det krävs alltså verktygspecifik kompetens, förutom ett fast grepp om databasteori i allmänhet.

Vassilakis pekar ut det väl etablerade språket sql, se faktaruta, som ett alternativ. Han tycker att det är lättare att förstå etl-beskrivningar gjorda i sql än de som görs med visuella verktyg. Och det gäller enligt honom speciellt för mer komplexa definitioner.

Läs mer: Navelskådande präglar datahantering

En tänkbar mellanväg kan kanske vara att förbättra hanteringen av sql-mallar för att skapa etl-lösningar. Det kanske fungerar att ha ett visuellt verktyg för att hantera och använda mallar, för att sedan definiera detaljerna genom att skriva sql-kod.

En annan alternativ väg, speciellt i nosql-sammanhang, är att använda något mer generellt språk, som Java eller Javascript. Och det görs ofta, till exempel för att skapa big data-lösningar med Hadoop.

En sak är i alla fall klar: Analyser av stora datamängder, från allt fler olika datakällor, lär bli allt vanligare. Det innebär att tid behöver läggas på etl-arbetet. Frågan är hur det arbetet ska utföras, med visuella verktyg eller genom att skriva programkod i sql eller i något annat språk.

Fakta

Sql uttyds oftast Structured Query Language. Det är det mest använda språket för att definiera, manipulera och söka i databaser. Många leverantörer av relationsdatabaser håller sig till en något så när standardiserad kärna av sql, för att sedan fylla på med egna tillägg.