Что такое Beekeeper: автоматическая очистка метаданных Hive-таблиц

Сегодня рассмотрим, что такое Beekeeper и как этот сервис помогает администраторам Hadoop и пользователям Apache Hive очищать метаданные этого NoSQL-хранилища. Читайте далее, зачем удалять устаревшие пути из Metastore и как настроить конфигурацию Hive-таблиц для автоматического прослушивания событий их изменения.

Для чего очищать потерянные метаданные в Apache Hive

Напомним, Apache Hive относится к стеку SQL-on-Hadoop и позволяет анализировать данные в HDFS с помощью SQL-подобного языка структурированных запросов (HiveQL). Чтобы сопоставить схемы таблиц и баз данных с информацией в HDFS, Hive использует хранилище метаданных (MetaStore), где хранится вся информация о таблицах базы данных в Presto и Hive. Подробнее об этом мы писали здесь. На практике Hive часто используется в качестве средства аналитики больших данных, хранящихся в корпоративных озерах на базе Hadoop HDFS. Поскольку работа с данными всегда носит эволюционный характер, некоторые наборы данных в Data Lake больше не используются. При этом могут возникнуть ситуации, когда данные существуют в файловой системе, но недоступны через HiveQL-запрос, например, при удалении раздела во внешней таблице Hive. Таким образом, наборы данных, на которые не ссылается Hive, становятся устаревшими, «потерянными», путают пользователей и могут повлечь ненужные расходы на попытки их обработки [1].

Чтобы решить проблему устаревших данных, американская travel-компания Expedia Group разработала сервис под названием Beekeeper. Изначально он был создан для собственных нужд, а затем исходный код этого проекта был выложен на Github под лицензией Apache 2.0 [2]. Далее мы рассмотрим, как устроен Beekeeper и какова его польза для администратора Hadoop и пользователя Apache Hive.

Что такое Beekeeper и как он работает с Hive-таблицами

Beekeeper развивает идею другого open-source проекта Expedia Group под названием Circus Train, который копирует наборы данных Hive как неизменяемые моментальные снимки, чтобы обеспечить надежную согласованность и изоляцию реплицированного хранилища метаданных за счет указания на новый snapshot только при успешном завершении. В результате остается множество snapshot’ов, на которые Hive Metastore больше не ссылается. Поэтому Circus Train включает модуль Housekeeping для последующего удаления этих файлов.

Именно модуль Housekeeping был переписан и обновлен в виде проекта Beekeeper – автономного сервиса для удаления устаревших данных, на которые больше не ссылается Hive Metastore.

Beekeeper использует Apiary — озеро данных федеративного облака с открытым исходным кодом — для обнаружения изменений в Hive Metastore. Один из компонентов Apiary, Metastore Listener, фиксирует события Hive и публикует их как сообщения в топике SNS (Simple Notification Service, простой сервис обмена сообщениями). Beekeeper использует эти сообщения для обнаружения изменений в Hive Metastore и выполнения соответствующих удалений.

Beekeeper состоит из трех отдельных Java-приложений на основе Spring:

Scheduler Apiary — приложение, которое планирует пути и метаданные для удаления в общей базе данных, с одной таблицей для путей без ссылок, а другой – для метаданных с истекшим сроком действия. Это приложение периодически опрашивает очередь SQS Apiary на предмет событий Hive Metastore и вставляет пути S3 и таблицы Hive в базу данных, планируя их удаление.
Path Cleanup – приложение для удаления путей, на которые нет ссылок, периодически запрашивая их у базы данных.
Metadata Cleanup — приложение, которое удаляет метаданные с истекшим сроком действия, периодически запрашивая их у базы данных

Свойство «без ссылки» может быть добавлено в Hive-таблицы, чтобы определять, когда ссылки на пути перестают существовать. Такая проверка запускается следующими событиями над таблицами Hive:

alter_partition – изменение раздела;
alter_table – изменение таблицы;
drop_partition – удаление раздела со всеми данными и структурой;
drop_table – удаление таблицы со всеми данными и структурой.

По умолчанию события alter_partition и alter_table не требуют дополнительной настройки Hive-конфигураций. Другие типы событий рекомендуется внести в белый список для каждой таблицы, чтобы избежать непредвиденной потери данных. Таким образом, работа Beekeeper выглядит так [2]:

Таблица Hive настраивается с параметром remove.unreferenced.data = true;
с таблицей выполняется операция, в результате которой некоторые метаданные теряются, например, имезняется или удаляется раздел и пр.;
случившиеся при этом события Hive Metastore прослушивает Apiary Metastore Listener;
Beekeeper собирает из очереди события Hive с помощью Apiary Receiver;
Beekeeper обрабатывает эти сообщения и планирует удаление потерянных путей, добавляя их в базу данных;
запланированные к удалению пути удаляются после настраиваемой задержки, по умолчанию равной 3 дня.

Также Beekeeper 3.1.0 поддерживает удаление временных таблиц из озера данных, для которых определен срок жизни (TTL, Time-to-Live). Beekeeper будет отслеживать их и обеспечивать удаление метаданных таблицы и базовых данных после достижения указанного TTL. Для партиционированных таблиц TTL будет применяться для каждого раздела. Конкретный раздел будет удален, как только будет достигнут его TTL, а соответствующая таблица будет удалена только тогда, когда не останется никаких разделов. Это полезно, когда пользователи хотят работать с данными в режиме скользящего окна, например, удалить все данные старше 30 дней. Для не партиционированных таблиц TTL будет применен ко всей таблице сразу: она будет удалена при достижении заданного срока. Это пригодится, если необходимо создавать временные таблицы, например, для тестирования [3].

При этом важно знать о некоторых проблемах TTL-функции, которые разработчики планируют устранить в будущем [2]:

если таблица или раздел удаляются пользователем до истечения TTL-срока, на связанные с ними пути не будет ссылок и они не будут очищены. Избежать этого можно, добавив в таблицу свойство unreferenced. Но оно прослушивает любое drop-событие в этой таблице, поэтому любой путь для таблицы/раздела, удаленный Beekeeper во время очистки TTL, будет снова запланирован для удаления в таблице очистки без ссылки.
если переименовать партиционированную таблицу с существующими разделами, эти разделы не будут удалены через drop до тех пор, пока не истечет TTL-срок таблицы. К примеру, таблица создается с задержкой очистки в 2 дня и в нее добавляется раздел. Задержка изменяется на 10 дней, а затем таблица переименовывается. В текущем выпуске Beekeeper существующий раздел не будет переназначен для удаления из новой таблицы, а удалится вместе с ней через 10 дней вместо 2.

Впрочем, несмотря на указанные проблемы, Beekeeper решает одну из важных ежедневных задач дата-инженера и администратора Hadoop Hive, позволяя автоматически очищать устаревшие пути и потерянные метаданные. Для этого к настройкам Hive-таблицы следует добавить несколько конфигураций [2]:

beekeeper.remove.unreferenced.data = true – необходимо, чтобы Beekeeper отслеживал таблицу на предмет потерянных данных;
unreferenced.data.retention.period = X, где X – это продолжительность задержки между планированием и удалением в формате ISO_8601, например, P7D или PT3H, по умолчанию равен 3 дня;
beekeeper.hive.event.whitelist = X, где X – это список типов событий, разделенных запятыми, для внесения в белый список потерянных данных: alter_partition, alter_table, drop_table, drop_partition;
remove.expired.data = true – необходим для включения TTL для Hive-таблицы, который будет отслеживать Beekeeper;
beekeeper.expired.data.retention.period = X, где X – это продолжительность TTL для таблицы в формате ISO_8601, например, P7D или PT3H, по умолчанию равен 30 дней.

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

Смотреть расписание

Записаться на курс

Источники