Объекты базы данных в устаревшем хранилище метаданных Hive

Документация По Azure Databricks посвящена работе с объектами данных с помощью каталога Unity, но большинство инструкций также применяются к работе с объектами, зарегистрированными в устаревшем хранилище метаданных Hive.

В этой статье описывается, как работать с объектами базы данных, зарегистрированными в устаревшем хранилище метаданных Hive. В частности, в этой статье описывается, где работа с объектами хранилища метаданных Hive отличается от работы с объектами каталога Unity. Здесь также описываются другие аспекты поведения, которые могут оказаться неожиданными.

Databricks рекомендует перенести все данные из устаревшего хранилища метаданных Hive в каталог Unity. См. статью Обновление таблиц и представлений Hive до Unity Catalog.

Как работает управление данными хранилища метаданных Hive?

Хотя рабочие области Azure Databricks продолжают включать встроенное хранилище метаданных Hive, управление данными с помощью хранилища метаданных Hive устарело. Databricks рекомендует использовать каталог Unity для всех систем управления данными. См. статью "Работа с устаревшим хранилищем метаданных Hive" вместе с каталогом Unity.

Включение рабочей области для каталога Unity не снижает возможность работы с данными, уже зарегистрированными в хранилище метаданных Hive. Все объекты данных, зарегистрированные в устаревшем хранилище метаданных Hive, отображаются в интерфейсах каталога Unity в каталоге hive_metastore . Гибридное рабочее пространство, использующее Hive Metastore и Unity Catalog, может быть полезным вариантом при переходе с давно существующего рабочего пространства Hive Metastore. Однако преимущества Unity Catalog в области управления данными и производительности очень велики, и вам следует как можно скорее полностью перевести свои рабочие области.

Хранилище метаданных Hive использует контроль доступа к таблицам (ACL таблиц) для управления доступом к объектам базы данных. Некоторая поддержка остается для управления доступом к таблицам при использовании вычислений в стандартном режиме доступа. См. раздел управления доступом к таблицам хранилища метаданных Hive (устаревшая версия).

Сквозная передача учетных данных — это устаревший подход к управлению доступом к данным для объектов базы данных в Hive Metastore. В этой статье не рассматриваются вопросы сквозной передачи учетных данных. См. Сквозная передача учетных данных (устаревшая версия).

Примечание.

Там, где в этой статье упоминается управление доступом к данным в хранилище метаданных Hive, имеется в виду устаревшее управление доступом к таблицам.

Что такое hive_metastore каталог?

В рабочей области, в которой включен Unity Catalog, все схемы в метахранилище Hive отображаются как дочерние элементы каталога hive_metastore в трехуровневом пространстве имен Unity Catalog. Хранилище метаданных 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 Catalog, со следующими различиями в поведении:
    • Если вы не предоставляете расположение, используется расположение /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 Catalog. При удалении управляемой таблицы в хранилище метаданных Hive все базовые файлы данных удаляются немедленно. С другой стороны, в каталоге Unity можно использовать управляемую таблицу в течение 7 дней, а данные удаляются UNDROP безвозвратно в течение 30 дней.

Вы можете использовать доступ по пути для чтения или записи данных в управляемых таблицах метахранилища Hive, тогда как в Unity Catalog это невозможно и не требуется.

Внешние таблицы в хранилище метаданных Hive

Большинство таблиц, созданных в Azure Databricks перед введением каталога Unity, были настроены как внешние таблицы в хранилище метаданных Hive. Устаревшие рекомендации, отдававшие предпочтение внешним таблицам, как правило, были сосредоточены на нескольких ключевых аспектах:

  • Вы можете зарегистрировать внешнюю таблицу на основе существующих данных в облачном хранилище объектов.
  • Вы можете напрямую получить доступ к файлам данных во внешних таблицах из внешних систем для операций чтения или записи.
  • Файлы данных не были удалены, если таблица была удалена случайно.
  • Поскольку для внешних таблиц требуется LOCATION, производственные данные с меньшей вероятностью случайно окажутся в корневом каталоге DBFS.

Azure Databricks теперь рекомендует использовать управляемые таблицы Unity Catalog для большинства сценариев хранения табличных данных. См. управляемые таблицы Unity Catalog для Delta Lake и Apache Iceberg.

Представления в хранилище метаданных Hive

Вы можете объявить представление в хранилище метаданных Hive, поддерживаемое любым источником данных, поддерживаемым Azure Databricks. В Unity Catalog можно определять представления только на основе таблиц и представлений Unity Catalog, включая сторонние таблицы, материализованные представления и таблицы OpenSharing.

Из-за возможности создавать представления для нетабличных источников данных представления в хранилище метаданных Hive в сочетании с другими настройками доступа в пользовательской среде могут предоставлять неожиданный или непреднамеренный доступ к данным.

Например, рассмотрим следующее:

  • Таблица my_table определяется с помощью пути /mnt/my_tableподключения DBFS.
    • Учетные данные подключения DBFS хранятся в рабочей области, поэтому все пользователи имеют доступ к этому пути по умолчанию.
  • ACL таблиц используются, чтобы ограничить доступ к 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: