Недавно мы рассматривали, как дата-инженеры Airbnb перевели аналитические нагрузки корпоративного озера данных с Apache Hive на Iceberg и Spark. Продолжая разговор про эти фреймворки реализации Data Lake, сегодня разберем стратегии миграции озера данных с Apache Hive на Iceberg.
Зачем уходить с Apache Hive на Iceberg и как это сделать
Напомним, в отличие от Apache Hive, Iceberg отлично поддерживает высокопроизводительные аналитические нагрузки, включая сериализуемую изоляцию данных, перемещения во времени на основе моментальных снимков и эволюцию схемы. Эти преимущества Apache Iceberg над Hive достигаются благодаря тому, что Iceberg хранит сами записи и их метаданные в объектном хранилище, тогда как Hive – в файловом, этот открытый формат таблиц. Эта архитектурная разница позволяет всем приложениям, которые работают с озером данных, одновременно и напрямую обновлять или считывать данные из Data Lake, упрощая ETL-процессы. Подробно об отличиях Apache Hive и Iceberg мы писали здесь.
Чтобы перейти от Hive к Iceberg, можно воспользоваться одним из следующих вариантов миграции:
- Миграция данных на месте (in-place migration), что позволяет избежать перезаписи данных, а сразу создавать новые таблицы Apache Iceberg, которые содержат уже существующие файлы данных в озере данных.
- Теневая миграция (shadow migration), когда создается новая таблица Iceberg и все связанные с ней метаданные, а также перезаписываются все файлы данных. Эта новая таблица (тень) становится основной после того, как все данные будут синхронизированы. Большие наборы данных можно обрабатывать партиями.
Рассмотрим достоинства и недостатки каждого из подходов.
Код курса
HIVE
Ближайшая дата курса
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Миграция данных на месте
Этот вариант перехода с Apache Hive на Iceberg может занять меньше времени, поскольку все данные не будут пересоздаваться. Если возникнет ошибка при записи метаданных Iceberg, нужно перезаписать только метаданные, а не сами данные, что тоже экономит время. Происхождение данных сохраняется, поскольку метаданные из ранее существовавшего каталога все еще существуют.
Однако, при добавлении новых данных во время записи метаданных, придется повторить попытку их включения в набор. Предотвратить повторную попытку этой операции можно во время простоя записи, что не всегда выполнимо в реальности. Кроме того, этот подход не работает, если какие-либо данные необходимо переформулировать. Чтобы обеспечить такую миграцию, Iceberg имеет несколько процедур, встроенных в расширения Spark. Какую процедуру использовать, зависит от того каталога Apache Spark.
Чтобы заменить существующую таблицу Hive, сделав ее таблицей Iceberg, следует выполнить процедуру миграции, сперва создав новую таблицу, используя файлы данных исходной таблицы. В новой таблице Iceberg используются те же файлы данных, что и в исходной таблице Hive. В идеале сначала надо создать временную тестовую таблицу с помощью процедуры моментального снимка, а затем использовать процедуру миграции. Исходные файлы данных должны быть в формате Parquet, AVRO или ORC.
Добавить файлы данных из существующей таблицы Hive в существующую таблицу Iceberg поможет процедура add_files. Она добавляет существующие файлы данных из исходной таблицы Hive в существующую таблицу Iceberg с новым моментальным снимком, включающим эти файлы. Исходная таблица Hive и целевая таблица Iceberg будут ссылаться на одни и те же файлы данных.
Код курса
NOSQL
Ближайшая дата курса
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Теневая миграция таблиц Hive
При теневой миграции создается не только тень – новая таблица Iceberg и все связанные с ней метаданные, а также перезаписываются все файлы данных. Таблица-тень становится основной после синхронизации всех данных. Теневая миграция позволяет проводить аудит и проверку данных, так как файлы данных должны быть прочитаны для переформулирования. Можно заранее применить изменения схемы и раздела. В случае теневой миграции проблемы с повреждением данных маловероятны, поскольку данные проверяются и синхронизируются в процессе.
Однако, в этом варианте миграции объем хранилища для набора данных удваивается, поскольку придется хранить как исходную таблицу Hive, так и новую таблицу Iceberg. Впрочем, это временная проблема, т.к. старую таблицу Hive можно удалить после завершения миграции. Более значимый недостаток теневой миграции в том, что из-за перезаписи данных и метаданных, этот путь может занять намного больше времени, чем миграция на месте. Кроме того, достаточно трудно поддерживать синхронизацию таблиц, если во время переноса в исходную таблицу Hive вносятся изменения. Хотя эта проблема также временная, поскольку синхронизация обновлений не имеет значения после удаления исходной таблицы по завершении миграции.
Для небольших наборов данных переопределение таблицы целиком можно легко выполнить с помощью распараллеленной операции CREATE TABLE AS SELECT (CTAS), которая создает новую таблицу на основе выходных данных инструкции SELECT. CTAS — это самый простой и быстрый способ создания и вставки данных в таблицу с помощью одной команды. По сути, CTAS — это версия инструкции SELECT…INTO с более широкими возможностями настройки: SELECT…INTO не позволяет изменять метод распределения или тип индекса в рамках одной операции. А CTAS дает возможность указать как распределение данных таблицы, так и тип ее структуры.
CTAS очень часто применяется при создании копии таблицы для изменения данных и позволяет изменить ранее созданную таблицу в партиционированную таблицу по определенному столбцу. CTAS определяет, как будет изменен столбец разделения и может использоваться для изменения партиционирования, индексирования и типов столбцов.
Возвращаясь к теневой миграции с Apache Hive на Iceberg для больших наборов данных можно переформулировать первоначальный пакет с помощью оператора CTAS и продолжить оперировать пакетными вставками до тех пор, пока весь источник не будет загружен в новую таблицу.
Архитектура и план миграции данных
Независимо от выбранного способа миграции данных, этот процесс требует тщательной архитектуры и обычно состоит из следующих этапов:
- пока новая таблица Iceberg еще не создана и не синхронизирована с источником, пользовательские операции чтения и записи продолжают выполняться в исходной таблице Hive;
- когда таблица Iceberg создана, но не полностью синхронизирована, операции чтения применяются к исходной таблице Hive, а операции записи применяются к исходной и новой таблицам;
- после синхронизации новой таблицы можно переключиться на операции чтения в новой таблице. Пока нет подтверждения, что миграция данных выполнена успешно, следует применять операции записи к исходной и новой таблицам.
- Когда все, наконец, протестировано, синхронизировано и работает корректно, можно применить все операции чтения и записи к новой таблице Iceberg и удалить исходную таблицу Hive.
По мере прохождения этих этапов дата-инженеру следует проверять согласованность данных и ведение журнала ошибок, чтобы управлять качеством, устранять неполадки и измерять продолжительность миграции.
В заключение отметим, что хотя процедуры Iceberg и операторы CTAS обеспечивают простой способ переноса существующих таблиц Hive, следует разработать такой план миграции, чтобы свести к минимуму возможные сбои или вовсе устранить их, повышая надежность корпоративного Data Lake.
Больше подробностей про администрирование и эксплуатацию Apache Hive и других компонентов экосистемы Hadoop для хранения и аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники