Unity Catalog і походження даних

Вступ до Databricks Lakehouse

Gang Wang

Senior Data Scientist

Чому важливе керування

Сотні таблиць у кількох командах
«Чи бачить маркетинг фінансові дані клієнтів?»
«Звіт виглядає хибно — звідки насправді ці дані?»
Unity Catalog централізує відповіді

recraft: half: Лабіринт взаємопов'язаних конвеєрів даних і папок із знаками запитання зверху, що уособлює складність даних без керування

Ієрархія Unity Catalog

Дерево ієрархії Unity Catalog

Metastore — один на обліковий запис, контейнер верхнього рівня
Каталоги — на кшталт «production» чи «development»
Схеми — групують пов'язані об'єкти (напр., «sales»)
Містить tables, views і functions

Керування доступом

-- Надати доступ на читання до схеми
GRANT SELECT
ON SCHEMA production.sales
TO `analytics_team`;

-- В Revoke доступ на рівні таблиці
REVOKE SELECT
ON TABLE production.sales.customers
FROM `intern_group`;

Дозволи на кожному рівні ієрархії
Надавайте SELECT, MODIFY, CREATE для каталогів, схем або таблиць
Успадковуються — грант на каталог діє для всіх його схем

Походження даних

Звідки взялися ці дані?

flowchart: bronze_orders (джерело), silver_orders (очищено), gold_daily_revenue (агреговано), Revenue Dashboard (споживач)

Автоматичне відстеження зв'язків між таблицями під час виконання запитів
Відстежуйте вгору (джерела) та вниз (споживачів)

Походження на практиці

Upstream — простежити, звідки походять дані
Downstream — що залежить від цієї таблиці
Аналіз впливу — якщо змінити цей стовпець, що зламається?
Зневадження — звіт показує хибні числа, простежте джерело

recraft: half: Детектив із лупою розглядає ланцюжок пов'язаних документів і таблиць даних, що уособлює розслідування походження даних

Підсумок

Unity Catalog — централізоване керування всіма активами даних
Ієрархія — metastore → catalog → schema
Керування доступом — SQL-гранти на кожному рівні, успадковуються вниз
Походження — автоматичне відстеження потоків даних вгору і вниз

Давайте потренуємось!

Вступ до Databricks Lakehouse