Több száz terabájtnyi adat migrálása az Azure Cosmos DB-be

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Nosql MongoDB Cassandra Gremlin Táblázat

Az Azure Cosmos DB több terabájtnyi adatot tud tárolni. Nagy léptékű adatmigrálás elvégzésével áthelyezheti éles számítási feladatait az Azure Cosmos DB-be. Ez a cikk azokat a kihívásokat ismerteti, amelyek a nagy léptékű adatok az Azure Cosmos DB-be való áthelyezésével kapcsolatosak, továbbá bemutatja az eszközt, amely segít a kihívások leküzdésében, és az adatok az Azure Cosmos DB-be történő migrálásában. Ebben az esettanulmányban az ügyfél az Azure Cosmos DB API for NoSQL-t használta.

Mielőtt áttelepítené a teljes számítási feladatot az Azure Cosmos DB-be, migrálhatja az adatok egy részhalmazát az olyan szempontok ellenőrzéséhez, mint a partíciókulcs kiválasztása, a lekérdezési teljesítmény és az adatmodellezés. A megvalósíthatósági igazolás ellenőrzése után a teljes számítási feladatot áthelyezheti az Azure Cosmos DB-be.

Eszközök az adatmigráláshoz

Az Azure Cosmos DB migrálási stratégiái jelenleg eltérnek az API-választástól és az adatok méretétől függően. Kisebb adathalmazok migrálásához – az adatmodellezés ellenőrzéséhez, a lekérdezési teljesítményhez, a partíciókulcs választásához stb. – használhatja Azure Data Factory Azure Cosmos DB-összekötőjét. Ha ismeri a Sparkot, az Azure Cosmos DB Spark-összekötőt is használhatja az adatok migrálásához.

A nagy léptékű migrálásokkal kapcsolatos kihívások

Az adatok Azure Cosmos DB-be való migrálására szolgáló meglévő eszközök bizonyos korlátozásokkal rendelkeznek, amelyek különösen nagy méretekben válnak nyilvánvalóvá:

  • Korlátozott vertikális felskálázási képességek: Ahhoz, hogy az adatok terabájtjait a lehető leggyorsabban migrálhassa az Azure Cosmos DB-be, és hatékonyan felhasználhassa a teljes kiosztott átviteli sebességet, a migrálási ügyfeleknek korlátlanul fel kell tudniuk skálázni őket.

  • Az előrehaladás nyomon követésének és ellenőrzésének hiánya: Fontos nyomon követni a migrálási folyamatot, és ellenőrizni kell az ellenőrzőpontot a nagy adathalmazok migrálása során. Ellenkező esetben a migrálás során felmerülő hibák leállítják az áttelepítést, és a folyamatot teljesen el kell kezdenie. Nem lenne hatékony újraindítani a teljes migrálási folyamatot, ha annak 99%-a már befejeződött.

  • A kézbesítetlen levelek várólistájának hiánya: A nagy adathalmazokban bizonyos esetekben problémák merülhetnek fel a forrásadatok egyes részeivel kapcsolatban. Emellett átmeneti problémák is lehetnek az ügyféllel vagy a hálózattal kapcsolatban. Az ilyen esetek egyike sem okozhatja a teljes migrálás meghiúsulását. Bár a legtöbb migrálási eszköz robusztus újrapróbálkozési képességekkel rendelkezik, amelyek védelmet nyújtnak az időszakos problémák ellen, ez nem mindig elegendő. Ha például a forrásadat-dokumentumok kevesebb mint 0,01%-a nagyobb 2 MB-nál, akkor a dokumentum írása meghiúsul az Azure Cosmos DB-ben. Ideális esetben hasznos, ha a migrálási eszköz megőrzi ezeket a "sikertelen" dokumentumokat egy másik kézbesítetlen levélsorba, amely az áttelepítés után feldolgozható.

Ezen korlátozások közül számos ki van javítva olyan eszközök esetében, mint az Azure Data Factory, az Azure Data Migration Services.

Egyéni eszköz tömeges végrehajtói kódtárral

A fenti szakaszban ismertetett kihívások megoldhatók egy olyan egyéni eszközzel, amely egyszerűen felskálázható több példányra, és rugalmas az átmeneti hibákkal szemben. Emellett az egyéni eszköz szüneteltetheti és folytathatja a migrálást különböző ellenőrzőpontokon. Az Azure Cosmos DB már biztosítja a tömeges végrehajtói kódtárat , amely magában foglal néhány ilyen funkciót. A tömeges végrehajtói kódtár például már rendelkezik az átmeneti hibák kezelésére szolgáló funkcióval, és csomópontonként körülbelül 500 K kérelemegységet képes felskálázni egy csomópont szálainak felskálázására. A tömeges végrehajtói kódtár a forrásadatkészletet olyan mikro kötegekre is particionálja, amelyek egymástól függetlenül, ellenőrzőpont-készítés formájában működnek.

Az egyéni eszköz a tömeges végrehajtói kódtárat használja, és támogatja a horizontális felskálázást több ügyfél között, valamint a betöltési folyamat során felmerülő hibák nyomon követését. Az eszköz használatához a forrásadatokat Azure Data Lake Storage (ADLS) különböző fájljaira kell particionálva lennie, hogy a különböző migrálási feldolgozók átvehessék az egyes fájlokat, és betölthessék őket az Azure Cosmos DB-be. Az egyéni eszköz egy külön gyűjteményt használ, amely metaadatokat tárol az egyes forrásfájlok áttelepítési folyamatáról az ADLS-ben, és nyomon követi a velük kapcsolatos hibákat.

Az alábbi kép az egyéni eszköz használatával végzett migrálási folyamatot ismerteti. Az eszköz virtuális gépek készletén fut, és minden virtuális gép lekérdezi a nyomkövetési gyűjteményt az Azure Cosmos DB-ben, hogy bérletet szerezzen be az egyik forrásadatpartíción. Ha ez megtörtént, az eszköz beolvassa a forrásadatpartíciót, és betölti az Azure Cosmos DB-be a tömeges végrehajtói kódtár használatával. Ezután a nyomkövetési gyűjtemény frissül, hogy rögzítse az adatbetöltés folyamatát és a felmerült hibákat. Az adatpartíció feldolgozása után az eszköz megpróbálja lekérdezni a következő elérhető forráspartíciót. A folyamat a következő forráspartíciót dolgozza fel mindaddig, amíg az összes adat át nem migrálódik. Az eszköz forráskódja az Azure Cosmos DB tömeges betöltési adattárában érhető el.

Migrálási eszköz beállítása

A nyomkövetési gyűjtemény az alábbi példában látható módon tartalmaz dokumentumokat. Ezeket a dokumentumokat a forrásadatok minden partíciója esetében látni fogja. Minden dokumentum tartalmazza a forrásadat-partíció metaadatait, például a helyét, az áttelepítés állapotát és a hibákat (ha vannak):

{ 
  "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 
}

Az adatmigrálás előfeltételei

Az adatmigrálás megkezdése előtt figyelembe kell venni néhány előfeltételt:

Az adatméret becslése:

Előfordulhat, hogy a forrásadatok mérete nem pontosan megfelel az Azure Cosmos DB adatméretének. A forrásból beszúrhat néhány mintadokumentumot, hogy ellenőrizze az adatméretüket az Azure Cosmos DB-ben. A mintadokumentum méretétől függően az Azure Cosmos DB teljes adatmérete a migrálást követően megbecsülhető.

Ha például az Azure Cosmos DB-ben végzett migrálás után minden dokumentum körülbelül 1 KB, és körülbelül 60 milliárd dokumentum található a forrásadatkészletben, az azt jelenti, hogy az Azure Cosmos DB becsült mérete megközelíti a 60 TB-ot.

Tárolók előzetes létrehozása elegendő kérelemegységgel:

Bár az Azure Cosmos DB automatikusan skálázza fel a tárterületet, nem ajánlott a legkisebb tárolóméretből kiindulni. A kisebb tárolók alacsonyabb átviteli sebességgel rendelkeznek, ami azt jelenti, hogy a migrálás sokkal tovább tart. Ehelyett célszerű létrehozni a tárolókat a végső adatmérettel (az előző lépésben becsült módon), és győződjön meg arról, hogy az áttelepítési számítási feladat teljes mértékben felhasználja a kiosztott átviteli sebességet.

Az előző lépésben. Mivel az adatméret becsült mérete körülbelül 60 TB, a teljes adathalmaz elhelyezéséhez legalább 2,4 M kérelemegység-tárolóra van szükség.

A migrálás sebességének becslése:

Feltételezve, hogy a migrálási számítási feladat a teljes kiosztott átviteli sebességet fel tudja használni, a kiosztott teljes folyamat becslést adna az áttelepítési sebességről. Az előző példát folytatva 5 kérelemegységre van szükség egy 1 KB-os dokumentum írásához az Azure Cosmos DB API for NoSQL-fiókba. A 2,4 millió kérelemegység másodpercenként 480 000 dokumentum (vagy 480 MB/s) átvitelét teszi lehetővé. Ez azt jelenti, hogy a 60 TB-os teljes migrálás 125 000 másodpercet vagy körülbelül 34 órát vesz igénybe.

Ha azt szeretné, hogy a migrálás egy napon belül befejeződjön, növelje a kiosztott átviteli sebességet 5 millió kérelemegységre.

Az indexelés kikapcsolása:

Mivel a migrálást a lehető leghamarabb el kell végezni, célszerű minimálisra csökkenteni az időt és az indexek létrehozására fordított kérelemegységeket az egyes betöltött dokumentumokhoz. Az Azure Cosmos DB automatikusan indexeli az összes tulajdonságot, érdemes minimálisra csökkenteni az indexelést néhány kifejezésre, vagy teljesen kikapcsolni a migrálás során. A tároló indexelési szabályzatát kikapcsolhatja úgy, hogy az indexelésMode értékét a következő módon egyikre sem módosítja:

  { 
        "indexingMode": "none" 
  }

Az áttelepítés befejezése után frissítheti az indexelést.

Migrálási folyamat

Az előfeltételek teljesítése után az alábbi lépésekkel migrálhatja az adatokat:

  1. Először importálja az adatokat a forrásból a Azure Blob Storage. A migrálás sebességének növelése érdekében hasznos párhuzamosítani a különböző forráspartíciók között. Az áttelepítés megkezdése előtt a forrásadatkészletet 200 MB körüli méretű fájlokra kell particionálni.

  2. A tömeges végrehajtói kódtár felskálázható, így egyetlen ügyfél virtuális gépen 500 000 kérelemegységet használhat fel. Mivel az elérhető átviteli sebesség 5 millió kérelemegység, 10 Ubuntu 16.04 virtuális gépet (Standard_D32_v3) kell üzembe helyezni ugyanabban a régióban, ahol az Azure Cosmos DB-adatbázis található. Ezeket a virtuális gépeket a migrálási eszközzel és annak beállításfájljával kell előkészítenie.

  3. Futtassa az üzenetsor-lépést az egyik ügyfél virtuális gépen. Ez a lépés létrehozza a nyomkövetési gyűjteményt, amely megvizsgálja az ADLS-tárolót, és létrehoz egy folyamatkövetési dokumentumot a forrásadatkészlet partíciófájljaihoz.

  4. Ezután futtassa az importálási lépést az összes ügyfél virtuális gépen. Mindegyik ügyfél tulajdonjogot vehet fel egy forráspartíción, és betöltheti az adatait az Azure Cosmos DB-be. Miután elkészült, és az állapota frissült a nyomkövetési gyűjteményben, az ügyfelek lekérdezhetik a következő elérhető forráspartíciót a nyomkövetési gyűjteményben.

  5. Ez a folyamat a forráspartíciók teljes készletének betöltéséig folytatódik. Az összes forráspartíció feldolgozása után az eszközt újra kell futtatni a hibajavítási módban ugyanazon a nyomkövetési gyűjteményen. Ez a lépés a hibák miatt újra feldolgozandó forráspartíciók azonosításához szükséges.

  6. A hibák némelyike a forrásadatok helytelen dokumentumai miatt fordulhat elő. Ezeket azonosítani és javítani kell. Ezután újra kell futtatnia az importálási lépést a sikertelen partíciókon, hogy újra betöltse őket.

Az áttelepítés befejezése után ellenőrizheti, hogy az Azure Cosmos DB-ben a dokumentumszám megegyezik-e a forrásadatbázis dokumentumszámával. Ebben a példában az Azure Cosmos DB teljes mérete 65 terabájtra változott. A migrálás után az indexelés szelektíven be van kapcsolva, és a kérelemegységek a számítási feladat műveletei által megkövetelt szintre csökkenthetők.

Következő lépések

  • További információ: a . NET-ben és a Java-ban a tömeges végrehajtói kódtárat használó mintaalkalmazások kipróbálásával.
  • A tömeges végrehajtói kódtár integrálva van az Azure Cosmos DB Spark-összekötőbe. További információt az Azure Cosmos DB Spark-összekötőről szóló cikkben talál.
  • A nagy léptékű migrálásokkal kapcsolatos további segítségért lépjen kapcsolatba az Azure Cosmos DB termékcsapatával, és hozzon létre egy támogatási jegyet az "Általános tanácsadás" problématípus és a "Nagy méretű (TB+) migrálások" altípus alatt.
  • Kapacitástervezést szeretne végezni az Azure Cosmos DB-be való migráláshoz? A kapacitástervezéshez használhatja a meglévő adatbázisfürtre vonatkozó információkat.