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

Статья
04/26/2024

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

Каталог Unity — это точное решение для управления данными и ИИ на платформе Databricks. Он помогает упростить обеспечение безопасности и управление данными и предоставляет центральное место для администрирования и аудита доступа к данным. Delta Sharing — это безопасная платформа для обмена данными в Azure Databricks с пользователями за пределами вашей организации. Он использует каталог Unity для управления и аудита поведения общего доступа.

Стандартные блоки управления данными и изоляции данных

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

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

Схема модели объектов Unity Catalog

К объектам в этой иерархии относятся следующие объекты:

Хранилище метаданных: хранилище метаданных — это контейнер верхнего уровня объектов в каталоге Unity. Хранилища метаданных живут на уровне учетной записи и работают в качестве верхней части пирамиды в модели управления данными Azure Databricks.

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

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

Хранилища метаданных обеспечивают региональную изоляцию, но не предназначены в качестве единиц изоляции данных. Изоляция данных должна начинаться на уровне каталога.
Каталоги. Каталоги — это самый высокий уровень в иерархии данных (таблица схемы > каталога>, представление или том), управляемый хранилищем метаданных каталога Unity. Они предназначены в качестве основной единицы изоляции данных в типичной модели управления данными Azure Databricks.

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

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

Если каталог является основной единицей изоляции данных в модели управления данными Azure Databricks, рабочая область является основной средой для работы с ресурсами данных. Администраторы хранилища метаданных и владельцы каталогов могут управлять доступом к каталогам независимо от рабочих областей или привязывать каталоги к определенным рабочим областям, чтобы обеспечить обработку определенных типов данных только в этих рабочих областях. Для обработки персональных данных могут потребоваться отдельные рабочие области и рабочие области разработки, например отдельная рабочая область.

По умолчанию разрешения доступа для защищаемого объекта наследуются дочерними элементами этого объекта с каталогами в верхней части иерархии. Это упрощает настройку правил доступа по умолчанию для данных и указание разных правил на каждом уровне иерархии только в том месте, где они нужны.
Схема (база данных): схемы, также известные как базы данных, представляют собой логические группировки табличных данных (таблиц и представлений), не табличных данных (томов), функций и моделей машинного обучения. Они позволяют упорядочивать и контролировать доступ к данным, которые более детализированные, чем каталоги. Обычно они представляют один вариант использования, проект или песочницу команды.

Схемы могут храниться в том же физическом хранилище, что и родительский каталог, или можно настроить схему для хранения отдельно от остальной части родительского каталога.

Администраторы хранилища метаданных, владельцы родительского каталога и владельцы схем могут управлять доступом к схемам.
Таблицы: таблицы находятся на третьем уровне трехуровневого пространства имен каталога Unity. Они содержат строки данных.

Каталог Unity позволяет создавать управляемые таблицы и внешние таблицы.

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

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

Владельцы родительского каталога и владельцы схем могут управлять доступом к таблицам, так как администраторы хранилища метаданных (косвенно).
Представления: представление — это объект только для чтения, производный от одной или нескольких таблиц и представлений в хранилище метаданных.
Строки и столбцы: доступ на уровне строк и столбцов вместе с маскированием данных предоставляется с помощью динамических представлений или фильтров строк и маскировок столбцов. Динамические представления доступны только для чтения.
Тома: тома находятся на третьем уровне трехуровневого пространства имен каталога Unity. Они управляют не табличными данными. Тома можно использовать для хранения, упорядочивания и доступа к файлам в любом формате, включая структурированные, полуструктурированные и неструктурированные данные. Файлы в томах нельзя зарегистрировать в виде таблиц.
Модели и функции: хотя они не являются, строго говоря, ресурсы данных, зарегистрированные модели и определяемые пользователем функции также могут управляться в каталоге Unity и находиться на самом низком уровне в иерархии объектов. См. статью "Управление жизненным циклом модели" в каталоге Unity и определяемых пользователем функциях в каталоге Unity.

Планирование модели изоляции данных

Если организация использует платформу данных, например Azure Databricks, часто необходимо иметь границы изоляции данных между средами (например, разработкой и рабочей средой) или между операционными подразделениями.

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

Пользователи могут получать доступ только к данным на основе указанных правил доступа.
Данные могут управляться только назначенными людьми или командами.
Данные физически разделяются в хранилище.
Доступ к данным можно получить только в указанных средах.

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

Пользователи могут получать доступ только к данным на основе указанных правил доступа.

Большинство организаций имеют строгие требования к доступу к данным на основе внутренних или нормативных требований. Типичные примеры данных, которые должны быть защищены, включают сведения о заработной плате сотрудника или кредитную карта платежную информацию. Доступ к этому типу информации обычно жестко контролируется и периодически проверяется. Каталог Unity обеспечивает детальный контроль над ресурсами данных в каталоге, чтобы соответствовать этим отраслевым стандартам. С помощью элементов управления, которые предоставляет каталог Unity, пользователи могут просматривать и запрашивать только те данные, которые они имеют право видеть и запрашивать.

Данные могут управляться только назначенными людьми или командами.

Каталог Unity предоставляет возможность выбирать между централизованным и распределенным моделями управления.

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

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

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

Владение и доступ к каталогу Unity

Данные физически отделены в хранилище

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

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

Например, предположим, что у вашей организации есть политика соответствия компании, требующая производственных данных, связанных с персоналом, находиться в контейнере abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net. В каталоге Unity это требование можно достичь, задав расположение на уровне каталога, создав каталог, например hr_prod, и назначив расположение abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/каталог unity. Это означает, что управляемые таблицы или тома, созданные в hr_prod каталоге (например, с помощью) CREATE TABLE hr_prod.default.table …хранят данные в abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/каталоге unity. При необходимости можно указать расположения уровня схемы для упорядочивания данных на hr_prod catalog более детальном уровне.

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

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

Например, если таблица myCatalog.mySchema.myTable создана, my-region-metastoreрасположение хранилища таблиц определяется в соответствии со следующим правилом:

Если расположение было предоставлено mySchema, оно будет сохранено там.
Если нет, и расположение было предоставлено myCatalog, оно будет храниться там.
Наконец, если расположение не было предоставлено myCatalog, оно будет храниться в расположении, связанном с ним my-region-metastore.

Иерархия хранилища каталога Unity

Доступ к данным можно получить только в указанных средах

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

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

Теперь давайте более подробно рассмотрим процесс настройки каталога Unity в соответствии с вашими потребностями.

Настройка хранилища метаданных каталога Unity

Хранилище метаданных — это контейнер верхнего уровня объектов в каталоге Unity. Хранилища метаданных управляют ресурсами данных (таблицами, представлениями и томами), а также другими защищаемыми объектами, управляемыми каталогом Unity. Полный список защищаемых объектов см. в разделе "Защищаемые объекты" в каталоге Unity.

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

Советы для настройки хранилищ метаданных:

Необходимо настроить одно хранилище метаданных для каждого региона, в котором есть рабочие области Azure Databricks.

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

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

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

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

Администраторы рабочей области также могут выполнять задачи управления рабочими областями, такие как управление владением заданиями и просмотр записных книжек, которые могут предоставлять косвенный доступ к данным, зарегистрированным в каталоге Unity. Администратор рабочей области — это привилегированная роль, которую следует тщательно распределить.
При использовании рабочих областей для изоляции доступа к данным пользователей может потребоваться использовать привязки каталога рабочей области. Привязки каталога рабочей области позволяют ограничить доступ к каталогам по границам рабочей области. Например, вы можете убедиться, что администраторы рабочей области и пользователи могут получать доступ только к рабочим данным из prod_catalog рабочей среды рабочей области prod_workspace. По умолчанию используется общий доступ к каталогу со всеми рабочими областями, подключенными к текущему хранилищу метаданных. См . раздел (необязательно) Назначение каталога определенным рабочим областям.

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

См. статью Создание хранилища метаданных Unity Catalog.

Настройка внешних расположений и учетных данных хранения

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

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

Учетные данные хранилища заключают в себе долгосрочные облачные учетные данные, которые обеспечивают доступ к облачному хранилищу. Это может быть управляемое удостоверение Azure (настоятельно рекомендуется) или субъект-служба. Использование управляемого удостоверения Azure имеет следующие преимущества по сравнению с использованием субъектов-служб:

Управляемые удостоверения не требуют обслуживания учетных данных или смены секретов.
Если рабочая область Azure Databricks развернута в собственной виртуальной сети (также известной как внедрение виртуальной сети), можно подключиться к учетной записи Azure Data Lake Storage 2-го поколения, защищенной брандмауэром хранилища.

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

Совет

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

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

Упорядочение данных

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

Каталоги каталога Unity

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

Объекты, управляемые каталогом Unity, могут быть управляемыми или внешними:

Управляемые объекты — это способ создания объектов данных в каталоге Unity по умолчанию.

Каталог Unity управляет жизненным циклом и макетом файлов для этих защищаемых объектов. Не следует использовать средства за пределами Azure Databricks для управления файлами в управляемых таблицах или томах напрямую.

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

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

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

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

Внешние таблицы поддерживают Delta Lake и многие другие форматы данных, включая Parquet, JSON и CSV. Управляемые и внешние тома можно использовать для доступа к файлам произвольных форматов и хранения файлов: данные могут быть структурированы, частично структурированы или неструктурированы.

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

Управление внешними расположениями, внешними таблицами и внешними томами

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

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

После настройки внешних расположений в каталоге Unity можно создать внешние таблицы и тома в каталогах внутри внешних расположений. Затем можно использовать каталог Unity для управления доступом пользователей и групп к этим таблицам и томам. Это позволяет предоставить определенным пользователям или группам доступ к определенным каталогам и файлам в контейнере облачного хранилища.

Примечание.

При определении тома облачный URI-код ресурса (URI) к данным в пути тома регулируется разрешениями тома.

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

Каждый защищаемый объект в каталоге Unity имеет владельца. Субъект, создающий объект, становится его первоначальным владельцем. Владелец объекта имеет все разрешения для использования этого объекта, например SELECT и MODIFY для таблицы, а также разрешение на предоставление разрешений для доступа к защищаемому объекту другим субъектам. Только владельцы защищаемого объекта имеют разрешение на предоставление привилегий для этого объекта другим субъектам. Поэтому рекомендуется указать в качестве владельца всех объектов группу, которая отвечает за выдачу разрешений для объекта. Передавать права владения защищаемым объектом группе могут владелец и администратор хранилища метаданных. Кроме того, если объект содержится в каталоге (например, в таблице или представлении), то владелец каталога и схемы может изменить владение объектом.

Защищаемые объекты в каталоге Unity иерархичны, а привилегии наследуются сверху вниз. Это означает, что предоставление привилегии каталогу или схеме автоматически предоставляет привилегию всем текущим и будущим объектам в каталоге или схеме. Дополнительные сведения см. в разделе "Модель наследования".

Чтобы считывать данные из таблицы или представления, у пользователя должны быть следующие права:

SELECT для таблицы или представления
USE SCHEMA для схемы, которой принадлежит таблица
USE CATALOG для каталога, которому принадлежит схема

USE CATALOG позволяет участнику пройти по каталогу, чтобы получить доступ к его дочерним объектам и USE SCHEMA разрешить участнику пройти по схеме, чтобы получить доступ к его дочерним объектам. Например, чтобы выбрать данные из таблицы, пользователям необходимо иметь SELECT привилегии для этой таблицы и USE CATALOG привилегии родительского каталога, а также USE SCHEMA привилегии родительской схемы. Таким образом, эту привилегию можно использовать для ограничения доступа к разделам пространства имен данных определенным группам. Распространенный сценарий заключается в настройке схемы для каждой команды, в которой только эта команда имеет привилегии USE SCHEMA и CREATE для этой схемы. Это означает, что любые таблицы, созданные участниками команды, могут предоставляться только членам команде.

Доступ к таблице можно защитить с помощью следующего синтаксиса SQL:

GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

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

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  id,
  CASE WHEN is_account_group_member(< group_name >) THEN email ELSE 'REDACTED' END AS email,
  country,
  product,
  total
FROM
  < catalog_name >.< schema_name >.< table_name >;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;

Вы можете защитить доступ к строкам с помощью динамического представления во вторичной схеме, как показано в следующем синтаксисе SQL:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  *
FROM
  < catalog_name >.< schema_name >.< table_name >
WHERE
  CASE WHEN is_account_group_member(managers) THEN TRUE ELSE total <= 1000000 END;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

Вы также можете предоставить пользователям безопасный доступ к таблицам с помощью фильтров строк и маски столбцов. Дополнительные сведения см. в разделе "Фильтрация конфиденциальных данных таблицы" с помощью фильтров строк и маски столбцов.

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

Управление конфигурациями кластеров

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

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

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

В приведенном ниже формате JSON приведено определение политики для кластера с режимом общего доступа:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9]*\\.x-scala.*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "USER_ISOLATION",
    "hidden": true
}
}

В приведенном ниже формате JSON приведено определение политики для автоматизированного кластера заданий с режимом доступа к одному пользователю:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9].*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "SINGLE_USER",
    "hidden": true
},
"single_user_name": {
    "type": "regex",
    "pattern": ".*",
    "hidden": true
}
}

Аудит доступа

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

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

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

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

Для совместного использования данных между хранилищами метаданных можно использовать Databricks-to-Databricks Delta Sharing. Это позволяет регистрировать таблицы из хранилищ метаданных в разных регионах. Эти таблицы будут отображаться как объекты только для чтения в потребляющем хранилище метаданных. Доступ к этим таблицы можно предоставить как к любому другому объекту в каталоге Unity.

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

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

Стандартные блоки управления данными и изоляции данных

Планирование модели изоляции данных

Пользователи могут получать доступ только к данным на основе указанных правил доступа.

Данные могут управляться только назначенными людьми или командами.

Данные физически отделены в хранилище

Доступ к данным можно получить только в указанных средах

Настройка хранилища метаданных каталога Unity

Настройка внешних расположений и учетных данных хранения

Упорядочение данных

Управление внешними расположениями, внешними таблицами и внешними томами

Рекомендации для использования внешних расположений

Рекомендации для использования внешних томов

Рекомендации для использования внешних таблиц

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

Управление конфигурациями кластеров

Аудит доступа

Подробнее

Дополнительные ресурсы

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

Стандартные блоки управления данными и изоляции данных

Планирование модели изоляции данных

Пользователи могут получать доступ только к данным на основе указанных правил доступа.

Данные могут управляться только назначенными людьми или командами.

Данные физически отделены в хранилище

Доступ к данным можно получить только в указанных средах

Настройка хранилища метаданных каталога Unity

Настройка внешних расположений и учетных данных хранения

Упорядочение данных

Управление внешними расположениями, внешними таблицами и внешними томами

Рекомендации для использования внешних расположений

Рекомендации для использования внешних томов

Рекомендации для использования внешних таблиц

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

Управление конфигурациями кластеров

Аудит доступа

Безопасное предоставление общего доступа к данным с помощью разностного общего доступа

Подробнее

Дополнительные ресурсы