Объекты базы данных в устаревшем хранилище метаданных Hive
Документация По Azure Databricks посвящена работе с объектами данных с помощью каталога Unity, но большинство инструкций также применяются к работе с объектами, зарегистрированными в устаревшем хранилище метаданных Hive.
В этой статье описывается, как работать с объектами базы данных, зарегистрированными в устаревшем хранилище метаданных Hive. В частности, в этой статье описывается, где работа с объектами хранилища метаданных Hive отличается от работы с объектами каталога Unity. Он также описывает другие поведения, которые могут быть непредвиденными.
Databricks рекомендует перенести все данные из устаревшего хранилища метаданных Hive в каталог Unity. См. статью "Обновление таблиц и представлений Hive до каталога Unity".
Как работает управление данными хранилища метаданных Hive?
Хотя рабочие области Azure Databricks продолжают включать встроенное хранилище метаданных Hive, управление данными с помощью хранилища метаданных Hive устарело. Databricks рекомендует использовать каталог Unity для всех систем управления данными. См. статью " Работа с каталогом Unity" и устаревшим хранилищем метаданных Hive.
Включение рабочей области для каталога Unity не снижает возможность работы с данными, уже зарегистрированными в хранилище метаданных Hive. Все объекты данных, зарегистрированные в устаревшем хранилище метаданных Hive, отображаются в интерфейсах каталога Unity в каталоге hive_metastore
. Гибридная рабочая область хранилища метаданных Hive и каталога Unity может быть полезной моделью для перехода длительной рабочей области хранилища метаданных Hive. Однако преимущества управления данными и производительности каталога Unity являются высокими, и вы должны полностью перенести рабочие области, как можно скорее.
Хранилище метаданных Hive использует управление доступом к таблицам (списки управления доступом к таблицам) для управления доступом к объектам базы данных. Некоторая поддержка остается для управления доступом к таблицам при использовании вычислений в режиме общего доступа. См. раздел управления доступом к таблицам хранилища метаданных Hive (устаревшая версия).
Сквозное руководство по учетным данным — это устаревший шаблон для управления данными в объектах базы данных хранилища метаданных Hive. В этой статье не рассматривается сквозное руководство по учетным данным. См. сквозное руководство по учетным данным (устаревшая версия).
Примечание.
Где эта статья относится к управлению доступом к данным в хранилище метаданных Hive, он ссылается на устаревший контроль доступа к таблице.
Что такое hive_metastore
каталог?
В рабочей области, которая включена для каталога Unity, все схемы в хранилище метаданных Hive отображаются в качестве дочерних hive_metastore
элементов каталога в пространстве имен каталога Unity с тремя уровнями. Хранилище метаданных Hive на самом деле не использует каталоги, и эта конструкция предоставляет точку входа для таблиц в устаревшем хранилище метаданных Hive для пользователей каталога Unity. Используйте следующий синтаксис для запроса таблиц в устаревшем хранилище метаданных Hive:
SELECT * FROM hive_metastore.schema_name.table_name
Примечание.
При необходимости можно задать hive_metastore
каталог как рабочую область по умолчанию в рабочих областях с поддержкой каталога Unity. См. раздел "Управление каталогом по умолчанию".
Схемы в хранилище метаданных Hive
В устаревшем хранилище метаданных Hive схема является самым высоким уровнем в иерархии объектов данных.
Существует ряд важных различий между каталогом Unity и хранилищем метаданных Hive, включая следующие:
- Невозможно создать схемы в хранилище метаданных Hive с помощью обозревателя каталогов. Вы можете просматривать и изменять разрешения для схем.
- Схемы, созданные в хранилище метаданных Hive, могут использовать только буквенно-цифровые символы ASCII и символы подчеркивания в их именах.
- Хранилище метаданных Hive позволяет объявлять
LOCATION
схему во время создания. Эти функции аналогичны расположениям управляемого хранилища каталога Unity с следующими различиями в поведении:- Если вы не предоставляете расположение, используется расположение
/user/hive/warehouse/<schema-name>
по умолчанию. Это расположение находится в корневом каталоге DBFS, который не рекомендуется хранить какие-либо рабочие данные. - Предоставленный путь может быть любым расположением облачного хранилища, доступным для пользователя, который создает схему, включая облачные URI, корневую базу данных DBFS и подключения DBFS.
- Доступ к расположению не управляется хранилищем метаданных Hive.
- При удалении схемы в хранилище метаданных Hive все файлы в этом расположении схемы удаляются рекурсивно независимо от типа таблицы (управляемого или внешнего).
- Если вы не предоставляете расположение, используется расположение
Чтобы избежать случайной потери данных, Databricks рекомендует следующее при работе с расположениями схемы хранилища метаданных Hive:
- Не назначайте расположение схемы, которое уже содержит данные.
- Не создавайте внешнюю таблицу в расположении схемы.
- Не делитесь расположением между несколькими схемами.
- Не назначайте расположение схемы, которое перекрывает другое расположение схемы. Другими словами, не используйте путь, который является дочерним элементом другого расположения схемы.
- Не назначайте расположение схемы, перекрывающее расположение внешней таблицы.
Управляемые таблицы в хранилище метаданных Hive
Управляемые таблицы в хранилище метаданных Hive не имеют никаких преимуществ производительности управляемых таблиц в каталоге Unity. Как и управляемые таблицы каталога Unity, управляемые таблицы хранилища метаданных Hive используют Delta Lake по умолчанию. Однако в хранилище метаданных Hive, в отличие от каталога Unity, можно также создать управляемую таблицу с помощью большинства других форматов данных, поддерживаемых Azure Databricks.
Управляемые таблицы в хранилище метаданных Hive всегда создаются в расположении хранилища содержащей схемы. Вычислительные ресурсы, используемые для запроса управляемой таблицы, должны иметь доступ к расположению хранилища.
Хранилище метаданных Hive не управляет макетом данных управляемых таблиц так, как выполняет каталог Unity. При удалении управляемой таблицы в хранилище метаданных Hive все базовые файлы данных удаляются немедленно. С другой стороны, в каталоге Unity можно использовать управляемую таблицу в течение 7 дней, а данные удаляются UNDROP
безвозвратно в течение 30 дней.
Доступ на основе пути можно использовать для чтения или записи данных в управляемых таблицах хранилища метаданных Hive, в то время как в каталоге Unity нельзя и не нужно.
Внешние таблицы в хранилище метаданных Hive
Большинство таблиц, созданных в Azure Databricks перед введением каталога Unity, были настроены как внешние таблицы в хранилище метаданных Hive. Устаревшие рекомендации, которые предпочитали внешние таблицы, обычно сосредоточены на нескольких ключевых аспектах:
- Вы можете зарегистрировать внешнюю таблицу на основе существующих данных в облачном хранилище объектов.
- Вы можете напрямую получить доступ к файлам данных во внешних таблицах из внешних систем для операций чтения или записи.
- Файлы данных не были удалены, если таблица была удалена случайно.
- Так как для внешних таблиц требуются
LOCATION
рабочие данные, скорее всего, случайно в конечном итоге в корневом каталоге DBFS.
Azure Databricks теперь рекомендует управляемые таблицы каталога Unity для большинства табличных данных. См. статью " Работа с управляемыми таблицами".
Представления в хранилище метаданных Hive
Вы можете объявить представление в хранилище метаданных Hive, поддерживаемое любым источником данных, поддерживаемым Azure Databricks. В каталоге Unity можно объявлять только представления для таблиц и представлений каталога Unity, включая внешние таблицы, материализованные представления и таблицы разностного общего доступа.
Из-за возможности объявления представлений в не табличных источниках данных представления в хранилище метаданных Hive могут предоставлять неожиданный или непреднамеренное доступ к данным в сочетании с другими конфигурациями доступа в пользовательской среде.
Например, рассмотрим следующее:
- Таблица
my_table
определяется с помощью пути/mnt/my_table
подключения DBFS.- Учетные данные подключения DBFS хранятся в рабочей области, поэтому все пользователи имеют доступ к этому пути по умолчанию.
- Списки управления таблицами используются для ограничения доступа к
my_table
группе пользователей.- Устаревшие списки управления доступом к таблице применяются только к вычислительным ресурсам, конфигурированных с общим режимом доступа или хранилищами SQL.
- Представление
my_view
определяется непосредственно для облачного URI, который поддерживает те же файлы'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'
данных.- Учетные данные URI зависят от политик доступа, определенных в сеансе Spark или конфигурации вычислений.
my_view
Представление имеет следующие свойства:
- Он не использует учетные данные подключения DBFS, используемые для подключения облачного хранилища объектов к
/mnt/my_table
. - Он не учитывает списки ACL таблицы, заданные
my_table
независимо от конфигураций вычислений. - Для этого требуется политика доступа к данным, настроенная для вычислений, которые предоставляют доступ на
'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'
чтение.
Примечание.
Это один из примеров неожиданного поведения, с которыми вы можете столкнуться, и не исчерпывающие все потенциальные недостатки, представленные представлениями в устаревшем хранилище метаданных Hive. Databricks рекомендует использовать каталог Unity для всех определений представлений.
Поддержка устаревших таблиц Hive и HiveQL
Azure Databricks включает в себя некоторые устаревшие возможности для таблиц Hive и функций HiveQL. Эта функция является остатком ранних версий Azure Databricks и экосистемы средств Apache Hadoop. Databricks не рекомендует использовать таблицы Hive или другие функции Hive, так как эта функция не оптимизирована и не поддерживается в некоторых конфигурациях вычислений.
В следующих статьях описаны устаревшие функции Hive: