Hive Metastore или Iceberg REST Catalog: четыре требования, по которым решают о переходе

Q: Что ломается при миграции таблиц из Hive в Iceberg?

Есть три основных риска.. Неподдерживаемые форматы. Процедура migrate завершится с ошибкой, если хотя бы одна партиция использует формат вне Avro, Parquet или ORC. Таблицы с кастомными SerDe придётся не мигрировать, а перезаписывать в поддерживаемый формат.. Бакетирование. Spark не мигрирует бакетированные таблицы. Trino ведёт себя иначе: переносит такую таблицу как небакетированную Iceberg-таблицу. Формально миграция пройдёт, но бакетирование исчезнет, и последствия могут проявиться позже в профиле запросов.. Ожидание команды CONVERT TO ICEBERG. Такой команды нет. Для перехода используют snapshot, migrate или addfiles. При migrate исходная таблица по умолчанию сохраняется под именем tableBACKUP_, поэтому откат предусмотрен сразу. Главное — не удалить резервную таблицу раньше времени.

25 сентября 2026 г.

Евгений Левашов

Автор статьи

Команда, которая обсуждает переход с Hive Metastore на Iceberg REST Catalog, часто сравнивает два продукта. Такая постановка устарела. Начиная с версии 4.1.0, выпущенной 31 июля 2025 года, Hive Metastore сам публикует эндпоинты Iceberg REST Catalog API. Одну таблицу можно открыть через Thrift или REST: «Iceberg users can access Iceberg tables via either Hive Metastore Thrift API (using HiveCatalog) or Iceberg REST Catalog API». Метастор стал одной из реализаций протокола, с которым его обычно сравнивают.

Выбирать приходится не продукт, а режим эксплуатации каталога. Производительность здесь не главный критерий: публично измеримого порога, после которого Lakehouse обязательно должен отказаться от метастора, нет. Решение появляется, когда Hive Metastore не закрывает требования по своей архитектуре, а не когда достигается определённая нагрузка.

В этой статье — чек-лист из четырёх требований, три сценария по его итогам, признаки исчерпания метастора, сравнение четырёх режимов и разбор миграции со стоп-факторами. Возможно, менять ничего не понадобится: достаточно включить REST-эндпоинт у уже работающего метастора.

Статья подготовлена с экспертом

Никита Янченков, руководитель подразделения Аналитические сервисы и управление данными

Четыре режима вместо двух продуктов

Формулировка «Hive Metastore или Iceberg REST» смешивает транспорт, протокол и конкретный продукт. На деле есть четыре режима с разным порогом входа и набором ограничений.

Режим 1. Классический метастор через Thrift

Hive Metastore — сервис-реестр метаданных таблиц. Он хранит схемы, описания партиций и пути к файлам в реляционной БД. Движки подключаются к нему по Thrift, а на каждом клиенте работает JVM-прослойка. Так устроено большинство контуров, выросших из Hadoop.

Режим 2. Тот же метастор с Iceberg REST API

REST-слой включается через порт сервлета metastore.catalog.servlet.port. Thrift и REST работают одновременно с одними и теми же таблицами.

Функциональность выходила в двух релизах:

Hive 4.1.0 от 31 июля 2025 года: Iceberg REST Catalog (HIVE-28059), работа без аутентификации (HIVE-28998), прогон через compatibility kit (HIVE-29019)
Hive 4.2.0 от 23 ноября 2025 года: OAuth 2 (HIVE-29020), ViewCatalog через REST (HIVE-29036), клиент REST-каталога (HIVE-28658), операции записи через REST-клиент (HIVE-29220), исправление падения REST-слоя на обычном метасторе (HIVE-29145)

Последний фикс важен для эксплуатации. В версии 4.1.0 REST-путь ещё сырой, поэтому ориентироваться стоит на Hive 4.2.0. На сентябрь 2026 года актуальны Hive 4.2.1, Apache Iceberg 1.11.0 и Trino 483.

Режим 3. Сторонний Iceberg REST-каталог

Это отдельный stateless-сервис, реализующий спецификацию Iceberg REST Catalog. Состояние хранится в бэкенд-БД, а сервис масштабируется горизонтальными репликами за балансировщиком. К этому классу относятся Apache Polaris, Project Nessie, Lakekeeper и другие реализации. Как соотносятся Polaris, Nessie и другие реализации, мы разбирали отдельно.

Режим 4. Каталог как продукт

Здесь REST-протокол дополнен эксплуатационной обвязкой: интерфейсом управления, ролями и пользователями, средствами обслуживания таблиц. На российском рынке в таком режиме работает CedrusData Catalog.

Сравнение часто становится некорректным из-за двух мифов.

Миф 1. У метастора нет современной аутентификации. У REST-слоя Hive есть четыре метода аутентификации:

OAuth 2 с внешним Authorization Server, в документации используется Keycloak
JWT, метод по умолчанию с проверкой через JWKS; имя пользователя берётся из claim sub
simple через заголовок x-actor-username, который документация не рекомендует для production
none только для тестирования

Миф 2. OAuth2 в Iceberg REST устарел. Устарел встроенный эндпоинт выдачи токенов /v1/oauth/tokens: он помечен в спецификации как_ DEPRECATED for REMOVAL_ с версии Iceberg Java 1.6.0. Клиентам предлагают использовать внешний сервер через свойство oauth2-server-uri. Так устроен REST-слой Hive Metastore и продуктовые каталоги.

Всё это относится к техническому каталогу, то есть реестру таблиц для движков. Каталог данных в смысле governance, с владельцами, глоссарием и политиками доступа, решает другую задачу.

Чек-лист: четыре требования

Каждое требование проверяется на собственном контуре.

1. Выдача временных кредов к хранилищу

Что это. Клиент не хранит постоянный ключ к бакету. Он запрашивает у каталога короткоживущие креды. В спецификации Iceberg REST для этого есть credential vending и remote signing, эндпоинты /credentials и /sign.

Почему Thrift-путь не закрывает требование. Hive Metastore не работает с выдачей временных кредов. Ключи объектного хранилища остаются в конфигурации движка. Включение REST-эндпоинта у метастора ничего не меняет: в опубликованном Hive ответе /v1/config есть операции с таблицами, представлениями и транзакциями, но нет ни /credentials, ни /sign.

Если движок не должен получать постоянные ключи к бакету, метастор не закроет требование ни через Thrift, ни через собственный REST API.

Обход через свойства каталога небезопасен. Документация Apache Polaris для федерации метастора прямо запрещает хранить креды объектного хранилища в свойствах каталога: секреты возвращаются клиентам через /config.

Как проверить у себя. Найдите, где лежит ключ к бакету: в catalog properties координатора, переменных окружения воркеров или секрете оркестратора. Посчитайте число людей и сервисов с доступом к нему, а также оцените последствия ротации. Если один бессрочный ключ хранится в конфигурации, требование уже актуально.

2. Атомарный коммит по нескольким таблицам

Что это. Одна транзакция обновляет несколько таблиц целиком: либо изменения попадают во все таблицы, либо не попадают никуда. В спецификации для этого используется POST /v1/{prefix}/transactions/commit, операция commitTransaction. При успешном коммите сервер возвращает 204, при конфликте требований — 409 с CommitFailedException, после чего клиент может повторить операцию.

Почему Thrift-путь не закрывает требование. Поддержка мультитабличного коммита реализована в REST-каталоге: метод commitTransaction(SessionContext, List) использует endpoint V1_COMMIT_TRANSACTION. В классическом HiveCatalog аналогичного метода нет, поэтому выполнить мультитабличный коммит через Hive Metastore по Thrift нельзя.

С REST-режимом Hive Metastore ситуация не такая однозначная. Эндпоинт POST /v1/{prefix}/transactions/commit есть в опубликованном примере ответа /v1/config. Но заявленный эндпоинт ещё не доказывает реализацию, проверенную в бою.

Как проверить у себя. Посмотрите, есть ли пайплайны, в которых одновременно должны обновляться факт, витрина и словарь измерений. Разберите сценарий падения между коммитами: потребуется ручной откат, повторный прогон или витрины разойдутся на несколько часов. Если компенсирующая логика уже написана вручную и её приходится сопровождать, требование горит.

3. Контроль доступа на слое каталога

Что это. Сервис каталога определяет, кто видит namespace и кто может писать в таблицу. Правило действует сразу для всех движков.

Почему Thrift-путь не закрывает требование самостоятельно. Нельзя считать, что в Hive Metastore нет RBAC. Контроль доступа есть, но подключается внешним компонентом. Hive документирует интеграцию с Apache Ranger через RangerHiveAuthorizerFactory, с правами на уровне базы и таблицы. Ranger также поддерживает маскирование колонок и фильтрацию строк.

Это рабочая архитектура, но она требует отдельного продукта, его развёртывания, обновления и дежурства. В REST-каталогах контроль доступа встроен в сервис, поэтому правила описываются в одном месте.

Как проверить у себя. Посчитайте, сколько систем участвует в описании одного правила доступа: Ranger, конфигурации движков, политики бакета, гранты в БД метаданных. Если правило живёт в трёх местах и у него два владельца, рассинхрон почти неизбежен. Требование особенно жёсткое в Data Mesh-контурах, где данными владеют доменные команды, а не единая платформенная.

4. Клиенты вне JVM

Что это. Python-сервис, Go-приложение или cloud-native компонент обращается к каталогу по обычному HTTP без JVM-прослойки.

Это единственное из четырёх требований, которое Hive Metastore способен закрыть сам. Thrift требует JVM на каждом клиенте, а REST-эндпоинт метастора доступен по HTTP. Достаточно включить сервлет и сохранить Thrift для существующих клиентов. Но переходить на REST стоит только с Hive 4.2.0: в 4.1.0 REST-слой падал на обычном метасторе.

Как проверить у себя. Посчитайте Thrift-клиентов и их владельцев. Это прямой множитель стоимости миграции: при переходе на REST клиентов придётся переписывать или проксировать.

Что делать с чек-листом

Если ни одно из требований не оказалось критичным, Hive Metastore можно оставить как есть. Не стоит начинать миграцию только потому, что появился Iceberg REST Catalog: работающий метастор не требует замены без конкретной причины.

Если нужен только доступ к каталогу для клиентов вне JVM, достаточно обновить Hive до версии 4.2.0 и включить Iceberg REST API. Thrift-клиенты продолжат работать, а новые сервисы смогут обращаться к тем же таблицам по HTTP.

Если требуются временные креды к объектному хранилищу или единый контроль доступа на уровне каталога, одного Hive Metastore уже недостаточно. Эти возможности не появятся от включения REST-эндпоинта, поэтому придётся рассматривать отдельный Iceberg REST-каталог или готовый каталоговый продукт.

С мультитабличными транзакциями ситуация менее однозначная. REST-слой Hive Metastore публикует нужный эндпоинт, но его стоит проверить на собственном стенде с Hive 4.2.0. Если коммит нескольких таблиц работает и покрывает нужный сценарий, можно обойтись обновлением.

Три сценария по итогам

Сценарий A. Метастор остаётся рациональным выбором

Живой Hadoop-контур, где метастор уже развёрнут и обслуживается, не обязательно нужно считать техническим долгом. Остаться на нём стоит и в следующих случаях.

В production есть non-Iceberg форматы. Это жёсткое ограничение. Iceberg REST описывает Iceberg-таблицы и представления, но не Hive-таблицы произвольного формата. CedrusData Catalog прямо указывает, что не реализует Hive Metastore Thrift API и не заменяет Hive в остальных сценариях. Если в контуре есть текстовые таблицы, кастомные SerDe или форматы вне Avro, Parquet и ORC, метастор остаётся необходимым.

Есть внутренние сервисы, завязанные на Thrift. Каждый такой клиент нужно учитывать в смете миграции.

Нет бюджета на миграцию, но нужна REST-совместимость. Можно включить Iceberg REST API у самого метастора и не отключать Thrift. Такой переход получится провести постепенно.

Сценарий B. Гибрид: метастор и Iceberg REST одновременно

Есть три варианта, от наименее до наиболее инвазивного.

Двойной API у метастора, Hive 4.2+. Самый дешёвый путь: Thrift-клиенты остаются без изменений, а новые движки используют REST. Для эксплуатации нужна версия не ниже Hive 4.2.0.

Федерация метастора через Polaris. Документация проекта, пока в ветке in-dev/unreleased, описывает федерацию с существующим Hive Metastore. Внешний HMS остаётся источником истины для метаданных, а Polaris берёт на себя доступ, политики и подключение нескольких движков.

Перед пилотом нужно учесть ограничения:

Polaris придётся пересобрать с флагом -PNonRESTCatalogs=HIVE, иначе готовые бинарные сборки отклонят запросы федерации Hive.
Поддерживается только аутентификация IMPLICIT, поэтому несколько Hive identities в одном развёртывании использовать нельзя.
Федерация generic-таблиц не реализована: HiveFederatedCatalogFactory#createGenericCatalog выбрасывает UnsupportedOperationException.
Atlas-style failover и маршрутизация на несколько HMS пока не поддерживаются.
Креды объектного хранилища нельзя передавать через свойства каталога.

Несколько каталогов в одном движке. Trino может одновременно работать с каталогом hive.metastore=thrift и каталогом iceberg.catalog.type=rest. Это удобный переходный режим: новые витрины создаются в REST-каталоге, исторические таблицы остаются на прежнем месте.

Сценарий C. Iceberg REST как единственный разумный вариант

Этот сценарий появляется, когда требуется выдавать временные креды, нужен встроенный каталоговый контроль доступа или контур стал мультидвижковым. REST сокращает число интеграций: вместо коннектора для каждой пары «движок × каталог» достаточно один раз реализовать клиент на стороне движка и один раз — сервер на стороне каталога.

В этом сценарии уместен режим «каталог как продукт». Рассмотрим CedrusData Catalog по тому же чек-листу.

Что продукт закрывает:

Третье требование: RBAC на уровне каталога, управление пользователями и группами без внешнего Ranger.
Аутентификацию: OAuth2 client credentials flow через свойство credential и Bearer-токен через свойство token. Токены выпускаются командами access-token create и access-token create-temporary. На стороне движка используются iceberg.rest-catalog.security=oauth2 и iceberg.rest-catalog.oauth2.credential.
Четвёртое требование: REST-протокол, поэтому клиенты вне JVM подключаются по HTTP.
Эксплуатационную часть: Web UI, навигатор объектов, pluggable-архитектуру, управление обслуживанием Iceberg-таблиц, Java 21 и хранение метаданных в PostgreSQL или SQLite.
Формальные признаки: запись в реестре отечественного ПО № 27155 от 19 марта 2025 года, бесплатное распространение по открытой лицензии и платная версия с технической поддержкой, совместимость с S3-хранилищами YADRO TATLIN.OBJECT и «ЗАКРОМА». С марта 2026 года продукт входит в состав VK Tech.

Чего продукт пока не закрывает:

Второе требование. Мультитабличные транзакции находятся в плане развития продукта. Там же указаны автоматическое обслуживание Iceberg-таблиц, множественный координатор и проксирование других Iceberg REST-каталогов. Роадмап не стоит считать работающей функциональностью.
Первое требование. Credential vending в публично заявленной функциональности отсутствует. В плане развития есть динамический выбор S3-credentials для пользователей и Iceberg-таблиц, но включать это в обязательные требования пилота пока нельзя.
Автоматическое обслуживание. Подтверждено управление обслуживанием таблиц. Автоматические compaction, expiring snapshots и удаление осиротевших файлов находятся в плане развития. Для сравнения: Polaris не исполняет обслуживание, а только хранит политики, тогда как Unity Catalog выполняет его автоматически.
Замена Hive целиком. Thrift API продукт не реализует и не заменяет Hive в остальных сценариях. Его позиционирование — замена Hive Metastore для Apache Iceberg, а не замена Hive как платформы.

CedrusData Catalog — Iceberg REST для клиентов вне JVM, Web UI и управление пользователями из коробки

Признаки исчерпания метастора

По этим признакам нельзя определить универсальный момент, когда Hive Metastore пора менять. Это ориентиры из документации вендоров и практики эксплуатации: они показывают, где стоит проверить настройки и модель партиционирования, но не задают жёсткий предел для метастора.

Признак	Ориентир или симптом	Источник
Партиции на запрос	Один запрос должен обращаться не более чем к 10 000 партиций	Cloudera, тюнинг метастора, документация версии 7.3.1
Партиции на таблицу	После 10 000 партиций операции со всеми партициями, например DROP TABLE, могут падать. Это soft cap	Cloudera Community, «Hive Partitioning — maximum for cluster»
Латентность и число соединений	С ростом числа открытых соединений растёт латентность	Cloudera
Симптом в production	Socket Timeout при перечислении партиций до того, как запрос попадёт в планировщик. При миллионах партиций растёт риск отказа всего контура	lakeFS
Давление на реляционную БД	Удаление партиций у крупных таблиц может потребовать ограничить конкурентность одним запросом в пиковое время	lakeFS
Исторический архитектурный корень	При выборке партиций использовалась схема 1+N запросов к БД. Задачу завели в 2013 году и закрыли в Hive 0.12, но нагрузка на реляционную БД при большом числе партиций осталась	ASF Jira HIVE-4051

Цифру в 10 000 партиций часто воспринимают как общий предел, но это лишь рекомендация Cloudera по настройке Hive Metastore в конкретной сборке. Она не описывает возможности Iceberg REST-каталогов и не подходит для их сравнения.

Публичных замеров, которые сопоставляли бы задержки разных каталогов в одинаковых условиях, тоже нет. Поэтому утверждать, что REST-каталог быстрее Hive Metastore в несколько раз, пока не на чем.

Сравнение четырёх режимов

В таблице сравниваются не конкретные продукты, а способы работы с каталогом. У Hive Metastore есть два разных режима: классический доступ через Thrift и REST API для Iceberg. Их возможности зависят от версии Hive и настроек, поэтому они вынесены в отдельные колонки.

Критерий	Метастор через Thrift	Метастор с Iceberg REST API, Hive 4.1+	Iceberg REST-каталоги в общем случае	CedrusData Catalog
Legacy-слой	Тяжеловесный, тянет Hadoop-наследие	Тот же процесс и та же БД метаданных, REST поверх них	Легковесный stateless-сервис	Легковесный: Java 21, метаданные в PostgreSQL или SQLite
RBAC	Нативного нет, подключается внешний Ranger на уровне базы и таблицы	То же: Ranger, конфигурация описана в документации Hive	Контроль доступа встроен в сервис, полнота зависит от реализации	RBAC, управление пользователями и группами
UI управления	Нет	Нет	Зависит от реализации	Web UI и навигатор объектов
Обслуживание Iceberg	Нет	Нет	Зависит от реализации: Polaris хранит политики и не исполняет их, Unity Catalog выполняет автоматически	Управление обслуживанием подтверждено, автоматическое обслуживание в плане развития
OAuth	Нет, контур Kerberos и SASL	OAuth 2 с внешним Authorization Server с Hive 4.2, а также JWT, simple, none	OAuth2 через внешний oauth2-server-uri; встроенный /v1/oauth/tokens депрекирован	OAuth2 client credentials flow и Bearer-токен
Pluggable-архитектура	Нет	Нет	Зависит от реализации	Заявлена
Снимок каталога, согласованный по нескольким таблицам	Нет	Нет	Зависит от реализации	Заявлен
Мультитабличные транзакции	Нет: в HiveCatalog.java не реализованы	Эндпоинт заявлен в примере /v1/config, реализация не проверена	Часть протокола, входит в набор эндпоинтов по умолчанию	В плане развития, роадмап на август 2026 года

Time travel для одной таблицы обеспечивает сам формат Iceberg, поэтому он работает и с Hive Metastore. Можно открыть состояние таблицы на конкретный момент времени или по идентификатору снапшота.

Каталог отвечает за согласованный снимок нескольких таблиц. Например, чтобы факт, витрина и справочник читались в состоянии на один и тот же момент. Поэтому фраза «Hive Metastore не поддерживает time travel» неточна: речь здесь идёт о согласованном состоянии набора таблиц, а не об истории отдельной таблицы.

Миграция: синтаксис и стоп-факторы

Команды CONVERT TO ICEBERG не существует, хотя она регулярно попадает в технические задания. Для миграции используются три операции: snapshot, migrate и add_files.

snapshot: тестовая копия

CALL catalog.system.snapshot('db.src', 'db.dst')

Команда создаёт Iceberg-таблицу поверх файлов исходной таблицы, не забирая файлы себе. Отсюда два ограничения:

expire_snapshots для такой копии запрещён.
DELETE по исходной Hive-таблице ломает снапшот.

В Trino эта процедура не поддерживается.

migrate: конвертация на месте

CALL catalog.system.migrate('db.sample')

У процедуры есть два явных стоп-фактора:

Она завершится с ошибкой, если хотя бы одна партиция использует неподдерживаемый формат. Поддерживаются только Avro, Parquet и ORC. Кастомный SerDe нельзя мигрировать напрямую: данные придётся перезаписать в поддерживаемый формат.
Она завершится с ошибкой для бакетированной таблицы, потому что бакетирование не сохраняется.

Расхождение движков по бакетированию особенно опасно. Spark на бакетированной таблице падает, тогда как Trino мигрирует её как небакетированную Iceberg-таблицу. Ошибка Spark видна сразу, а тихая потеря бакетирования проявится позже, например в профиле запросов. Перед миграцией проверьте, каким движком она будет выполняться.

План отката уже предусмотрен. По умолчанию исходная таблица сохраняется под именем table_BACKUP_. Поведение регулируют аргументы drop_backup и backup_table_name. Не нужно писать отдельный механизм отката, достаточно не удалить резервную таблицу раньше времени.

add_files: крайний случай

Процедура не проверяет, соответствует ли схема добавляемых файлов схеме Iceberg-таблицы. Добавленные файлы могут быть физически удалены последующими операциями Iceberg. Использовать add_files стоит только тогда, когда migrate и snapshot не подходят.

В Trino часть процедур отключена по умолчанию:

iceberg.register-table-procedure.enabled=true
iceberg.add-files-procedure.enabled=true

Оба флага по умолчанию имеют значение false. system.migrate отдельным флагом не закрыта. В Trino add_files вызывается через ALTER TABLE ... EXECUTE, а не через system.add_files. Для аргумента _recursive_director_y значение по умолчанию — fail.

Если процедура «не находится», сначала проверьте флаги, а уже потом ищите ошибку в конфигурации или баг движка.

Смена каталога и перенос данных — разные операции. При переводе таблиц с legacy-каталога на REST переписывать файлы не требуется: меняются только метаданные. Публичных замеров такой миграции нет, поэтому обещать конкретное время выполнения не стоит.

Стоимость миграции в человеко-днях также нельзя вывести из публичных данных. Её оценивают по параметрам конкретного контура:

числу Thrift-клиентов, которые нужно переписать или проксировать;
доле таблиц в форматах вне Avro, Parquet и ORC;
наличию бакетирования и кастомных SerDe;
числу систем, в которых сейчас описываются правила доступа.

Частые вопросы про Hive Metastore и Iceberg REST Catalog

Нужно ли мигрировать с Hive Metastore, если упёрлись в производительность?

Публично измеримого порога производительности, после которого Lakehouse обязательно нужно переводить с Hive Metastore на другой каталог, нет. Цифра «не более 10 000 партиций на запрос» — ориентир Cloudera для тюнинга Hive Metastore в документации версии 7.3.1, а не характеристика самого продукта и тем более не универсальная константа для других каталогов.

Таймауты при перечислении партиций могут означать, что метастор пора тюнинговать или что в контуре неудачно выбрана модель партиционирования. Каталог меняют по функциональным причинам: нужны временные креды к хранилищу, атомарные операции над несколькими таблицами, контроль доступа на уровне каталога или клиенты вне JVM.

Правда ли, что Hive Metastore не умеет time travel?

Нет. Time travel — свойство формата Apache Iceberg. Снапшот таблицы по идентификатору или времени доступен и в том случае, если Iceberg-таблица зарегистрирована в Hive Metastore.

Каталог отвечает за другую возможность: согласованный снимок нескольких таблиц. Он позволяет прочитать набор витрин в состоянии на один момент времени. Hive Metastore не предоставляет именно такую функцию, но это не означает отсутствия time travel у отдельных Iceberg-таблиц.

Что даёт Iceberg REST Catalog по сравнению с Thrift?

Iceberg REST Catalog — открытая спецификация HTTP API для операций с каталогом Apache Iceberg: работы с namespace и таблицами, загрузки метаданных, коммита изменений, снапшотов и представлений.

По сравнению с Thrift-путём REST даёт три ключевые возможности:

Клиенты вне JVM: Python-сервисы, Go-приложения и cloud-native компоненты подключаются по обычному HTTP.
Stateless-сервер с горизонтальным масштабированием через реплики за балансировщиком.
Возможности, реализованные на уровне протокола, а не только формата: мультитабличный коммит POST /v1/{prefix}/transactions/commit и выдачу временных кредов к хранилищу.

Поддерживает ли Hive Metastore OAuth?

В REST-режиме — да, начиная с Hive 4.2.0, где появилась поддержка OAuth 2 (HIVE-29020). Документация Hive описывает интеграцию с внешним Authorization Server, например Keycloak.

REST-слой Hive поддерживает четыре метода аутентификации:

OAuth 2 через внешний Authorization Server.
JWT, метод по умолчанию.
simple.
none, только для тестирования.

В классическом Thrift-контуре OAuth нет: там используются Kerberos и SASL. Поэтому фраза «Hive Metastore не поддерживает OAuth» применима только к Thrift-пути.

Что ломается при миграции таблиц из Hive в Iceberg?

Есть три основных риска.

Неподдерживаемые форматы. Процедура migrate завершится с ошибкой, если хотя бы одна партиция использует формат вне Avro, Parquet или ORC. Таблицы с кастомными SerDe придётся не мигрировать, а перезаписывать в поддерживаемый формат.

Бакетирование. Spark не мигрирует бакетированные таблицы. Trino ведёт себя иначе: переносит такую таблицу как небакетированную Iceberg-таблицу. Формально миграция пройдёт, но бакетирование исчезнет, и последствия могут проявиться позже в профиле запросов.

Ожидание команды CONVERT TO ICEBERG. Такой команды нет. Для перехода используют snapshot, migrate или add_files. При migrate исходная таблица по умолчанию сохраняется под именем table_BACKUP_, поэтому откат предусмотрен сразу. Главное — не удалить резервную таблицу раньше времени.

Заменяет ли CedrusData Catalog Hive целиком?

Нет. CedrusData Catalog позиционируется как замена Hive Metastore для Apache Iceberg. Он не реализует Hive Metastore Thrift API и не заменяет Hive в сценариях, не связанных с Iceberg.

На практике это означает:

таблицы вне Iceberg остаются в существующем Hive-контуре;
Thrift-клиенты продолжают работать с Hive Metastore или требуют отдельной миграции;
CedrusData Catalog берёт на себя Iceberg-часть: RBAC, OAuth2, Web UI и REST-доступ для клиентов вне JVM.

Что делать дальше

Каталог выбирают от требований контура, а не от того, насколько новый или модный протокол появился на рынке.

Сначала проверьте версию Hive. Если контур уже работает на Hive 4.2.0 или его можно обновить, включите Iceberg REST API поверх существующего Hive Metastore. Это даст REST-доступ и OAuth 2 без переезда на другой каталог.
Затем пройдите по четырём требованиям. Hive Metastore не умеет выдавать временные креды к хранилищу и не даёт встроенного контроля доступа на уровне каталога — ни через Thrift, ни через REST. Клиентов вне JVM можно подключить после включения REST API. Поддержку мультитабличных транзакций в REST-режиме Hive лучше проверить на стенде, прежде чем закладывать её в архитектуру.
Не пытайтесь вывести момент миграции из одного графика или числа партиций. Таймауты при их перечислении могут указывать на проблемы с настройками или партиционированием, но сами по себе не доказывают, что каталог нужно менять.
Переход удобнее начинать с гибридной схемы. Можно оставить существующие таблицы и Thrift-клиентов в Hive Metastore, а новые витрины создавать в REST-каталоге. Другой вариант — включить REST API у самого метастора и постепенно переводить на него новые сервисы.
Оценивайте продукты только по функциям, которые уже доступны. Возможности из роадмапа не стоит включать в обязательные требования. Если они критичны для пилота, заранее получите от вендора письменное подтверждение сроков и статуса.

Иногда правильный результат проверки — ничего не менять. Если Hive Metastore нормально обслуживается и справляется с нагрузкой, новый протокол не повод для миграции. Переход нужен, когда появляются задачи, которые метастор не может закрыть своей архитектурой.