Migrowanie setek terabajtów danych do usługi Azure Cosmos DB

  • Artykuł

DOTYCZY: Nosql Mongodb Cassandra Gremlin Tabeli

Usługa Azure Cosmos DB może przechowywać terabajty danych. Można przeprowadzić migrację danych na dużą skalę, aby przenieść obciążenie produkcyjne do usługi Azure Cosmos DB. W tym artykule opisano wyzwania związane z przenoszeniem danych na dużą skalę do usługi Azure Cosmos DB oraz przedstawiono narzędzie, które pomaga sprostać tym wyzwaniom i migruje dane do usługi Azure Cosmos DB. W tej analizie przypadku klient użył interfejsu API usługi Azure Cosmos DB dla noSQL.

Przed przeprowadzeniem migracji całego obciążenia do usługi Azure Cosmos DB możesz przeprowadzić migrację podzestawu danych, aby zweryfikować niektóre aspekty, takie jak wybór klucza partycji, wydajność zapytań i modelowanie danych. Po zweryfikowaniu weryfikacji koncepcji możesz przenieść całe obciążenie do usługi Azure Cosmos DB.

Narzędzia do migracji danych

Strategie migracji usługi Azure Cosmos DB różnią się obecnie w zależności od wyboru interfejsu API i rozmiaru danych. Aby migrować mniejsze zestawy danych — do sprawdzania poprawności modelowania danych, wydajności zapytań, wyboru klucza partycji itp. — można użyć łącznika usługi Azure Cosmos DB Azure Data Factory. Jeśli znasz platformę Spark, możesz również użyć łącznika Spark usługi Azure Cosmos DB do migracji danych.

Wyzwania związane z migracjami na dużą skalę

Istniejące narzędzia do migrowania danych do usługi Azure Cosmos DB mają pewne ograniczenia, które stają się szczególnie widoczne na dużych skalach:

  • Ograniczone możliwości skalowania w poziomie: aby migrować terabajty danych do usługi Azure Cosmos DB tak szybko, jak to możliwe, i aby efektywnie korzystać z całej aprowizowanej przepływności, klienci migracji powinni mieć możliwość skalowania w poziomie na czas nieokreślony.

  • Brak śledzenia postępu i wskazywania kontrolnego: ważne jest, aby śledzić postęp migracji i sprawdzać podczas migrowania dużych zestawów danych. W przeciwnym razie wszelkie błędy występujące podczas migracji spowodują zatrzymanie migracji i konieczne będzie rozpoczęcie procesu od podstaw. Ponowne uruchomienie całego procesu migracji nie byłoby wydajne, gdy 99% zostało już ukończonych.

  • Brak kolejki utraconych komunikatów: w przypadku dużych zestawów danych w niektórych przypadkach mogą występować problemy z częściami danych źródłowych. Ponadto mogą wystąpić przejściowe problemy z klientem lub siecią. Jeden z tych przypadków nie powinien powodować niepowodzenia całej migracji. Mimo że większość narzędzi migracji ma niezawodne możliwości ponawiania prób, które chronią przed sporadyczne problemy, nie zawsze jest to wystarczające. Na przykład jeśli rozmiar dokumentów danych źródłowych jest mniejszy niż 0,01%, spowoduje to niepowodzenie zapisu dokumentu w usłudze Azure Cosmos DB. Najlepiej jest, aby narzędzie migracji utrwalało te "nieudane" dokumenty do innej kolejki utraconych komunikatów, które można przetworzyć po migracji.

Wiele z tych ograniczeń jest naprawianych w przypadku narzędzi, takich jak Azure Data Factory, Azure Data Migration Services.

Narzędzie niestandardowe z biblioteką funkcji wykonawczej operacji zbiorczych

Wyzwania opisane w powyższej sekcji można rozwiązać przy użyciu niestandardowego narzędzia, które można łatwo skalować w poziomie w wielu wystąpieniach i jest odporny na błędy przejściowe. Ponadto narzędzie niestandardowe może wstrzymywać i wznawiać migrację w różnych punktach kontrolnych. Usługa Azure Cosmos DB udostępnia już bibliotekę funkcji wykonawczej operacji zbiorczych , która zawiera niektóre z tych funkcji. Na przykład biblioteka funkcji wykonawczej operacji zbiorczych ma już funkcję obsługi błędów przejściowych i może skalować wątki w poziomie w jednym węźle, aby korzystać z około 500 K JEDNOSTEK RU na węzeł. Biblioteka funkcji wykonawczej operacji zbiorczych dzieli również źródłowy zestaw danych na mikrosady, które są obsługiwane niezależnie jako forma tworzenia punktów kontrolnych.

Narzędzie niestandardowe używa biblioteki funkcji wykonawczej operacji zbiorczych i obsługuje skalowanie w poziomie na wielu klientach oraz śledzenie błędów podczas procesu pozyskiwania. Aby użyć tego narzędzia, dane źródłowe powinny być podzielone na odrębne pliki w usłudze Azure Data Lake Storage (ADLS), aby różne procesy robocze migracji mogły odebrać każdy plik i pozyskać je do usługi Azure Cosmos DB. Narzędzie niestandardowe korzysta z oddzielnej kolekcji, która przechowuje metadane dotyczące postępu migracji dla każdego pojedynczego pliku źródłowego w usłudze ADLS i śledzi wszelkie skojarzone z nimi błędy.

Na poniższej ilustracji opisano proces migracji przy użyciu tego narzędzia niestandardowego. Narzędzie jest uruchomione na zestawie maszyn wirtualnych, a każda maszyna wirtualna wysyła zapytanie do kolekcji śledzenia w usłudze Azure Cosmos DB w celu uzyskania dzierżawy na jednej z partycji danych źródłowych. Po wykonaniu tej czynności źródłowa partycja danych jest odczytywana przez narzędzie i pozyskiwana do usługi Azure Cosmos DB przy użyciu biblioteki funkcji wykonawczej operacji zbiorczych. Następnie kolekcja śledzenia zostanie zaktualizowana w celu zarejestrowania postępu pozyskiwania danych i napotkanych błędów. Po przetworzeniu partycji danych narzędzie próbuje wysłać zapytanie o następną dostępną partycję źródłową. Kontynuuje przetwarzanie następnej partycji źródłowej do momentu zmigrowania wszystkich danych. Kod źródłowy narzędzia jest dostępny w repozytorium pozyskiwania zbiorczego usługi Azure Cosmos DB .

Konfiguracja narzędzia migracji

Kolekcja śledzenia zawiera dokumenty, jak pokazano w poniższym przykładzie. Takie dokumenty będą widoczne dla każdej partycji w danych źródłowych. Każdy dokument zawiera metadane partycji danych źródłowych, takie jak jego lokalizacja, stan migracji i błędy (jeśli istnieją):

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

Wymagania wstępne dotyczące migracji danych

Przed rozpoczęciem migracji danych należy wziąć pod uwagę kilka wymagań wstępnych:

Szacowanie rozmiaru danych:

Rozmiar danych źródłowych może nie być dokładnie mapowy na rozmiar danych w usłudze Azure Cosmos DB. Aby sprawdzić rozmiar danych w usłudze Azure Cosmos DB, można wstawić kilka przykładowych dokumentów ze źródła. W zależności od rozmiaru przykładowego dokumentu można oszacować całkowity rozmiar danych w usłudze Azure Cosmos DB po migracji.

Jeśli na przykład każdy dokument po migracji w usłudze Azure Cosmos DB wynosi około 1 KB, a w źródłowym zestawie danych znajduje się około 60 miliardów dokumentów, oznaczałoby to, że szacowany rozmiar w usłudze Azure Cosmos DB będzie zbliżony do 60 TB.

Wstępne tworzenie kontenerów z wystarczającą ilością jednostek RU:

Mimo że usługa Azure Cosmos DB automatycznie skaluje magazyn w poziomie, nie zaleca się rozpoczynania od najmniejszego rozmiaru kontenera. Mniejsze kontenery mają niższą dostępność przepływności, co oznacza, że migracja potrwa znacznie dłużej. Zamiast tego warto utworzyć kontenery z ostatecznym rozmiarem danych (szacowanym w poprzednim kroku) i upewnić się, że obciążenie migracji w pełni zużywa aprowizowaną przepływność.

W poprzednim kroku. ponieważ rozmiar danych oszacowano na około 60 TB, do obsługi całego zestawu danych wymagany jest kontener o rozmiarze co najmniej 2,4 M JEDNOSTEK RU.

Szacowanie szybkości migracji:

Zakładając, że obciążenie migracji może korzystać z całej aprowizowanej przepływności, aprowizowanie w całym systemie zapewni oszacowanie szybkości migracji. Kontynuując poprzedni przykład, 5 jednostek RU jest wymaganych do zapisania dokumentu 1 KB do interfejsu API usługi Azure Cosmos DB dla konta NoSQL. 2,4 miliona jednostek RU umożliwiłoby transfer 480 000 dokumentów na sekundę (lub 480 MB/s). Oznacza to, że całkowita migracja 60 TB potrwa 125 000 sekund lub około 34 godziny.

Jeśli chcesz, aby migracja została ukończona w ciągu dnia, należy zwiększyć aprowizowaną przepływność do 5 milionów jednostek RU.

Wyłącz indeksowanie:

Ponieważ migracja powinna zostać ukończona tak szybko, jak to możliwe, zaleca się zminimalizowanie czasu i jednostek RU spędzonych na tworzeniu indeksów dla każdego pozyskanego dokumentu. Usługa Azure Cosmos DB automatycznie indeksuje wszystkie właściwości. Warto zminimalizować indeksowanie do wybranych kilku terminów lub wyłączyć ją całkowicie na potrzeby migracji. Zasady indeksowania kontenera można wyłączyć, zmieniając wartość indexingMode na brak, jak pokazano poniżej:

  { 
        "indexingMode": "none" 
  }

Po zakończeniu migracji można zaktualizować indeksowanie.

Proces migracji

Po ukończeniu wymagań wstępnych można migrować dane, wykonując następujące czynności:

  1. Najpierw zaimportuj dane ze źródła do Azure Blob Storage. Aby zwiększyć szybkość migracji, warto zrównać różne partycje źródłowe. Przed rozpoczęciem migracji źródłowy zestaw danych powinien zostać podzielony na pliki o rozmiarze około 200 MB.

  2. Biblioteka funkcji wykonawczej operacji zbiorczych może być skalowana w górę, aby korzystać z 500 000 jednostek RU na pojedynczej maszynie wirtualnej klienta. Ponieważ dostępna przepływność wynosi 5 milionów jednostek RU, należy aprowizować 10 maszyn wirtualnych z systemem Ubuntu 16.04 (Standard_D32_v3) w tym samym regionie, w którym znajduje się baza danych usługi Azure Cosmos DB. Należy przygotować te maszyny wirtualne za pomocą narzędzia migracji i jego pliku ustawień.

  3. Uruchom krok kolejki na jednej z maszyn wirtualnych klienta. Ten krok tworzy kolekcję śledzenia, która skanuje kontener usługi ADLS i tworzy dokument śledzenia postępu dla każdego z plików partycji zestawu danych źródłowych.

  4. Następnie uruchom krok importowania na wszystkich maszynach wirtualnych klienta. Każdy z klientów może przejąć własność na partycji źródłowej i pozyskiwać dane do usługi Azure Cosmos DB. Po zakończeniu i zaktualizowaniu stanu w kolekcji śledzenia klienci mogą następnie wykonywać zapytania o następną dostępną partycję źródłową w kolekcji śledzenia.

  5. Ten proces jest kontynuowany do momentu pozyskiwania całego zestawu partycji źródłowych. Po przetworzeniu wszystkich partycji źródłowych narzędzie powinno zostać uruchomione ponownie w trybie korekty błędów w tej samej kolekcji śledzenia. Ten krok jest wymagany do zidentyfikowania partycji źródłowych, które powinny zostać ponownie przetworzone z powodu błędów.

  6. Niektóre z tych błędów mogą być spowodowane nieprawidłowymi dokumentami w danych źródłowych. Należy je zidentyfikować i naprawić. Następnie należy ponownie uruchomić krok importowania na partycjach, które zakończyły się niepowodzeniem, aby je ponownie pozyskać.

Po zakończeniu migracji można sprawdzić, czy liczba dokumentów w usłudze Azure Cosmos DB jest taka sama jak liczba dokumentów w źródłowej bazie danych. W tym przykładzie łączny rozmiar w usłudze Azure Cosmos DB okazał się wynosić 65 terabajtów. Po migracji indeksowanie może być selektywnie włączone, a jednostki RU można obniżyć do poziomu wymaganego przez operacje obciążenia.

Następne kroki