Рекомендации по работе с каталогом Unity

В этом документе приведены рекомендации по использованию каталога Unity для обеспечения наиболее эффективного управления данными. Общие сведения об управлении данными в Azure Databricks см. в статье об управлении данными с помощью Azure Databricks. Общие сведения о каталоге Unity см. в разделе "Что такое каталог Unity?".

Идентичности

Субъекты (пользователи, группы и учетные записи служб) должны быть определены на уровне учетной записи Azure Databricks, чтобы им можно было назначать привилегии для защищаемых объектов каталога Unity. Databricks рекомендует использовать SCIM для создания субъектов в учетной записи Azure Databricks из вашего провайдера удостоверений.

Рекомендации:

• Избегайте (и отключите существующую) подготовку SCIM на уровне рабочей области. Назначение субъектов непосредственно в рабочую область должно быть зарезервировано для устаревших рабочих областей, которые не поддерживают Unity Catalog. Вы должны полностью управлять предоставлением услуг на уровне учетной записи.

• Определите группы и управляйте ими в идентификаторе поставщика удостоверений. Они должны соответствовать определениям группы организации.

  Группы ведут себя иначе, чем пользователи и служебные приложения. Хотя пользователи и субъекты-службы, добавляемые в рабочую область, автоматически синхронизируются с вашим аккаунтом Azure Databricks, группы на уровне рабочей области не синхронизируются. Если в вашей рабочей области есть локальные группы, необходимо вручную перенести их в учетную запись, предпочтительно, воспроизводя их в вашем поставщике удостоверений (если необходимо) и предоставляя их в учетную запись.

• Настройте группы, чтобы их можно было эффективно использовать для предоставления доступа к данным и другим защищаемым объектам каталога Unity. Избегайте прямых грантов пользователям, когда это возможно.

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

• Избегайте добавления пользователей вручную в учетную запись или рабочую область. Избегайте изменения групп в Azure Databricks: используйте вашего поставщика удостоверений личности.

• Используйте учетные записи службы для выполнения задач. Субъекты-службы обеспечивают автоматизацию заданий. Если вы используете пользователей для выполнения заданий, которые записываются в рабочую среду, вы рискуете перезаписать рабочие данные случайно.

Дополнительные сведения см. в статье "Управление пользователями, субъектами-службами и группами" и "Синхронизация пользователей и групп" из идентификатора Microsoft Entra с помощью SCIM.

Роли администратора и мощные привилегии

Назначение ролей администратора и мощных привилегий, таких как ALL PRIVILEGES и MANAGE, требует осторожности:

• Понимайте привилегии администраторов учетных записей, рабочих областей и хранилища метаданных перед их назначением. См . раздел "Права администратора" в каталоге Unity.
• По возможности назначьте эти роли группам.
• Администраторы хранилища метаданных являются необязательными. Назначьте их только в том случае, если они нужны. Инструкции см. в разделе (Необязательно) Назначение роли администратора хранилища метаданных.
• Назначьте владение объектом группам, особенно если объекты используются в рабочей среде. Создатель любого объекта является его первым владельцем. Создатели должны передать право собственности соответствующим группам.
• Только администраторы хранилища метаданных, владельцы и пользователи с MANAGE привилегиями объекта могут предоставлять привилегии для этого объекта. Владельцы родительских каталогов и схем также могут предоставлять привилегии для всех объектов в каталоге или схеме. Будьте умеренными в распределении прав собственности и привилегий MANAGE.
• Проявляйте осторожность в назначении ALL PRIVILEGES, который включает все привилегии, кроме MANAGE, EXTERNAL USE LOCATION и EXTERNAL USE SCHEMA.

Назначение привилегий

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

Рекомендации:

• Узнайте о роли USE CATALOG и привилегияхUSE SCHEMA.

  • USE CATALOG | SCHEMA предоставляет возможность просматривать данные в каталоге или схеме. Только эти привилегии не предоставляют доступ к объектам в каталоге и схеме, но они являются необходимым условием для предоставления пользователям такого доступа. Предоставьте этим привилегиям только пользователям, которые должны иметь возможность просматривать данные в каталоге или схеме.
  • USE CATALOG | SCHEMA, ограничивая доступ к каталогу или схеме, запрещает владельцам объектов (например, создателю таблиц) непреднамеренно назначать доступ к этому объекту (таблице) пользователям, которые не должны иметь доступ. Обычно создается схема для каждой команды, и права доступа USE SCHEMA и CREATE TABLE предоставляются только этой команде (вместе с USE CATALOG к родительскому каталогу).

• Поймите роль привилегии BROWSE :

  • BROWSE позволяет пользователям просматривать метаданные для объектов в каталоге с помощью обозревателя каталогов, браузера схемы, поиска, графа происхождения information_schema, и REST API. Он не предоставляет доступ к данным.
  • BROWSE позволяет пользователям обнаруживать данные и запрашивать к нему доступ, даже если у них нет USE CATALOG прав или USE SCHEMA привилегий.
  • Databricks рекомендует предоставлять BROWSE на каталоги группе All account users на уровне каталогов, чтобы делать данные доступными для обнаружения и обеспечивать возможность запросов на доступ.

• Настройте назначения запросов доступа для поддержки самостоятельного доступа:

  • Если назначения запросов доступа не настроены, пользователи не могут запрашивать доступ к объектам, даже если они могут их обнаружить.
  • Databricks рекомендует включить адреса электронной почты по умолчанию, чтобы запросы автоматически отправлялись владельцу каталога или владельцу объекта, если не настроено другое назначение.
  • Можно настроить назначение для адресов электронной почты, Slack, Microsoft Teams, PagerDuty, веб-хуков или URL-адреса перенаправления в систему запросов вашей организации.

• Понять разницу между владением объектами и привилегиями MANAGE :

  • Владелец объекта обладает всеми привилегиями на объекте, такими как SELECT и MODIFY для таблицы, а также правом предоставлять привилегии защищаемому объекту другим субъектам и передавать право владения другим субъектам.
  • Владельцы могут предоставить MANAGE привилегию делегировать права владения на объект другим субъектам.
  • Владельцы каталогов и схем могут передавать владение любым объектом в каталоге или схеме.
  • Рекомендуется настроить владение или предоставить привилегию MANAGE для всех объектов группе, ответственной за администрирование грантов на объект.

• Зарезервировать прямой MODIFY доступ к рабочим таблицам для субъектов-служб.

Дополнительные сведения см. в разделе "Управление привилегиями" в каталоге Unity.

Хранилища метаданных

Ниже приведены правила и рекомендации по созданию хранилищ метаданных и управлению ими.

• В каждом регионе может быть только одно хранилище метаданных. В этом регионе все рабочие пространства связаны с этим хранилищем метаданных. Сведения о совместном использовании данных между регионами см. в разделе "Межрегионный и кроссплатформенный общий доступ".

• Хранилища метаданных обеспечивают региональную изоляцию, но не предназначены в качестве единиц изоляции данных по умолчанию. Изоляция данных обычно начинается на уровне каталога. Однако если вы предпочитаете более централизованную модель управления, можно создать управляемое хранилище на уровне метаданных. Рекомендации см. в разделе "Управляемое хранилище".

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

Каталоги и схемы

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

Рекомендации по использованию каталога и схемы:

• Упорядочение данных и объектов ИИ в каталогах и схемах, которые отражают подразделения и проекты. Часто это означает, что каталоги соответствуют области среды, команде, подразделению или некоторым сочетаниям этих. Это упрощает использование иерархии привилегий для эффективного управления доступом.
• Если рабочие среды и данные имеют одинаковые требования к изоляции, можно привязать каталог к определенной рабочей области. При необходимости создайте каталоги, которые могут быть ограничены набором рабочих областей.
• Всегда присваивайте права владения производственным каталогам и схемам группам, а не отдельным пользователям.
• Предоставьте USE CATALOG и USE SCHEMA только пользователям, которые должны иметь возможность просматривать или запрашивать данные, содержащиеся в них.

Дополнительные сведения о предоставлении привилегий каталогам и схемам см. в разделе "Назначение привилегий".

Управляемое хранилище

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

Рекомендации по расположениям управляемого хранилища:

• Присвойте предпочтение хранилищу уровня каталога в качестве основной единицы изоляции данных.

  Хранилище на уровне метаданных было необходимо в ранних средах каталога Unity, но больше не требуется.

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

• Не используйте контейнер, к которому можно получить доступ за пределами каталога Unity.

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

• Не используйте контейнер, который используется или использовался для корневой файловой системы DBFS.

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

  re:[ADLS] учетные записи поддерживают 20 000 запросов в секунду по умолчанию. Это может привести к ограничению рабочей нагрузки и замедлению. Использование нескольких контейнеров в одной учетной записи хранения не изменяет это ограничение на уровне учетной записи. Поэтому следует распределить хранилище по нескольким учетным записям.

  Такая полоска будет невидимой для конечных пользователей каталога Unity.

Управляемые и внешние таблицы

Управляемые таблицы полностью управляются каталогом Unity, что означает, что каталог Unity управляет как управлением, так и базовыми файлами данных для каждой управляемой таблицы. Они всегда в формате Delta или Apache Iceberg.

Внешние таблицы — это таблицы, доступ к которым из Azure Databricks управляется Unity Catalog, но жизненный цикл данных и макет файлов управляется с помощью вашего поставщика облачных услуг и других платформ данных. При создании внешней таблицы в Azure Databricks необходимо указать его расположение, которое должно находиться по пути, определенному во внешнем расположении каталога Unity.

Используйте управляемые таблицы:

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

  • Автоматическое сжатие
  • Автоматическая оптимизация
  • Быстрые операции чтения метаданных (кэширование метаданных)
  • Интеллектуальная оптимизация размера файлов

  Новые функциональные возможности Azure Databricks дают приоритет управляемым таблицам.

• Для всех новых таблиц.

Используйте внешние таблицы:

• Когда вы уже используете их и переходите с хранилища метаданных Hive на каталог Unity.

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

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

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

• Если внешние читатели или авторы должны иметь возможность взаимодействовать с данными из системы Databricks.

  Как правило, не следует разрешать внешний доступ даже к внешним таблицам, зарегистрированным в каталоге Unity. Это позволяет обойти управление доступом, аудит и отслеживание происхождения в каталоге Unity. Рекомендуется использовать управляемые таблицы и делиться данными между регионами или облачными провайдерами с помощью Delta Sharing. Если необходимо разрешить внешний доступ к внешним таблицам, ограничьте его чтением, при этом все операции записи выполняются через Каталог Azure Databricks и Unity.

• Необходимо поддерживать таблицы, не основанные на Delta или Iceberg, например, Parquet, Avro, ORC и т. д.

Дополнительные рекомендации по использованию внешних таблиц:

• Databricks рекомендует создавать внешние таблицы, используя одно внешнее местоположение для каждой схемы.
• Databricks настоятельно рекомендует не регистрировать таблицу в качестве внешней таблицы в более чем одном хранилище метаданных, так как это может привести к проблемам согласованности. Например, изменение схемы в одном хранилище метаданных не будет регистрироваться во втором хранилище метаданных. Используйте Delta Sharing для обмена данными между метахранилищами. См. межрегионный и кроссплатформенный общий доступ.

См. также таблицы Azure Databricks.

Управляемые и внешние тома

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

Используйте управляемые тома:

• Для большинства случаев использования, чтобы полностью воспользоваться возможностями управления каталога Unity.
• Если вы хотите создать таблицы, начиная с файлов в томе без выполнения COPY INTO или инструкций CTAS (CREATE TABLE AS).

Используйте внешние накопители.

• Регистрация участков для выгрузки необработанных данных, созданных внешними системами для поддержки их обработки на ранних этапах ETL-пайплайнов и других видов деятельности в области инженерии данных.
• Для регистрации промежуточных расположений для приема, например с помощью автозагрузчика COPY INTOили инструкций CTAS.
• Укажите места хранения файлов для дата-сайентистов, аналитиков данных и инженеров по машинному обучению для использования в их анализе данных и других задачах в области data science, если управляемые тома недоступны.
• Чтобы предоставить пользователям Azure Databricks доступ к произвольным файлам, созданным и вложенным в облачное хранилище другими системами, например, большими коллекциями неструктурированных данных (например, изображений, аудио, видео и PDF-файлов), захваченных системами наблюдения или устройствами Интернета вещей, или файлов библиотеки (JARs и файлов колес Python), экспортированных из локальных систем управления зависимостями или конвейеров CI/CD.
• Для хранения эксплуатационных данных, например, для ведения журнала или создания контрольных точек, когда использование управляемых томов невозможно.

Дополнительные рекомендации по использованию внешних томов:

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

См. также управляемые и внешние тома и внешние расположения.

Внешние местоположения

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

Чтобы эффективно использовать внешние локации:

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

• Не подключайте учетные записи хранения к DBFS, если они также используются в качестве внешних хранилищ. Databricks рекомендует перенести подключения к расположениям облачного хранилища во внешние расположения в Unity Catalog с помощью Catalog Explorer.

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

  Внешние расположения предоставляют доступ из каталога Unity к обширному расположению в облачном хранилище, например, к целому бакету или контейнеру (abfss://mycompany-[email protected]) или к широкому подпути (abfss://mycompany-[email protected]/unity-catalog). Цель заключается в том, что администратор облака может участвовать в настройке нескольких внешних расположений, а затем делегировать ответственность за управление этими расположениями администратору Azure Databricks в вашей организации. Затем администратор Azure Databricks может дополнительно упорядочить внешнее расположение, разделив его на области с более детализированными разрешениями, регистрируя внешние тома или внешние таблицы на определенных префиксах во внешнем расположении.

  Поскольку внешние расположения являются настолько всеобъемлющими, Databricks рекомендует предоставлять разрешение CREATE EXTERNAL LOCATION только администратору, отвечающему за настройку подключений между Unity Catalog и облачным хранилищем, или доверенным инженерам данных. Чтобы предоставить другим пользователям более подробный доступ, Databricks рекомендует регистрировать внешние таблицы или тома в верхней части внешних расположений и предоставлять пользователям доступ к данным с помощью томов или таблиц. Так как таблицы и тома являются дочерними элементами каталога и схемы, администраторы каталога или схемы имеют конечный контроль над разрешениями на доступ.

  Вы также можете управлять доступом к внешнему расположению, привязывая его к определенным рабочим областям. См. (необязательно) Назначение внешнего расположения определенным рабочим областям.

• Не предоставляйте пользователям общие READ FILES или WRITE FILES полномочия на внешние ресурсы.

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

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

  Тома позволяют работать с файлами, используя команды SQL, dbutils, API Spark, REST API, Terraform, а также пользовательский интерфейс для просмотра, загрузки и скачивания файлов. Кроме того, тома предлагают подключение FUSE, доступное в локальной файловой системе./Volumes/<catalog_name>/<schema_name>/<volume_name>/ Подключение FUSE позволяет специалистам по обработке и анализу данных получать доступ к файлам, как если бы они находились в локальной файловой системе, как это требуется для многих библиотек машинного обучения или операционной системы.

  Если необходимо предоставить непосредственный доступ к файлам во внешнем расположении (например, для изучения файлов в облачном хранилище, прежде чем пользователь создаст внешнюю таблицу или том), вы можете предоставить READ FILES. Случаи предоставления WRITE FILES редки.

• Избегайте конфликтов перекрытия путей: никогда не создавайте внешние диски или таблицы в корне внешней директории.

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

Для выполнения следующих действий следует использовать внешние расположения:

• Зарегистрируйте внешние таблицы и тома с помощью команд CREATE EXTERNAL VOLUME или CREATE TABLE.
• Зарегистрируйте расположение в качестве управляемого хранилища. Привилегия CREATE MANAGED STORAGE является предварительным условием.
• Изучите существующие файлы в облачном хранилище перед созданием внешней таблицы или тома в определенном префиксе. Привилегия READ FILES является предварительным условием. Назначьте эту привилегию с осторожностью. Дополнительные сведения см. в рекомендации в предыдущем списке.

Внешние расположения и внешние тома

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

Межрегионный и кроссплатформенный общий доступ

В каждом регионе может быть только одно хранилище метаданных. Если вы хотите совместно использовать данные между рабочими областями в разных регионах, используйте Databricks to Databricks Delta Sharing.

Рекомендации:

• Используйте хранилище метаданных с одним регионом для всех областей жизненного цикла разработки программного обеспечения и бизнес-единиц, например разработки, тестирования, продажи и маркетинга. Убедитесь, что рабочие области, требующие частого общего доступа к данным, находятся в одном регионе.
• Используйте Databricks to Databricks Delta Sharing между облачными регионами или поставщиками облачных служб.
• Используйте Delta Sharing для таблиц, к которым редко обращаются, так как вы несете ответственность за расходы за передачу данных из одного облачного региона в другой. Если вам необходимо часто предоставлять общий доступ к данным между регионами или поставщиками облачных услуг, ознакомьтесь с статьей "Мониторинг и управление затратами на исходящий трафик Delta Sharing" (для поставщиков).

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

• Диаграммы родословной создаются на уровне хранилища метаданных и не пересекают границы регионов или платформ. Это актуально даже в случае совместного использования ресурса в метахранилищах внутри той же учетной записи Databricks: информация о происхождении из источника не отображается в назначении, и наоборот.
• Управление доступом определяется на уровне хранилища метаданных и не пересекает границы региона или платформы. Если ресурсу назначены привилегии, и этот ресурс предоставляется другому хранилищу метаданных в учетной записи, то привилегии этого ресурса не применяются к целевой совместной базе данных. Необходимо предоставить привилегии для целевой общей папки в месте назначения.

Конфигурации вычислений

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

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

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