Vad är ETL i QlikView ?

ETL - Extract Transform Load i QlikViewETL handlar om att göra om rådata för att skapa data att agera på – i vårt fall att göra data redo att använda i QlikView.  Förkortningen ETL står för Extract (extrahera), Transform (omvandla) och Load (ladda).

När vi läser information från olika datakällor gäller det framförallt att få all data att ”prata samma språk”.

Den första delen av ETL-processen innebär att extrahera data från olika källsystem. Traditionellt är denna fas den mest utmanande aspekten av ETL eftersom att extrahera data på rätt sätt lägger grunden för alla efterföljande processer. För att komma ifrån den här problematiken brukar ett normalt QlikView-projekt läsa ut all data ur källsystemen. På så sätt får utvecklaren kontroll på hela datamängden och all datareducering sker istället i nästa steg – transform eller omvandlingen.

Transform betyder i vårt fall att göra om data så att den blir lättanvänd i QlikView. Data från skilda system benämner ofta samma sak på olika sätt och därför är ett av de viktigaste stegen i transform-steget att få den extraherade data att ”prata samma språk”. För att åstadkomma det lägger vi på ett antal affärsregler. Det kan exempelvis handla om att ensa en kontoplan för att matcha koncernredovisningen, översätta till konsekvent valutahantering eller att reducera data till en gemensam lägstanivå.

Vissa datakällor kommer att kräva mycket lite eller ingen manipulation av data. I andra fall kan en eller flera omvandlingar krävas. Omvandlingen är också ett viktigt sätt att tydliggöra data för att längre fram i projektet kunna använda samma utlästa data för andra delar av QlikView-utvecklingen.

ETL-processen sista steg är att ladda rätt data till rätt applikation/tillämpning. Normalt har ett företag flera olika QlikView-applikationer och oftast behöver inte all tillgänglig data användas i alla applikationer. Genom att endast använda nödvändig data optimeras prestanda och belastning på serverar minimeras.

ETL i praktiken

Rent praktiskt betyder ETL en likformighet i projekten. Det blir enkelt för såväl kunden som andra utvecklare att komma in i ett projekt och förstå vad som är gjort. I projektets första fas har det här kanske mindre betydelse, den stora utväxlingen får man i efterföljande utveckling när projektet går in i sin nästa utvecklingsfas.

Det som är viktigt är att dataflödet är automatiserat och att det är dokumenterat. Mycket av det som nämns som fördelar med ETL är egentligen inte unikt för ELT, men att arbeta med ETL tvingar alla inblandade att jobba på ett liknande sätt. ETL är den främsta anledningen att vi numera jobbar på konsekvent i såväl stora och små projekt. Vi ser också rent erfarenhetsmässigt att ETL leder till bättre dokumenterade projekt av en enkel anledning – när projekten följer samma mall blir det både transparent och lite pinsamt att inte dokumentera datatransformeringen.

Automatisering är inget unikt för ETL, men just att ha en standardisering av databearbetningen gör att vi kan optimera laddningen på ett sätt som är lite svår när man läser in all data direkt. Om man tittar på bemanningsföretaget (där vi jobbar där vi har en mycket stor ETL-struktur) kan vi nu välja med vilken frekvens olika datakällor ska läsas in. Den data som kommer från ekonomisystemet (där det sker kontinuerlig förändring) läser vi in data 1-2 gånger per dag. Datakällor som sällan förändras (som budget och prognos) läses in en gång per månad under en viss del av året. Det här betyder att vi får snabbare laddtider eftersom vi läser från QlikViews interna lagringsformat och det går alltid snabbare än att läsa från någon annan datakälla. Det beror på att läsningen från qvd:er är mycket optimerad.

Datakvalitet är som vänner på facebook

Det som är viktigt i den här dataprepareringen – när exempelvis två skilda analyser läser information från samma källa så måste affärslogiken för transformering vara en och samma – annars riskerar analysen mynna ut i att siffror som borde vara samma helt plötsligt diffar. Att siffrorna skiljer några procent är kanske i praktiken inte allt för besvärande, men den här typen av fel leder ofta till att tilltron till informationen sviktar vilket i förlängningen leder till minskad användning av viktiga analyser och rapporter.

Att försöka lansera ett system med bristande datakvalitet är dömt att misslyckas. Ett beslutsstöd med bristande datakvalitet är lika värdelöst som ett Facebook utan vänner. Det här är en av mycket viktig anledning att jobba med ETL. Datakvalitet är A och O inom B och I.

QlikView – som ETL fast tvärt om

Det traditionella QlikView-sättet att arbeta med data har alltid varit ETL – fast tvärt om. För inte allt för länge sedan var markandsbudskapet ungefär så här:

– Det behövs inget datalager, det är bara att läsa in data ni har i QlikView och börja analyser med en gång…

Inget kan vara mera fel. Det enda som är korrekta i det här påståendet handlar om skapa snabb licensförsäljning (vilket ju i ärlighetens namn är ett sunt och riktigt mål för den som säljer just licenser). Men för att skapa en långsiktig BI-lösning behövs den struktur som traditionella Business Intelligence-verktyg jobbat med i många år. Det behövs en genomtänkt struktur för att skapa en bra plattform för kvalificerat beslutsstöd – speciellt i företag där samma datakälla används på olika sätt.

Lösningarna går nu allt mer ifrån små, snabba analyser av ett enstaka system till mer komplexa datalager där företagets data ses och används mer som en helhet. Den typen av snabb analys där information bara läses in och analyseras är inte längre det allena saliggörande. Idag handlar det ofta om större lösningar och där krävs alltid en bra struktur för att säkra kvalitet och för att möjliggöra vidareutveckling.

Det här med struktur är något som analytiker och belackare använt när de kritiserat QlikView historiskt. Därför blev ETL något som började förordas av QlikTech för ett par år sedan. Det är en helt naturlig utveckling allt eftersom QlikView utvecklats till en allt mer ”enterprisemässig” produkt där exempelvis skalbarhet och klustring blir allt viktigare.

Med en genomarbetad ETL blir ett datalager i QlikView rent praktiskt likvärdigt stora, komplicerade och kostsamma lösningar. Visst finns det fall där en traditionellt datawarehouse-datalager är motiverat, men att praktiskt kunna dra nytta av den strukturerad data redan under projektutvecklingen är en central framgångsfaktor i varje BI-projekt.

Bild: Creative Commons Michael Mandiberg Andra om ETL CIO Sweden

Share on LinkedInTweet about this on TwitterShare on Google+Share on FacebookEmail this to someone

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *