5 этапов продуктивной миграции в облачный Hadoop на базе Google Dataproc

Автор Категория , , , ,
5 этапов продуктивной миграции в облачный Hadoop на базе Google Dataproc

Сегодня поговорим про особенности перехода с локального Hadoop-кластера в облачное SaaS-решение от Google платформу Dataproc. Читайте далее, какие 5 шагов нужно сделать, чтобы быстро развернуть и эффективно использовать облачную инфраструктуру для запуска заданий Apache Hadoop и Spark в системах хранения и обработки больших данных (Big Data).

Шаги переноса Data pipeline‘ов c локальной экосистемы Hadoop в облако

Напомним, Dataproc – это часть Google Cloud Platform, управляемый и настраиваемый облачный сервис Apache Spark и Hadoop, позволяющий использовать open-source инструменты стека Big Data для пакетной обработки, запросов, потоковой передачи и машинного обучения [1]. Вчера мы рассматривали его архитектуру, компонентный состав и принципы работы, а также средства обеспечения информационной безопасность. Сегодня активный переход в облака является одной из наиболее устойчивых тенденций в ИТ-сфере, включая развитие экосистемы Apache Hadoop. Поэтому дата-инженеру и администратору Big Data актуально знать, как обеспечить миграцию больших данных и конвейеров их обработки (data pipeline) в облако безболезненно для предприятия. Схематично весь процесс перехода можно разделить на 5 последовательных этапов, каждый из которых мы подробнее рассмотрим далее [2]:

1.       создание и настройка кластера;

2.       задание хранилища данных;

3.       создание и настройка data pipeline’ов;

4.       мониторинг производительности и обеспечение безопасности;

5.       оптимизация.

Создание облачного кластера Hadoop в Dataproc

Облачный кластер может использовать одну из версий образа, предоставленных Dataproc, или пользовательский вариант на основе одной из предоставленных версий. Версия образа – это стабильный и поддерживаемый пакет операционной системы, компонентов стека Big Data и коннекторов Google Cloud, таких как Google Cloud Storage Connector for Hadoop, о котором мы писали здесь. Можно использовать последнюю версию образа по умолчанию или выбрать вариант, соответствующий существующей платформе, включая дополнительные поддерживаемые компоненты, например, Druid и Presto. А если нужны компоненты, которые еще не доступны, например, Apache Livy, следует инициализировать их, запустив исполняемый файл или скрипт на каждом узле кластера сразу после его установки.

В Dataproc очень просто создать типовой Hadoop-кластер с одним главным узлом или кластер высокой доступности с тремя главными узлами. Для этого следует в оболочке Cloud Shell выполнить следующую команду [2]:

# create a cluster in us-central1

gcloud dataproc clusters create my-first-cluster \

–region=us-central1

Определение хранилища данных

После создания кластера и добавления в него нужных дополнительных компонент, следует перенести сами данные в Google Cloud. Для этого можно присоединить HDFS, подключив постоянные диски (PD) к узлам Dataproc-кластера. Это тоже один из продуктов Google, представляющий собой надежное высокопроизводительное блочное хранилище для экземпляров виртуальных машин [3]. Другой популярной альтернативой является использование Google Cloud Storage в качестве хранилища. Чтобы переключиться с HDFS на облачное хранилище, следует изменить префикс пути к файлу с hdfs:// на gs://. Можно также использовать реляционные хранилища, такие как Delta Lake на базе Apache Spark и Iceberg, для поддержки схемы, транзакций ACID и управления версиями данных. Напомним, Apache Iceberg – это открытый формат таблиц для огромных наборов аналитических данных, который добавляет в Presto и Spark SQL-подобные таблицы [4]. Примечательно, что независимо от выбора хранилища самих данных, для кластеров Dataproc следует использовать центральное хранилище метаданных Apache Hive c MySQL в CloudSQL в качестве базы данных. Чтобы упростить переход на BigQuery, бессерверное хранилище данных петабайтного масштаба, Dataproc предоставляет специальные коннекторы: BigQuery connector и BigQuery Spark connector [2].

Запуск аналитических конвейеров

Dataproc упрощает отправку заданий в кластер с помощью метода jobs.submit в API без необходимости настраивать экземпляры периметра. Он использует центральный уровень управления идентификацией и доступом для проверки подлинности и авторизации запросов, позволяя выполнять задания на частных кластерах максимально безопасно. Для более сложных конвейеров обработки данных из несколько взаимозависимых заданий в виде разветвленного DAG-графа, можно использовать workflow-шаблоны Dataproc или прибегнуть к помощи Apache Airflow от Google Cloud через Dataproc API с Cloud Composer [2].

Мониторинг и безопасность

Центральный уровень управления идентификацией и доступом обеспечивает простой доступ к выходным данным задания или контрольному журналу с помощью Cloud Logging. Чтобы управлять ресурсами и приложениями кластера и контролировать их через безопасный доступ к веб-интерфейсу Hadoop, следует включить Dataproc Component Gateway. Облачный мониторинг или облачное профилирование подходят для расширенных вариантов использования, таких как мониторинг работоспособности и производительности, создание аналитических отчетов или панелей мониторинга.

Чтобы обеспечить безопасность и изоляцию, каждый кластер рекомендуется запускать с отдельной учетной записью службы с доступом только к тем ресурсам, которые требуются для выполнения задания. Такая учетная запись службы также полезна при мониторинге, аудите и отладке. Поскольку между рабочими процессами нет взаимозависимости, пользователь Dataproc может тестировать и развертывать различные версии компонентов Hadoop и своего сервиса. А режим работы кластера по требованию (on demand) позволяет сократить расходы с помощью механизма вытесняемых экземпляров (инстансов) для выполнения задач. Однако, это не подойдет в случае работы с HDFS, поскольку такие инстансы могут быть отключены в любой момент [2].

Оптимизация

Наконец, когда данные и конвейеры их обработки перенесены в облако, имеет смысл задуматься об их оптимизации, чтобы снизить операционные накладные расходы и затраты. В частности, использование облачного хранилища данных и Apache Hive в качестве внешнего хранилища метаданных, позволяет отделить хранение от вычислений. Это позволяет сосредоточиться на процессах обработки больших данных, а не на особенностях эксплуатации кластера. В частности, можно создавать эфемерные кластеры по требованию, которые удаляются по завершении работы конвейера данных. Кроме того, по мере роста рабочих нагрузок часто возникает проблема накладных расходов, о чем мы недавно рассказывали на примере конвейеров из заданий Spark, запускаемых с помощью Apache AirFlow. В этом случае Dataproc обеспечивает ручное и автоматическое масштабирование, которое использует метрики YARN для управления количеством узлов [2].

Google Cloud Platform, Dataproc, Apache Hadoop, Spark, облака, конвейеры обработки Big Data
Схема запуска Hadoop/Spark-заданий в Google Dataproc

О других проблемах перехода от локального Hadoop-кластера к облачному объектному хранилищу с применением Spark-приложений читайте здесь.

Разобраться в тонкостях администрирования и эксплуатации экосистемы Apache Hadoop для хранения и обработки больших данных, вы сможете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

 

Источники

1.       https://cloud.google.com/dataproc/docs/concepts/overview

2.       https://medium.com/google-cloud/migrating-hadoop-to-dataproc-43e8da80ba98

3.       https://cloud.google.com/persistent-disk/

4.       https://iceberg.apache.org/