Inom data integration behövs det en process som regelbundet uppdaterar datalagret. Denna process brukar kallas för ETL-processen, även om processen egentligen använder ELT som metod.
Det första systemet för data integration baserat på strukturerad metadata skapades 1991 på University of Minnesota, Integrated Public Use Microdata Series (IPUMS). Systemet använde ett datalager, som uppdaterades med hjälp av en ETL-process (Extract, Transform & Load) som extraherade data, transformerade det och sedan laddade det i ett gemensamt schema i datalagret.
En traditionell ETL-process innebär att datat hämtas från källdatabasen till en separat ETL-server där datat transformeras till önskat format, och slutligen laddas till datalagret. Eftersom ETL-processen i många fall hanterar stora datamängder, innebär det att ETL-servern måste vara mycket kraftfull, och därmed dyr.
För att undvika att bearbetning av data på en separat ETL-server (istället för inuti en databas) har en annan metod blivit populär på senare tid, ELT (Extract, Load & Transform), vilket innebär att själva transformeringen görs inuti databasen där datalagret finns. Detta är ofta en mer effektiv metod, eftersom en databas är konstruerad för att hantera stora datamängder.
Speciellt i molnbaserade databaser som Amazon Redshift, Google BigQuery, Microsoft Fabric och Snowflake fungerar denna metod, även kallad Push-down SQL, väl. På liknande sätt är det möjligt att transformera data i källdatabasen innan det hämtas och skrivs till ett datalager, TEL (Transform, Extract & Load), men det belastar förstås källsystemet och används normalt inte inom data integration för analys.
I verkligheten finns det fler delsteg i en ETL-process, exempelvis:
Ett datalager behöver uppdateras regelbundet för att vara aktuellt. Uppdateringarnas frekvens beror på flera faktorer, bland annat hur ofta data i källsystemen uppdateras, hur lång tid ETL-processen kräver, hur snabbt datalaget kan hantera uppdateringar, och hur ofta användarna vill att datalagret uppdateras.
Förr var det vanligt att datalagret uppdaterades en gång i veckan, på veckoslutet, eftersom ETL-processen krävde väldigt lång tid. Numera är det vanligt att ett datalager uppdateras åtminstone varje dag. Med nuvarande teknik kan ETL-processen vara tillräckligt snabb för att göra det oftare, dvs flera gånger under dagen, men användare kan föredra att datat i datalagret inte ändras under dagen.
Dagens moderna lösningar kan tillåta betydligt kortare intervaller, som 15-30 minuter, speciellt om ELT används tillsammans med resurseffektiv datahämnting med hjälp av CDC och datalagret i moderna och snabba relationsdatabaser.
Ibland kan det vara nödvändigt att hämta och/eller bygga referensdata innan ETL-processen börjar hämta data från källsystemet. Det kan vara allt från dynamiska parametrar för databaskopplingar, databasfrågor, frågefilter till godkända intervall för datat. Detta delsteg används bara om integrationsprocessen kräver dynamiska referensdata.
Hämtning av data från ett källsystem är det första nödvändiga steget i en ETL-process. De flesta datalager hämtar data från flera olika källsystem, som kan vara av olika typer. Vanligast är relationsdatabasen, men även filer med text, CSV (Comma Separated Values), JSON (JavaScript Object Notation), XML (Xtensible Markup Language) eller binära data.
Andra typer kan vara NoSQL-databaser som tex IBM IMS (Information Management System), VSAM (Virtual Storage Access Method) eller ISAM (Indexed Sequential Access Method), eller MongoDB, DynamoDB, Cassandra, Neo4j med flera. Det börjar även bli alltmer vanligt med anrop till webbtjänster, såsom Salesforce och liknande, samt från strömmande data, tex Kafka. Det förekommer även att data hämtas från webbsidor (och liknande) med hjälp av data scraping.
För relationsdatabaser är det vanligt att använda frågespråket SQL, som ställer frågor direkt till databasen. Det kan av olika anledningar vara svårt eller omöjligt att få ställa frågor direkt till källdatabasen, antingen för att den är hårt belastad eller att den är låst av säkerhetsskäl. Dessa skäl kan ofta lösas om frågorna först har granskats och godkänts av de som är ansvariga för databasen och dess data, och sedan körs under övervakning. De kommer ändå att innebära en belastning för databasens motor.
Frågorna måste normalt sett dessutom innehålla logik för att enbart hämta de senaste ändringarna i datat. Vanligtvis lagras all historik i ett datalager, och därmed behöver enbart förändringarna i datat hämtas för att läggas till den samlade historiken innan analys.
Ett annat sätt är att använda databasens interna transaktionslogg. Nästan alla relationsdatabaser använder en intern transaktionslogg för att dess databasadminstratör skall kunna bevisa vad som är gjort och eventuellt kunna återställa data till en tidigare version. Det finns lösningar som kan tolka dessa loggar och därmed hämta alla förändringar utan att belasta databasens motor, vilket kallas för CDC (Catch Data Capture). En sådan lösning tillhandahålls av Qlik.
Ofta mellanlagrar man det hämtade datat på en landningsyta (Landing Zone), som ibland kallas Staging eller ODS (Operative Data Store). Normalt sett är datat på landsningsytan oförändrat så långt som möjligt, bortsett från konvertering till de datatyper som används i datalagrets databasplattform, samt operativ märkning av datat inför den förestående transformeringen.
Det finns olika synsätt på validering av data för ett datalager. En vanligt angreppssätt är att validera datat, och eventuellt korrigera det, när det skall lagras i datalagret (antingen innan eller efter transformering). Andra förespråkar att man lagrar data exakt som det ser ut i källsystemet (så långt som datatyperna tillåter det) och låter användarna av datat, analytikerna, att korrigera eventuella datafel. De flesta anser dock att felen skall korrigeras så tidigt som möjligt, dvs i källsystemet.
Datafel kan vara allt ifrån att en datatyp inte stämmer överens (och därmed inte kan lagras alls), data som saknas (tex är NULL), en kodning som saknar förklaring, manuella skrivfel till siffror som är orimliga. Det är mest effektivt om alla fel kan rättas i källdatasen, men ibland är det inte möjligt. Då bör man använda en metod för att hantera alla datafel. Skall de sparas utan åtgärd (och lösas senare), skall de korrigeras automatiskt (så långt som möjligt), skall de läggas undan för manuell åtgärd, eller skall hela ETL-processen stoppas?
Data som kommer från olika källsystem har normalt olika struktur och kodning. Ett källsystem lagrar ofta data ett normaliserat format som passar sitt data. På samma sätt används ofta olika typer av kodning av datat, som passar detta data. Dessa strukturer och kodningar måste sammanställas och integreras för att det skall gå att kombinera data i en analys. Detta kallas ofta för tvätt av data.
Eftersom en analytiker gärna vill slippa att göra denna, ofta tidsödande, sammanställning vid varje analys är det mer effektivt att transformera data innan det lagras i ett integrerat datalager. Själva transformationen är beroende på respektive källsystem, men det finns generella angreppssätt som kan vara användbara. Exempelvis hur man märker datat, hur man sparar metadata om processen, eller hur man hanterar eventuella datafel.
Många källsystem sparar inte på historik, huvudsakligen för att historiken inte används av det operativa systemet. Däremot är historik ofta viktig vid analys, eftersom man ofta vill se vad som händer över tiden. Det är vanligt att spara på historik när man sammanställer datat i ett integrerat datalager.
Vanliga typer av transformeringar och åtgärder:
Normalt behöver data mellanlagras i temporära Staging-tabeller medan transformeringen utförs, ofta i flera steg. Ett modernt ETL-verktyg klarar av att skapa, använda och radera dessa tabeller automatiskt, så de kommer inte synas när ETL-processen är avklarad.
Lagring av data i ett datalager är själva syftet med en ETL-process. Det görs innan (eller samtidigt som) transformeringen om man använder ELT som metod. I detta fall använder man Push Down SQL i datalagret när man lagrar datat. Teoretiskt sett kan en ETL-process lagra data på vilken plattform som helst, men i praktiken används normalt en relationsdatabas som plattform för datalagret.
Data kan lagras i datalagret enligt olika datamodeller. De tre modellerna som förekommer är antingen i den tredje normalformen (enligt Bill Inmon), som en stjärnmodell med dimensioner (enligt Ralph Kimball), eller som en dataorienterad modell med hubbar och satelliter kallad data vault (enligt Dan Lindstedt). Den senare modellen är mer flexibel och erbjuder bättre spårbarhet än de andra.
Det är vanligt att man (ofta i föregående steg) även ser till att tillhandahålla data på ett lättillgängligt sätt för att underlätta möjligheterna att analysera datat. Strukturen i den centrala delen av datalagret som innehåller all historik kan vara svår att förstå för en affärsorienterad analytiker, och det är normalt att tillhandahålla data med en affärsorienterad struktur.
Om datalagret är baserat på en relationsdatabas finns det två huvudprinciper för att tillgängliggöra det. Antingen finns det lättförståeliga databasvyer, ett semantiskt lager, som läser data direkt från datalagrets själva hjärta, eller kopierar man delar av datat till Dataförråd (Data Marts), som är mindre kopior av datalagret avsedda för fokuserade frågor och analyser. Den första metoden kräver en mycket snabb databas som tex Teradata, och den andra metoden kommer duplicera data vilket kräver mer diskutrymme.
För att kunna hålla koll på ETL-processen och vad den har gjort, sparar man även metadata om ETL-processen. Det är allt från om exakt när och hur ETL-processen startade, varade och slutade (operativ metadata), vilka data som hanterades och hur hanteringen gick (teknisk metadata), till hur data stämde överens med affärsregler och liknande (business metadata). Metadata används även i delsteg, för uppföljning.
Ett brett område som omfattar alla tänkbara aspekter på själva ETL-processen, på hur den stämmer överens med olika regler (compliance), på vad som hände med data som hanterades och hur data kan spåras tillbaka till dess källa (spårbarhet), på hur fel hanterats och vad som eventuellt behöver ändras (felhantering), till alla möjliga frågor som kan ställas.
Beroende på vilka krav som finns kan det vara nödvändigt att arkivera processerade data och/eller de delsteg som exekverats. Metadata kan innehålla tillräcklig information om exekverade delsteg, men ibland kan ytterligare information krävas. Processerade data bör i normalfallet inte behöva arkiveras, men beroende på vilka krav som finns kan det vara nödvändigt.
Sidan skapad 4 december 2024 (egen sida om DI)
Sammanställt av Christer Tärning.