Data Governance — что это и зачем аналитику

Что такое Data Governance

Data Governance — это набор процессов, ролей и стандартов, которые обеспечивают качество, безопасность и доступность данных в компании. Если коротко: это ответ на вопросы «откуда эти данные?», «можно ли им доверять?» и «кто имеет к ним доступ?».

Когда в компании 5 аналитиков и одна база — управление данными происходит «на словах». Когда аналитиков 50, баз — 10, а ETL-пайплайнов — сотни, без формального Data Governance начинается хаос: разные определения одних и тех же метрик, дублирование таблиц, непонятные поля без документации.

Зачем это аналитику

Может показаться, что Data Governance — тема для инженеров данных и менеджмента. Но аналитик — первый, кто страдает от плохого управления данными:

• Нет документации → тратите час на разведку, что значит поле status_v2 в таблице orders_new_final.
• Нет data lineage → не понимаете, откуда берутся данные в отчёте и почему цифры не сходятся.
• Нет стандартов качества → строите дашборд на данных с 30% пропусков и узнаёте об этом после презентации.
• Нет контроля доступа → либо у вас нет данных, которые нужны, либо есть доступ к тому, чего не должны видеть.

Аналитик — потребитель данных номер один. Чем лучше управление данными, тем быстрее и точнее ваша работа.

Ключевые компоненты

Data Catalog — каталог данных

Централизованный реестр всех таблиц, полей, метрик и их описаний. Вместо Slack-сообщения «а что значит поле X?» вы открываете каталог и находите описание, владельца и пример значений.

Инструменты: DataHub, Amundsen, Atlan, встроенные каталоги в Databricks и BigQuery.

Data Lineage — происхождение данных

Визуальная карта: откуда данные пришли, через какие трансформации прошли, в какие отчёты попали. Когда метрика «сломалась» — lineage показывает, на каком этапе что пошло не так.

Пример: таблица revenue_daily собирается из raw_orders → ETL в clean_orders → агрегация в revenue_daily. Если raw_orders начал терять записи — lineage покажет цепочку.

Data Quality — качество данных

Автоматические проверки: полнота (нет ли пропусков?), уникальность (нет ли дубликатов?), актуальность (когда данные обновлялись последний раз?), валидность (значения в допустимом диапазоне?).

-- Пример проверки качества: пропуски и дубликаты в таблице orders
SELECT
    COUNT(*) AS total_rows,
    COUNT(*) - COUNT(order_id) AS null_order_ids,
    COUNT(*) - COUNT(DISTINCT order_id) AS duplicate_order_ids,
    COUNT(*) - COUNT(revenue) AS null_revenue,
    MIN(created_at) AS earliest_order,
    MAX(created_at) AS latest_order
FROM orders;

Инструменты: Great Expectations, dbt tests, Monte Carlo, Soda.

Access Control — управление доступом

Кто имеет доступ к каким данным. Персональные данные пользователей (PII) — только ограниченному кругу. Финансовые данные — только финансовому отделу. RBAC (Role-Based Access Control) — стандартный подход.

Data Mesh vs централизованное управление

Традиционный подход — централизованная команда данных, которая управляет всеми хранилищами и стандартами. Работает, пока компания не вырастает до 500+ человек.

Data Mesh — альтернативный подход, где каждая команда (домен) владеет своими данными как продуктом. Команда маркетинга управляет маркетинговыми данными, команда продукта — продуктовыми. Центральная платформа даёт инструменты, но не контролирует данные напрямую.

	Централизованное	Data Mesh
Владение данными	Центральная команда	Доменные команды
Стандарты	Единые, сверху	Единые принципы, реализация — на доменах
Масштабируемость	Ограничена размером команды	Масштабируется с ростом компании
Сложность	Ниже	Выше

На практике большинство компаний используют гибридный подход: централизованные стандарты + распределённая ответственность.

Практический пример: что пошло не так

Компания запускает акцию «Скидка 20%». Маркетинг смотрит в один дашборд — выручка выросла на 15%. Финансы смотрят в другой — выручка упала на 5%. Почему?

• Маркетинг считает revenue как сумму amount из таблицы orders.
• Финансы считают revenue как amount - refunds - chargebacks из таблицы transactions.
• Оба правы — но у них разные определения одной метрики.

Data Governance решает это через единый глоссарий метрик: одно определение revenue, задокументированное, с указанием источника и формулы. Все дашборды используют одну и ту же таблицу.

Инструменты

• dbt — нормализация, документация моделей, тесты качества данных, lineage из коробки.
• Great Expectations — фреймворк для data quality checks в Python. Описываете ожидания («столбец revenue не содержит NULL», «значения > 0»), GE проверяет автоматически.
• Monte Carlo — observability-платформа: мониторинг качества данных, алерты при аномалиях, автоматический lineage.
• DataHub / Atlan — каталоги данных с поиском, документацией, lineage и управлением доступом.

Вопросы с собеседований

— Что такое Data Governance и зачем оно нужно? — Это система процессов и стандартов для управления данными: документация, качество, lineage, доступ. Нужно, чтобы данные были надёжными, понятными и безопасными. Без него — хаос: разные определения метрик, непонятные таблицы, дубликаты.

— Как бы вы организовали data quality checks? — Автоматические тесты на каждом этапе пайплайна: проверка на NULL, дубликаты, допустимые диапазоны, freshness (данные обновлены за последние N часов). Инструменты: dbt tests для SQL-моделей, Great Expectations для Python-пайплайнов, алерты в Slack при сбоях.

— Что такое data lineage и зачем оно? — Карта происхождения данных: от источника через трансформации до финального отчёта. Помогает при дебаге (где сломалось?), при изменениях (что затронет изменение таблицы X?) и при аудите (откуда эта цифра?).

— Что делать, если разные команды считают одну метрику по-разному? — Создать единый глоссарий метрик с чёткими определениями, формулами и источниками. Технически — одна «золотая» таблица или модель в dbt, которую используют все дашборды. Организационно — назначить владельца каждой ключевой метрики.

FAQ

Что такое Data Governance простыми словами?

Это правила и процессы, которые отвечают за порядок в данных компании. Как в библиотеке: есть каталог (что где лежит), есть правила (кто может брать какие книги), есть контроль качества (все книги на месте и не повреждены). Без этого — свалка, в которой никто ничего не находит.

Нужно ли аналитику разбираться в Data Governance?

Да. Аналитик — главный потребитель данных. Вы должны знать, где найти документацию таблиц, как проверить качество данных перед анализом и кому написать, если данные выглядят подозрительно. На собеседованиях это спрашивают всё чаще, особенно на Middle+ позиции.

Какие инструменты Data Governance самые популярные?

dbt — для документации и тестов SQL-моделей. Great Expectations — для проверки качества данных в Python. DataHub и Atlan — как каталоги данных. Monte Carlo — для мониторинга и алертов. Многие компании начинают с dbt tests + Confluence-документации, и это уже покрывает 80% потребностей.

---

Потренируйте вопросы по аналитике данных — откройте тренажёр. 1500+ вопросов для собеседования аналитика. Бесплатно.