Версия сайта для слабовидящих
Недавно мы рассматривали производительность ETL-конвейеров на Apache Spark с озером данных на MinIO. Сегодня разберем, чем это легковесное объектное хранилище отличается от распределенной файловой системы Apache Hadoop и как перейти на него с HDFS.
Зачем переходить на MinIO
Хотя HDFS до сих пор активно используется во многих Big Data проектах в качестве основного хранилища данных и базы корпоративного Data Lake, многие предприятия мигрируют в облачные сервисы хранения объектов. Одним из таких является MinIO — высокопроизводительное объектное хранилище, совместимое с AWS S3. Оно может быть развернуто в публичном или частном облаке на платформе программной виртуализации Kubernetes. В отличие от HDFS, MinIO хранит не файлы, а объекты, которые состоят из файлов и метаданных. Главным преимуществом MinIO по сравнению с HDFS является скорость: MinIO работает намного быстрее. Сегодня MinIO считается самым быстрым хранилищем объектов на рынке с пропускной способностью GET/PUT 325 и 165 ГиБ/с соответственно всего на 32 узлах NVMe. Эти скорости позволяют выполнять любую рабочую нагрузку на MinIO, от расширенной аналитики до AI/ML.
Системы Hadoop полагаются на несколько узлов вычислений и хранения, каждый из которых обрабатывает подмножество общего набора данных. Он включает в себя три копии необработанных данных для надежности и большое количество узлов по мере увеличения размера наборов данных. Это означает потенциально сотни серверов. Объектное хранилище по своей природе более надежно, чем Hadoop, и не требует создания трех копий данных. А благодаря отделению вычислений от хранения, объем вычислительных ресурсов для аналитики больших данных можно адаптировать к рабочей нагрузке, а не извлекать из узлов HDFS. Таким образом, MinIO работать на меньшем количестве серверов, чем HDFS, требует меньше места на диске или твердотельном накопителе для хранения данных. Это экономит время и деньги. Поэтому проекты миграции озера данных с HDFS на MinIO актуальны для многих компаний. Однако, выполнить такой переход не так-то просто на практике. Как это сделать, мы рассмотрим далее.
План перехода с HDFS
Прежде всего, как и в любых проектах миграции данных, следует определить, какие данные необходимо перенести. Поскольку миграция данных является дорогостоящей операцией, лучше всего выполнять миграцию только тех данных, которые будут немедленно необходимы приложениям. Исторические данные можно перемещать в хранилище резервных копий и загружать в объектное хранилище по мере необходимости. Шаги для переноса исторических данных будут такими же, как и для оперативных.
Определив набор данных, подлежащих переносу, необходимо рассмотреть следующие вопросы сопоставления структуры данных, скорости и архитектуры миграции. Последним шагом является непосредственное выполнение миграции. Общая структура данных в HDFS имеет следующую схему:
hdfs://apps/$app_name/$db_name/$table_name/$record
где $app_name — это название приложения управления данными, например, Hive, $db_name — название базы данных, $table_name — название таблицы, а $record — строка таблицы.
Необходимо воспроизвести точную структуру этих данных в объектном хранилище. Например, создать сегмент для каждого приложения, а его вложенные папки — для каждой базы данных в этом приложении. Далее следует, что таблицы будут вложенными папками папок базы данных, а записи будут вложенными папками папок таблиц. Таким образом, структура хранилища объектов будет следующей:
s3a://$app_name/$db_name/$table_name/$record
Чтобы приспособиться к шаблонам использования, когда разные приложения масштабируются с разной скоростью, обычно создается отдельный кластер MinIO для каждого приложения и используется сегмент для каждой базы данных. Это позволит управлять, масштабировать и защищать каждый кластер MinIO как отдельную единицу. Структура хранилища объектов для работы с Apache Hive будет следующей:
s3a://endpoint-hive:9000/$hive_db_name/$table_name/$record
А для работы со Spark такой:
s3a://endpoint-spark:9000/$spark_db_name/$table_name/$record
Если в базе данных много записей, и каждая из них хранится в отдельном файле, то перед переносом данных их лучше сгруппировать в файлы, чтобы решить проблему «слишком большого количества файлов», о чем мы писали здесь. Это повысит производительность выполнения запросов, особенно если в таблице много записей.
Для переноса данных с максимальной скоростью параметры переноса должны быть установлены так, чтобы по максимуму утилизировать возможности аппаратного обеспечения. Например, в изначальном кластере HDFS с 10 узлами, каждый узел имел 8 жестких дисков и максимальную пропускную способность 200 МБ/с. С каналами связи 10 Гбит/с расчет максимальной производительности будет следующим:
- пропускная способность диска равна 8*200 МБ/с = 1600 МБ/с = 12,8 Гбит/с;
- пропускная способность сети равна 10 Гбит/с;
- пропускная способность ввода-вывода равна минимуму из этих двух значений (12,8 Гбит/с, 10 Гбит/с), т.е. 10 Гбит/с.
Для всего кластера HDFS максимальная пропускная способность будет равна произведению количества узлов на максимальную пропускную способность миграции данных, т.е. 10*10 Гбит/с = 100 Гбит/с. Это предполагает, что принимающий кластер имеет возможность принимать данные с такой скоростью. А минимальное количество времени для передачи всего набора данных можно рассчитать как общий объем данных в МБ, разделенный на максимальную пропускную способность кластера в МБ/с. Таким образом, перенос 1 петабайта данных с пропускной способность кластера 100 Гбит/с займет почти сутки (22 часа 13 минут и 20 секунд).
Определив желаемую пропускную способность, следует выбрать минимальное количество узлов, необходимое для ее достижения. Передача данных может быть инициирована с этих узлов на MinIO. В кластере MinIO с несколькими узлами можно агрегировать пропускную способность всех узлов, направив каждую из задач по передаче данных на другую конечную точку в кластере, равномерно распределив нагрузку по всем серверам с помощью циклического DNS или файла /etc/hosts. В случае использования файла с хостами на каждом из узлов этот файл /etc/hosts должен содержать доменное имя «minio», указывающее на другой узел в кластере.
Наконец, непосредственно сам перенос выполняется Hadoop-утилитой распределенного копирования DistCp, которая предназначена для большого межкластерного и внутрикластерного копирования. Она использует MapReduce для распространения, обработки и восстановления ошибок, а также создания отчетов. Утилита расширяет список файлов и каталогов во входные данные для сопоставления задач, каждая из которых копирует раздел файлов, указанных в исходном списке.
При копировании из нескольких источников DistCp прервет копирование с сообщением об ошибке при конфликте двух источников, разрешив конфликты в месте назначения согласно указанным параметрам. По умолчанию файлы, уже существующие в месте назначения, пропускаются, т. е. не заменяются исходным файлом. Количество пропущенных файлов сообщается в конце каждого задания, но оно может быть неточным, если процесс копирования потерпел неудачу для некоторого подмножества своих файлов, но был успешно выполнен в более поздней попытке.
При переносе данных важно, чтобы каждый NodeManager HDFS мог связаться как с исходной, так и с целевой файловыми системами. Для HDFS и источник, и место назначения должны использовать одну и ту же версию протокола или использовать протокол, совместимый с предыдущими версиями. После копирования рекомендуется создать и перепроверить список источника и места назначения, чтобы убедиться, что копирование было действительно успешным. Поскольку DistCp использует как Map/Reduce, так и FileSystem API, проблемы в любом из трех или между ними могут неблагоприятно повлиять на копию данных. Если другой клиент все еще записывает исходный файл, копирование, скорее всего, не удастся. Попытка перезаписать файл, записываемый в место назначения, также не должна завершаться в HDFS. Если исходный файл (повторно) перемещается до того, как он будет скопирован, копирование завершится с ошибкой FileNotFoundException.
Больше подробностей про администрирование и эксплуатацию экосистемы Hadoop для хранения и аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Hadoop для инженеров данных
- Безопасность озера данных Hadoop на платформе Arenadata
- Администрирование кластера Hadoop
- Интеграция Hadoop и NoSQL
Источники
