Поделиться через

Миграция локальных кластеров Apache Hadoop в Azure HDInsight

  • Статья

В этой статье представлены рекомендации по хранению данных в системах Azure HDInsight. Это часть цикла, где приведены лучшие методики, применимые при перемещении локальных систем Apache Hadoop в Azure HDInsight.

Выбор правильной системы хранения для кластеров HDInsight

Структура каталогов локальной файловой системы Apache Hadoop (HDFS) может быть воссоздана в службе хранилища BLOB-объектов Azure или в Azure Data Lake Storage. Затем можно безопасно и без потери пользовательских данных удалять используемые для расчетов кластеры HDInsight. Обе службы могут использоваться и как файловая система по умолчанию, и как дополнительная файловая система для кластера HDInsight. Кластер HDInsight и учетная запись хранения должны размещаться в одном регионе.

Хранилище Azure

Кластеры HDInsight могут использовать контейнер больших двоичных объектов в службе хранилища Azure как файловую систему по умолчанию или как дополнительную файловую систему. С кластерами HDInsight можно использовать учетную запись хранения уровня "Стандартный". Уровень Premier не поддерживается. Стандартный контейнер больших двоичных объектов хранит сведения о кластере, включая журналы заданий. Совместное использование одного контейнера больших двоичных объектов в качестве файловой системы по умолчанию для нескольких кластеров не поддерживается.

Определенные на этапе создания учетные записи хранения и соответствующие ключи хранятся в файле %HADOOP_HOME%/conf/core-site.xml на узлах кластера. Их также можно получить в разделе Custom core site (Пользовательский основной сайт) в конфигурации HDFS в интерфейсе Ambari. Ключ учетной записи хранения зашифрован по умолчанию. Перед тем как передать ключи управляющим программам Hadoop, используется собственный сценарий расшифровки. Задания, включая Hive, MapReduce, потоковую передачу Hadoop и Pig, могут переносить описание учетных записей хранения и метаданные вместе с ними.

Доступна функция георепликации службы хранилища Azure. Хотя это обеспечивает возможность географического восстановления и избыточность данных, переход в расположение геореплицированных данных при отработке отказа заметно сказывается на производительности, что может привести к дополнительным затратам. Поэтому мы рекомендуем взвешенно подходить к выбору георепликации и выбирать ее только в том случае, если ценность данных окупит дополнительные затраты.

Для доступа к данным, хранящимся в службе хранилища Azure, может использоваться один из следующих форматов:

Формат доступа к данным Description
wasb:/// Хранилище по умолчанию без шифрования обмена данными.
wasbs:/// Хранилище по умолчанию с шифрованием обмена данными.
wasb://<container-name>@<account-name>.blob.core.windows.net/ При взаимодействии с учетной записью хранения, кроме используемой по умолчанию. 

Целевые показатели масштабируемости для учетных записей хранения уровня "Стандартный" содержат текущие ограничения учетных записей хранения Azure. Если предельно достижимых показателей масштабируемости для одной учетной записи хранения недостаточно для работы приложения, то при разработке такого приложения можно настроить его на использование нескольких таких учетных записей и распределить объекты данных между ними.

Аналитика Службы хранилища предоставляет метрики для всех служб хранения, а на портале Azure можно настроить сбор метрик, которые будут визуализироваться с помощью диаграмм. Можно создать оповещения, чтобы получать уведомления о достижении пороговых значений для метрик ресурсов хранилища.

Служба хранилища Azure теперь предоставляет возможность обратимого удаления больших двоичных объектов. Это упрощает восстановление данных, если они ошибочно изменены или удалены приложением или другим пользователем учетной записи хранения.

Можно создавать моментальные снимки больших двоичных объектов. Моментальный снимок — это версия большого двоичного объекта только для чтения, сделанная в определенный момент времени, которая обеспечивает способ резервного копирования этого объекта. После создания моментального снимка его можно читать, копировать или удалять, но нельзя изменять.

Примечание.

Для более старых версий локальных дистрибутивов Hadoop, у которых нет сертификата wasbs, этот сертификат необходимо импортировать в доверенное хранилище Java.

Для импорта сертификатов в доверенное хранилище Java могут использоваться следующие методы.

Скачайте сертификат TLS/SSL большого двоичного объекта Azure в файл

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

Импортируйте указанный выше файл в доверенное хранилище Java на всех узлах:

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

Убедитесь, что добавленный сертификат находится в доверенном хранилище:

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

Дополнительные сведения см. в следующих статьях:

Azure Data Lake Storage 2-го поколения

Azure Data Lake Storage 2-го поколения — это новейшее предложение по хранению. Оно объединяет основные возможности Azure Data Lake Storage 1-го поколения с конечной точкой файловой системы, совместимой с Hadoop, непосредственно интегрированной в хранилище BLOB-объектов Azure. Это усовершенствование сочетает в себе преимущества масштабирования и экономии хранения объектов с высокой надежностью и производительностью, которые обычно связаны только с локальными файловыми системами.

Azure Data Lake Storage 2-го поколения создано на основе хранилища BLOB-объектов Azure и позволяет работать с данными с использованием как файловой системы, так и парадигм хранения объектов. Это хранилище предоставляет функции Azure Data Lake Storage 1-го поколения, например семантика файловой системы, защита на уровне файлов и масштабирование, а также экономичность, многоуровневость, возможности высокой доступности и аварийного восстановления, большую экосистему средств и пакетов SDK хранилища BLOB-объектов Azure. В Data Lake Storage Gen2 сохранились все качества хранилища объектов, а также появились возможности работы с файловой системой, что позволило оптимизировать рабочие нагрузки аналитики.

Основополагающая функция Azure Data Lake Storage 2-го поколения — это добавление иерархических пространств имен в службу хранилища BLOB-объектов, что позволяет упорядочивать объекты и файлы в иерархии каталогов, обеспечивая тем самым удобный доступ к данным. Иерархическая структура позволяет выполнять такие задачи, как переименование или удаление каталога, в виде единичных атомарных операций с метаданными в каталоге. Больше не нужно перечислять или обрабатывать все объекты с общим префиксом имени каталога.

Раньше облачная аналитика влияла на производительность, возможности управления и безопасность. Далее приведены основные функции ADLS 2-го поколения.

  • Доступ, совместимый с Hadoop. Хранилище Azure Data Lake Storage 2-го поколения позволяет получать доступ к данным и управлять ими так же, как и в распределенной файловой системе Hadoop (HDFS). Новыйдрайвер ABFS доступен во всех средах Apache Hadoop, которые включены в Azure HDInsight. Этот драйвер позволяет получать доступ к данным в ADLS 2-го поколения.

  • Надмножество разрешений POSIX. Модель безопасности Data Lake 2-го поколения полностью поддерживает разрешения ACL и POSIX, а также некоторую дополнительную детализацию, относящуюся к Data Lake Storage 2-го поколения. Параметры могут быть настроены через средства администрирования или с помощью платформ, таких как Hive и Spark.

  • Экономичность. Data Lake Storage Gen2 отличается низкой стоимостью приобретения емкости хранилища и выполнения транзакций. За счет таких встроенных функций, как Жизненный цикл хранилища BLOB-объектов Azure, в ходе жизненного цикла данных тарифные ставки максимально снижаются.

  • Поддержка средств, платформ и приложений хранилища BLOB-объектов. Хранилище Data Lake Storage Gen2 поддерживает большое количество средств, платформ и приложений хранилища BLOB-объектов.

  • Оптимизированный драйвер. Драйвер файловой системы больших двоичных объектов Azure (ABFS)оптимизирован специально для анализа больших данных. Соответствующие интерфейсы REST API отображаются через конечную точку dfs , dfs.core.windows.net.

Для доступа к данным, хранящимся в ADLS 2-го поколения, может использоваться один из следующих форматов:

  • abfs:///: доступ к хранилищу Data Lake Storage, используемому по умолчанию для кластера.
  • abfs://file_system@account_name.dfs.core.windows.net: используется при взаимодействии с Data Lake Storage, отличным от используемого по умолчанию.

Примечание.

Обновление основной или вторичной учетной записи хранения запущенного кластера с помощью возможностей Azure Data Lake Storage 2-го поколения не поддерживается. Чтобы изменить тип хранилища существующего кластера HDInsight на Data Lake Storage 2-го поколения, необходимо повторно создать кластер и выбрать учетную запись хранения с поддержкой иерархического пространства имен.

Дополнительные сведения см. в следующих статьях:

Обеспечение безопасности ключей хранилища Azure в локальной конфигурации кластера Hadoop

Ключи к хранилищу данных Azure, которые добавляются в файлы конфигурации Hadoop, устанавливают соединение между локальной системой HDFS и хранилищем BLOB-объектов Azure. Эти ключи можно защитить, зашифровав их с помощью инфраструктуры поставщика учетных данных Hadoop. Зашифрованные ключи можно надежно хранить и безопасно получать к ним доступ.

Чтобы подготовить учетные данные:

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

Чтобы добавить указанный выше путь поставщика в файл core-site.xml или в конфигурацию Ambari под настраиваемым основным сайтом:

<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>

Примечание.

Свойство пути поставщика также можно добавить в командную строку distcp вместо сохранения ключа на уровне кластера в файле core-site.xml следующим образом:

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

Ограничение доступа к данным службы хранилища Azure с помощью SAS

HDInsight по умолчанию имеет полный доступ к данным в учетных записях хранения Azure, связанных с кластером. Подписанные URL-адреса (SAS) в контейнере BLOB-объектов можно использовать для ограничения доступа к данным, например предоставить пользователям доступ только для чтения к данным.

Использование маркера SAS, созданного с помощью Python

  1. Откройте файл SASToken.py и измените следующие значения:

    Свойство маркера Description
    policy_name Имя, которое будет использоваться для создаваемой хранимой политики.
    storage_account_name Имя учетной записи хранения.
    storage_account_key Ключ для учетной записи хранения.
    storage_container_name Контейнер в учетной записи хранения, доступ к которому необходимо ограничить.
    example_file_path Путь к файлу, который будет отправляться в контейнер.

  2. Файл SASToken.py поставляется с разрешениями ContainerPermissions.READ + ContainerPermissions.LIST и может быть скорректирован с учетом варианта использования.

  3. Выполните сценарий следующим образом: python SASToken.py

  4. После выполнения сценария отобразится маркер SAS следующего вида: sr=c&si=policyname&sig=dOAi8CXuz5Fm15EjRUu5dHlOzYNtcK3Afp1xqxniEps%3D&sv=2014-02-14

  5. Чтобы ограничить доступ к контейнеру с помощью подписанного URL-адреса, добавьте пользовательскую запись в свойстве Add (Добавить) расширенной пользовательской конфигурации основного сайта Ambari HDFS для кластера.

  6. В полях Key (Ключ) и Value (Значение) укажите следующие значения.

    Ключ: fs.azure.sas.YOURCONTAINER.YOURACCOUNT.blob.core.windows.netЗначение: ключ SAS, возвращаемый приложением Python из указанного выше шага 4.

  7. Нажмите кнопку Add (Добавить), чтобы сохранить этот ключ и значение, а затем кнопку Save (Сохранить), чтобы сохранить изменения в конфигурации. При появлении запроса добавьте описание внесенного изменения (например, "Добавление доступа к хранилищу SAS") и нажмите кнопку Сохранить.

  8. В веб-интерфейсе Ambari выберите HDFS в списке слева, а затем выберите "Перезапустить все затронутые" в раскрывающемся списке "Действия службы" справа. Когда появится запрос, выберите Conform Restart All (Подтвердить перезапуск всех).

  9. Повторите эту процедуру для MapReduce2 и YARN.

Существует три важных аспекта, которые нужно помнить при использовании маркеров SAS в Azure:

  1. Если маркеры SAS создаются с разрешениями READ + LIST, пользователи, которые обращаются к контейнеру больших двоичных объектов, используя этот маркер SAS, не смогут записывать и удалять данные. Пользователи, которые обращаются к контейнеру больших двоичных объектов, используя этот маркер SAS, и пытаются выполнить операцию записи или удаления, получат сообщение типа "This request is not authorized to perform this operation".

  2. Если маркеры SAS создаются с разрешениями READ + LIST + WRITE (для ограничения только DELETE), команды, подобные hadoop fs -put, сначала записывают в файл \_COPYING\_, а затем пытаются переименовать файл. Эта операция HDFS сопоставляется с copy+delete для WASB. Так как разрешение DELETE не было предоставлено, запрос put завершится сбоем. Операция \_COPYING\_ — это функция Hadoop, предназначенная для обеспечения некоторого контроля параллелизма. В настоящее время нет никакого способа ограничить только операцию DELETE, не затрагивая также операции WRITE.

  3. К сожалению, поставщик учетных данных Hadoop и поставщик ключей расшифровки (ShellDecryptionKeyProvider) в настоящее время не работают с маркерами SAS и поэтому не могут быть защищены от видимости.

Дополнительные сведения см. в статье Использование подписанных URL-адресов хранилища Azure для ограничения доступа к данным в HDInsight.

Использование шифрования и репликации данных

Все данные, записываемые в службу хранилища Azure, автоматически шифруются с помощью шифрования службы хранилища (SSE). Данные в учетной записи хранения Azure всегда реплицируются для обеспечения высокой доступности. При создании учетной записи хранения можно выбрать один из следующих вариантов репликации:

Служба хранилища Azure предоставляет локально избыточное хранилище (LRS), но необходимо также скопировать критически важные данные в другую учетную запись Службы хранилища Azure в другом регионе с частотой, соответствующей потребностям плана аварийного восстановления. Копировать данные можно несколькими способами, в том числе с помощью ADLCopy, DistCp, Azure PowerShell или Фабрики данных Azure. Рекомендуется также применять политики доступа для учетной записи службы хранилища Azure, чтобы предотвратить случайное удаление.

Дополнительные сведения см. в следующих статьях:

Подключение дополнительных учетных записей службы хранения Azure к кластеру

При создании кластера HDInsight в качестве файловой системы по умолчанию выбирается учетная запись службы хранилища Azure или учетная запись Azure Data Lake Storage 1-го или 2-го поколения. Помимо этой учетной записи хранения по умолчанию в процессе создания или после создания кластера можно добавить дополнительные учетные записи хранения из той же или других подписок Azure.

Дополнительную учетную запись хранения можно добавить одним из следующих способов:

  • Добавить имя и ключ учетной записи хранения для основного сайта в расширенной пользовательской конфигурации Ambari HDFS и перезапустить службы.
  • Использовать действие сценария, передав имя и ключ учетной записи хранения.

Примечание.

В допустимых случаях ограничения в службе хранилища Azure можно увеличить с помощью запроса в службу поддержки Azure.

Дополнительные сведения см. в статье Добавление дополнительных учетных записей хранения в HDInsight.

Следующие шаги

Ознакомьтесь со следующей статьей в этой серии: рекомендации по переносу данных из локальной среды в Azure HDInsight Hadoop.