Migrera hundratals terabyte data till Azure Cosmos DB

  • Artikel

GÄLLER FÖR: Nosql Mongodb Cassandra Gremlin Tabell

Azure Cosmos DB kan lagra flera terabyte data. Du kan utföra en storskalig datamigrering för att flytta din produktionsarbetsbelastning till Azure Cosmos DB. I den här artikeln beskriver vi utmaningarna med att flytta storskaliga data till Azure Cosmos DB och introducerar ett verktyg som hjälper dig med migreringen. I den här fallstudien använde kunden Azure Cosmos DB API för NoSQL.

Innan du migrerar hela arbetsbelastningen till Azure Cosmos DB kan du migrera en delmängd data för att verifiera vissa aspekter som val av partitionsnyckel, frågeprestanda och datamodellering. När du har verifierat konceptbeviset kan du flytta hela arbetsbelastningen till Azure Cosmos DB.

Verktyg för datamigrering

Azure Cosmos DB-migreringsstrategierna skiljer sig för närvarande beroende på API-valet och storleken på data. Om du vill migrera mindre datauppsättningar – för att verifiera datamodellering, frågeprestanda, val av partitionsnyckel osv. – kan du använda Azure Data Factory Azure Cosmos DB-anslutningsapp. Om du är bekant med Spark kan du också välja att använda Azure Cosmos DB Spark-anslutningsappen för att migrera data.

Utmaningar för storskaliga migreringar

De befintliga verktygen för att migrera data till Azure Cosmos DB har vissa begränsningar som blir särskilt uppenbara i stor skala:

  • Begränsade utskalningsfunktioner: För att migrera terabyte med data till Azure Cosmos DB så snabbt som möjligt och för att effektivt använda hela det etablerade dataflödet bör migreringsklienterna ha möjlighet att skala ut på obestämd tid.

  • Brist på förloppsspårning och kontrollpunkter: Det är viktigt att spåra migreringsförloppet och kontrollera vid migrering av stora datamängder. Annars stoppar eventuella fel som inträffar under migreringen migreringen och du måste starta processen från grunden. Det skulle inte vara produktivt att starta om hela migreringsprocessen när 99 % av den redan har slutförts.

  • Brist på obeställbar kö: I stora datamängder kan det i vissa fall uppstå problem med delar av källdata. Dessutom kan det finnas tillfälliga problem med klienten eller nätverket. Något av dessa fall bör inte orsaka att hela migreringen misslyckas. Även om de flesta migreringsverktyg har robusta återförsöksfunktioner som skyddar mot tillfälliga problem räcker det inte alltid. Om till exempel mindre än 0,01 % av källdatadokumenten är större än 2 MB kommer dokumentskrivningen att misslyckas i Azure Cosmos DB. Helst är det användbart för migreringsverktyget att spara dessa "misslyckade" dokument i en annan kö med obeställbara meddelanden, som kan bearbetas efter migreringen.

Många av dessa begränsningar åtgärdas för verktyg som Azure Data Factory och Azure Data Migration Services.

Anpassat verktyg med massexecutor-bibliotek

Utmaningarna som beskrivs i avsnittet ovan kan lösas med hjälp av ett anpassat verktyg som enkelt kan skalas ut över flera instanser och som är motståndskraftigt mot tillfälliga fel. Dessutom kan det anpassade verktyget pausa och återuppta migreringen vid olika kontrollpunkter. Azure Cosmos DB tillhandahåller redan massexecutor-biblioteket som innehåller några av dessa funktioner. Till exempel har massexecutor-biblioteket redan funktioner för att hantera tillfälliga fel och kan skala ut trådar i en enda nod för att förbruka cirka 500 K RU:er per nod. Massexecutor-biblioteket partitionerar också källdatauppsättningen i mikrobatchar som hanteras oberoende av varandra som en form av kontrollpunkter.

Det anpassade verktyget använder massexecutor-biblioteket och stöder utskalning över flera klienter och för att spåra fel under inmatningsprocessen. Om du vill använda det här verktyget ska källdata partitioneras i distinkta filer i Azure Data Lake Storage (ADLS) så att olika migreringsarbetare kan hämta varje fil och mata in dem i Azure Cosmos DB. Det anpassade verktyget använder en separat samling som lagrar metadata om migreringsförloppet för varje enskild källfil i ADLS och spårar eventuella fel som är associerade med dem.

Följande bild beskriver migreringsprocessen med det här anpassade verktyget. Verktyget körs på en uppsättning virtuella datorer och varje virtuell dator frågar spårningssamlingen i Azure Cosmos DB för att hämta ett lån på en av källdatapartitionerna. När detta är klart läss källdatapartitionen av verktyget och matas in i Azure Cosmos DB med hjälp av massexecutor-biblioteket. Därefter uppdateras spårningssamlingen för att registrera förloppet för datainmatning och eventuella fel som påträffas. När en datapartition har bearbetats försöker verktyget fråga efter nästa tillgängliga källpartition. Den fortsätter att bearbeta nästa källpartition tills alla data har migrerats. Källkoden för verktyget finns på lagringsplatsen för massinmatning i Azure Cosmos DB .

Installation av migreringsverktyg

Spårningssamlingen innehåller dokument som visas i följande exempel. Du ser sådana dokument för varje partition i källdata. Varje dokument innehåller metadata för källdatapartitionen, till exempel dess plats, migreringsstatus och fel (om sådana finns):

{ 
  "owner": "25812@bulkimporttest07", 
  "jsonStoreEntityImportResponse": { 
    "numberOfDocumentsReceived": 446688, 
    "isError": false, 
    "totalRequestUnitsConsumed": 3950252.2800000003, 
    "errorInfo": [], 
    "totalTimeTakenInSeconds": 188, 
    "numberOfDocumentsImported": 446688 
  }, 
  "storeType": "AZURE_BLOB", 
  "name": "sourceDataPartition", 
  "location": "sourceDataPartitionLocation", 
  "id": "sourceDataPartitionId", 
  "isInProgress": false, 
  "operation": "unpartitioned-writes", 
  "createDate": { 
    "seconds": 1561667225, 
    "nanos": 146000000 
  }, 
  "completeDate": { 
    "seconds": 1561667515, 
    "nanos": 180000000 
  }, 
  "isComplete": true 
}

Förutsättningar för datamigrering

Innan datamigreringen startar finns det några förutsättningar att tänka på:

Beräkna datastorleken:

Källdatastorleken kanske inte exakt mappas till datastorleken i Azure Cosmos DB. Några exempeldokument från källan kan infogas för att kontrollera datastorleken i Azure Cosmos DB. Beroende på exempeldokumentets storlek kan den totala datastorleken i Azure Cosmos DB efter migreringen beräknas.

Om till exempel varje dokument efter migreringen i Azure Cosmos DB är cirka 1 KB och om det finns cirka 60 miljarder dokument i källdatauppsättningen skulle det innebära att den uppskattade storleken i Azure Cosmos DB skulle vara nära 60 TB.

Skapa containrar i förväg med tillräckligt många RU:er:

Även om Azure Cosmos DB skalar ut lagringen automatiskt är det inte lämpligt att börja från den minsta containerstorleken. Mindre containrar har lägre tillgänglighet för dataflöde, vilket innebär att migreringen tar mycket längre tid att slutföra. I stället är det användbart att skapa containrarna med den slutliga datastorleken (som uppskattas i föregående steg) och se till att migreringsarbetsbelastningen förbrukar det etablerade dataflödet fullt ut.

I föregående steg. Eftersom datastorleken uppskattades till cirka 60 TB krävs en container med minst 2,4 M RU:er för att hantera hela datamängden.

Beräkna migreringshastigheten:

Förutsatt att migreringsarbetsbelastningen kan förbruka hela det etablerade dataflödet skulle den etablerade genomgående ge en uppskattning av migreringshastigheten. Om du fortsätter med föregående exempel krävs 5 RU:er för att skriva ett dokument på 1 KB till Azure Cosmos DB API för NoSQL-konto. 2,4 miljoner RU:er skulle tillåta överföring av 480 000 dokument per sekund (eller 480 MB/s). Det innebär att den fullständiga migreringen på 60 TB tar 125 000 sekunder eller cirka 34 timmar.

Om du vill att migreringen ska slutföras inom en dag bör du öka det etablerade dataflödet till 5 miljoner RU:er.

Inaktivera indexeringen:

Eftersom migreringen bör slutföras så snart som möjligt rekommenderar vi att du minimerar tiden och ru:erna som ägnas åt att skapa index för vart och ett av de inmatade dokumenten. Azure Cosmos DB indexerar automatiskt alla egenskaper. Det är värt att minimera indexeringen till några få termer eller inaktivera den helt under migreringen. Du kan inaktivera containerns indexeringsprincip genom att ändra indexingMode till none enligt nedan:

  { 
        "indexingMode": "none" 
  }

När migreringen är klar kan du uppdatera indexeringen.

Migreringsprocessen

När förutsättningarna har slutförts kan du migrera data med följande steg:

  1. Importera först data från källan till Azure Blob Storage. Om du vill öka migreringens hastighet är det bra att parallellisera mellan olika källpartitioner. Innan du påbörjar migreringen bör källdatauppsättningen partitioneras i filer med en storlek på cirka 200 MB.

  2. Massexecutor-biblioteket kan skalas upp för att förbruka 500 000 RU:er på en enda virtuell klientdator. Eftersom det tillgängliga dataflödet är 5 miljoner RU:er bör 10 virtuella Ubuntu 16,04-datorer (Standard_D32_v3) etableras i samma region där din Azure Cosmos DB-databas finns. Du bör förbereda de här virtuella datorerna med migreringsverktyget och dess inställningsfil.

  3. Kör kösteget på en av de virtuella klientdatorerna. Det här steget skapar spårningssamlingen, som genomsöker ADLS-containern och skapar ett dokument för förloppsspårning för var och en av källdatauppsättningens partitionsfiler.

  4. Kör sedan importsteget på alla virtuella klientdatorer. Var och en av klienterna kan bli ägare till en källpartition och mata in sina data i Azure Cosmos DB. När den har slutförts och dess status har uppdaterats i spårningssamlingen kan klienterna sedan fråga efter nästa tillgängliga källpartition i spårningssamlingen.

  5. Den här processen fortsätter tills hela uppsättningen källpartitioner har matats in. När alla källpartitioner har bearbetats ska verktyget köras igen i felkorrigeringsläget i samma spårningssamling. Det här steget krävs för att identifiera de källpartitioner som ska bearbetas på nytt på grund av fel.

  6. Vissa av dessa fel kan bero på felaktiga dokument i källdata. Dessa bör identifieras och åtgärdas. Därefter bör du köra importsteget igen på de partitioner som misslyckades för att skicka om dem.

När migreringen är klar kan du verifiera att antalet dokument i Azure Cosmos DB är samma som antalet dokument i källdatabasen. I det här exemplet blev den totala storleken i Azure Cosmos DB 65 terabyte. Efter migreringen kan indexering aktiveras selektivt och RU:erna kan sänkas till den nivå som krävs av arbetsbelastningens åtgärder.

Nästa steg