Unity Catalog в Databricks: управління даними і governance без хаосу

Коротко: Unity Catalog — це unified governance layer для data та AI в Databricks. Він централізує контроль доступу, data discovery, audit logs, lineage, row-level security, column masking і управління data/AI assets у межах workspace, підключених до одного metastore. Якщо ваша команда працює в Databricks і хоче прибрати хаос у правах, каталогах і походженні даних — Unity Catalog є базовим інструментом для цього.

Вступ

Databricks-середовища ростуть швидко. Спочатку один workspace, кілька таблиць, невелика команда. Потім — кілька workspace, десятки pipeline-ів, нові аналітики, автоматизовані jobs, ML-моделі — і раптом ніхто не знає, хто має доступ до production-даних, звідки взялась таблиця і чи можна покластися на неї у звіті для бізнесу.

Unity Catalog був представлений Databricks як відповідь на цю проблему централізованого governance. У 2026 році для нових Databricks workspace він фактично є базовим шаром управління data та AI assets: доступами, метаданими, lineage, audit logs, data discovery та sharing.

У цій статті розберемо архітектуру Unity Catalog, модель дозволів, data lineage і типові помилки при впровадженні. Після прочитання у вас буде чітке розуміння, як цей інструмент вписується в сучасний data stack і з чого починати практичне налаштування.

Що таке Unity Catalog і навіщо він потрібен у Databricks?

Governance — це інфраструктура довіри до даних

Уявіть типову ситуацію: data team виросла до 15 людей, є кілька Databricks workspace для різних команд, і раптом фінансовий директор запитує — а хто взагалі має доступ до таблиці з транзакціями? Ніхто не знає точно.

Саме тут проявляється цінність data governance — не як бюрократичної процедури, а як технічної основи для довіри до даних. Бізнес приймає рішення на основі даних, і ці дані мають бути надійними, зрозумілими і захищеними.

Unity Catalog — це єдиний governance-рівень для Databricks workspace, підключених до одного metastore. Він не означає “один каталог для всього”: навпаки, всередині metastore можна створювати кілька catalog для середовищ, доменів, команд або продуктів, але правила доступу й управління метаданими залишаються централізованими.

Коротка передісторія: як Databricks жив без Unity Catalog

До Unity Catalog багато Databricks-середовищ працювали через workspace-level Hive Metastore. Це означало ізоляцію метаданих між workspace, дублювання таблиць, складніше керування правами та обмежену прозорість походження даних. Частину задач доводилося вирішувати окремими правилами, naming convention, документацією та зовнішніми процесами.

Unity Catalog вирішує цю проблему на рівні архітектури: metastore стає верхнім рівнем governance для data та AI assets у конкретному cloud region, а workspace підключаються до нього й працюють із єдиною моделлю каталогів, схем, дозволів, lineage та audit.

Як влаштований Unity Catalog: архітектура і ключові концепції

Тришарова ієрархія: Catalog → Schema → Table

Уся структура Unity Catalog будується на трьох рівнях namespace:

• Catalog — верхній рівень для організації data та AI assets усередині metastore. Його часто використовують для середовищ, бізнес-доменів або команд: prod_catalog, dev_catalog, finance_catalog.
• Schema — namespace всередині catalog для більш детальної організації об’єктів. Наприклад: sales, marketing, finance або окремий use case / sandbox команди.
• Table / View / Volume / Function / Model / Service — конкретні securable objects усередині schema, для яких можна налаштовувати права доступу й governance-політики.

Звернення до таблиці через повний namespace виглядає так:

SELECT * FROM prod_catalog.sales.transactions;

SELECT * FROM prod_catalog.sales.transactions;

Правильне іменування catalog і schema з самого початку — одна з речей, які або рятують, або створюють технічний борг. Базова практика: одразу визначити, чи ви розділяєте catalog за середовищами (prod/dev/staging), бізнес-доменами, командами або продуктами.

Securable objects: що саме можна захищати і контролювати

Unity Catalog керує широким переліком об’єктів:

Metastore, workspace і account: як вони пов’язані

Metastore — верхній об’єкт Unity Catalog, який містить securable objects у межах одного cloud region. До нього можна підключати один або кілька workspace. На практиці організація може мати кілька metastores для різних регіонів або ізоляційних меж, тому архітектуру варто проєктувати до масового створення каталогів.

Як працює контроль доступу до даних у Unity Catalog?

GRANT і REVOKE: SQL-синтаксис для управління правами

Unity Catalog реалізує централізовану модель дозволів через SQL-команди GRANT і REVOKE або через UI. Права можна видавати на різних рівнях ієрархії — catalog, schema, table, view, volume, function, model та інші securable objects. 

-- Надати групі аналітиків доступ до схеми в production catalog

GRANT USE CATALOG ON CATALOG prod_catalog TO `analysts`;
GRANT USE SCHEMA ON SCHEMA prod_catalog.sales TO `analysts`;
GRANT SELECT ON TABLE prod_catalog.sales.transactions TO `analysts`;

-- Надати групі аналітиків доступ до схеми в production catalog

GRANT USE CATALOG ON CATALOG prod_catalog TO `analysts`;
GRANT USE SCHEMA ON SCHEMA prod_catalog.sales TO `analysts`;
GRANT SELECT ON TABLE prod_catalog.sales.transactions TO `analysts`;

-- Забрати право на запис
REVOKE MODIFY ON TABLE prod_catalog.sales.transactions FROM `analysts`;

-- Забрати право на запис
REVOKE MODIFY ON TABLE prod_catalog.sales.transactions FROM `analysts`;

Важливий нюанс: у Unity Catalog діє privilege inheritance. Частину прав можна надати на рівні catalog або schema, щоб вони застосовувалися до поточних і майбутніх об’єктів нижче в ієрархії. Але це не модель “explicit deny”: права потрібно проєктувати через групи, рівні ієрархії та принцип least privilege.

Рівні привілеїв: від USE CATALOG до SELECT і MODIFY

Основні привілеї в Unity Catalog:

• USE CATALOG — право на використання каталогу (необхідна умова для доступу до будь-чого всередині)
• USE SCHEMA — право на використання схеми
• SELECT — читання даних з таблиці або view
• MODIFY — запис, оновлення, видалення рядків
• CREATE TABLE — створення таблиць у схемі
• CREATE SCHEMA — створення схем у каталозі
• ALL PRIVILEGES — широка група прав на об’єкт, але для production-середовищ краще видавати точкові privileges за принципом least privilege

Важливий нюанс: щоб прочитати таблицю, користувач потребує USE CATALOG + USE SCHEMA + SELECT. Відсутність будь-якого з цих прав призведе до помилки доступу.

Сервісні акаунти, групи та identity federation

Типова точка плутанини для нових користувачів — різниця між account-level identities і workspace-local підходами. Для Unity Catalog правильніше керувати доступом через account-level groups, service principals і identity federation, щоб одна й та сама модель доступу працювала між workspace.

На практиці варто керувати доступом через групи та service principals, а не через окремих користувачів. Це спрощує onboarding, offboarding, автоматизовані jobs і аудит доступів.

Unity Catalog працює з identity federation і зовнішніми identity providers, зокрема Microsoft Entra ID, AWS IAM Identity Center та Google Cloud Identity. Це дозволяє синхронізувати користувачів і групи на account-рівні й не дублювати управління доступом у кожному workspace.

Для чутливих даних, наприклад PII або GDPR-кейсів, Unity Catalog підтримує row filters і column masks. У сучасному підході ці правила можна застосовувати напряму до таблиць або централізовано через ABAC-політики та governed tags, щоб не дублювати однакову логіку на десятках таблиць.

Як Unity Catalog відстежує походження даних: data lineage і аудит

Автоматичний data lineage: що відстежується і як це виглядає

Data lineage — це розуміння того, звідки прийшли дані і як вони трансформувались по дорозі. Для бізнесу це питання довіри до звітів. Для data-команди — інструмент дебагу.

Unity Catalog автоматично збирає lineage для queries, виконаних у Databricks, з деталізацією до column-level там, де це можливо. Lineage агрегується між workspace, підключеними до одного metastore, і може показувати таблиці, view, jobs, notebooks, dashboards, ML model versions, file paths та external assets.

Практичний сценарій: показник у дашборді раптово змінився. З lineage видно, яка upstream-таблиця або трансформація є джерелом проблеми — замість того щоб вручну трасувати залежності між десятками pipeline.

5 практичних use cases для data lineage:

1. Compliance і аудит — довести регулятору, звідки взялись дані у звіті
2. Дебаг pipeline — швидко знайти джерело помилки або аномалії
3. Impact analysis — перед зміною схеми таблиці зрозуміти, які downstream-об’єкти постраждають
4. Onboarding — нові члени команди бачать архітектуру даних через граф залежностей
5. Документування для бізнесу — прозорість у тому, як формуються ключові метрики

Важливе обмеження: lineage працює для об’єктів, зареєстрованих у Unity Catalog, і queries, виконаних через підтримувані Databricks interfaces, зокрема Spark DataFrame / Spark SQL, notebooks або SQL query editor. Якщо джерела або цілі звертаються напряму за path, наприклад delta.”s3://…”, column-level lineage може не визначатися. Для зовнішніх систем потрібно реєструвати external metadata objects.

Audit logs: хто, що і коли робив з вашими даними

Databricks audit logs фіксують події доступу й адміністрування, зокрема операції з Unity Catalog. У сучасному підході їх можна аналізувати через system table `system.access.audit` після ввімкнення system tables; також можливе налаштування delivery audit logs у cloud storage. Це не “таблиця Delta Lake всередині Unity Catalog за замовчуванням”, а окремий механізм observability та security-аудиту.

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

Data discovery і пошук у каталозі даних

Unity Catalog дозволяє працювати з comments, owners, tags і governed tags для data discovery та класифікації. Це робить каталог корисним не лише для data engineers, а й для аналітиків, governance-команд і нетехнічних стейкхолдерів, які шукають надійні джерела даних самостійно.

Типові помилки при впровадженні Unity Catalog

Помилки при міграції з Hive Metastore

Помилка #1: мігрувати все одразу. Спроба перенести всі legacy tables, jobs і permissions у Unity Catalog за один раз часто створює ризики. Практичний підхід — почати з нових проєктів, критичних shared datasets або одного домену, перевірити модель доступу й тільки потім масштабувати міграцію.

Помилка #2: плутанина між managed і external tables. Managed tables зберігаються в managed storage, яким керує Databricks/Unity Catalog; при DROP TABLE дані та metadata видаляються відповідно до поведінки managed table. External tables посилаються на дані у вашому cloud storage через external location; DROP TABLE видаляє metadata, але не самі underlying files. Це різна поведінка, і її потрібно пояснити команді до міграції.

Помилка #3: відсутність naming convention. Catalog, schema, table, volume та service principal без чіткої системи іменування швидко створюють технічний борг. Рефакторити naming convention після того, як на ній побудовані десятки pipeline-ів, складно й ризиковано.

Проблеми з external locations і cloud storage permissions

Помилка #4: неправильне налаштування external locations і storage credentials. External location у Unity Catalog — це зареєстрований шлях у cloud storage, пов’язаний зі storage credential. Якщо IAM role, service principal або service account не має потрібних cloud permissions, жодні GRANT у Unity Catalog не виправлять доступ до underlying storage.

Помилка #5: ігнорування account-level groups і service principals. Управління доступом лише на workspace-рівні призводить до дублювання налаштувань і різної поведінки між workspace.

Позиція автора: де Unity Catalog вирішує проблему, а де — ні

Unity Catalog добре вирішує governance всередині Databricks і для assets, зареєстрованих у його metastore. Але якщо значна частина даних живе поза Databricks — у Snowflake, Redshift, BigQuery, on-prem DWH або інших каталогах — Unity Catalog покриває тільки частину governance-картини. У таких сценаріях потрібна архітектура інтеграції з іншими каталогами, external metadata, federation або окремими enterprise data catalog рішеннями.

Для таких сценаріїв варто дивитися не лише на Unity Catalog, а й на інші catalog/federation підходи: open-source Unity Catalog APIs, Apache Polaris для Iceberg-сценаріїв, enterprise data catalogs і federated governance.

FAQ: питання про Unity Catalog і data governance в Databricks

Питання: Що таке Unity Catalog в Databricks?
Відповідь: Unity Catalog — це unified governance layer для data та AI assets у Databricks. Він забезпечує централізований контроль доступу, data discovery, lineage, auditing, sharing, row filters, column masks, governed tags і управління securable objects: таблицями, view, volumes, functions, models, services, connections та іншими ресурсами. Unity Catalog працює через metastore, до якого підключаються workspace у відповідному cloud region.

Питання: Як налаштувати Unity Catalog у Databricks?
Відповідь: У нових Databricks accounts/workspaces Unity Catalog часто вже ввімкнений автоматично. Для legacy-середовищ потрібно перевірити metastore, прив’язку workspace, адміністраторів, identity federation, account-level groups, storage credentials, external locations і compute, сумісний із Unity Catalog. Після цього створюють catalog, schema, tables/views/volumes і налаштовують GRANT/REVOKE або UI-права за принципом least privilege.

Питання: Unity Catalog vs Hive Metastore — що краще для Databricks?
Відповідь: Для нових Databricks-проєктів Unity Catalog є рекомендованим підходом, тому що дає централізований governance, тришаровий namespace catalog.schema.table, lineage, audit logs, access control, volumes, models і сучасні security-механізми. Hive Metastore залишається legacy-підходом для старих середовищ. Перехід із Hive Metastore до Unity Catalog варто планувати поступово: починати з нових проєктів або окремих доменів, а не переносити все за один раз.

Питання: Які помилки роблять при роботі з Unity Catalog?
Відповідь: Найпоширеніші помилки: видавати права окремим користувачам замість груп і service principals; плутати managed та external tables; не проєктувати catalog/schema naming convention; ігнорувати external locations і cloud permissions; очікувати, що lineage покриє всі зовнішні інструменти автоматично; переносити legacy Hive Metastore об’єкти без поетапної міграції й тестування доступів.

Висновок: як почати працювати з Unity Catalog на практиці

Unity Catalog — це централізований governance layer для data та AI в Databricks, який вирішує реальні проблеми контролю доступу, data discovery, lineage, audit, sharing і масштабованості в командах, що ростуть.

Він дає технічну основу для роботи з даними, якій можна довіряти. Але сам по собі інструмент не замінює культуру роботи з даними — naming conventions, документування, відповідальність за якість даних — це все одно завдання команди.

Якщо хочете опанувати побудову data pipeline, governance і хмарну інфраструктуру на практиці, спеціалізація Analytics & Data Engineer від Data Lab може дати системний шлях від Python і SQL до сучасного data engineering стеку, cloud-платформ і практичних проєктів.