Extrahering, transformering och laddning (ETL)

Microsoft Fabric
Azure Data Factory

Organisationer behöver ofta samla in data från flera källor i olika format och flytta dem till ett eller flera datalager. Målet kanske inte är samma typ av datalager som källan, och data måste ofta formas, rensas eller transformeras innan de läses in.

Olika verktyg, tjänster och processer hjälper dig att hantera dessa utmaningar. Oavsett metod måste du samordna arbetet och tillämpa datatransformeringar i datapipelinen. I följande avsnitt beskrivs vanliga metoder och metoder för dessa uppgifter.

Extrahera, transformera, läsa in (ETL)-process

Extrahera, transformera, läsa in (ETL) är en dataintegreringsprocess som konsoliderar data från olika källor till ett enhetligt datalager. Under omvandlingsfasen ändras data enligt affärsregler med hjälp av en specialiserad motor. Detta innebär ofta stagingtabeller som tillfälligt lagrar data medan de bearbetas och slutligen laddas in till sin slutliga destination.

Diagram över ETL-processen (extract, transform, load).

Datatransformeringen som sker omfattar vanligtvis olika åtgärder, till exempel filtrering, sortering, aggregering, sammanfogning av data, rensning av data, deduplicering och validering av data.

Ofta körs de tre ETL-faserna parallellt för att spara tid. När data till exempel extraheras kan en transformeringsprocess fungera på data som redan har tagits emot och förbereda dem för inläsning, och en inläsningsprocess kan börja arbeta med förberedda data i stället för att vänta på att hela extraheringsprocessen ska slutföras. Du utformar vanligtvis parallelliseringen utifrån gränserna för datapartitionering (datum, tenant, shardnyckel) för att undvika skrivkonflikter och möjliggöra idempotenta omförsök.

Relevant tjänst:

Andra verktyg:

Extrahera, läsa in, transformera (ELT)

Extrahering, inläsning och transformering (ELT) skiljer sig från ETL endast i var transformeringen sker. I ELT-pipelinen sker omvandlingen i måldatalagret. I stället för att använda en separat transformeringsmotor används bearbetningsfunktionerna i måldatalagret för att transformera data. Detta förenklar arkitekturen genom att ta bort transformeringsmotorn från pipelinen. En annan fördel med den här metoden är att skalning av måldatalagret även skalar ELT-pipelinens prestanda. ELT fungerar dock bara bra när målsystemet är tillräckligt kraftfullt för att transformera data effektivt.

Diagram över elt-processen (extract, load, transform).

Vanliga användningsfall för ELT hör till stordatasfären. Du kan till exempel börja med att extrahera källdata till flata filer i skalbar lagring, till exempel ett Hadoop Distributed File System (HDFS), Azure Blob Storage eller Azure Data Lake Storage Gen2. Tekniker som Spark, Hive eller PolyBase kan sedan användas för att köra frågor mot källdata. Den viktigaste punkten med ELT är att datalagret som används för att utföra omvandlingen är samma datalager där data slutligen förbrukas. Det här datalagret läser direkt från den skalbara lagringen i stället för att läsa in data i sin egen separata lagring. Den här metoden hoppar över datakopieringssteg som finns i ETL, vilket ofta kan vara tidskrävande för stora datamängder. Vissa arbetsbelastningar materialiserar transformerade tabeller eller vyer för att förbättra frågeprestanda eller framtvinga styrningsregler. ELT innebär inte alltid enbart virtualiserade transformeringar.

Den sista fasen av ELT-pipelinen omvandlar vanligtvis källdata till ett format som är mer effektivt för de typer av frågor som måste stödjas. Data kan till exempel partitioneras med vanliga filtrerade nycklar. ELT kan också använda optimerade lagringsformat som Parquet, vilket är ett kolumnorienterat lagringsformat som organiserar data efter kolumn för att möjliggöra komprimering, predicate pushdown och effektiva analytiska genomsökningar.

Relevant Microsoft-tjänst:

Välja ETL eller ELT

Valet mellan dessa metoder beror på dina krav.

Välj ETL när:

  • Du behöver flytta tunga transformationer bort från ett resursbegränsat målsystem
  • Komplexa affärsregler kräver specialiserade omvandlingsmotorer
  • Regulatoriska krav eller efterlevnadskrav kräver sammanställda staginggranskningar före inläsning

Välj ELT när:

  • Ditt målsystem är ett modernt datalager eller lakehouse med elastisk skalning av beräkningsresurser
  • Du måste bevara rådata för undersökande analys eller framtida schemautveckling
  • Transformeringslogik drar nytta av målsystemets interna funktioner

Dataflöde och kontrollflöde

I samband med datapipelines säkerställer kontrollflödet ordnad bearbetning av en uppsättning uppgifter. För att framtvinga rätt bearbetningsordning för dessa uppgifter används prioritetsbegränsningar. Du kan se dessa begränsningar som anslutningar i ett arbetsflödesdiagram, som visas i följande bild. Varje uppgift har ett resultat, till exempel framgång, fel eller slutförande. Efterföljande aktiviteter initierar inte bearbetning förrän dess föregående har slutförts med något av dessa resultat.

Kontrollflöde kör dataflöde som en aktivitet. I en dataflödesaktivitet extraheras data från en källa, transformeras eller läses in i ett datalager. Utdata från en dataflödesaktivitet kan vara indata till nästa dataflödesaktivitet och dataflöden kan köras parallellt. Till skillnad från kontrollflöden kan du inte lägga till begränsningar mellan aktiviteter i ett dataflöde. Du kan dock lägga till ett datavisningsprogram för att observera data när de bearbetas av varje uppgift.

Diagram över ett dataflöde som körs som en uppgift i ett kontrollflöde.

I diagrammet finns det flera uppgifter i kontrollflödet, varav en är en dataflödesaktivitet. En av uppgifterna är kapslad i en behållare. Containrar kan användas för att tillhandahålla struktur för uppgifter, vilket ger en arbetsenhet. Ett sådant exempel är för upprepande element i en samling, till exempel filer i en mapp eller databasinstruktioner.

Relevant tjänst:

Omvänd ETL

Omvänd ETL är processen att flytta transformerade, modellerade data från analyssystem till operativa verktyg och program. Till skillnad från traditionell ETL, som flödar data från driftsystem till analys, aktiverar omvänd ETL insikter genom att skicka tillbaka kurerade data till den plats där företagsanvändare kan agera på den. I en omvänd ETL-pipeline flödar data från informationslager, sjöhus eller andra analyslager till driftsystem som:

  • Crm-plattformar (Customer Relationship Management)
  • Verktyg för marknadsföringsautomatisering
  • Kundsupportsystem
  • Arbetsbelastningsdatabaser

Metoden följer fortfarande en extraherings-, transformerings- och inläsningsprocess. Transformeringssteget är där du konverterar från det specifika format som används av ditt informationslager eller andra analyssystem för att justera mot målsystemets.

Se Omvänd extrahering, transformering och inläsning (ETL) med Azure Cosmos DB för NoSQL för ett exempel.

Arkitekturer för strömmande data och frekvent sökväg

När du behöver Lambda-snabbsökväg eller Kappa-arkitekturer kan du prenumerera på datakällor när data genereras. Till skillnad från ETL eller ELT, som fungerar på datauppsättningar i schemalagda batchar, bearbetar realtidsströmning data när de anländer, vilket möjliggör omedelbara insikter och åtgärder.

Diagram över push-, transformerings- och inläsningsprocessen.

I en strömningsarkitektur matas data in från händelsekällor till en meddelandekö eller händelsehubb (till exempel Azure Event Hubs eller Kafka) och bearbetas sedan av en dataströmprocessor (till exempel Fabric Real-Time Intelligence, Azure Stream Analytics eller Apache Flink). Processorn tillämpar transformationer som filtrering, aggregering, berikning eller sammanfogning med referensdata – medan data fortfarande är i rörelse – innan resultaten dirigeras till efterföljande system som dashboards, aviseringar eller databaser.

Den här metoden är idealisk för scenarier där korta svarstider och kontinuerliga uppdateringar är viktiga, till exempel:

  • Övervaka tillverkningsutrustning för avvikelser
  • Identifiera bedrägerier vid finansiella transaktioner
  • Driva realtidsinstrumentpaneler för logistik eller drift
  • Utlösa aviseringar baserat på sensortrösklar

Tillförlitlighetsöverväganden för strömning

  • Använd kontrollpunkter för att garantera bearbetning minst en gång och återställa från fel
  • Utforma transformeringar så att de är idempotenta för att hantera eventuell duplicerad bearbetning.
  • Implementera vattenstämpling för händelser som inkommer sent och bearbetning som inte är i ordning
  • Använd dead letter-köer för meddelanden som inte kan bearbetas

Teknikval

Datalager:

Pipeline och orkestrering:

Lakehouse och modern analys:

Nästa steg

Beslutsguide för Fabric för datatransformering