Dela via

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 mellanlagringstabeller som tillfälligt lagrar data när de bearbetas och slutligen läses in i målet.

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 parallellisering runt datapartitionsgränser (datum, klientorganisation, shardnyckel) för att undvika skrivkonkurrering och aktivera idempotent återförsök.

Relevant tjänst:

Andra verktyg:

Extrahera, läsa in, transformera (ELT)

Extrahering, inläsning, transformering (ELT) skiljer sig från ETL enbart i den plats där omvandlingen 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, som är ett kolumnformat som organiserar data efter kolumn för att aktivera komprimering, predikat-pushdown och effektiva analysgenomsökningar.

Relevant Microsoft-tjänst:

Välja ETL eller ELT

Valet mellan dessa metoder beror på dina krav.

Välj ETL när:

  • Du måste avlasta tunga transformeringar från ett begränsat målsystem
  • Komplexa affärsregler kräver specialiserade omvandlingsmotorer
  • Regel- eller efterlevnadskrav kräver granskade mellanlagringsgranskningar innan de läses in

Välj ELT när:

  • Ditt målsystem är ett modernt informationslager eller lakehouse med elastisk beräkningsskalning
  • 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 anslutningsappar i ett arbetsflödesdiagram, som du ser i bilden nedan. 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öden kör dataflöden som en uppgift. 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 container. 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.

Ett exempel finns i ETL (Reverse extract, transform, &load) with Azure Cosmos DB for NoSQL (Omvänd extrahering, transformering och inläsning) med Azure Cosmos DB för NoSQL .

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 transformeringar som filtrering, aggregering, berikande eller koppling med referensdata – allt i rörelse – innan resultatet dirigeras till underordnade system som instrumentpaneler, 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
  • Designtransformeringar som ska vara idempotent för att hantera potentiell duplicerad bearbetning
  • Implementera vattenstämpling för händelser som inkommer sent och bearbetning som inte är i ordning
  • Använda köer med obeställbara meddelanden för meddelanden som inte kan bearbetas

Teknikval

Datalager:

Pipeline och orkestrering:

Lakehouse och modern analys:

Nästa steg

Beslutsguide för infrastrukturresurser för datatransformering