Зачем делать моментальные снимки состояния распределенной файловой системы Apache Hadoop, почему не стоит создавать снапшоты HDFS в корневом каталоге и как найти оптимальную частоту сохранения состояния больших данных.
Как устроен механизм снапшотов в HDFS
Чтобы повысить надежность системы, ее состояние необходимо периодически сохранять. Для баз данных и файловых систем эта операция реализуется с помощью механизма снапшотов (snapshot) – моментальных снимков текущего состояния системы на конкретный момент времени. В отличие от бэкапа – резервной копии всего объема данных, который создается долго и предполагает блокировку изменений, чтобы гарантировать консистентность данных, моментальный снимок фиксирует мгновенное состояние хранимых объектов, не создавая их полную и независимую копию. Эта технология позволяет организовать целостное резервное копирование большого объёма данных без блокировки мутации данных, если делать бэкап с зафиксированного снапшота. Также снапшоты позволяют защитить систему от ошибок пользователя и обеспечить аварийное восстановление в случае критического сбоя, откатившись к зафиксированному рабочему состоянию.
Идея снапшотов в распределенной файловой системе Apache Hadoop реализована очень эффективно: снимок создает мгновенно, независимо от размера и глубины поддерева каталога, фиксируя список блоков и размер файла для указанного поддерева. При этом дополнительные копии блоков HDFS не создаются: моментальный снимок фиксирует список блоков и размер файла без фактического копирование данных, в отличие от процедуры создания бэкапа.
Само создание моментального снимка всегда требует одинаковых усилий, поскольку создается только запись каталога таблицы снапшотов и его состояния на тот момент. Однако, удаление моментального снимка HDFS требует обхода всего поддерева бинарного поиска для каждого файла или каталога со сбором блоков, которые будут удалены. Это приводит к накладным расходам и может потребовать большого объема памяти для сбора блоков. Вычислительная сложность определения отличий между 2-мя разными снапшотами также зависит от количества файлов и каталогов в пути сравнения, изменений и сделанных снимков. Определить эти различия позволяет команда snapshotDiff. Если запустить ее с опцией -update, можно переместить вычисленную разницу в указанный целевой каталог.
Создание снапшотов не влияет на регулярные операции HDFS: изменения записываются в обратном хронологическом порядке, поэтому прямой доступ к текущим данным не блокируется. Данные снапшота вычисляются путем вычитания изменений из текущих данных. Чтобы разрешить создание снапшота в каком-либо каталоге HDFS, администратор должен разрешить эту возможность, установив конфигурацию snapshottable. Каталог с такой настройкой может одновременно хранить 65 536 снимков без ограничений на количество каталогов таблиц снапшотов.
Однако, если в каталоге таблицы снапшотов уже есть моментальные снимки, такой каталог нельзя удалить или переименовать до удаления снимков. Вложенные каталоги таблиц снапшотов не допускаются, т.е. каталог не может snapshottable, если какой-либо из его предков или потомков имеет эту настройку включенной.
Разобравшись с основами работы механизма снапшотов в HDFS, далее рассмотрим лучшие практики его использования.
ТОП-5 советов по работе с моментальными снимками распределенной файловой системы Apache Hadoop
Не рекомендуется создавать моментальные снимки в корневом каталоге файловой системы, который включает папку с временными данными (tmp) и корзину, где содержится множество ненужных файлов. Эти файлы будет невозможно фактически удалить, если они содержатся в снапшотах.
Поэтому не следует делать снапшоты HDFS слишком часто. Лучше создавать моментальные снимки только при необходимости, например, только после завершения заданий и высоких рабочих нагрузок, чтобы избежать записи файлов tmp. Также следует регулярно удалять ненужные снимки.
Рекомендуется установить единые политики моментальных снимков для всей файловой системы, несмотря на разное содержание каталогов HDFS. Если в разных проектах будет разное время удаления собственных снапшотов, есть вероятность случайно удалить не тот снимок, что приведет к сложной реструктуризации внутренних данных. В свою очередь, откат назад с его восстановлением может быть долгим, поскольку зависит от количества операций и промежуточных снимков между исходным и текущим состояниями, как было отмечено ранее. Поэтому рекомендуется создавать снимки в каталогах проекта и каталогах пользователей.
Чтобы процедура сравнения не занимала слишком много времени, лучше вычислять разницу между снашпотами, когда она не слишком велика, т.е. между сравниваемыми снимками прошло не слишком много времени. Поэтому рекомендуется вычислять для вновь созданных снимков, время создания которых не слишком отличается. По аналогичной причине не следует запускать сравнение снимков в snapshottable-каталоге, который может включать в себя временные файлы.
При удалении нескольких снимков лучше удалять их по мере обновления, т.е. от самого старого к самому новому, поскольку удаление снапшотов в случайном порядке может привести к сложной реструктуризации внутренних данных. Определить порядок создания моментальных снимков поможет команда lsSnapshot <snapshotDir>. Затем можно отсортировать выходные данные по идентификатору моментального снимка. Если самый старый снимок файловой системы больше не нужен, его следует немедленно удалить: это поможет освободить место, но не приведет к потере данных.
Освойте администрирование и эксплуатацию Apache Hadoop для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
