Omówienie usługi Azure Storage w usłudze HDInsight

Azure Storage to niezawodne rozwiązanie magazynu ogólnego przeznaczenia, które bezproblemowo integruje się z usługą HDInsight. Usługa HDInsight może używać kontenera obiektów blob w usłudze Azure Storage jako domyślnego systemu plików dla klastra. Za pośrednictwem interfejsu HDFS pełny zestaw składników w usłudze HDInsight może działać bezpośrednio na danych ze strukturą lub bez struktury przechowywanych jako obiekty blob.

Zalecamy używanie oddzielnych kontenerów magazynu dla domyślnego magazynu klastra i danych biznesowych. Separacja polega na odizolowaniu dzienników usługi HDInsight i plików tymczasowych od własnych danych biznesowych. Zalecamy również usunięcie domyślnego kontenera obiektów blob, który zawiera dzienniki aplikacji i systemu, po każdym użyciu w celu zmniejszenia kosztów magazynowania. Przed usunięciem kontenera upewnij się, że dzienniki są pobierane.

Jeśli zdecydujesz się zabezpieczyć konto magazynu za pomocą ograniczeń Zapory i sieci wirtualnew wybranych sieciach, pamiętaj, aby włączyć wyjątek Zezwalaj na zaufane usługi firmy Microsoft.... Wyjątkiem jest to, że usługa HDInsight może uzyskać dostęp do konta magazynu.

Architektura magazynu usługi HDInsight

Na poniższym diagramie przedstawiono abstrakcyjny widok architektury usługi HDInsight usługi Azure Storage:

Usługa HDInsight zapewnia dostęp do rozproszonego systemu plików, który jest lokalnie dołączony do węzłów obliczeniowych. Dostęp do tego systemu plików można uzyskać przy użyciu w pełni kwalifikowanego identyfikatora URI, na przykład:

hdfs://<namenodehost>/<path>

Za pośrednictwem usługi HDInsight można również uzyskiwać dostęp do danych w usłudze Azure Storage. Składnia jest następująca:

wasb://<containername>@<accountname>.blob.core.windows.net/<path>

W przypadku kont, które mają hierarchiczną przestrzeń nazw (Azure Data Lake Storage Gen2), składnia jest następująca:

abfs://<containername>@<accountname>.dfs.core.windows.net/<file.path>/

Podczas korzystania z konta usługi Azure Storage z klastrami usługi HDInsight należy wziąć pod uwagę następujące zasady:

• Kontenery na kontach magazynu połączonych z klastrem: Ponieważ nazwa konta i klucz są skojarzone z klastrem podczas tworzenia, masz pełny dostęp do obiektów blob w tych kontenerach.

• Kontenery publiczne lub publiczne obiekty blob na kontach magazynu, które nie są połączone z klastrem: Masz uprawnienia tylko do odczytu do obiektów blob w kontenerach.

  Note

  Kontenery publiczne umożliwiają uzyskanie listy wszystkich obiektów blob, które są dostępne w tym kontenerze i uzyskiwania metadanych kontenera. Publiczne obiekty blob umożliwiają dostęp do obiektów blob tylko wtedy, gdy znasz dokładny adres URL. Aby uzyskać więcej informacji, zobacz Zarządzanie anonimowym dostępem do odczytu do kontenerów i obiektów blob.

• Kontenery prywatne na kontach magazynu, które nie są połączone z klastrem: Nie można uzyskać dostępu do obiektów blob w kontenerach, chyba że zdefiniujesz konto magazynu podczas przesyłania zadań WebHCat.

Konta magazynu zdefiniowane w procesie tworzenia i ich klucze są przechowywane w %HADOOP_HOME%/conf/core-site.xml w węzłach klastra. Domyślnie usługa HDInsight używa kont magazynu zdefiniowanych w pliku core-site.xml. To ustawienie można zmodyfikować przy użyciu narzędzia Apache Ambari. Aby uzyskać więcej informacji na temat ustawień konta magazynu, które można zmodyfikować lub umieścić w pliku core-site.xml, zobacz następujące artykuły:

• Pomoc techniczna platformy Azure w usłudze Hadoop: Azure Blob Storage
• Obsługa platformy Azure w usłudze Hadoop: ABFS — Azure Data Lake Storage Gen2

Wiele zadań WebHCat, w tym Apache Hive. Usługi MapReduce, apache Hadoop streaming i Apache Pig zawierają opis kont magazynu i metadanych. (Ten aspekt dotyczy obecnie języka Pig z kontami magazynu, ale nie dla metadanych). Aby uzyskać więcej informacji, zobacz Using an HDInsight cluster with alternate storage accounts and metastores (Używanie klastra usługi HDInsight z alternatywnymi kontami magazynu i magazynami metadanych).

Obiekty blob mogą być używane na potrzeby danych ze strukturą i bez struktury. Kontenery obiektów blob przechowują dane jako pary klucz/wartość i nie mają hierarchii katalogów. Jednak nazwa klucza może zawierać znak ukośnika ( / ), aby wyglądał tak, jakby plik był przechowywany w strukturze katalogów. Na przykład kluczem obiektu blob może być input/log1.txt. Nie istnieje rzeczywisty input katalog, ale ze względu na znak ukośnika w nazwie klucza klucz wygląda jak ścieżka pliku.

Korzyści wynikające z usługi Azure Storage

Klastry obliczeniowe i zasoby magazynu, które nie są kolokowane, mają implikowane koszty wydajności. Te koszty są ograniczane przez sposób tworzenia klastrów obliczeniowych w pobliżu zasobów konta magazynu w regionie świadczenia usługi Azure. W tym regionie węzły obliczeniowe mogą wydajnie uzyskiwać dostęp do danych za pośrednictwem szybkiej sieci w usłudze Azure Storage.

Podczas przechowywania danych w usłudze Azure Storage zamiast systemu plików HDFS uzyskujesz kilka korzyści:

• Ponowne użycie i udostępnianie danych: Dane w systemie plików HDFS znajdują się wewnątrz klastra obliczeniowego. Tylko aplikacje, które mają dostęp do klastra obliczeniowego, mogą używać danych przy użyciu interfejsów API systemu plików HDFS. Natomiast dane w usłudze Azure Storage można uzyskać za pośrednictwem interfejsów API systemu plików HDFS lub interfejsów API REST usługi Blob Storage. W związku z tym rozwiązaniem można użyć większego zestawu aplikacji (w tym innych klastrów usługi HDInsight) i narzędzi do tworzenia i korzystania z danych.

• Archiwizowanie danych: Gdy dane są przechowywane w usłudze Azure Storage, klastry usługi HDInsight używane do obliczeń można bezpiecznie usunąć bez utraty danych użytkownika.

• Koszt magazynowania danych: Przechowywanie danych w systemie plików DFS w dłuższej perspektywie jest bardziej kosztowne niż przechowywanie danych w usłudze Azure Storage. Ponieważ koszt klastra obliczeniowego jest wyższy niż koszt usługi Azure Storage. Ponadto, ponieważ dane nie muszą być ponownie ładowane dla każdej generacji klastra obliczeniowego, oszczędzasz również koszty ładowania danych.

• Elastyczne skalowanie w poziomie: Mimo że system plików HDFS zapewnia skalowany w poziomie system plików, skala jest określana przez liczbę węzłów tworzonych dla klastra. Zmiana skali może być bardziej skomplikowana niż możliwości elastycznego skalowania, które są automatycznie uzyskiwane w usłudze Azure Storage.

• Replikacja geograficzna: Usługę Azure Storage można replikować geograficznie. Chociaż 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. Dlatego należy ostrożnie wybierać replikację geograficzną i tylko wtedy, gdy wartość danych uzasadnia dodatkowy koszt.

Niektóre zadania i pakiety MapReduce mogą tworzyć wyniki pośrednie, które nie powinny być przechowywane w usłudze Azure Storage. W takim przypadku można wybrać przechowywanie danych w lokalnym systemie plików HDFS. Usługa HDInsight używa systemu plików DFS dla kilku z tych pośrednich wyników w zadaniach Hive i innych procesach.

Dalsze kroki

• Wprowadzenie do usługi Azure Data Lake Storage Gen2
• Wprowadzenie do usługi Azure Storage
• Używanie usługi Azure Storage z klastrami usługi Azure HDInsight
• Używanie usługi Azure Data Lake Storage Gen2 z klastrami usługi Azure HDInsight