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

Molndatalager och datasjöar berikar data, centraliserar information och möjliggör kraftfull analys. Men det verkliga värdet av data ligger i att omvandla insikter till verkliga beslut och kundupplevelser. För att uppnå det här målet måste rena och tillförlitliga data flytta ut från lagret/datasjöarna till driftsystem. Omvänd ETL flyttar data från ditt informationslagerlager, till exempel Delta Lake i Azure Databricks eller Microsoft Fabric, tillbaka till driftsystem. Med det här migreringssteget kan underordnade appar använda de senaste, berikade data för driftanalys i realtid. Omvänd ETL spelar en avgörande roll för att frigöra datatillgångarnas fulla potential genom att överbrygga klyftan mellan analys och åtgärder, vilket möjliggör bättre beslutsfattande.

Azure Cosmos DB för NoSQL är utformat för ultralåg svarstid, global distribution och NoSQL-skalbarhet, vilket gör det idealiskt för realtidsprogram. Med omvänd ETL kan du synkronisera Delta-berikade data till Azure Cosmos DB, vilket möjliggör driftanalys i realtid. Du kan använda det här mönstret för att skicka data som produktkataloger, anpassad kundinformation, prisuppdateringar, inventeringsdata och funktionsrekommendationer. Du kan skicka dessa data till ditt driftdatalager och ge underordnade appar möjlighet att fatta datadrivna beslut direkt.

Lösningsarkitektur

En effektiviserad arkitektur för att implementera omvänd ETL består av Apache Spark och Azure Databricks. Den här arkitekturen extraherar rensade och berikade data från källor som Delta Tables och skriver tillbaka data till driftlagret i Azure Cosmos DB för NoSQL.

Det här diagrammet innehåller följande komponenter:

• Datakällor som innehåller data som; produktdata, CRM-data, beställningsinformation och annonsinformation.

• ETL-arbetsflödet flyttar data från de ursprungliga datakällorna till ett informationslager eller en datasjö för att lagra och berika data med hjälp av lösningar som Azure Databricks eller Microsoft Fabric.

• Omvända ETL-arbetsflöden för att migrera berikade data till ett driftdatalager med hjälp av Apache Spark- och Delta-tabeller

• Åtgärdsdatalager som Azure Cosmos DB for NoSQL för att använda berikade data i realtidsprogram.

Den omvända ETL-processen möjliggör scenarier som:

• Real-Time beslut: Appar får åtkomst till de senaste data utan att förlita sig på analytiker eller SQL.

• Dataaktivering: Insikter skickas dit de behövs – inte bara på instrumentpaneler.

• Enhetlig sanningskälla: Delta Lake fungerar som det kanoniska lagret, vilket säkerställer konsekvens mellan system.

Datainmatningssteg

För scenarier som funktionslagring, rekommendationsmotorer, bedrägeridetektion eller produktkataloger i realtid är det viktigt att separera dataflödet i två steg. Dessa steg förutsätter att du har en omvänd ETL-pipeline från Delta Lake till Azure Cosmos DB för NoSQL.

Stegen i det här diagrammet består av:

1. Inledande inläsning: Den första inläsningen är ett engångsprocesssteg för batchbearbetning för att mata in alla historiska data från Delta-tabeller i Azure Cosmos DB för NoSQL. Den lägger grunden för din omvända ETL-pipeline genom att se till att det operativa datalagret har fullständiga historiska data. Den här belastningen är ett grundläggande steg innan inkrementell synkronisering av data påbörjas.

2. Cdc-synkronisering (Change Data Capture): Det här steget implementerar en inkrementell, kontinuerlig synkronisering av ändringar från Delta-tabeller till Azure Cosmos DB för NoSQL. Ändringar i deltatabellen kan samlas in efter aktivering av Delta Change Data Feed (CDF). Du kan implementera antingen batchbaserad eller strömmande synkronisering av ändringsdatafångst (CDC).

Det finns två alternativ för CDC-synkronisering i Azure Cosmos DB för NoSQL:

• Batch CDC-synkronisering: Det här alternativet körs enligt ett schema (t.ex. dagligen eller varje timme) och läser in en inkrementell ögonblicksbild av data baserat på ändringar som har samlats in sedan den senaste versionen eller tidsstämpeln.

  Tips/Råd

  Växla till en nyare Azure Cosmos DB-ögonblicksbild för att undvika datainkonsekvenser när stora inkrementella volymer läses in från en deltatabell till Azure Cosmos DB för NoSQL. När du till exempel skriver till en ny container eller använder en versionsflagga vänder du en pekare till en nyare skärmbild när de nya data har lästs in fullständigt.

• Stream CDC-synkronisering: Det här alternativet synkroniserar kontinuerligt inkrementella ändringar nästan i realtid, vilket håller målsystemet uppdaterat med minimal fördröjning. Det här alternativet använder Apache Spark-strukturerad direktuppspelning för att kontinuerligt samla in och skriva ändringar. Deltatabellen fungerar som en strömningskälla med readChangeData = true, och Azure Cosmos DB for NoSQL-anslutningsappen fungerar som en direktuppspelningsmottagare.

  Tips/Råd

  Ange en kontrollpunktsplats för att säkerställa att förloppet spåras och att dubbletter av skrivningar undviks.

Metodtips

• Använd Apache Spark batch-jobb med Azure Cosmos DB för NoSQL-anslutning för att utföra den initiala inläsningen.

• Optimera inmatningshastigheten genom att växla till standardtilldelat dataflöde om den initiala belastningen förväntas förbruka en stor mängd RU/s i förhållande till ditt allokerade dataflöde. Mer specifikt använder du standardetablerade dataflöden om det maximala antalet enheter för begäranden per sekund (RU/s) används konsekvent under större delen av den inledande inläsningsprocessen. Använd inte autoskalningsdataflöde för det första inläsningssteget i det här scenariot.

  Tips/Råd

  Om det normaliserade RU-förbrukningsmåttet konsekvent är 100%anger måttet att den inledande belastningen konsekvent använder de maximala enheter för autoskalningsbegäran (RU: er). Det här tröskelvärdet är en tydlig indikator på att det här scenariot gäller för din arbetsbelastning och att du bör använda standardetablerade dataflöden.

• Välj en effektiv partitionsnyckel som maximerar parallelliteten. Mer information finns i rekommendationer för partitionering och partitionsnyckel.

• Planera för det totala antalet partitioner och totalt antal RU/s för alla partitioner för stora datainmatningar. Mer information och vägledning finns i rekommendationer för partitionering och dataflöde.

• Använd Apache Spark-dataflödeskontroll för att begränsa RU-förbrukningen (request unit) för jobb. Dataflödeskontroll hjälper till att förhindra överbelastning av den operativa målkontainern.

• Använd autoskalad genomströmning när det är möjligt i Azure Cosmos DB för NoSQL för CDC-synkronisering, eftersom autoskalning dynamiskt skalar upp/ned RU/s baserat på användning. Autoskalningsdataflöde är idealiskt för periodiska och spikiga arbetsbelastningar som schemalagda CDC-synkroniseringsjobb. Mer information finns i rekommendationer för dataflöde.

• Beräkna den inledande inmatningstiden för det första datainläsningssteget. Mer information och ett exempel finns i uppskattning av dataflöde.

Nästa steg