Ändra datainsamling i Azure Cosmos DB-analysarkiv

GÄLLER FÖR: Nosql Mongodb

Med CDC (Change Data Capture) i Azure Cosmos DB-analysarkivet kan du effektivt använda ett kontinuerligt och inkrementellt flöde av ändrade (infogade, uppdaterade och borttagna) data från analysarkivet. Sömlöst integrerad med Azure Synapse och Azure Data Factory ger det dig en skalbar no-code-upplevelse för stora datavolymer. Eftersom funktionen för att samla in ändringsdata baseras på analysarkivet förbrukar den inte etablerade RU:er, påverkar inte dina transaktionsarbetsbelastningar, ger lägre svarstid och har lägre TCO.

Funktionen för att samla in ändringsdata i Azure Cosmos DB-analysarkivet kan skriva till olika mottagare med hjälp av ett Azure Synapse- eller Azure Data Factory-dataflöde.

Diagram of the analytical store in Azure Cosmos DB and how it, with change data capture, can write to various first and third-party target services.

Mer information om mottagartyper som stöds i ett mappningsdataflöde finns i dataflödestyper som stöds.

Förutom att tillhandahålla inkrementellt dataflöde från analysarkivet till olika mål har ändringsdatainsamling stöd för följande funktioner:

  • Stöder insamling av borttagningar och mellanliggande uppdateringar
  • Möjlighet att filtrera ändringsflödet för en viss typ av åtgärd (Infoga | TTL för uppdateringsborttagning) | |
  • Stöder tillämpning av filter, projektioner och transformeringar i ändringsflödet via källfråga
  • Flera ändringsflöden i samma container kan användas samtidigt
  • Varje ändring i containern visas exakt en gång i flödet för insamling av ändringsdata och kontrollpunkterna hanteras internt åt dig
  • Ändringar kan synkroniseras "från början" eller "från en viss tidsstämpel" eller "från och med nu"
  • Det finns ingen begränsning kring den fasta kvarhållningsperioden för data som ändringar är tillgängliga för

Effektiv inkrementell datainsamling med internt hanterade kontrollpunkter

Varje ändring i Cosmos DB-containern visas exakt en gång i CDC-flödet och kontrollpunkterna hanteras internt åt dig. Detta hjälper till att åtgärda nackdelarna nedan med det vanliga mönstret för att använda anpassade kontrollpunkter baserat på värdet "_ts":

  • Filtret "_ts" tillämpas på datafilerna som inte alltid garanterar minimal datagenomsökning. De internt hanterade GLSN-baserade kontrollpunkterna i den nya CDC-funktionen säkerställer att den inkrementella dataidentifieringen görs, bara baserat på metadata och garanterar därför minimal datagenomsökning i varje dataström.

  • Synkroniseringsprocessen för analysarkivet garanterar inte "_ts" baserad ordning, vilket innebär att det kan finnas fall där en inkrementell posts "_ts" är mindre än den senaste kontrollpunkten "_ts" och kan missas i den inkrementella dataströmmen. Den nya CDC överväger inte "_ts" för att identifiera de inkrementella posterna och garanterar därför att ingen av de inkrementella posterna missas.

Funktioner

Ändringsdatainsamling i Azure Cosmos DB-analysarkivet stöder följande viktiga funktioner.

Samla in ändringar från början

När alternativet Start from beginning har valts innehåller den första inläsningen en fullständig ögonblicksbild av containerdata i den första körningen, och ändrade eller inkrementella data samlas in i efterföljande körningar. Detta begränsas av egenskapen analytical TTL och dokument som TTL-tagits bort från analysarkivet ingår inte i ändringsflödet. Exempel: Föreställ dig en container med analytical TTL värdet 31536000 sekunder, vilket motsvarar 1 år. Om du skapar en CDC-process för den här containern inkluderas endast dokument som är nyare än 1 år i den inledande belastningen.

Samla in ändringar från en viss tidsstämpel

När alternativet Start from timestamp har valts bearbetar den inledande inläsningen data från den angivna tidsstämpeln och inkrementella eller ändrade data samlas in i efterföljande körningar. Den här processen begränsas också av egenskapen analytical TTL .

Samla in ändringar från och med nu

När alternativet Start from timestamp har valts registreras inte alla tidigare åtgärder i containern.

Samla in borttagningar, mellanliggande uppdateringar och TTL:er

Funktionen för att samla in ändringsdata för analysarkivet samlar in borttagningar, mellanliggande uppdateringar och TTL-åtgärder. De insamlade borttagningarna och uppdateringarna kan tillämpas på mottagare som stöder borttagnings- och uppdateringsåtgärder. Värdet {_rid} identifierar posterna unikt och genom att ange {_rid} som nyckelkolumn på mottagarsidan återspeglas uppdaterings- och borttagningsåtgärderna på mottagaren.

Observera att TTL-åtgärder betraktas som borttagna. Kontrollera avsnittet källinställningar för att kontrollera lägesinformation och stöd för mellanliggande uppdateringar och borttagningar i mottagare.

Filtrera ändringsflödet för en viss typ av åtgärd

Du kan filtrera flödet för ändringsdatainsamling för en viss typ av åtgärd. Du kan till exempel endast selektivt samla in åtgärderna insert och update, vilket ignorerar åtgärderna user-delete och TTL-delete.

Tillämpa filter, projektioner och transformeringar i ändringsflödet via källfrågan

Du kan också använda en källfråga för att ange filter, projektioner och transformeringar, som alla skulle pushas ned till kolumnanalysarkivet. Här är ett exempel på en källfråga som bara samlar in inkrementella poster med filtret Category = 'Urban'. Den här exempelfrågan projicerar bara fem fält och tillämpar en enkel transformering:

SELECT ProductId, Product, Segment, concat(Manufacturer, '-', Category) as ManufacturerCategory
FROM c 
WHERE Category = 'Urban'

Flera CDC-processer

Du kan skapa flera processer för att använda CDC i analysarkivet. Den här metoden ger flexibilitet för att stödja olika scenarier och krav. En process kanske inte har några datatransformeringar och flera mottagare, men en annan kan ha utplattade data och en mottagare. Och de kan köras parallellt.

Dataflödesisolering, kortare svarstid och lägre TCO

Åtgärder i Cosmos DB-analysarkivet förbrukar inte de etablerade RU:erna och påverkar därför inte dina transaktionsarbetsbelastningar. Ändringsdatainsamling med analysarkiv har också lägre svarstid och lägre TCO. Den lägre svarstiden beror på analysarkivet som möjliggör bättre parallellitet för databehandling och minskar den övergripande TCO som gör att du kan öka kostnadseffektiviteten under dessa snabbt föränderliga ekonomiska förhållanden.

Scenarier

Här är vanliga scenarier där du kan använda ändringsdatainsamling och analysarkivet.

Förbruka inkrementella data från Cosmos DB

Du kan använda analysarkivets ändringsdatainsamling om du för närvarande använder eller planerar att använda:

  • Inkrementell datainsamling med hjälp av Azure Data Factory-Dataflöde eller aktiviteten Kopiera.
  • En gång batchbearbetning med Hjälp av Azure Data Factory.
  • StrömmaNde Cosmos DB-data
    • Analysarkivet har upp till 2 minuters svarstid för att synkronisera transaktionslagerdata. Du kan schemalägga Dataflöde i Azure Data Factory varje minut.
    • Om du behöver strömma utan ovanstående svarstid rekommenderar vi att du använder funktionen för ändringsflöde i transaktionsarkivet.
  • Samla in borttagningar, inkrementella ändringar, tillämpa filter på Cosmos DB-data.
    • Om du använder Azure Functions-utlösare eller något annat alternativ med ändringsflöde och vill samla in borttagningar, inkrementella ändringar, tillämpa transformeringar osv. Vi rekommenderar att du ändrar datainsamlingen i analysarkivet.

Inkrementell feed till valfri analysplattform

Funktionen för att samla in ändringsdata möjliggör en analyslösning från slutpunkt till slutpunkt som ger dig flexibiliteten att använda Azure Cosmos DB-data med någon av de mottagartyper som stöds. Mer information om mottagartyper som stöds finns i typer av mottagare som stöds av dataflöde. Med insamling av ändringsdata kan du även föra in Azure Cosmos DB-data i en centraliserad datasjö och koppla data till data från andra olika källor. Du kan platta ut data, partitionera dem och tillämpa fler transformeringar i Azure Synapse Analytics eller Azure Data Factory.

Ändra datainsamling i Azure Cosmos DB för MongoDB-containrar

Det länkade tjänstgränssnittet för API:et för MongoDB är inte tillgängligt i Azure Data Factory-dataflöden ännu. Du kan använda api:et för MongoDB:s kontoslutpunkt med det länkade tjänstgränssnittet Azure Cosmos DB for NoSQL tills den länkade Mongo-tjänsten stöds direkt.

I gränssnittet för en ny Länkad NoSQL-tjänst väljer du Ange manuellt för att ange Kontoinformation för Azure Cosmos DB. Här använder du kontots NoSQL-dokumentslutpunkt (exempel: https://<account-name>.documents.azure.com:443/) i stället för Mongo DB-slutpunkten (exempel: mongodb://<account-name>.mongo.cosmos.azure.com:10255/)

Nästa steg