ETL-verktyg för datavaruhus

Transkript

1 Examensarbete vid institutionen för datavetenskap Umeå Universitet Författare: Johan Unger Handledare: Tommy Jakobsen (ABB Power Technology Products AB) Johan Karlsson (Umeå Universitet) Datum måndag den 21 januari 2002

2 Sammanfattning Detta examensarbete har huvudsakligen bestått av tre delar: 1. Studie av datavaruhus med fokusering på ETL (Extraction, Transformation & Loading). 2. Teoretisk jämförelse, analys och val av ETL-verktyg (PowerMart eller DTS). 3. Design och implementation av datavaruhus och ETL-processer, samt framtagande av gränssnitt för rapporter och analyser. Arbetet inleddes med en teoretisk studie av datavaruhus och ETL. Från de kunskaper som inhämtades under denna studie och de direkta behov som identifierades på ABB, utvecklades en metod för analysera ETL-verktyg. Metoden bestod av ett antal mätparametrar, som beskrev behoven för laddningen av datavaruhuset, vilka möjliggjorde en analys av verktygen. Valet av ETL-verktyg stod mellan Informatica PowerMart och Microsoft DTS och efter jämförelsen valdes DTS. Efter detta val satte utvecklingen av datavaruhus och ETL igång. Datavaruhuset utvecklades i Microsoft SQL Server 2000 och när datavaruhuset stod färdigt användes Crytsal Report för rapportgenering och Excel 2000 som analysverktyg mot datavaruhuset. Idag finns en testmiljö för datavaruhuset uppe på ABB. Användare kan via ABBs intranät erhålla rapporter och med hjälp av Excel 2000 utföra analyser på data från datavaruhuset.

3 Abstract This master thesis consists of three major parts. 1. Study of data warehouse and ETL (Extraction, Transformation and Loading) 2. Theoretical comparison, analysis and selection of one ETL-tool (PowerMart or DTS). 3. Design and implementation of a data warehouse and ETL-processes, with development of interfaces for reports and analysis. The work started with a theoretical study of data warehouses and ETL. From the knowledge acquired from the study and the direct requirements identified on ABB, a method to analyse ETL-tools was developed. The method contained a number of parameters that described the requirements for the loading of the data warehouse, which made it possible to examine the tools. The choice of ETL-tool stood between Informatica PowerMart and Microsoft DTS and when the analysis was finished the choice fell on DTS. When the choice was made the development of the data warehouse and ETL started. The data warehouse was implemented with Microsoft SQL Server 2000 and when the data warehouse was up, Crystal Report was used to make reports out of the data and Microsoft Excel 2000 was used to analyse the data in the data warehouse. Today there s a working test environment on ABB. Users can through ABB s Intranet obtain reports and with Excel 2000 analyse data from the data warehouse.

4 1 INLEDNING BAKGRUND PROBLEMBESKRIVNING SYFTE OCH MÅL AVGRÄNSNINGAR 4 2 METOD INLEDNING DATAVARUHUS VARFÖR BEHÖVS DATAVARUHUS? DIMENSIONELLA DATABASER STJÄRNMODELLEN DATAFLÖDET ETL ETLS UPPGIFTER FAKTORER SOM PÅVERKAR ETL ANGREPPSSÄTT FÖR ETL JÄMFÖRELSEMETOD IDENTIFIERA BEHOV DEFINIERA OCH VIKTA PARAMETRAR GRUPPERING AV PARAMETER BETYGSSYSTEM BERÄKNING AV PARAMETERGRUPPS BETYG ANALYS AV JÄMFÖRELSEMETODEN RISKER MED JÄMFÖRELSEMETODEN 21 3 ANALYS AV ETL-VERKTYG NULÄGESANALYS FÖR ABB VAL AV PARAMETRAR ANSLUTNINGSMÖJLIGHETER (GRUPP 1) LADDNINGSFUNKTIONALITET (GRUPP 2) ANVÄNDARVÄNLIGHET (GRUPP 3) ADMINISTRATION OCH DRIFT (GRUPP 4) KOSTNADER (GRUPP 5) POWERMART ÖVERBLICK PARAMETRAR DTS ÖVERBLICK PARAMETRAR SAMMANFATTNING AV JÄMFÖRELSEN SLUTSATS 44

5 4 GENOMFÖRANDE BASLAGRET LADDNING AV BASLAGER ANALYSLAGRET LADDNING AV ANALYSLAGRET KONFIGURATION AV DTS OLAP-KUBER ANVÄNDARGRÄNSSNITT FÖR OLAP-KUBER ANVÄNDARGRÄNSSNITT FÖR RAPPORTER 54 5 RESULTAT OCH FRAMTID 55 6 TACK 56 7 ORDLISTA 57 8 KÄLLFÖRTECKNING 58 2

6 1 Inledning 1.1 Bakgrund Det här examensarbetet utförs på ABB Power Technology Products AB under Business Area Unit (BAU) Transformers i Ludvika. ABB PTP tillverkar högspänningsprodukter och ingår i den globala teknikkoncernen ABB. Huvudkontoret för ABB ligger i Zürich, Schweiz och antal anställda är ca personer i över 100 länder. Antal anställda i Sverige är strax under och på BAU-enheten Transformers arbetar ca 500 personer. Transformers ansvarar för försäljning och tillverkning av krafttransformatorer och shuntreaktorer. Vi lever idag i ett informationssamhälle där information samlas och distribueras i snabb takt. Företag är i ständigt behov av analyser och rapporter som bygger på data och information som företaget på olika sätt har tillgång till. Informationen ligger ofta i företagets affärssystem och kan ibland vara spridd över flera heterogena system. Ett behov finns alltså att sammanföra informationen i företaget och strukturera den, för att senare kunna utföra analyser på det insamlade materialet. Det är detta behov som har skapat begreppet Data Warehousing. Ett datavaruhus (Data Warehouse) är ett system som kan hämta data från olika källor, sammanföra det på ett strukturerat sätt som möjliggör att analyser av den insamlade information kan utföras med enkelhet. För att ladda ett datavaruhus behövs ett verktyg som samlar in, bearbetar och slutligen laddar datan till datavaruhuset. ETL-verktyg (Extraction, Transformation, Loading) är ett samlingsbegrepp för dessa verktyg. 1.2 Problembeskrivning ABB PTP Transformer (PTTFO) lagrar idag det mesta av sin information i affärssystemet BaaN. BaaN är ett ERP-system (Enterprise Resource Planning) som används genom hela produktionen, från beställning av råvaror till försäljning till kund. En sak som kännetecknar ett ERP-system är att det är avsett för att lagra information, det är inte direkt anpassat för att visa och analysera sitt data. Det är pga denna begränsning som behovet av ett nytt system föddes, ett system från vilket man kan producera rapporter och genomföra analyser. Det man eftersöker är alltså ett datavaruhus inleddes ett datavaruhusprojekt kallat Business Intelligence System (BIS) Data Warehouse på ABB. Man beslutade sig för att använda Microsoft SQL Server 7.0 (MS SQL 7.0) för själva datavaruhuset och en produkt av BaaN som heter Broadbase som ETL-verktyg. På grund av omprioriteringar och att kompetensen på Broadbase försvann från ABB lades projektet på is hösten Under sommaren 2001 fick projektet ny vind i seglen, men nu visste man inte vilket ETL-verktyg som skulle användas. Två kandidater kom upp, Microsofts Data Transformation Service (DTS) och Informaticas PowerMart. 3

7 1.3 Syfte och mål Syftet med detta examensarbete är att få klarhet i vilket av ETL-verktygen Microsoft DTS och Informatica PowerMart som är lämpligast att använda i ABBs datavaruhuslösning. När ett val av verktygen kan göras ska datavaruhuset designas och implementeras i Microsoft SQL Server Även prototyper av användargränssnitt för rapporter och analyser ska tas fram. Det som skall uppnås med detta examensarbete är alltså följande: Ett val av ETL-verktygen DTS och PowerMart skall göras efter en jämförelse av hur de lämpar sig för ABBs situation. Datavaruhuset med tillhörande laddningsrutiner skall designas och utvecklas så att det passar för rapportering och analysering av data. Ett förslag på användargränssnitt skall tas fram, där användare från sin arbetsstation kan ta fram rapporter och analysera datan. 1.4 Avgränsningar Även fast detta datavaruhus ska kunna hantera data från flera olika avdelningar kommer endast inköpsdata att tas med i detta projekt. Denna avgränsning görs för att datamängden inte ska bli för stor och för att se att lösningen håller hela vägen, från BaaN till slutanvändare. Dock måste hänsyn tas till att data från andra avdelningar ska kunna tillföras senare. 4

8 2 Metod 2.1 Inledning Eftersom detta examensarbete inleddes med en teoretisk jämförelse började jag med att söka litteratur som behandlar datavaruhus och ETL-verktyg. Jag bestämde mig för några böcker som jag tyckte gav ett seriöst intryck och där författaren har god erfarenhet av datavaruhus. För övrigt har Internet varit den stora källan för information och jag har försökt hålla mig till sidor som jag bedömt som trovärdiga. Förutom dessa två källor har jag dessutom haft tillgång till muntliga källor på ABB och produktdokumentation om ETL-verktygen från tillverkarna. För att genomföra en jämförelse av två ETL-verktyg måste man först förstå den miljö där de arbetar. Därför börjar jag i detta kapitel med att beskriva datavaruhus och du som läsare får lära dig vad de används till och de begrepp som används inom detta område. Efter det beskriver jag laddningen av datavaruhus och krav som av olika anledningar ställs på den. Kapitlet avslutas med en beskrivning av den jämförelsemetod jag utvecklat och använt för att jämföra de båda verktygen. 2.2 Datavaruhus Varför behövs datavaruhus? Företag är i ständigt behov av olika rapporter, sammanställningar och analyser. Det kan handla om lönsamhetsrapporter, sammanställningar av resultat och analyser av kundbeteende. Som tidigare nämnts så är ett datavaruhus en slags samlingsplats för företagsdata, från vilken analyser av datan kan göras på ett enkelt sätt. När datavaruhusen började dyka upp i början av 1990-talet menade man att ett datavaruhus skulle innehålla statisk historisk data samlad under en lång. Gupta [Gupta 1997] ger följande långa definition, fritt översatt: ett datavaruhus är en strukturerad utbyggbar miljö avsedd för analyser av ickeföränderlig data, logiskt och fysiskt transformerad från flera källor för att passa företagsstrukturen, uppdaterad och underhållen under en lång tid, uttryckt i enkla företagstermer och summerad för analyser. Varför behövs nu ett datavaruhus för att analysera data? Datan finns ju redan i företagets olika system, går den inte att analyser därifrån direkt? För att svara på den frågan varför datavaruhus behövs så måste vi titta lite närmare på de system där data ofta ligger lagrat, sk affärssystem. Typiskt för affärssystem är att de är designade för registrering av data med bra stöd för transaktioner, såsom orderbehandling, inventarieföränderingar, och inmatning av data om personal. Flera transaktioner kan utföras samtidigt då dessa system ofta används av flera användare samtidigt. Vanligt är också att data i dessa system ligger lagrat i någon relationsdatabas som är normaliserad till någon nivå. Det som görs med en databas som normaliseras är i grova drag att data delas upp i flera tabeller i stället för att all data ligger i en och samma tabell. Mellan tabellerna finns referenser som gör det möjligt att slå samman tabellerna för att 5

9 utläsa data. Normalisering av databaser görs för att minska utrymmet för att lagra data och få konsistens i systemet [Elmasri 2000]. Affärssystemen rensas regelbundet på data när transaktioner inte längre är aktuella, för att hålla datavolymerna nere vilket i sin tur höjer prestanda. Vi kan sammanfatta de karaktäristiska dragen för ett affärssystem med följande punkter: Data är ofta lagrat i en relationsdatabas. Normalisering utnyttjas i någon grad för utrymmesbesparing och konsistens. Transaktioner utförs snabbt och över en liten datamängd. Flera transaktioner utförs samtidigt från olika terminaler. Lagrar dynamisk data som uppdateras dagligen. Gammal data töms regelbundet. Kort sagt kan man säga att affärssystem är avsedda för inmatning av data rörande företagets produktion på en detaljerad nivå, men för analyser ska vi nu se att det behövs ett annat system. Ett företag har sällan all sin data lagrad i ett enda system, utan ofta används flera olika system för olika uppgifter. Det kan handla om allt från stora affärssystem till mindre specifika databaser för lokala lösningar. För att utföra analyser av data från flera heterogena system måste datan sammanföras till en homogen plats. Om man dessutom vill analysera trender över flera år så måste data finnas lagrad för flera år, vilket det vanligtvis inte finns i affärssystem. Detta medför att stora datamängder måste lagras i systemet vilket i sin tur medför att man måste tänka på prestanda när det gäller svarstider. En person som arbetar med en analys tappar lätt bort sig om han eller hon måste vänta länge på att få fram resultaten. Normaliserade databaser kan innebära längre svarstider eftersom sammanslagning av tabeller kan behövas. För att få ner svarstiderna kan det bli aktuellt att denormalisera datastrukturen, alltså minska antalet tabeller. På detta sätt kan antalet sammanslagningar av tabeller minska vilket ger bättre prestanda på svarstider. De karaktäristiska dragen för ett system avsett för analyser är: Flexibel datamodell för flexibla analyser. Denormaliserat för optimering av frågor. Innehåller stora datamängder, data som sträcker över flera år. Sammanför heterogen data till en plats vilket möjliggör analyser av den. Statisk data som ej ändras av användaren. Detta system är kort sagt ett system där data är anpassat för att presenteras och analyseras, jämfört med ett affärssystemet där informationen registreras. På grund av dessa skillnader mellan de behov som finns av analyser och den datastruktur där data ligger lagrat så behövs datavaruhusen. En ytterligare anledning till att placera data för analyser i ett annat system är för att minska påfrestningarna på affärssystemen. En analys av data över flera år skapar en fråga mot databasen som kan ta lång tid att beräkna och detta kan göra att affärssystemens prestanda sänks, vilket i de flesta fall inte är önskvärt. 6

10 Under de senaste åren har idéerna kring datavaruhus förändrats. I den ursprungliga idén menade man att data i ett datavaruhus var statisk och inte gick att ändra när den väl var där. Gupta [Gupta 1997] menar att det är näst intill omöjligt att underhålla dynamisk data i ett datavaruhus och att alla data måste vara statisk. Detta är något man frångått på senare år och flera bl a Kimball [Kimball 1998] menar att ett datavaruhus måste kunna uppdateras. Om en leverantör t ex byter adress så måste denna förändring även slå igenom i datavaruhuset, vilket kan te sig ganska naturligt Dimensionella databaser Dimensionella databaserna, även kallade OLAP-databaser (On-line Analysis Processing), har med tiden blivit populär för att lagra data i ett datavaruhus. OLAP definierades i tolv punkter av E.F Codd 1993, och 1995 kompletterade han dem med ytterligare sex punkter [Pendse 2001]. Anledningen till OLAPdatabasens popularitet är att den ger användaren en intuitiv bild av hur data är organiserat, vilket underlättar analyser av data. Databasen ger även god prestanda när det gäller svarstider för frågor mot datan jämfört med en normaliserad relationsdatabas. Logiskt brukar OLAP-databaser representeras med hjälp av sk OLAP-kuber. En geometrisk kub har tre dimensioner, men en OLAP-kub kan ha fler. Nedan ser vi ett exempel på en OLAP-kub för ett bilföretag med tre dimensioner som p g a att den just består av tre dimensioner kan representeras med en geometrisk kub. Bild 1: Exempel på OLAP-kub. 7

11 Dimensioner och fakta är två viktiga begrepp när vi talar om OLAP-kuber. Fakta är själva datan vi vill analysera och dimensionerna, axlarna i kuben, är de sätt vi vill analysera datan på. OLAP-kuben är indelad i celler där datan (fakta) ligger lagrad, som i detta fall är antal sålda bilar. Dimensionerna i kuben motsvarar de olika grupperingssätten som datan kan grupperas och summeras efter. Kuben ovan är tänkt att analysera bilförsäljningen i antal bilar över tidsperioden januari till mars Bilföretaget säljer tre bilmodeller (A, B och C) i tre affärer (Stockholm, Göteborg och Umeå). Bilmodeller och försäljningsort (affär) anses som lämpliga grupperingar och passar därför som dimensioner. En tredje dimension som är med i denna kub är tid. Tiden anger när bilarna såldes och ger möjlighet att gruppera bilförsäljningen tidsmässigt. Dessa tre dimensioner ger möjlighet att gruppera och summera datan i cellerna och de kan kombineras för önskad analys. Det totala antalet bilar som sålts under det första kvartalet 2001 är summan av alla celler vilket är 315 st ( ). Utifrån denna totalsumma kan vi arbeta oss ner till en mer detaljerad nivå genom att gruppera kuben med hjälp av de olika dimensioner. Man kan se det som att man skär ut ett snitt ur kuben och får på det viset informationen grupperad efter dimensionen. Om vi t ex analyserar datan med hjälp av modelldimensionen ser vi att för modell B, som är en medlem i modelldimensionen, är summan av cellerna i det snittet 205 st ( ). Modell B har alltså sålts i 205 exemplar under det första kvartalet Om vi fortsätter att skära ut delar ur kuben kan vi erhålla ännu mer detaljerad information. Vi lägger till affärsdimensionen och tittar bara på värden tillhörande dimensionsmedlemmen Umeå, alltså bilar av modell B som sålts i Umeå under det första kvartalet 2001, och ser att antalet blir 125 st (50+75). På detta sätt kan vi ställa komplicerade frågor till databasen och samtidigt ha en enkel och lättförståelig bild av databasen. Antalet celler som ingår i OLAP-kuben beror på hur dimensionerna är uppbyggda. Detta styr med vilken detaljrikedom fakta i kuben är lagrad. En dimension kan vara uppbyggd enligt en hierarki vars lägsta nivå bestämmer detaljrikedomen. En typisk dimension med hierarki är tidsdimensionen. Bild 2: Exempel på dimension för tid med hierarki. 8

12 Ett exempel på en tidsdimension med hierarki ses på bild 2 (denna hierarki syns ej i OLAP-kuben på bild 1). Hierarkin i denna dimension är i fallande ordning, alla, år, kvartal, och månad, vilket gör att den mest detaljerade nivån av fakta i kuben är månadsvis. För varje nivå kan datan summeras och beräknas i förhand vilket minskar svarstider för databasen. Dessa delsummeringar kallas för aggregat [Lupin 2001]. Den översta nivån, alla, består av en medlem som summerar all data i kuben. Analyseras kuben med tidsdimensionen på nivå alla erhålls en summa av all data i kuben. Nästa nivå, år, består av tre medlemmar, vilka representerar tre olika år. Datan i kuben kan högst tillhöra en medlem (år) och detta medför att fakta i kuben delas upp på dessa tre medlemmar. Ett exempel på tre medlemmar för nivån år kan vara 1999, 2000 och 2001, och väljer vi 1999 får vi de värden i kuben som tillhör 1999 summerade. Genom att gå ner genom en hierarki på detta sätt får vi mer och mer detaljerad information om datan i kuben. Att röra sig ner i en dimensionshierarki och på det sättet få mer detaljerad information kallas för att göra drill-down. Hierarkier i dimensioner kan byggas upp på olika sätt. En hierarki kan ha en eller flera rötter och kan vara balanserad eller obalanserad [Thomsen 1999]. Valet av struktur på hierarkin avgörs av hur dimensionen är uppbyggd i verkligheten Stjärnmodellen Det fysiska lagringssättet för en OLAP-databas håller fast vid relationsdatabaser, men med restriktionen att fakta organiseras och grupperas med hjälp av olika dimensioner. Fakta lagras i faktatabeller medan dimensioner definieras med dimensionstabeller och de samordnas i vad man brukar kalla en stjärnmodell. En stjärnmodell består av en faktatabell och en mängd dimensionstabeller. Bild 3: Stjärnmodell I faktatabellen ligger förutom själva värdet (fakta) också referenser till de dimensionstabeller som definierar värdet. De dimensionstabeller som refereras 9

13 från faktatabellen ger tillsammans varje värde en betydelse och dessa referenser utgör även den unika nyckeln för varje värde. Referenserna till dimensionstabellerna utgör alltså tillsammans primärnyckeln i faktatabellen. Primärnyckeln är det eller de attribut som unikt identifierar en tupel i databastabell. De värden som är lämpligast som fakta i en faktatabell är numeriska värden eftersom de går att addera. Det gör det möjligt att gruppera värden efter dimensionerna och på det sättet beräkna summor och medelvärden etc. Textdata lämpar sig inte eftersom det saknar denna egenskap. En dimensionstabell innehåller information om dimensionen och har en primärnyckel som unikt identifierar varje dimensionsmedlem (tupel). Övriga attribut i dimensionstabellen innehåller information om dimensionen och kan användas för att bygga upp hierarkier i dimensionen. Bild 4: Stjärnmodell för försäljningen för bilföretag. Bild 4 visar hur en stjärnmodell för OLAP-kuben på bild 1 skulle kunna se ut. Fakta, antal sålda bilar, ligger lagrat i faktatabellens attribut Antal och för varje värde finns referenser till tillhörande dimensionstabeller. Dimensionstabellerna innehåller, utöver primärnyckel, attribut som gör det möjligt att bygga upp hierarkier. Affärsdimensionsen innehåller fem attribut som gör det möjligt att geografiskt placera försäljningen på olika nivåer. En variant på stjärnmodellen är den så kallade snöflingemodellen (engelska: snowflake model). Denna modell bygger på stjärnmodellen, men minst en dimension har en tillhörande yttre dimension. Genom att använda sig av denna modell minskas dubbellagringen som uppkommer med hierarkier, men antalet sammanslagningar av tabeller ökar vid frågor med denna dimension [Kimball 1998]. 10

14 2.2.4 Dataflödet Nu när vi vet vad ett datavaruhus är och hur data är lagrat där så är det dags att titta på den miljö där datavaruhuset finns och hur data flödar från källa till slutanvändare. Nedan ser vi en enkel bild över hur data flödar genom ett system. Bild 5: Dataflöde från källor till datavaruhus och användarprogram. Informationen vi vill analyser finns lagrad i en eller flera datakällor. Dessa datakällor kan vara allt från enkla textfiler till mer komplicerade affärssystem. En typ av affärssystem som blir allt vanligare är sk ERP-system (Enterprise Resource Planning). ERP-system är affärssystem som bygger på en klientserver-lösning [Cox III, 1995] och de kan innehålla tusentals databastabeller. Exempel på ERP-system är SAP och BaaN. Andra typer av källor där informationen kan vara lagrad är databaser, kalkylark, e-post och Internetsidor. För att kunna sammanföra informationen från alla källor måste den ofta bearbetas. Den måste först extraheras ur källorna och sedan rensas och tvättas på olika sätt för att enkelt gå att analysera. Ett mellansteg där datan ligger efter extrahering kallas behandlingsarea (engelska: Staging Area). Det är här det mesta av transformeringen äger rum. Innan den laddas till datavaruhuset måste den omstruktureras så att den passar den struktur som används där, t ex en OLAP-databas. Denna process brukar delas in i tre steg och kallas för ETL (Extraction, Transformation, Loading) och program som sköter denna process kallas för ETL-verktyg. ETL behandlas i nästa kapitel ETL. När data är färdigbehandlat hamnar det så småningom i datavaruhuset. Datavaruhus brukar vara logiskt strukturerade efter de olika affärsområden som ingår i datavaruhuset. Ett sådan logiskt affärsområde kallas i datavaruhuset för ett data mart och kan t ex innehålla data från ekonomi- eller försäljningsavdelningen [Kimball 1998]. Viss data kan dock ingå i flera olika logiska affärsområden, det kan handla om information som är generell för hela företaget såsom personalinformation. Det sista steget i dataflödet är när informationen görs tillgänglig för användare. Användarna är personer som skall analysera informationen i datavaruhuset och de kan vara chefer och beslutsfattare. Dessa personer använder sig av olika program för att titta på och analysera informationen i datavaruhuset. Det finns en mängd olika applikationer för dessa ändamål, bl a rapportgeneratorer, OLAP-verktyg och data mining-verktyg. 11

15 2.3 ETL ETL är den processen som innefattar flyttning av data från källor till datavaruhus. Oftast är detta ingen enkel kopiering, utan omstrukturering och justering av data måste göras vilket gör att detta inte är någon liten och enkel uppgift. Upptill 70 procent av tiden i ett datavaruhusprojekt kan gå åt till ETL [Meyer 2001], och det är vanligt att företag avsätter mellan 40 till 70 procent av projektbudgeten till ETL [Allison 2001]. Dessa siffror säger en del om hur stor och viktig del ETL är i ett datavaruhusprojekt. I detta kapitel beskrivs ETL-processen, laddningen av datavaruhuset. Vilket ansvar har ETL, vad utförs av ETL och hur kan en ETL-lösning se ut? Detta är frågor som kommer att besvaras i kapitlet ETLs uppgifter ETL, som är en förkortning för de engelska orden Extraction, Transformation, Loading, kan sägas ha tre huvuduppgifter. Dessa går, inte helt oväntat, att utläsa ur själva förkortning ETL. Läsning av data (Extraction) Omvandling av data (Transformation) Laddning av data (Loading) Dessa punkter är de tre faser eller steg som datan måste gå igenom för att införas i datavaruhuset. Det första steget är läsning av data från källorna där datan finns lagrad. Data kopieras i detta steg från källorna till en behandlingsarea. Behandlingsarean kan vara någon typ av databas eller en enkel textfil. När källdatan finns samlad i denna behandlingsarea kan nästa steg påbörjas, transformering av data. Under denna transformering tvättas, rensas och omstruktureras data på ett sätt att det senare kan laddas in i datavaruhuset. Exempel på tvättning är avrundning av tal och exempel på rensning är att man helt enkelt plockar bort data som inte är intressant för någon analys. Omstrukturering av data behövs när strukturen på data skiljer sig mellan källan och datavaruhuset. Detta förekommer t ex när källan är en relationsdatabas och datavaruhuset bygger på en OLAP-databas. När transformeringen är avklarad kan det sista steget inledas, själva laddningen av data till datavaruhuset. 12

16 Bild 6: ETL-processens tre steg. Denna modell av laddningen av ett datavaruhus används av bl a Kimball [Kimball 1998] och Scott [Scott 2000]. Det är viktigt att förstå att dessa tre steg inte alltid är distinkta från varandra. Kimball [Kimball 1998] understryker att transformeringen av data kan ske i processens alla tre steg. Redan under extraheringen av källdata kan data omvandlas under extraktrutinerna och detta gäller även för laddningsrutinerna Faktorer som påverkar ETL Den miljö där ETL arbetar påverkar utformningen av ETL-processen [Scott 2000]. De faktorer som påverkar ETL-processen kan delas in i fyra huvudkategorier: Data och datastruktur Applikationer Arkitektur Personal Data och datastrukturer Det första man kanske kommer att tänka på som påverkar laddningen av ett datavaruhus är själv datan som skall laddas och hur dess struktur ser ut. Kvaliteten på datan bestämmer vad som måste göras med den under transformeringen. Idealet är att datan i datakällorna är så pass bra att den bara är att ladda in, men så är sällan fallet. Om t ex inmatningen av textsträngar görs manuellt i ett affärssystem kan detta medföra problem vid tolkningen av dessa. Två olika strängar kan egentligen betyda samma sak, som t ex I.B.M är samma företag som IBM, och detta måste ETL-processen klara av att hantera. ETL ansvarar alltså för att höja kvaliteten på datan så att analyser blir möjliga. Andra typer av dataomvandlingar är datatypskonvertering och tolkning av förkortningar och nullvärden. Förkortningar som används i datakällan för att spara utrymme lämpar sig inte för analyser. Om t ex en bit används för att representera ja och nej för ett attribut i datakällan, är det bättre att använda sig av textsträngen ja eller nej för detta attribut i datavaruhuset för att öka förståelsen vid analyser. ETL-processen ansvarar för att detta görs. 13

17 I de fall där källdata och datavaruhusets datastruktur skiljer sig måste data omstruktueras. Detta blir aktuellt när data ligger lagrat enligt en relationsmodell och datavaruhuset använder sig av en OLAP-databas. Generellt kan man säga att ju mer datastrukturerna skiljer sig från varandra desto mer krävs av ETL för att anpassa datan innan den kan laddas. När data laddas från flera olika datakällor kan problem uppkomma med primärnycklarna som finns i dessa källor. Primärnycklarna i de olika källorna kan stå i konflikt med varandra vilket medför att datan inte kan sammanföras i datavaruhuset. Spänner laddningen över lång tid finns det risk att återanvändning av primärnycklar sker i datakällorna. Eftersom affärssystem i vissa fall rensas så finns risk att primärnycklar återanvänds, och detta skapar ytterligare problem för datavaruhuset. En lösning som bl a förordas av Kimball [Kimball 1998] och Navarro [Navarro 2000] är att istället för datakällornas primärnycklar använda en annan nyckel i datavaruhuset. Denna nyckel kallas för surrogatnyckel och kan vara uppbyggd på olika sätt. Det som rekommenderas är att använda ett löpnummer (heltal) för varje tupel och detta är även fördelaktigt för utrymmesbesparingar. Ett heltal tar fyra byte jämfört med en textsträng som kan ta betydligt mer utrymme. Fördelen med att använda surrogatnycklar istället för källsystemens primärnycklar kan sammanfattas med följande punkter: Förenklar sammanföring av data från olika system som använder olika typer av primärnycklar. Förebygger problem med återanvändning av primärnycklar i datakällorna. Förenklar eventuellt byte av källa, då källans primärnycklarna inte påverkar datavaruhuset. Kräver mindre lagringsutrymme. Nackdelen med att använda surrogatnycklar i datavaruhus är att det blir mer kompilicerat att införa och uppdatera data. När dessa operationer ska utföras måste källdatans primärnyckel samman kopplas med datavaruhusets motsvarande surrogatnyckel innan operationen kan verkställas. Hanteringen av dessa surrogatnycklar faller på ETL-processens ansvar Applikationer Utöver de tre huvudsakliga uppgifterna som ETL-processen har tillkommer andra uppgifter, såsom loggning av felaktigt data och underrättelse av fel. Om dessa uppgifter ska skötas av redan befintliga program måste ETL-processen klara av att kommunicera med dessa. ETL-processen måste passa in bland de applikationer som företaget redan använder sig av och dessa faktorer påverkar givetvis utformningen av ETL-processen Arkitektur Även faktorer som kommer från den dataarkitektur företaget använder sig av påverkar ETL. Det kan handla om kommunikation och överföring av data över ett nätverk mellan två olika typer av plattformar, t ex Windows och UNIX. Ligger data utspritt på flera olika plattformar måste ETL-processen klara av att kommunicera och hämta data från dessa. Andra faktorer som påverkar ETL kan vara vilken tillgång på lagringsutrymme ETL-processen har, för exempelvis behandlingsarean. 14

18 Personal Personalens kunskap och bakgrund påverkar utformningen av ETL. Utvecklas ETL-processen av en grupp programmerare som är experter på ett programmeringsspråk väljer de nog det språket även fast det kanske inte är den optimala lösningen. Samtidigt är det bra om kompetensen för lösningen av ETL-processen finns i företaget. Personalen som ska administrera ETLprocessen har förmodligen också en del att säga om hur driften i form av loggning och felhantering ska ske Angreppssätt för ETL Hur kan man nu praktiskt lösa denna ETL-process? Vi har ett problem vi vill lösa med hjälp av en dator och ställs då inför två alternativ, skriva ett program eller köpa ett program som löser detta problem. Scott [Scott 2000] menar att det finns fyra olika angreppsätt för dataomvandling och dataöverföring. Dessa är att programmera en egen lösningen, köpa en kompilator för meta data, köpa ett ETL-verktyg eller välja en blandning av de tre. Jag vill dock ge följande bild av de alternativ som finns: 1. Programmera en egen lösning. 2. Köpa ett ETL-verktyg. 3. Välja en blandning av de två ovannämnda. Anledningen till att jag väljer denna indelning istället för Scotts är att jag anser att hans kategorier går in i varandra. Jag nöjer mig med att säga att det går att programmera en lösning (program, kompilator), köpa ett ETL-verktyg (program, kompilator) eller kombinera dessa två Programmera en egen lösning Att programmera en egen lösning kan göras på olika abstraktionsnivåer. Man kan använda sig av SQL, skriva ett program i något programmeringsspråk (C++, Java, etc), eller skriva en egen kompilator som utifrån Meta Data från källor och datavaruhus skapar ETL-processer. Eftersom denna typ av ETLlösning ligger relativt nära hårdvaran har man goda möjligheter att optimera den efter sin situation, men samtidigt så medför den en risk. Risken är att kompetensen för programmet ligger hos en eller ett fåtal personer, de personer som var med och utvecklade programmet. Försvinner de från företaget så försvinner även kompetensen för programmet. Risk finns även för att vidareutveckling och underhåll av egenutvecklade lösningar är svårt och kostsamt Köpa ett ETL-verktyg Istället för att skriva en egen lösning kan man köpa en ETL-lösning. Program som jobbar med laddning av datavaruhus brukar kallas för ETL-verktyg och de finns enligt Meyer [Meyer 2001] över 75 produkter som påstår sig ha någon slags ETL-funktion. Fördelen med denna lösning är att man får en produkt som troligen har flera användare vilket ökar möjligheten till externt kunnande om produkten. Några av nackdelarna är att man får en produkt som är generell och inte optimerad för sin situation, och att produktens funktionalitet och möjligheter styr strukturen på data i datavaruhuset [Kimball 1998]. 15

19 Välja en blandning av de två ovannämnda alternativen Ett alternativ är att välja en lösning som innehåller de två ovannämnda angreppssätten. Det kan t ex finnas situationer där ett köpt verktyg inte klarar av en viss typ av omvandling och denna funktion måste implementeras i en egen delapplikation. Detta gör då att man kompletterar det köpta ETLverktyget med ett eget program. Ställs man inför detta problem ofta med ett köpt ETL-verktyg bör man nog fundera på om ETL-verktyget är värt att ha eller om man ska programmera en egen lösning. Det angreppsätt som är aktuellt i detta examensarbete är förstås att köpa ett ETL-verktyg, eftersom arbetet består av en jämförelse av två sådana produkter. Anledning till att ABB väljer att köpa ett ETL-verktyg är för att man eftersträvar en allmän lösning där extern support kan erhållas. Att köpa en produkt anses också vara mer lätthanterligt och enklare att underhålla än en unikt tillverkad lösning. 2.4 Jämförelsemetod Hur jämför man två ETL-verktyg? Ett sätt kan ju vara att gå igenom varje produkt i detalj och se vilka funktioner och möjligheter varje produkt besitter. Problemet med denna metod är att den tar mycket tid, särskilt om produkten är stor. Ett annat problem med denna metod är att den ger information om produkten som inte är relevant för att lösa problemet. Resultat man får från en sådan undersökning täcker förmodligen områden som inte är aktuella för det datavaruhus man utvecklar. Dessutom finns ju denna information redan i tillverkarnas dokumentation av produkterna och kan alltså hämtas där. Jag letade ett tag efter en metod för att göra jämförelser av ETL-verktyg, men hittade inget konkret tillvägagångssätt. Det jag dock hittade var andras jämförelser av ETL-verktyg, problemet med dessa var att få tillgång till resultaten kostade mycket pengar. Tillslut bestämde jag mig för att utveckla en egen jämförelsemetod. Varför gjorde jag nu detta? Jo, tittar man på de fyra faktorer som påverkar utformningen av ETL, data, arkitektur, personal, och applikationer, så är de unika för varje datavaruhus. Data som laddas kommer från företagets egna källor, arkitekturen och applikationer har företaget byggt upp själv och de behov som personalen har är också olika från fall till fall. Jag har därför byggt upp min jämförelsemetod av ETL-verktyg efter de behov och förutsättningar som finns på ABB. Ett problem med denna metod är att den fokuserar på nuet. Den ser inte till framtida behov som kan finnas på datavaruhuset och ETL-verktyget. För att ta hänsyn till tänkbara framtid behov, så har jag utgått från andras erfarenheter av val och behov av ETLverktyg. Jag har främst studerat skrifter av Kimball [Kimball 1998] och Meyer [Meyer 2001] som belyser viktiga egenskaper hos ETL-verktyg. Det är viktigt att komma ihåg att detta inte är någon jämförelse mellan verktygen som ger svar på vilket verktyg som passar bäst i ett generellt fall. Jämförelsen syftat till att avgöra vilket verktyg som är mest lämpligt för ABBs situation och förutsättningar. Nedan följer en beskrivning av tillvägagångssättet för jämförelsen av ETLverktygen. 1. Identifiera behov, direkt eller allmänt behov. 2. Definiera parametrar som gör det möjligt att mäta hur produkten uppfyller behoven. 16

20 3. Vikta parametrar. 4. Gruppera parametrarna i huvudgrupper. Alla parametrar som tillhör en huvudgrupp kommer att påverka gruppens resultat beroende på dess vikt. En parameter med låg vikt påverkar gruppens sammanlagda resultat lite, medan en parameter med hög vikt påverkar resultatet mycket. 5. Skapa ett betygssystem där det är enkelt att betygsätta varje parameter. 6. Studera varje produkt och betygsätt varje parameter 7. Summera varje grupp av parametrar och normalisera värdet. 8. Jämför produkternas resultat Identifiera behov Det första steget är ganska naturligt och det är att identifiera vilka behov och krav som finns på ETL-verktyget. Det är dels krav som ställs direkt på ETLverktyget, såsom datastrukturer i källorna och administrering, och dels kravs som ställs på rapport- och analysmöjligheter som i sin tur påverkar ETLverktyget. De krav som ställs direkt på ETL-verktyget kommer från ABBs ITavdelning, de som ska sköta och utveckla laddningarna. Kraven härifrån var ganska konkreta. Inköpsavdelningen, som är kunden i detta projekt, hade några önskningar om vad rapporter skulle innehålla och klara av, men kraven på analysmöjligheter var inte lika klara. Vidareutveckling av datavaruhuset kan medföra andra behov och krav på ETLverktyget än de som kan identifieras enligt ovan. Därför har jag inkluderat behov som med hög sannolikhet kan tänkas uppkomma i framtida versioner av datavaruhuset. Dessa behov grundas på mina studier av datavaruhus och ETLverktyg. De olika typerna av behoven jag har identifierat efter detta resonemang är följande. Direkta behov. Dessa behov kan direkt utläsas från de krav och behov som kommer från IT- och inköpsavdelningen. Dessa behov finns idag. Allmänna behov. Dessa behov kan ej utläsas från de krav och behov som identifierats, men bör ändå tillgodoses av ETL-verktyget. Härkomsten av dessa behov kommer ifrån mina studier av datavaruhus och ETL-verktyg Definiera och vikta parametrar Utifrån de behov som identifierats skapas parametrar som möjliggör en jämförelse av verktygen. En parameter kan innefatta ett eller flera behov och varje parameter viktas mellan ett till tre, där ett innebär att behoven parametern innefattar är av mindre betydelse och tre innebär att behoven parametern innefattar är av högre betydelse. Viktningsnivåerna beskrivs enligt följande: 1. Låg. De behov som en parameter med denna vikt beskriver uppskattas om de uppfylls av ETL-verktyget. Behov av detta slag finns troligen inte idag, men kan tänkas uppkomma i framtida versioner av datavaruhuset. 2. Medel. De behov som en parameter med denna vikt beskriver bör uppfyllas av ETL-verktyget. Behov av detta slag finns troligen idag eller kommer med hög sannolikhet att uppkomma vid en vidareutveckling av datavaruhuset. 3. Hög. De behov som en parameter med denna vikt beskriver måste uppfyllas av ETL-verktyget. Behov av detta slag finns idag. 17