Unity Catalog в Databricks: правильная настройка управления данными

Unity Catalog является слоем управления данными в Databricks. Он определяет, кто может видеть и изменять каждую таблицу, представление, том файлов, функцию и AI-модель, записывает lineage между ними и журналирует доступ, чтобы вы могли доказать это аудитору.

Если вы сегодня работаете на Databricks, вы уже на нём или переходите на него. Устаревший Hive metastore уходит, и каждая новая функция Databricks предполагает, что под ней Unity Catalog.

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

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

Всё находится под metastore, контейнером верхнего уровня. Ниже него активы данных и AI используют трёхуровневое пространство имён: catalog.schema.object. Запрос к prod_finance.gl.journal_lines называет каталог, схему и таблицу.

Объекты, на которые выдаются права, называются защищаемыми объектами (securable objects). Согласно документации Unity Catalog, они делятся на две группы:

1. Активы в пространстве имён: таблицы, представления, тома (управляемое файловое хранилище), функции, модели и сервисы.
2. Объекты уровня metastore: учётные данные хранилища (storage credentials), внешние расположения (external locations), подключения (к внешним базам данных) и общие ресурсы (shares).

Два из этих объектов уровня metastore заслуживают простого объяснения, потому что они определяют, где физически лежат ваши данные.

Storage credential оборачивает облачное удостоверение, например роль IAM или управляемое удостоверение, которое имеет доступ к учётной записи хранения или бакету. External location связывает путь в хранилище с учётными данными. Вместе они позволяют Unity Catalog читать и записывать облачное хранилище, не раздавая ключи пользователям.

Далее: управляемые и внешние таблицы. С управляемыми таблицами Unity Catalog управляет таблицей и её файлами. С внешними таблицами он управляет только доступом.

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

Одно ограничение определяет всё: на каждый облачный регион может быть только один metastore. Изоляцию нельзя решить большим количеством metastore. Её решают каталогами.

Разрешения Unity Catalog представляют собой стандартные SQL-права (grants), которые наследуются вниз. Право на каталог действует для каждой схемы и таблицы внутри него. Пользователю нужны USE CATALOG и USE SCHEMA, чтобы добраться до таблицы, а затем SELECT, чтобы её читать.

GRANT USE CATALOG ON CATALOG prod_finance TO `finance-analysts`;
GRANT USE SCHEMA ON SCHEMA prod_finance.gl TO `finance-analysts`;
GRANT SELECT ON SCHEMA prod_finance.gl TO `finance-analysts`;

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

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

Средство контроля	Что делает	Статус (октябрь 2026 года)
Права и владение	Привилегии на уровне объектов, наследуемые от каталога к схеме и к объекту	Общедоступно
Фильтры строк и маски столбцов на уровне таблицы	SQL-функция, привязанная к одной таблице, скрывает строки или маскирует значения	Общедоступно
Политики ABAC для фильтров строк и масок столбцов	Одна политика, заданная на уровне каталога, схемы или таблицы, действует для каждого объекта с governed tag	GA с 28 апреля 2026 года
Governed tags	Теги уровня учётной записи с контролируемыми ключами, значениями и списком тех, кто может их назначать	GA со 2 апреля 2026 года
Классификация данных	Сканирует таблицы и помечает чувствительные данные, например PII	GA с 20 апреля 2026 года; пользовательские классификаторы в Beta
Политики ABAC DENY и политики уровня metastore	Явные запреты, которые перекрывают права; политики в масштабе metastore	Beta
ABAC для внешних движков	Внешние движки читают управляемые таблицы под защитой ABAC, а политики применяются бессерверными вычислениями Databricks	GA с 1 октября 2026 года

Даты взяты из заметок о выпуске Databricks за апрель 2026 года и заметок за октябрь 2026 года.

ABAC (управление доступом на основе атрибутов) является изменением, которое важнее всего для крупных сред. Вместо того чтобы писать маску для каждой таблицы, вы помечаете столбцы тегом, скажем classification = export_controlled, и пишете одну политику, которая маскирует каждый помеченный столбец для всех, кто не входит в указанную группу.

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

Сначала проверьте вычисления. Таблицы под защитой ABAC требуют бессерверных вычислений или Databricks Runtime 16.4 и выше. Старые кластеры вообще не могут их читать.

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

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

Lineage собирается автоматически, вплоть до уровня столбцов, для запросов через Databricks SQL и Spark DataFrames в любом рабочем пространстве, подключённом к metastore. Он охватывает ноутбуки, задания, конвейеры и дашборды. Lineage столбцов теряется, когда код обращается к таблицам по пути в хранилище: ещё одна причина отказаться от доступа по путям.

Доказательства для аудита берутся из системных таблиц. system.access.audit хранит события аудита и в документации по системным таблицам всё ещё помечена как Public Preview.

Рядом лежат таблицы lineage и биллинга с бесплатным хранением в течение 365 дней. По умолчанию системные таблицы видят только администраторы учётной записи и metastore, поэтому заранее решите, кто получит доступ на чтение и будете ли вы копировать данные аудита в вашу SIEM для более долгого хранения.

Обмен данными в этом году сменил название. Databricks объявил OpenSharing 10 июня 2026 года как следующую версию протокола Delta Sharing, которую теперь курирует Linux Foundation и которая расширена на AI-активы и клиентов Iceberg.

В старой документации и контрактах вы всё ещё увидите «Delta Sharing». Share является объектом Unity Catalog, и обмен между Databricks и Databricks также служит способом перемещать данные между региональными metastore.

Для смешанных сред управляемые и внешние (foreign) таблицы Apache Iceberg стали общедоступными 21 мая 2026 года. Внешние таблицы читаются через Lakehouse Federation из каталогов вроде AWS Glue или Snowflake Horizon. Такие движки, как Spark, Flink и Trino, могут использовать конечную точку Iceberg REST catalog в Unity Catalog.

Есть также Unity Catalog с открытым исходным кодом под эгидой LF AI & Data Foundation, но это проект на стадии sandbox, а не управляемый сервис. Не стройте на нём план выхода без тестирования.

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

Два способа нарезать каталоги

Каталог на среду

• Каталоги dev, test и prod, схемы по доменам
• Просто привязать каждый каталог к его рабочему пространству
• Владение размывается, когда домены растут внутри одного каталога
• Подходит небольшим командам и ранним этапам внедрения

Каталог на домен и среду

• prod_finance, prod_quality, dev_finance и так далее
• Группа каждого домена владеет своими каталогами
• Ясная ответственность и более чистый охват аудита
• Больше каталогов, которые нужно называть, привязывать и наделять правами

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

Остальной дизайн сводится к четырём правилам:

1. Группы приходят из вашего провайдера удостоверений. Передавайте пользователей и группы в учётную запись Databricks через автоматическое управление удостоверениями или через SCIM, если ваш провайдер его не поддерживает. Определяйте группы в Microsoft Entra ID, Okta или аналоге, а не в Databricks. Когда человек уходит, доступ уходит вместе с его учётной записью в каталоге.
2. Группы владеют промышленными объектами. Собственная рекомендация Databricks: назначать владельцами промышленных каталогов и схем группы, а не отдельных людей. Владелец может выдавать доступ, поэтому человек в роли владельца становится постоянным исключением.
3. Привязывайте каталоги к рабочим пространствам. Промышленный каталог, привязанный только к промышленным рабочим пространствам, нельзя запросить из песочницы, что бы ни говорили права.
4. Классифицируйте до того, как выдавать права. Согласуйте короткий словарь тегов (чувствительность, персональные данные, экспортный контроль, система-источник) в виде governed tags и пишите политики ABAC на его основе.

В производстве я организовывал каталоги по заводским системам, то есть по домену OT и систем-источников, а не по заводам. Данные OT из историков, MES и датчиков лежат в своих каталогах, которыми владеет команда данных по производству или инженерии. Данные IT из ERP (SAP, Oracle или Microsoft Dynamics 365), систем качества и цепочки поставок лежат в других.

Подготовленные, связанные данные для аналитиков живут в третьем наборе. Граница OT/IT становится видна в самом каталоге. Если в объёме работ есть выгрузка из ERP, мои заметки о том, почему проваливаются миграции данных SAP, применимы и к потокам данных ERP.

В оборонных программах ждите от службы безопасности четырёх вопросов. Кто может видеть данные под экспортным контролем? Как они отделены от всего остального?

Где они хранятся? Можете ли вы доказать всё это для любого дня за последний год?

Unity Catalog отвечает на большинство из них, если проектировать с расчётом на это:

1. Минимальные привилегии. Никаких прав на уровне metastore или каталога для широких групп. Выдавайте права на уровне схемы именованным группам и используйте маски ABAC для столбцов с тегом контролируемых данных. Используйте политики DENY, только когда они выйдут из Beta и ваши органы аккредитации их примут.
2. Разделение. Отдельные каталоги для контролируемых данных с собственным управляемым расположением хранилища, привязанные к выделенным рабочим пространствам. Databricks рекомендует управляемое хранилище на уровне каталога как основную единицу изоляции, и это здесь хорошо подходит.
3. Резидентность. Один metastore на регион означает, что данные остаются в регионе своего хранилища, если только кто-то не откроет к ним общий доступ. Рассматривайте каждый share в OpenSharing и каждую межрегиональную связь как решение о резидентности, требующее согласования.
4. Доказательства для аудита. Lineage плюс system.access.audit, выгружаемые в вашу SIEM, показывают, кто к чему обращался и куда это ушло. Помните, что таблица аудита всё ещё в Public Preview. В моей работе в оборонной отрасли службы безопасности хотели, чтобы журналы аудита копировались в их собственную SIEM, а не просто оставались в системных таблицах Databricks. Закладывайте этот поток в план с самого начала.

Unity Catalog не решает, что считается секретными данными или данными под контролем ITAR, и не заменяет аккредитацию. Некоторые оборонные нагрузки вообще нельзя запускать в коммерческом облачном регионе.

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

Это порядок, которого я бы придерживался в компании, переходящей с Hive metastore или начинающей с нуля.

1. Согласуйте модель каталогов и соглашение об именовании. Домен плюс среда, записано и подписано владельцами данных. Измените это позже, и вам придётся переименовывать всё.
2. Подключите провайдера удостоверений. Предоставление доступа на уровне учётной записи, группы определены в каталоге пользователей, SCIM на уровне рабочих пространств отключён для рабочих пространств с Unity Catalog.
3. Настройте storage credentials и external locations. Ими владеет платформенная группа. Больше никто не получает CREATE EXTERNAL LOCATION.
4. Создайте каталоги с управляемым хранилищем и привязками к рабочим пространствам. Промышленными каталогами с первого дня владеют группы.
5. Определите governed tags и включите классификацию данных. Проверьте её находки, прежде чем писать на их основе политики.
6. Напишите политики ABAC для чувствительных столбцов. Протестируйте с реальными пользователями на каждом типе вычислений, который вы используете, включая любые кластеры ниже Runtime 16.4.
7. Мигрируйте с Hive metastore. Теперь Databricks рекомендует сначала федерировать Hive metastore, а затем обновлять таблицы на месте. UCX помогает в крупных средах, но это проект Databricks Labs, который поддерживает сообщество, а не официальная поддержка. Учитывайте это в плане.
8. Включите выгрузку аудита и проверку lineage. Выдайте доступ на чтение к системным таблицам, настройте поток в SIEM и договоритесь, кто что проверяет.
9. Отключите доступ к Hive metastore, когда всё будет перенесено, чтобы никто тихо не продолжал строить на старом пути.

1. Выдача прав отдельным людям. Неделю это работает. Потом никто не может ответить, у кого к чему есть доступ.
2. Один огромный каталог со схемами по командам. Владение и охват аудита размываются, и позже вы всё перестраиваете.
3. Оставлять таблицы внешними «пока что». Вы теряете возможности управляемых таблиц и сохраняете двух владельцев у каждого файла.
4. Тестирование политик на одном типе кластеров. ABAC ведёт себя по-разному в зависимости от вычислений; старые среды выполнения просто падают.
5. Отношение к аудиту как к более поздней фазе. Аудитор спросит о периоде до того, как вы его включили.

Если вы на раннем этапе, опишите модель каталогов и словарь тегов на одной странице до того, как кто-то создаст первый каталог. Если вы в середине миграции, проведите оценку, составьте список всех таблиц, которые всё ещё внешние или всё ещё на Hive metastore, и назначьте каждой владельца и дату.

Для общей картины начните с материала о том, для чего используется Databricks, и посмотрите цены Databricks, прежде чем рассчитывать бессерверные вычисления под ABAC. Если вы сравниваете платформы, моё сравнение Snowflake и Databricks разбирает управление данными с обеих сторон. Я помогаю организациям в производстве и оборонной отрасли принимать такие проектные решения; если вам пригодится второе мнение, запишитесь на звонок.

Что такое Unity Catalog в Databricks?

Unity Catalog является слоем управления данными для Databricks. Он даёт одно место для управления доступом к таблицам, представлениям, томам файлов, функциям и AI-моделям, автоматически собирает lineage и записывает доступ в системные таблицы аудита. К активам обращаются как catalog.schema.object под единым metastore на каждый регион.

ABAC в Databricks уже общедоступен?

Да. Политики управления доступом на основе атрибутов для фильтров строк и масок столбцов стали общедоступными 28 апреля 2026 года, а governed tags и классификация данных тоже стали GA в апреле 2026 года. Политики DENY, политики уровня metastore и пользовательские классификаторы на октябрь 2026 года всё ещё были в Beta.

Delta Sharing и OpenSharing это одно и то же?

Да. Databricks объявил OpenSharing в июне 2026 года как следующее развитие протокола Delta Sharing, которое теперь курирует Linux Foundation и которое расширено на AI-активы и клиентов Iceberg. Документация Databricks теперь описывает обмен данными под названием OpenSharing.

Использовать в Unity Catalog управляемые или внешние таблицы?

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

Как перейти с Hive metastore на Unity Catalog?

Databricks рекомендует сначала федерировать Hive metastore как внешний (foreign) каталог, а затем обновлять таблицы на месте без перемещения данных. Для крупных сред инструменты UCX от Databricks Labs оценивают готовность и переносят группы, разрешения и таблицы, но UCX поддерживает сообщество, а не официальная поддержка.

Организовывать каталоги по средам или по бизнес-доменам?

Для большинства предприятий и так и так: один каталог на домен в каждой среде, например prod_finance и dev_finance. Это даёт группе каждого домена ясное владение и чистый охват аудита. Небольшие команды могут начать с одного каталога на среду и схем по доменам.