ETL står for Extract, Transform, Load og beskriver den proces der flytter data fra kildesystemer til et centralt lager, typisk et data warehouse, hvor den kan analyseres. Hvis business intelligence er det synlige dashboard, er ETL det usynlige maskineri der sørger for at de rigtige data er tilgængelige i det rigtige format.
Extract-fasen handler om at hente data fra kildesystemerne. I en typisk dansk virksomhed kan det være ordredata fra et ERP-system som NAV eller SAP, kundedata fra et CRM-system som Salesforce eller HubSpot, webtrafikdata fra Google Analytics, og finansdata fra e-conomic eller Dinero. Hver kilde har sin egen struktur, sit eget API og sine egne begrænsninger. Extraction kan ske som full load, hvor hele datasættet hentes hver gang, eller som incremental load, hvor kun nye og ændrede rækker hentes baseret på et tidsstempel eller en change data capture mekanisme.
Transform-fasen er der hvor rå data bliver til analyserbar information. Transformationer spænder fra simple operationer som at standardisere datoformater og fjerne dubletter, til komplekse forretningslogikker som at beregne customer lifetime value eller allokere marketingomkostninger til individuelle salg. Typiske transformationer inkluderer datarensning (fjern ugyldige værdier, standardisér navne og adresser), databerigelse (tilføj beregnede felter, slå op i referencetabeller), konformering (ensret dimensioner på tværs af kildesystemer, så "Danmark" og "DK" og "DNK" alle mappes til den samme nøgle), og aggregering (summér transaktionsdata til daglige eller månedlige totaler for hurtigere forespørgsler).
Load-fasen skriver de transformerede data ind i destinationssystemet. I et data warehouse bruges typisk to strategier: truncate-and-reload, hvor hele tabellen erstattes ved hver kørsel, og incremental append, hvor nye rækker tilføjes og eksisterende opdateres. Slowly changing dimensions håndterer historik for dimensionsdata der ændrer sig over tid, for eksempel når en kunde skifter adresse eller en medarbejder ændrer afdeling.
Moderne dataarkitekturer har introduceret ELT som et alternativ til traditionel ETL. I ELT indlæses rå data først i data warehouse (Extract, Load), og transformationerne udføres derefter direkte i databasen med SQL. Cloud data warehouses som Snowflake, BigQuery og Databricks har gjort denne tilgang attraktiv, fordi de tilbyder næsten ubegrænset beregningskraft til at transformere data in-place.
Værktøjer til ETL og ELT spænder fra open source til enterprise. Apache Airflow er en populær open source workflow-orchestrator der koordinerer komplekse datapipelines. dbt (data build tool) har revolutioneret ELT ved at lade analytikere definere transformationer som SQL-modeller med versionering og test. Fivetran og Airbyte automatiserer extraction fra hundredvis af kilder. For Microsoft-baserede organisationer tilbyder Azure Data Factory og SSIS (SQL Server Integration Services) tæt integration med Power BI og det øvrige Microsoft-økosystem.
Fejlhåndtering er kritisk i ETL-processer. En enkelt korrupt fil eller et API-timeout kan stoppe hele datapipelinen. Robuste ETL-løsninger implementerer retry-logik, alerting ved fejl, datavailderings-checkpoints og mulighed for at genstarte fra et specifikt punkt i processen. Logging af hver kørsel med antal behandlede rækker, afviste rækker og køretider giver overblik over pipelinens sundhed.
Scheduling bestemmer hvornår ETL-jobs kører. Batch-ETL kører typisk natlige jobs der behandler det foregående døgns data, hvilket er tilstrækkeligt for de fleste rapporteringsbehov. Near-real-time ETL med micro-batching hvert 5-15. minut bruges til operationelle dashboards. Real-time streaming med teknologier som Apache Kafka er nødvendig for usecases som fraud detection eller live prisoptimering.
Performance-optimering af ETL inkluderer parallelisering af uafhængige transformationer, partitionering af store tabeller, brug af staging-tabeller til mellemresultater, og inkrementel processering i stedet for full reload. For et dansk mellemstort firma med 10-50 millioner rækker i kernesystemerne bør en typisk natlig ETL-kørsel tage minutter, ikke timer.
Når du designer din ETL-arkitektur, start med at kortlægge dine datakilder og deres opdateringsfrekvenser. Definér klare navngivningskonventioner for tabeller, kolonner og jobs. Dokumentér transformationslogikken, så den næste analytiker kan forstå hvad der sker. Test med realistiske datamængder, ikke kun med et par hundrede testrækker. Og overvåg aktivt via dashboards der viser pipelinens status, dataktualitet og kvalitetsmetrikker.
