Преобразование внешних или внешних таблиц Delta Lake в управляемые таблицы каталога Unity

Замечание

При преобразовании внешней таблицы в управляемую таблицу поддерживаются только внешние таблицы, подключённые через Hive metastore и Glue Federation.

Чтобы преобразовать внешнюю или стороннюю таблицу Delta Lake в управляемую таблицу Unity Catalog в Azure Databricks, используйте команду ALTER TABLE ... SET MANAGED или, для внешних таблиц, обозреватель каталогов. Преобразование сохраняет конфигурации таблиц, включая имя, параметры, разрешения и представления, и сохраняет журнал таблиц.

Для преобразований внешних таблиц см. также: SET MANAGED

• Минимизирует время простоя при чтении и записи.
• Обрабатывает одновременные операции записи во время преобразования.
• Позволяет откатить преобразованную управляемую таблицу обратно во внешнюю таблицу.
• Перенаправляет операции чтения и записи на основе пути, чтобы разрешить устаревший код функционировать после преобразования.

Хотя вы также можете использовать CREATE TABLE AS SELECT (CTAS) для преобразования внешней таблицы, Databricks рекомендует SET MANAGED для этих преимуществ.

При преобразовании внешних таблиц Databricks задает для преобразованной таблицы значение параметра предиктивной оптимизации INHERIT, а не включает ее автоматически. См. Внешние таблицы в SQL.

Сведения о преобразовании внешних таблиц в внешние таблицы см. в статье "Преобразование внешней таблицы в таблицу каталога Unity".

Prerequisites

Предварительные требования различаются в зависимости от того, преобразуете ли вы внешнюю таблицу или стороннюю таблицу.

Внешние таблицы

Преобразование внешних таблиц в управляемые таблицы имеет следующие предварительные требования:

• Формат: таблица должна использовать формат Delta Lake.
• Среда выполнения: Чтобы использовать SET MANAGED, UNSET MANAGED или TRUNCATE UNIFORM HISTORY, необходимо использовать Databricks Runtime 17.3 LTS или выше либо бессерверные вычисления.
• Средства чтения и записи: средства чтения и записи Azure Databricks для исходных таблиц должны работать в Databricks Runtime версии 15.4 LTS или более поздней. Если читатели или писатели используют 14.3 LTS или ниже, ознакомьтесь с устаревшими читателями и писателями.
• Внешние клиенты: сторонние клиенты (не Databricks) должны поддерживать чтение из таблиц под управлением Unity Catalog. См. таблицы Microsoft Access с клиентами Delta.
  • Используйте панель мониторинга Access Insights, чтобы определить, являются ли читатели и писатели, которые обращаются к вашим таблицам, пользователями Databricks Runtime или внешними пользователями, не использующими Databricks.
• Совместимость функций: если в таблице есть minReaderVersion=2, minWriterVersion=7 и tableFeatures={..., columnMapping}, команда SET MANAGED завершается с ошибкой DELTA_TRUNCATED_TRANSACTION_LOG. Проверьте, имеет ли ваша таблица эти свойства с помощью DESCRIBE DETAIL. См. сведения о совместимости функций Delta Lake и протоколах.

После преобразования операции ввода-вывода, использующие путь, автоматически перенаправляются в новое управляемое расположение с небольшими потерями производительности. Databricks рекомендует перевести весь доступ, основанный на пути, на доступ, основанный на именах, чтобы избежать потерь производительности. См. перенаправление на основе пути.

Important

Чтобы избежать конфликтов, отмените все существующие OPTIMIZE задания команд (ликвидная кластеризация, сжатие, ), работающие во внешней таблице, ZORDERи не запланируйте какие-либо задания во время преобразования внешних таблиц в управляемые таблицы.

Внешние таблицы

Преобразование внешних таблиц в управляемые таблицы имеет следующие предварительные требования:

• Формат данных: внешняя таблица должна использовать формат Delta Lake. Чтобы выполнить однократное преобразование Parquet, см. раздел "Преобразование в Delta Lake".
• Среда выполнения: Databricks Runtime 17.3 или более поздней версии.
• Тип таблицы: тип таблицы в метахранилище Hive (HMS) должен соответствовать внешней таблице HMS. Команда завершается ошибкой, если таблица является управляемой таблицей HMS.
• Права доступа: OWNER или MANAGE права доступа к таблице и CREATE право доступа к EXTERNAL LOCATION.

Время простоя и время копирования данных

Команда SET MANAGED сводит к минимуму или полностью исключает время простоя по сравнению с альтернативными подходами, такими как DEEP CLONE.

Внешние таблицы

Процесс преобразования внешних таблиц использует двухэтапный подход:

1. Начальная копия данных (без простоя) — команда копирует данные таблицы и журнал транзакций Delta из внешнего расположения в управляемое расположение. Активные операции чтения и записи во внешнюю таблицу выполняются без прерывания.
2. Переключение на управляемое расположение (кратковременный простой): коммиты, сделанные во внешнем расположении на первом этапе, перемещаются в управляемое расположение, а метаданные таблицы обновляются, чтобы зарегистрировать новое управляемое расположение. На этом шаге все записи во внешнюю локацию временно блокируются, что приводит к простою системы, выполняющей запись. Читатели в Databricks Runtime 16.4 LTS или более поздней версии не испытывают простоя, но читатели в Databricks Runtime 15.4 LTS и ниже могут столкнуться с простоем.

В следующей таблице показано предполагаемое время простоя на основе размера исходной таблицы и предполагаемой скорости пропускной способности 0,5–2 ГБ/ядра ЦП/минуты:

Размер таблицы	Рекомендуемый размер кластера	Предполагаемое время копирования данных	Предполагаемое время простоя читателя и писателя
100 ГБ или меньше	32-ядерное / Очень большое SQL хранилище	~6 мин или меньше	~1–2 мин или меньше
1 TБ	64-ядро / хранилище 2X-Large SQL	~30 мин	~1-2 мин
10 ТБ	256-ядерное / 4X-Large SQL-склад	~1,5 ч	~1-5 мин

Замечание

Время простоя может отличаться в зависимости от таких факторов, как размер файла, количество файлов и количество фиксаций.

Внешние таблицы

Время простоя при преобразовании внешней таблицы зависит от того, используете ли вы MOVE или COPY:

• Для MOVEэтого время простоя может возникать, как описано для внешних таблиц. См. внешние таблицы.
• Для COPY вы должны самостоятельно управлять временем простоя, поскольку в процессе преобразования исходная таблица копируется в управляемое хранилище, в результате чего создаются две отдельные копии данных. Вы несете ответственность за отключение операций чтения и записи в исходную таблицу во внешнем каталоге и перенос рабочих нагрузок для использования новой управляемой таблицы.

Преобразование в управляемую таблицу

Преобразуйте внешнюю таблицу с помощью Catalog Explorer или SQL либо преобразуйте стороннюю таблицу с помощью SQL.

Внешние таблицы с помощью обозревателя каталогов (бета-версия)

Important

Преобразование внешних в управляемые таблицы с помощью обозревателя каталогов находится в бета-версии.

С помощью обозревателя каталогов можно преобразовать одну или несколько внешних таблиц в схему одновременно.

1. Перейдите в таблицу или схему, которую вы хотите преобразовать в обозревателе каталогов.

2. В разделе "Сведения об этой таблице " (страница сведений о таблице) или "Сведения об этой схеме " (страница сведений о схеме) нажмите кнопку "Обзор оптимизаций".

3. В диалоговом окне "Почему миграция в управляемые таблицы каталога Unity" нажмите кнопку "Продолжить".

   

4. Выберите внешние таблицы, которые требуется преобразовать. При открытии диалогового окна на странице сведений о таблице обозреватель каталогов предварительно выбирает таблицу. Используйте панель поиска для поиска дополнительных таблиц. Управляемые таблицы недоступны для выбора.

   

5. Нажмите Создать блокнот преобразования.

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

   

7. В записной книжке просмотрите рекомендации и убедитесь, что выполнены все предварительные требования.

8. Запустите ячейку SET УПРАВЛЯЕМЫХ Запросов.

После запуска ячейки тип таблицы отображается как MANAGED вместо EXTERNAL в обозревателе каталогов. Обновите страницу, если состояние не обновляется немедленно.

Внешние таблицы с помощью SQL

В зависимости от того, включена ли внешняя таблица Apache Iceberg для чтения (UniForm), выполните одну из следующих команд. Чтобы проверить, включено ли для таблицы чтение Iceberg, см. Проверка того, что чтение Iceberg включено.

• Для внешних таблиц Unity Catalog без включённой поддержки чтения Iceberg выполните следующую команду:

  ALTER TABLE catalog.schema.my_external_table SET MANAGED;
  

  После преобразования можно включить чтение Iceberg в управляемой таблице без вопросов совместимости.

• Для внешних таблиц Unity Catalog с уже включённым чтением Iceberg выполните следующую команду:

  ALTER TABLE catalog.schema.my_external_table SET MANAGED TRUNCATE UNIFORM HISTORY;
  

  Включите TRUNCATE UNIFORM HISTORY для обеспечения оптимальной производительности и совместимости таблиц. TRUNCATE UNIFORM HISTORY усекает только историю UniForm Iceberg и не удаляет историю Delta. Эта команда приводит к кратковременному простою операций чтения и записи для Iceberg после усечения.

После преобразования таблицы существующие потоки чтения и записи завершаются ошибкой. Перезапустите потоки с теми же конфигурациями, чтобы автоматически использовать перенаправление на основе пути. Убедитесь, что читатели и авторы корректно работают с управляемой таблицей. См. поведение потоковой передачи.

Прогнозная оптимизация автоматически включена после преобразования, если вы не отключили ее вручную. Проверьте , включена ли прогнозная оптимизация.

Azure Databricks сохраняет данные во внешнем расположении каталога Unity в течение 14 дней, чтобы разрешить откат. См. раздел Как отменить преобразование управляемой таблицы. Через 14 дней с включенной прогнозной оптимизацией Azure Databricks автоматически удаляет эти данные для восстановления хранилища и экономии затрат. Если вы отключите прогнозную оптимизацию, выполните команду VACUUM (требуется Databricks Runtime 17.3 LTS или выше или бессерверные вычисления) в только что преобразованной управляемой таблице через 14 дней, чтобы освободить хранилище самостоятельно.

VACUUM my_converted_table

Замечание

Даже при включенной прогнозной оптимизации данные во внешнем расположении каталога Unity могут не удаляться через 14 дней. Например, это может произойти, если управляемая таблица редко используется или небольшая. Если сохранились предыдущие данные, вручную запустите VACUUM, чтобы удалить их.

Azure Databricks удаляет только данные во внешнем хранилище. Журнал транзакций Delta и ссылка на таблицу в каталоге Unity хранятся.

Внешние таблицы с использованием SQL

Чтобы преобразовать внешнюю таблицу каталога Unity в управляемую каталогом Unity, выполните следующую команду:

ALTER TABLE source_table SET MANAGED {MOVE | COPY}

• таблица_источника

  Существующая внешняя таблица, подключённая через федерацию в Unity Catalog.

• MOVE

  Преобразует таблицу в управляемую и отключает доступ к исходной таблице во внешнем каталоге.

  • Доступ через внешний каталог или доступ на основе пути завершается сбоем после преобразования таблицы. Все операции чтения и записи в таблицу обязаны использовать пространство имен каталога Unity для доступа. Рассмотрим пример.

    SELECT * FROM catalog_name.schema_name.table_name;
    

  • Доступ на основе пути не поддерживается и приводит к сбою после преобразования таблицы. Рассмотрим пример.

    SELECT * FROM delta.`protocol://path/to/table`;
    

  • Требования к версиям средств чтения и записи, а также к совместимости с клиентами совпадают с описанными в разделах «Предварительные требования» и «Устаревшие средства чтения и записи».

  • Значение прогнозной оптимизации установлено по умолчанию на INHERIT, если вы не настроили его вручную. Чтобы проверить, включена ли прогнозная оптимизация, ознакомьтесь со сведениями о том, включена ли прогнозная оптимизация.

• COPY

  Преобразует таблицу в управляемое без изменения или отключения доступа к исходной таблице во внешнем каталоге.

  • Во время преобразования в управляемый процесс преобразования копирует данные из исходной таблицы в управляемое место хранения, определенное для внешней таблицы, создавая две отдельные копии: новую управляемую таблицу и исходную таблицу во внешнем каталоге.
  • В отличие от ситуации, когда при использовании MOVE операции чтения и записи завершаются ошибкой, при использовании COPY вы несете ответственность за правильное отключение операций чтения и записи в исходной таблице во внешнем каталоге и обеспечение того, чтобы рабочие нагрузки мигрировали в новый каталог.

После преобразования таблицы необходимо перезапустить все потоковые задания (чтение или запись), использующие внешнюю таблицу, и убедиться, что ваши модули чтения и записи работают с управляемой таблицей.

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

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

Предупреждение

Databricks рекомендует избегать одновременного выполнения нескольких SET MANAGED команд в одной таблице, что может привести к несогласованному состоянию таблицы.

Проверка преобразования

Чтобы убедиться, что ваша таблица успешно преобразована в управляемую таблицу, проверьте, является ли таблица TypeMANAGED. Вы можете выполнить одно из следующих действий:

• Откройте новую вкладку и перейдите в обозреватель каталогов. На вкладке "Сведения" в разделе "О этой таблице" тип таблицы отображается как Managed.

• Проверьте таблицу Type , выполнив следующую команду SQL:

  DESCRIBE EXTENDED catalog_name.schema_name.table_name
  

  Чтобы проверить несколько таблиц одновременно или запросить проверку, выполните запрос information_schema.tables :

  SELECT table_type FROM system.information_schema.tables
  WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';
  

Устаревшие средства чтения и записи

Databricks рекомендует обновить все компоненты для чтения и записи до Databricks Runtime 15.4 LTS или более поздней версии, чтобы использовать все возможности SET MANAGED, включая хранение истории таблицы.

Вы по-прежнему можете использовать SET MANAGED, если у вас есть читатели или средства записи в Databricks Runtime версии 15.3 или более ранней. Однако после преобразования в управляемую таблицу можно перемещаться по истории предыдущих коммитов только по версии, а не по временной метке.

Если в течение 14 дней выполнить откат к внешней таблице, снова станет доступно перемещение во времени к историческим коммитам, созданным до преобразования. Переход во времени с использованием меток времени не поддерживается для коммитов, выполненных для преобразованной управляемой таблицы в период между преобразованием и откатом. См. раздел Как отменить преобразование управляемой таблицы.

Для записи в таблицу после преобразования с использованием Databricks Runtime 15.3 или более ранней версии требуется удалить компонент inCommitTimestamp:

ALTER TABLE <table_name> DROP FEATURE inCommitTimestamp;

Перенаправление на основе пути

В Databricks Runtime 18.1 и выше, после преобразования внешней таблицы в управляемую таблицу Unity Catalog, чтение и запись данных по пути к предыдущему внешнему расположению автоматически перенаправляются на новое управляемое расположение. Чтение на основе пути — это код, например SELECT * FROM delta.`/path/to/my_table`. Перенаправление на основе пути сокращает время и усилия, необходимые для миграции в управляемые таблицы, позволяя устаревшему коду, использующим пути к хранилищу, продолжать работать без рефакторинга.

Преобразования внешних таблиц не перенаправляют доступ по пути.

Azure Databricks рекомендует, чтобы в случаях использования с низкой задержкой вы заменили доступ, основанный на пути, на доступ, основанный на именах. Перенаправление на основе пути увеличивает задержку на несколько сотен миллисекунд для каждого чтения или записи по пути и требует, чтобы старые журналы Delta оставались доступны во внешнем расположении каталога Unity. Операции чтения и записи на основе имен не имеют дополнительных затрат на производительность. См. раздел «Миграция кода, основанного на путях, на код, основанный на именах».

Перевести код с использования путей на использование имен

Если вы решили не использовать перенаправление на основе пути, можно перенести устаревший код. Чтобы выполнить миграцию, замените ссылки по пути ссылками по имени.

В следующем примере кода приведена ссылка на таблицу с указанием пути к файлам:

SELECT * FROM delta.`/path/to/customers_table`;

Замените ссылку, основанную на пути, ссылкой по имени на внешнюю таблицу, как показано в следующем коде:

SELECT * FROM catalog_name.schema_name.customers_table;

Поведение потоковой передачи

Потоковая обработка с перенаправлением по пути поддерживает операции чтения и записи в следующих версиях Databricks Runtime:

• Чтение поддерживается в Databricks Runtime 18.1 и выше.
• Записи поддерживаются в Databricks Runtime 18.2 и выше.

После преобразования необходимо перезапустить все задания потоковой передачи, чтобы избежать чтения или записи в предыдущее расположение таблицы.

Потоковая передача на основе пути считывает и записывает сбой и останавливается на следующей контрольной точке с сообщением о миграции:

• Для операций чтения поток вызывает ошибку: DELTA_STREAMING_INTERRUPTED_BY_MANAGED_TABLE_CONVERSION: The table at <path> has been converted to a Unity Catalog managed table. The stream has been stopped to ensure data consistency. Restart the stream and it will automatically resume from the last committed offset using the converted table
• При записи первый микропакет после преобразования вызывает ошибку: Operation not allowed: STREAMING WRITE cannot be performed on a table with redirect feature. The no redirect rules are not satisfied []

Чтобы устранить ошибки, перезапустите потоки с теми же конфигурациями. Доступ на основе маршрута автоматически перенаправляется в управляемую таблицу.

Ограничения перенаправления на основе пути см. в разделе "Ограничения".

Устранение неполадок преобразования

В этом разделе описывается, как устранить распространенные проблемы при преобразовании внешних таблиц в управляемые таблицы каталога Unity с помощью SET MANAGED.

VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED

Если преобразование завершается ошибкой, всегда повторите попытку с использованием той же версии Databricks Runtime. Метаданные могут сериализоваться по-разному в разных версиях, что вызывает VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED сбой при повторной попытке преобразования в другой версии Databricks Runtime.

Завершение работы кластера во время преобразования

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

Поврежденная внешняя таблица

Если внешняя таблица уже повреждена (например, недопустимое состояние таблицы), преобразование может завершиться ошибкой, например DELTA_TRUNCATED_TRANSACTION_LOG, DELTA_TXN_LOG_FAILED_INTEGRITYили DELTA_STATE_RECOVER_ERRORS. Прежде чем пытаться преобразовать, убедитесь, что вы можете выполнять основные операции во внешней таблице, например DESCRIBE DETAIL.

Сбой проверки файла

Команда SET MANAGED проверяет, что все файлы из последнего снимка таблицы были скопированы в новое расположение управляемой таблицы. Если отсутствуют файлы, команда завершается ошибкой DELTA_ALTER_TABLE_SET_MANAGED_FAILED.FILE_VALIDATION_FAILED .

Чтобы устранить эту проблему, выполните следующие действия.

1. Проверьте журналы драйверов Spark, чтобы определить, какие файлы не удалось перенести.
2. Убедитесь, что эти файлы существуют в исходном расположении внешней таблицы и доступны.
3. Повторите ALTER TABLE ... SET MANAGED команду.

Если проблема сохранится, обратитесь в службу поддержки Databricks.

Отменить преобразование в управляемую таблицу

Important

Для команд отката требуются бессерверные вычислительные ресурсы или Databricks Runtime версии 17.3 LTS или более поздней.

Внешняя таблица

После преобразования внешней таблицы в управляемую таблицу можно выполнить откат в течение 14 дней с помощью команды UNSET MANAGED. Это обновляет метаданные таблицы, чтобы вернуться к исходному внешнему расположению. Databricks сохраняет все записи, сделанные в управляемое расположение после преобразования.

Чтобы выполнить откат к внешней таблице, выполните следующую команду:

ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED;

Примите во внимание указанные ниже сведения.

• Если команда отката прервана или завершается ошибкой, повторно запустите ее, чтобы повторить попытку.
• После отката необходимо перезапустить задания потоковой передачи, аналогичные преобразованию.
• Коммиты, сделанные в управляемом расположении между преобразованием и откатом, позволяют выполнять переход к состоянию данных по версии, но не по метке времени.
• Через семь дней после отката Azure Databricks автоматически удаляет данные в управляемой области.

Внешняя таблица: MOVE

Предупреждение

Необходимо выполнить UNSET MANAGED перед удалением управляемой таблицы. Удаление таблицы без предварительного выполнения UNSET MANAGED может привести к потере данных или нарушению их согласованности.

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

1. Чтобы выполнить откат к внешней таблице, выполните следующую команду:

ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED

1. Чтобы повторно связать таблицу с внешней таблицей, удалите внешнюю таблицу с помощью следующей команды:

DROP TABLE catalog.schema.my_managed_table

Внешняя таблица доступна после следующей синхронизации каталога.

Примите во внимание указанные ниже сведения.

• Для коммитов, которые вы внесли во внешнем местоположении между преобразованием и откатом, можно выполнить переход к состоянию по версии, но не по метке времени.
• Через семь дней после отката Databricks удаляет данные из управляемого расположения.

Внешняя таблица: COPY

Чтобы выполнить откат миграции таблицы, не нужно выполнить UNSET MANAGED команду, так как исходная таблица во внешнем каталоге не была изменена. Удалите управляемую таблицу и Databricks повторно объединяет ее как внешнюю таблицу после следующей синхронизации каталога.

Проверка отката

Проверяйте откат по-разному для внешних и сторонних таблиц.

Внешние таблицы

Чтобы убедиться, что ваша управляемая таблица была успешно преобразована обратно во внешнюю таблицу, проверьте, является ли таблица Type внешней EXTERNAL. Вы можете выполнить одно из следующих действий:

• Откройте новую вкладку и перейдите в обозреватель каталогов. На вкладке "Сведения" в разделе "О этой таблице" тип таблицы отображается как "Внешний".

• Проверьте таблицу Type , выполнив следующую команду SQL:

  DESCRIBE EXTENDED catalog_name.schema_name.table_name
  

  Чтобы проверить несколько таблиц одновременно или запросить проверку, выполните запрос information_schema.tables :

  SELECT table_type FROM system.information_schema.tables
  WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';
  

Внешние таблицы

Чтобы убедиться, что ваша управляемая таблица была успешно преобразована во внешнюю таблицу, проверьте, является ли таблица Type внешней FOREIGN. Вы можете выполнить одно из следующих действий:

• Откройте новую вкладку и перейдите в обозреватель каталогов. На вкладке "Сведения" в разделе "О этой таблице" тип таблицы отображается как внешний.

• Проверьте тип таблицы, выполнив следующую команду SQL:

  SELECT table_type FROM system.information_schema.tables
  WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';
  

  Столбец table_type отображается как FOREIGN.

Замечание

Не используйте DESCRIBE EXTENDED для проверки преобразований или откатов внешних таблиц. Федерация использует hive_metastore поведение каталога для этой команды, поэтому она отображает таблицу Type как EXTERNALнезависимо от фактического состояния таблицы.

Дополнительные разделы

В этом разделе содержатся дополнительные разделы по преобразованию внешних и внешних таблиц в управляемые таблицы.

Преобразование на уровне схемы или каталога

Вы можете автоматизировать преобразование таблиц на уровне схемы или каталога:

• Выполните итерацию по таблицам в схемах, чтобы преобразовать каждую таблицу по отдельности.

• Используйте проект лабораторий discoverx для одновременного преобразования всех схем или каталогов:

  df = (dx.from_tables("prod.*.*")
  .with_sql("ALTER TABLE {full_table_name} SET MANAGED;")
  .apply())
  

См. статью Databricks Labs и discoverx.

Создание таблиц в внешнем каталоге

Внешние или управляемые таблицы можно создать в внешнем каталоге. Поведение зависит от конфигурации схемы:

• Для схем Glue или eHMS или схем с управляемым расположением, заданным в каталоге Unity: при выполнении CREATE TABLE foreign_catalog.schema.tableэто создает управляемую или внешнюю таблицу каталога Unity. Databricks не отправляет или не синхронизирует таблицу с внешним каталогом.
• Для схем из внутренних подключений метахранилища Hive: если попытаться создать таблицу в другой схеме, она все равно создаст таблицу в другой схеме, а также создаст таблицу в hive_metastore.
• Для устаревшего хранилища метаданных Рабочей области Hive: так как это имеет федерацию чтения и записи, если вы создаете таблицу в внешнем каталоге, она также создает таблицу во внутреннем хранилище метаданных Hive.

Внешние таблицы, поддерживаемые DBFS

При преобразовании таблицы, хранящейся в DBFS, Databricks сохраняет текущее соответствие пути DBFS в качестве расположения облачного пути для внешней таблицы.

Ограничения

Преобразование внешних или внешних таблиц в управляемые таблицы имеет следующие ограничения:

• История таблицы для коммитов, выполненных после преобразования, но до отката, позволяет перемещаться во времени по номеру версии, но не по временной метке.

• OpenSharing не полностью совместим с командой SET MANAGED . Поддерживается Open Sharing, но при совместном использовании данных из Databricks в Databricks управляемое расположение таблицы получателя не обновляется автоматически. Получатель продолжает считывать данные из прежнего расположения, пока вы не предоставите общий доступ к таблице повторно. Чтобы повторно предоставить общий доступ к таблице, выполните следующие команды:

  ALTER SHARE <share_name> REMOVE TABLE <table_name>;
  ALTER SHARE <share_name> ADD TABLE <table_name> AS <table_share_name> WITH HISTORY;
  

• Если управляемое по умолчанию расположение хранилища метаданных каталога Unity, каталога или схемы находится в другом облачном регионе из расположения хранилища исходной таблицы, может потребоваться дополнительная плата за передачу данных между регионами от поставщика облачных служб.

  Чтобы проверить расположение схемы и каталога, выполните следующие команды:

  DESC SCHEMA EXTENDED <catalog_name>.<schema_name>;
  
  DESC CATALOG EXTENDED <catalog_name>;
  

  Чтобы проверить расположение хранилища метаданных, выполните любую из следующих команд:

  DESC METASTORE; -- Option 1
  SELECT * FROM system.information_schema.metastores; -- Option 2
  

Ограничения перенаправлений на основе пути:

• После преобразования необходимо перезапустить все задания потоковой передачи. См. поведение потоковой передачи.
• Перенаправление на основе пути предусмотрено только для обратной совместимости в рамках процесса миграции и не предоставляет новый доступ по пути к управляемым таблицам Unity Catalog.

Ограничения внешних таблиц:

• Для преобразования поддерживаются только внешние таблицы, подключенные через Hive metastore и Glue Federation.