Сегодня рассмотрим, что такое 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 в Москве:
Источники
