Udostępnij za pośrednictwem

Migrowanie lokalnych klastrów Apache Hadoop do usługi Azure HDInsight

  • Artykuł

Ten artykuł zawiera zalecenia dotyczące magazynu danych w systemach usługi Azure HDInsight. Jest to część serii, która zawiera najlepsze rozwiązania ułatwiające migrowanie lokalnych systemów Apache Hadoop do usługi Azure HDInsight.

Wybieranie odpowiedniego systemu magazynowania dla klastrów usługi HDInsight

Lokalna struktura katalogów systemu plików Apache Hadoop (HDFS) może zostać ponownie utworzona w usłudze Azure Blob Storage lub Azure Data Lake Storage. Następnie można bezpiecznie usunąć klastry usługi HDInsight używane do obliczeń bez utraty danych użytkownika. Obie usługi mogą być używane zarówno jako domyślny system plików, jak i dodatkowy system plików dla klastra usługi HDInsight. Klaster usługi HDInsight i konto magazynu muszą być hostowane w tym samym regionie.

Azure Storage

Klastry usługi HDInsight mogą używać kontenera obiektów blob w usłudze Azure Storage jako domyślnego systemu plików lub dodatkowego systemu plików. Konto magazynu w warstwie Standardowa jest obsługiwane w przypadku klastrów usługi HDInsight. Warstwa Premier nie jest obsługiwana. Domyślny kontener obiektów blob przechowuje informacje dotyczące klastra, takie jak dzienniki i historia zadań. Udostępnianie jednego kontenera obiektów blob jako domyślnego systemu plików dla wielu klastrów nie jest obsługiwane.

Konta magazynu zdefiniowane w procesie tworzenia i ich odpowiednie klucze są przechowywane w %HADOOP_HOME%/conf/core-site.xml węzłach klastra. Dostęp do nich można również uzyskać w sekcji "Niestandardowa lokacja podstawowa" w konfiguracji systemu plików HDFS w interfejsie użytkownika systemu Ambari. Klucz konta magazynu jest domyślnie szyfrowany, a skrypt odszyfrowywania niestandardowego służy do odszyfrowywania kluczy przed przekazaniem ich do demonów usługi Hadoop. Zadania, w tym Hive, MapReduce, Przesyłanie strumieniowe hadoop i Pig, zawierają opis kont magazynu i metadanych.

Usługę Azure Storage można replikować geograficznie. Mimo że replikacja geograficzna zapewnia odzyskiwanie geograficzne i nadmiarowość danych, przejście w tryb failover do lokalizacji zreplikowanej geograficznie poważnie wpływa na wydajność i może wiązać się z dodatkowymi kosztami. Zaleca się wybranie replikacji geograficznej odpowiednio i tylko wtedy, gdy wartość danych jest warta dodatkowych kosztów.

Jeden z następujących formatów może służyć do uzyskiwania dostępu do danych przechowywanych w usłudze Azure Storage:

Format dostępu do danych opis
wasb:/// Uzyskaj dostęp do domyślnego magazynu przy użyciu niezaszyfrowanej komunikacji.
wasbs:/// Uzyskaj dostęp do domyślnego magazynu przy użyciu zaszyfrowanej komunikacji.
wasb://<container-name>@<account-name>.blob.core.windows.net/ Używane podczas komunikowania się z kontem magazynu innego niż domyślne. 

Cele skalowalności dla kont magazynu w warstwie Standardowa zawiera listę bieżących limitów na kontach usługi Azure Storage. Jeśli potrzeby aplikacji przekraczają cele skalowalności jednego konta magazynu, można skompilować aplikację w celu użycia wielu kont magazynu, a następnie podzielić obiekty danych na te konta magazynu.

Usługa Azure analityka magazynu udostępnia metryki dla wszystkich usług magazynu i witryny Azure Portal można skonfigurować zbieranie metryk do wizualizacji za pomocą wykresów. Alerty można utworzyć w celu powiadamiania o osiągnięciu progów dla metryk zasobów magazynu.

Usługa Azure Storage oferuje usuwanie nietrwałe dla obiektów blob, które ułatwiają odzyskiwanie danych po przypadkowej modyfikacji lub usunięciu przez aplikację lub innego użytkownika konta magazynu.

Można tworzyć migawki obiektów blob. Migawka to wersja obiektu blob tylko do odczytu wykonywana w danym momencie i umożliwia tworzenie kopii zapasowej obiektu blob. Po utworzeniu migawki można ją odczytywać, kopiować lub usuwać, ale nie modyfikować.

Uwaga

W przypadku starszych wersji lokalnych dystrybucji hadoop, które nie mają certyfikatu "wasbs", należy je zaimportować do magazynu zaufania języka Java.

Do importowania certyfikatów do magazynu zaufania Języka Java można użyć następujących metod:

Pobieranie certyfikatu TLS/SSL usługi Azure Blob do pliku

echo -n | openssl s_client -connect <storage-account>.blob.core.windows.net:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > Azure_Storage.cer

Zaimportuj powyższy plik do magazynu zaufania java na wszystkich węzłach

keytool -import -trustcacerts -keystore /path/to/jre/lib/security/cacerts -storepass changeit -noprompt -alias blobtrust -file Azure_Storage.cer

Sprawdź, czy dodany certyfikat znajduje się w magazynie zaufania

keytool -list -v -keystore /path/to/jre/lib/security/cacerts

Aby uzyskać więcej informacji, zobacz następujące artykuły:

Azure Data Lake Storage Gen2

Usługa Azure Data Lake Storage Gen2 to najnowsza oferta magazynu. Łączy podstawowe możliwości z pierwszej generacji usługi Azure Data Lake Storage Gen1 z punktem końcowym systemu plików zgodnym z usługą Hadoop bezpośrednio zintegrowanym z usługą Azure Blob Storage. To ulepszenie łączy korzyści ze skalowania i kosztów magazynu obiektów z niezawodnością i wydajnością zwykle skojarzonymi tylko z lokalnymi systemami plików.

Usługa Azure Data Lake Storage Gen 2 jest oparta na usłudze Azure Blob Storage i umożliwia interfejs z danymi przy użyciu zarówno modelu systemu plików, jak i magazynu obiektów. Funkcje usługi Azure Data Lake Storage Gen1, takie jak semantyka systemu plików, zabezpieczenia na poziomie plików i skalowanie, są łączone z niskim kosztem, magazynem warstwowym, funkcjami wysokiej dostępności/odzyskiwania po awarii oraz dużym ekosystemem zestawu SDK/narzędzi z usługi Azure Blob Storage. W usłudze Data Lake Storage Gen2 wszystkie cechy magazynu obiektów pozostają przy jednoczesnym dodaniu zalet interfejsu systemu plików zoptymalizowanego pod kątem obciążeń analitycznych.

Podstawową cechą usługi Data Lake Storage Gen2 jest dodanie hierarchicznej przestrzeni nazw do usługi Blob Storage, która organizuje obiekty/pliki w hierarchię katalogów na potrzeby wydajnego dostępu do danych. Struktura hierarchiczna umożliwia operacje, takie jak zmiana nazwy lub usunięcie katalogu jako pojedyncze operacje metadanych niepodzielnych w katalogu, a nie wyliczanie i przetwarzanie wszystkich obiektów, które współużytkujące prefiks nazwy katalogu.

W przeszłości analiza oparta na chmurze musiała naruszyć bezpieczeństwo w obszarach wydajności, zarządzania i zabezpieczeń. Najważniejsze funkcje usługi Azure Data Lake Storage (ADLS) Gen2 są następujące:

  • Dostęp zgodny z usługą Hadoop: usługa Azure Data Lake Storage Gen2 umożliwia zarządzanie danymi i uzyskiwanie do ich dostępu tak samo jak w przypadku rozproszonego systemu plików Hadoop (HDFS). Nowy sterownik ABFS jest dostępny we wszystkich środowiskach Apache Hadoop, które są zawarte w usłudze Azure HDInsight. Ten sterownik umożliwia dostęp do danych przechowywanych w usłudze Data Lake Storage Gen2.

  • Nadzbiór uprawnień POSIX: model zabezpieczeń dla usługi Data Lake Gen2 w pełni obsługuje uprawnienia listy ACL i POSIX wraz z dodatkowym stopniem szczegółowości specyficznym dla usługi Data Lake Storage Gen2. Ustawienia można skonfigurować za pomocą narzędzi administracyjnych lub struktur, takich jak Hive i Spark.

  • Opłacalne: usługa Data Lake Storage Gen2 oferuje tanią pojemność magazynu i transakcje. W miarę przechodzenia danych przez cały cykl życia stawki rozliczeniowe zmieniają się, aby zminimalizować koszty za pomocą wbudowanych funkcji, takich jak cykl życia usługi Azure Blob Storage.

  • Współpracuje z narzędziami, strukturami i aplikacjami usługi Blob Storage: usługa Data Lake Storage Gen2 nadal współpracuje z szeroką gamą narzędzi, struktur i aplikacji, które istnieją obecnie w usłudze Blob Storage.

  • Zoptymalizowany sterownik: sterownik systemu plików obiektów blob platformy Azure (ABFS) jest zoptymalizowany specjalnie pod kątem analizy danych big data. Odpowiednie interfejsy API REST są udostępniane za pośrednictwem punktu końcowego dfs , dfs.core.windows.net.

Jeden z następujących formatów może służyć do uzyskiwania dostępu do danych przechowywanych w usłudze ADLS Gen2:

  • abfs:///: Uzyskaj dostęp do domyślnej usługi Data Lake Storage dla klastra.
  • abfs://file_system@account_name.dfs.core.windows.net: używany podczas komunikowania się z usługą Data Lake Storage inną niż domyślna.

Uwaga

Uaktualnianie podstawowego lub pomocniczego konta magazynu uruchomionego klastra z możliwościami usługi Azure Data Lake Storage Gen2 nie jest obsługiwane. Aby zmienić typ magazynu istniejącego klastra usługi HDInsight na usługę Data Lake Storage Gen2, należy ponownie utworzyć klaster i wybrać konto magazynu z włączoną hierarchiczną przestrzenią nazw.

Aby uzyskać więcej informacji, zobacz następujące artykuły:

Zabezpieczanie kluczy usługi Azure Storage w ramach lokalnej konfiguracji klastra hadoop

Klucze usługi Azure Storage, które są dodawane do plików konfiguracji usługi Hadoop, ustanawiają łączność między lokalnym systemem plików HDFS i usługą Azure Blob Storage. Te klucze można chronić, szyfrując je za pomocą platformy dostawcy poświadczeń usługi Hadoop. Po zaszyfrowaniu można je przechowywać i uzyskiwać do nich bezpieczny dostęp.

Aby aprowizować poświadczenia:

hadoop credential create fs.azure.account.key.account.blob.core.windows.net -value <storage key> -provider jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks/file

Aby dodać powyższą ścieżkę dostawcy do core-site.xml lub do konfiguracji narzędzia Ambari w ramach niestandardowej lokacji podstawowej:

<property>
    <name>hadoop.security.credential.provider.path</name>
        <value>
        jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks
        </value>
    <description>Path to interrogate for protected credentials.</description>
</property>

Uwaga

Właściwość ścieżki dostawcy można również dodać do wiersza polecenia distcp zamiast przechowywać klucz na poziomie klastra na core-site.xml w następujący sposób:

hadoop distcp -D hadoop.security.credential.provider.path=jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks /user/user1/ wasb:<//yourcontainer@youraccount.blob.core.windows.net/>user1

Ograniczanie dostępu do danych usługi Azure Storage przy użyciu sygnatury dostępu współdzielonego

Usługa HDInsight domyślnie ma pełny dostęp do danych na kontach usługi Azure Storage skojarzonych z klastrem. Sygnatury dostępu współdzielonego (SAS) w kontenerze obiektów blob mogą służyć do ograniczania dostępu do danych, takich jak zapewnienie użytkownikom dostępu tylko do odczytu do danych.

Używanie tokenu SAS utworzonego za pomocą języka Python

  1. Otwórz plik SASToken.py i zmień następujące wartości:

    Właściwość tokenu opis
    policy_name Nazwa używana dla przechowywanych zasad do utworzenia.
    storage_account_name Nazwa konta magazynu.
    storage_account_key Klucz konta magazynu.
    storage_container_name Kontener na koncie magazynu, do którego chcesz ograniczyć dostęp.
    example_file_path Ścieżka do pliku przekazanego do kontenera.

  2. Plik SASToken.py zawiera ContainerPermissions.READ + ContainerPermissions.LIST uprawnienia i można go dostosować na podstawie przypadku użycia.

  3. Wykonaj skrypt w następujący sposób: python SASToken.py

  4. Po zakończeniu działania skryptu wyświetla token SAS podobny do następującego tekstu: sr=c&si=policyname&sig=dOAi8CXuz5Fm15EjRUu5dHlOzYNtcK3Afp1xqxniEps%3D&sv=2014-02-14

  5. Aby ograniczyć dostęp do kontenera za pomocą sygnatury dostępu współdzielonego, dodaj niestandardowy wpis do konfiguracji podstawowej lokacji klastra w obszarze Ambari HDFS Configs Advanced Custom Core-site Add.

  6. W polach Klucz i Wartość użyj następujących wartości:

    Klucz: Wartość: fs.azure.sas.YOURCONTAINER.YOURACCOUNT.blob.core.windows.netklucz SYGNATURy dostępu współdzielonego zwrócony przez aplikację języka Python z kroku 4 powyżej.

  7. Kliknij przycisk Dodaj, aby zapisać ten klucz i wartość, a następnie kliknij przycisk Zapisz, aby zapisać zmiany konfiguracji. Po wyświetleniu monitu dodaj opis zmiany ("na przykład dodawanie dostępu do magazynu SAS), a następnie kliknij przycisk Zapisz.

  8. W internetowym interfejsie użytkownika systemu ambari wybierz pozycję HDFS z listy po lewej stronie, a następnie wybierz pozycję Uruchom ponownie wszystkie objęte z listy rozwijanej Akcje usługi po prawej stronie. Po wyświetleniu monitu wybierz pozycję Potwierdź ponowne uruchomienie wszystkich.

  9. Powtórz ten proces dla technologii MapReduce2 i YARN.

Istnieją trzy ważne kwestie, które należy pamiętać o użyciu tokenów SAS na platformie Azure:

  1. Po utworzeniu tokenów SAS przy użyciu uprawnień "ODCZYT + LISTA" użytkownicy, którzy uzyskują dostęp do kontenera obiektów blob przy użyciu tego tokenu SAS, nie będą mogli "zapisywać i usuwać" danych. Użytkownicy, którzy uzyskują dostęp do kontenera obiektów blob przy użyciu tego tokenu SAS i spróbują wykonać operację zapisu lub usunięcia, otrzymają komunikat podobny do "This request is not authorized to perform this operation".

  2. Gdy tokeny SAS są generowane z uprawnieniami READ + LIST + WRITE (aby ograniczyć DELETE tylko), polecenia takie jak hadoop fs -put najpierw zapis w \_COPYING\_ pliku, a następnie spróbuj zmienić nazwę pliku. Ta operacja systemu plików HDFS jest mapowane na copy+delete element dla WASB. DELETE Ponieważ nie podano uprawnień, polecenie "put" zakończy się niepowodzeniem. Operacja \_COPYING\_ jest funkcją hadoop przeznaczoną do zapewnienia kontroli współbieżności. Obecnie nie ma możliwości ograniczenia tylko operacji "DELETE" bez wpływu na operacje "WRITE", jak również.

  3. Niestety dostawca poświadczeń hadoop i dostawca klucza odszyfrowywania (ShellDecryptionKeyProvider) obecnie nie działa z tokenami SAS i obecnie nie może być chroniony przed widocznością.

Aby uzyskać więcej informacji, zobacz Używanie sygnatur dostępu współdzielonego usługi Azure Storage do ograniczania dostępu do danych w usłudze HDInsight.

Korzystanie z szyfrowania danych i replikacji

Wszystkie dane zapisywane w usłudze Azure Storage są automatycznie szyfrowane przy użyciu szyfrowania usługi Storage (SSE). Dane na koncie usługi Azure Storage są zawsze replikowane w celu zapewnienia wysokiej dostępności. Podczas tworzenia konta magazynu można wybrać jedną z następujących opcji replikacji:

Usługa Azure Storage udostępnia magazyn lokalnie nadmiarowy (LRS), ale należy również skopiować krytyczne dane na inne konto usługi Azure Storage w innym regionie z częstotliwością dostosowaną do potrzeb planu odzyskiwania po awarii. Istnieją różne metody kopiowania danych, w tym ADLCopy, DistCp, Azure PowerShell lub Azure Data Factory.  Zaleca się również wymuszanie zasad dostępu dla konta usługi Azure Storage, aby zapobiec przypadkowemu usunięciu.

Aby uzyskać więcej informacji, zobacz następujące artykuły:

Dołączanie dodatkowych kont usługi Azure Storage do klastra

Podczas procesu tworzenia usługi HDInsight jako domyślny system plików wybrano konto usługi Azure Storage, usługę Azure Data Lake Storage Gen1 lub usługę Azure Data Lake Storage Gen2. Oprócz tego domyślnego konta magazynu można dodawać dodatkowe konta magazynu z tej samej subskrypcji platformy Azure lub różnych subskrypcji platformy Azure podczas procesu tworzenia klastra lub po utworzeniu klastra.

Dodatkowe konto magazynu można dodać na jeden z następujących sposobów:

  • Ambari HDFS Config Advanced Custom Core-site Dodaj nazwę konta magazynu i klucz Ponowne uruchamianie usług
  • Używanie akcji Skrypt przez przekazanie nazwy i klucza konta magazynu

Uwaga

W prawidłowych przypadkach użycia limity usługi Azure Storage można zwiększyć za pośrednictwem żądania skierowanego do pomocy technicznej platformy Azure.

Aby uzyskać więcej informacji, zobacz Dodawanie kolejnych kont magazynu do usługi HDInsight.

Następne kroki

Przeczytaj następny artykuł z tej serii: Najlepsze rozwiązania dotyczące migracji danych lokalnych do usługi Azure HDInsight Hadoop.