Поделиться через

Объекты базы данных в устаревшем хранилище метаданных 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: