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. Koniecznie pobierz dzienniki przed usunięciem kontenera.
Jeśli zdecydujesz się zabezpieczyć konto magazynu za pomocą ograniczeń Zapory i sieci wirtualne w 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 wygląda następująco:
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 w ramach kont magazynu, które są podłączone do klastra: ponieważ nazwa konta i klucz są kojarzone 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.
Uwaga
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 jedynie osobom znającym dokładny adres URL. Aby uzyskać więcej informacji, zobacz Zarządzanie dostępem anonimowym w trybie 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 konto magazynu zostanie zdefiniowane podczas przesyłania zadań WebHCat.
Konta magazynu definiowane w procesie tworzenia oraz ich klucze są przechowywane w pliku %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 z danymi ze strukturą i bez niej. 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 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:
Udostępnianie i ponowne użycie danych: dane w systemie plików HDFS znajdują się wewnątrz klastra obliczeniowego. Tylko te aplikacje, które mają dostęp do klastra obliczeniowego mogą używać danych za pomocą 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: chociaż system plików HDFS zapewnia skalowanie w poziomie, skala jest wyznaczana 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ługa Azure Storage może być replikowana 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.
Uwaga
Większość poleceń systemu plików HDFS (na przykład ls, copyFromLocali mkdir) działa zgodnie z oczekiwaniami w usłudze Azure Storage. Tylko polecenia specyficzne dla natywnej implementacji systemu plików HDFS (nazywanej systemem plików DFS), takie jak fschk i dfsadmin, pokazują różne zachowanie w usłudze Azure Storage.