Migrowanie danych z lokalnego klastra Hadoop do usługi Azure Storage przy użyciu usługi Azure Data Factory

DOTYCZY: Azure Data Factory Azure Synapse Analytics

Usługa Azure Data Factory zapewnia wydajny, niezawodny i ekonomiczny mechanizm migracji danych na dużą skalę z lokalnego systemu plików HDFS do usługi Azure Blob Storage lub Azure Data Lake Storage Gen2.

Usługa Data Factory oferuje dwa podstawowe podejścia do migrowania danych z lokalnego systemu plików HDFS na platformę Azure. Możesz wybrać podejście na podstawie swojego scenariusza.

• Tryb DistCp usługi Data Factory (zalecany): w usłudze Data Factory możesz użyć narzędzia DistCp (rozproszonej kopii) do kopiowania plików w postaci "jak to jest" do usługi Azure Blob Storage (w tym kopiowania etapowego) lub usługi Azure Data Lake Store Gen2. Użyj usługi Data Factory zintegrowanej z narzędziem DistCp, aby skorzystać z istniejącego zaawansowanego klastra w celu uzyskania najlepszej przepływności kopiowania. Możesz również skorzystać z elastycznego planowania i ujednoliconego środowiska monitorowania z usługi Data Factory. W zależności od konfiguracji usługi Data Factory działanie kopiowania automatycznie konstruuje polecenie DistCp, przesyła dane do klastra Hadoop, a następnie monitoruje stan kopiowania. Zalecamy tryb DistCp usługi Data Factory do migrowania danych z lokalnego klastra Hadoop do platformy Azure.
• Natywny tryb środowiska Integration Runtime usługi Data Factory: DistCp nie jest opcją we wszystkich scenariuszach. Na przykład w środowisku sieci wirtualnych platformy Azure narzędzie DistCp nie obsługuje prywatnej komunikacji równorzędnej usługi Azure ExpressRoute z punktem końcowym sieci wirtualnej usługi Azure Storage. Ponadto w niektórych przypadkach nie chcesz używać istniejącego klastra Hadoop jako aparatu do migrowania danych, aby nie stosować dużych obciążeń w klastrze, co może mieć wpływ na wydajność istniejących zadań ETL. Zamiast tego możesz użyć natywnej funkcji środowiska Integration Runtime usługi Data Factory jako aparatu, który kopiuje dane z lokalnego systemu plików HDFS na platformę Azure.

Ten artykuł zawiera następujące informacje o obu podejściach:

Wydajność

W trybie DistCp usługi Data Factory przepływność jest taka sama jak w przypadku niezależnego używania narzędzia DistCp. Tryb DistCp usługi Data Factory maksymalizuje pojemność istniejącego klastra Hadoop. Narzędzia DistCp można używać do kopiowania dużych między klastrami lub wewnątrz klastra.

Narzędzie DistCp używa usługi MapReduce do efektu dystrybucji, obsługi błędów i odzyskiwania oraz raportowania. Rozwija listę plików i katalogów do danych wejściowych na potrzeby mapowania zadań. Każde zadanie kopiuje partycję pliku określoną na liście źródłowej. Za pomocą usługi Data Factory zintegrowanej z narzędziem DistCp można tworzyć potoki w celu pełnego wykorzystania przepustowości sieci, liczby operacji we/wy na sekundę magazynu i przepustowości w celu zmaksymalizowania przepływności przenoszenia danych dla środowiska.

Natywny tryb środowiska Integration Runtime usługi Data Factory umożliwia również równoległość na różnych poziomach. Równoległość umożliwia pełne wykorzystanie przepustowości sieci, liczby operacji we/wy na sekundę magazynu i przepustowości w celu zmaksymalizowania przepływności przenoszenia danych:

• Jedno działanie kopiowania może korzystać ze skalowalnych zasobów obliczeniowych. Za pomocą własnego środowiska Integration Runtime można ręcznie skalować maszynę w górę lub skalować w poziomie do wielu maszyn (do czterech węzłów). Jedno działanie kopiowania partycjonuje jego plik ustawiony we wszystkich węzłach.
• Jedno działanie kopiowania odczytuje dane i zapisuje je w magazynie danych przy użyciu wielu wątków.
• Przepływ sterowania usługi Data Factory może równolegle uruchamiać wiele działań kopiowania. Można na przykład użyć pętli Dla każdego.

Aby uzyskać więcej informacji, zobacz przewodnik dotyczący wydajności działania kopiowania.

Odporność

W trybie DistCp usługi Data Factory można użyć różnych parametrów wiersza polecenia DistCp (na przykład -i, ignorować błędy lub -updatezapisywać dane, gdy plik źródłowy i docelowy różnią się rozmiarem) dla różnych poziomów odporności.

W trybie natywnego środowiska Integration Runtime usługi Data Factory w jednym działaniu kopiowania usługa Data Factory ma wbudowany mechanizm ponawiania prób. Może obsługiwać określony poziom przejściowych błędów w magazynach danych lub w sieci bazowej.

Podczas kopiowania binarnego z lokalnego systemu plików HDFS do usługi Blob Storage i z lokalnego systemu plików HDFS do usługi Data Lake Store Gen2 usługa Data Factory automatycznie wykonuje punkty kontrolne w dużym stopniu. Jeśli uruchomienie działania kopiowania zakończy się niepowodzeniem lub upłynął limit czasu, po kolejnym ponowieniu próby (upewnij się, że liczba ponownych prób wynosi > 1), kopia zostanie wznowiona z ostatniego punktu awarii zamiast rozpoczynać się od początku.

Bezpieczeństwo sieci

Domyślnie usługa Data Factory przesyła dane z lokalnego systemu plików HDFS do usługi Blob Storage lub Azure Data Lake Storage Gen2 przy użyciu szyfrowanego połączenia za pośrednictwem protokołu HTTPS. Protokół HTTPS zapewnia szyfrowanie danych podczas przesyłania i uniemożliwia podsłuchiwanie i ataki typu man-in-the-middle.

Alternatywnie, jeśli nie chcesz, aby dane zostały przesłane za pośrednictwem publicznego Internetu, w celu zwiększenia bezpieczeństwa możesz przesyłać dane za pośrednictwem łącza prywatnej komunikacji równorzędnej za pośrednictwem usługi ExpressRoute.

Architektura rozwiązania

Ten obraz przedstawia migrowanie danych za pośrednictwem publicznego Internetu:

• W tej architekturze dane są bezpiecznie przesyłane przy użyciu protokołu HTTPS za pośrednictwem publicznego Internetu.
• Zalecamy używanie trybu DistCp usługi Data Factory w środowisku sieci publicznej. Możesz skorzystać z zaawansowanego istniejącego klastra, aby uzyskać najlepszą przepływność kopiowania. Możesz również korzystać z elastycznego planowania i ujednoliconego środowiska monitorowania z usługi Data Factory.
• W przypadku tej architektury należy zainstalować własne środowisko Integration Runtime usługi Data Factory na maszynie z systemem Windows za zaporą firmową, aby przesłać polecenie DistCp do klastra Hadoop i monitorować stan kopiowania. Ponieważ maszyna nie jest aparatem, który będzie przenosić dane (tylko w celu sterowania), pojemność maszyny nie ma wpływu na przepływność przenoszenia danych.
• Obsługiwane są istniejące parametry z polecenia DistCp.

Ten obraz przedstawia migrowanie danych za pośrednictwem łącza prywatnego:

• W tej architekturze dane są migrowane za pośrednictwem łącza prywatnej komunikacji równorzędnej za pośrednictwem usługi Azure ExpressRoute. Dane nigdy nie przechodzą przez publiczny Internet.
• Narzędzie DistCp nie obsługuje prywatnej komunikacji równorzędnej usługi ExpressRoute z punktem końcowym sieci wirtualnej usługi Azure Storage. Zalecamy użycie natywnej funkcji usługi Data Factory za pośrednictwem środowiska Integration Runtime w celu przeprowadzenia migracji danych.
• W przypadku tej architektury należy zainstalować własne środowisko Integration Runtime usługi Data Factory na maszynie wirtualnej z systemem Windows w sieci wirtualnej platformy Azure. Możesz ręcznie skalować maszynę wirtualną w górę lub skalować w poziomie do wielu maszyn wirtualnych, aby w pełni wykorzystać operacje we/wy sieci i magazynu na sekundę lub przepustowość.
• Zalecana konfiguracja do rozpoczęcia od dla każdej maszyny wirtualnej platformy Azure (z zainstalowanym własnym środowiskiem Integration Runtime usługi Data Factory) jest Standard_D32s_v3 z 32 procesorami wirtualnymi i 128 GB pamięci. Możesz monitorować użycie procesora CPU i pamięci maszyny wirtualnej podczas migracji danych, aby sprawdzić, czy chcesz skalować maszynę wirtualną w górę, aby uzyskać lepszą wydajność, czy skalować maszynę wirtualną w dół, aby zmniejszyć koszty.
• Można również skalować w poziomie, kojarząc maksymalnie cztery węzły maszyn wirtualnych z jednym własnym środowiskiem Integration Runtime. Pojedyncze zadanie kopiowania uruchomione względem własnego środowiska Integration Runtime automatycznie partycjonuje zestaw plików i używa wszystkich węzłów maszyny wirtualnej do równoległego kopiowania plików. W celu zapewnienia wysokiej dostępności zalecamy rozpoczęcie pracy z dwoma węzłami maszyny wirtualnej, aby uniknąć scenariusza awarii pojedynczego punktu awarii podczas migracji danych.
• Jeśli używasz tej architektury, dostępna jest początkowa migracja danych migawek i migracja danych różnicowych.

Najlepsze rozwiązania dotyczące implementacji

Zalecamy stosowanie tych najlepszych rozwiązań podczas implementowania migracji danych.

Uwierzytelnianie i zarządzanie poświadczeniami

• Aby przeprowadzić uwierzytelnianie w systemie plików HDFS, można użyć systemu Windows (Kerberos) lub anonimowego.
• Wiele typów uwierzytelniania jest obsługiwanych w przypadku nawiązywania połączenia z usługą Azure Blob Storage. Zdecydowanie zalecamy używanie tożsamości zarządzanych dla zasobów platformy Azure. Oparta na automatycznie zarządzanej tożsamości usługi Data Factory w usłudze Microsoft Entra ID tożsamości zarządzane umożliwiają konfigurowanie potoków bez podawania poświadczeń w połączonej definicji usługi. Alternatywnie możesz uwierzytelnić się w usłudze Blob Storage przy użyciu jednostki usługi, sygnatury dostępu współdzielonego lub klucza konta magazynu.
• Wiele typów uwierzytelniania jest również obsługiwanych w przypadku nawiązywania połączenia z usługą Data Lake Storage Gen2. Zdecydowanie zalecamy używanie tożsamości zarządzanych dla zasobów platformy Azure, ale można również użyć jednostki usługi lub klucza konta magazynu.
• Jeśli nie używasz tożsamości zarządzanych dla zasobów platformy Azure, zdecydowanie zalecamy przechowywanie poświadczeń w usłudze Azure Key Vault , aby ułatwić centralne zarządzanie kluczami i obracanie ich bez modyfikowania połączonych usług usługi Data Factory. Jest to również najlepsze rozwiązanie dla ciągłej integracji/ciągłego wdrażania.

Początkowa migracja danych migawek

W trybie DistCp usługi Data Factory można utworzyć jedno działanie kopiowania w celu przesłania polecenia DistCp i użyć różnych parametrów do kontrolowania zachowania początkowej migracji danych.

W trybie natywnego środowiska Integration Runtime usługi Data Factory zalecamy partycjonowanie danych, zwłaszcza w przypadku migracji ponad 10 TB danych. Aby podzielić dane na partycje, użyj nazw folderów w systemie plików HDFS. Następnie każde zadanie kopiowania usługi Data Factory może skopiować jedną partycję folderu naraz. W celu uzyskania lepszej przepływności można jednocześnie uruchomić wiele zadań kopiowania w usłudze Data Factory.

Jeśli którekolwiek z zadań kopiowania nie powiedzie się z powodu przejściowych problemów z siecią lub magazynem danych, możesz ponownie uruchomić zadanie kopiowania, które zakończyło się niepowodzeniem, aby ponownie załadować daną partycję z systemu plików HDFS. Nie ma to wpływu na inne zadania kopiowania ładujące inne partycje.

Migracja danych różnicowych

W trybie DistCp usługi Data Factory można użyć parametru -updatewiersza polecenia DistCp , zapisuj dane, gdy plik źródłowy i plik docelowy różnią się rozmiarem, na potrzeby migracji danych różnicowych.

W trybie natywnej integracji usługi Data Factory najbardziej wydajnym sposobem identyfikowania nowych lub zmienionych plików z systemu plików HDFS jest użycie konwencji nazewnictwa partycjonowanego czasowo. Gdy dane w systemie plików HDFS zostały podzielone na partycje czasowe z informacjami o wycinkach czasu w nazwie pliku lub folderu (na przykład /rrrr/mm/dd/file.csv), potok może łatwo zidentyfikować pliki i foldery, które mają być kopiowane przyrostowo.

Alternatywnie, jeśli dane w systemie plików HDFS nie są partycjonowane w czasie, usługa Data Factory może zidentyfikować nowe lub zmienione pliki przy użyciu ich wartości LastModifiedDate . Usługa Data Factory skanuje wszystkie pliki z systemu plików HDFS i kopiuje tylko nowe i zaktualizowane pliki, które mają ostatnio zmodyfikowany znacznik czasu większy niż ustawiona wartość.

Jeśli masz dużą liczbę plików w systemie plików HDFS, początkowe skanowanie plików może zająć dużo czasu, niezależnie od tego, ile plików jest zgodnych z warunkiem filtru. W tym scenariuszu zalecamy, aby najpierw podzielić dane na partycje przy użyciu tej samej partycji, która została użyta do migracji początkowej migawki. Następnie skanowanie plików może wystąpić równolegle.

Szacowana cena

Rozważmy następujący potok migracji danych z systemu plików HDFS do usługi Azure Blob Storage:

Załóżmy, że poniżej przedstawiono następujące informacje:

• Łączna ilość danych to 1 PB.
• Dane są migrowane przy użyciu natywnego trybu środowiska Integration Runtime usługi Data Factory.
• 1 PB jest podzielony na 1000 partycji, a każda kopia przenosi jedną partycję.
• Każde działanie kopiowania jest konfigurowane przy użyciu jednego własnego środowiska Integration Runtime skojarzonego z czterema maszynami i osiąga przepływność 500 MB/s.
• Współbieżność forEach jest ustawiona na 4 , a zagregowana przepływność wynosi 2 GB/s.
• W sumie ukończenie migracji trwa 146 godzin.

Poniżej przedstawiono szacowaną cenę na podstawie naszych założeń:

Dodatkowa dokumentacja

• Łącznik systemu plików HDFS
• Łącznik usługi Azure Blob Storage
• Łącznik usługi Azure Data Lake Storage Gen2
• Przewodnik dostosowywania wydajności działanie Kopiuj
• Tworzenie i konfigurowanie własnego środowiska Integration Runtime
• Wysoka dostępność i skalowalność własnego środowiska Integration Runtime
• Zagadnienia dotyczące zabezpieczeń przenoszenia danych
• Przechowywanie poświadczeń w usłudze Azure Key Vault
• Kopiowanie pliku przyrostowo na podstawie nazwy pliku partycjonowanego czasowo
• Kopiowanie nowych i zmienionych plików na podstawie daty ostatniej modyfikacji
• Strona cennika usługi Data Factory

Powiązana zawartość

• Kopiowanie plików z wielu kontenerów przy użyciu usługi Azure Data Factory