Теория о данных.

Безопасность и управление данными — Ч.1

🔐 Безопасность данных

Безопасность — это не “чужая зона ответственности”, а часть профессии каждого, кто работает с данными.

Если ты проектируешь пайплайны, делаешь отчеты, настраиваешь интеграции— ты тоже отвечаешь за то, кто, как и когда имеет к ним доступ.

P.S. На практике, конечно, матрица ответственности в каждой компании своя:
где-то контроль доступов лежит на ИБ и DevOps, где-то — на владельцах доменов данных, где-то распределён между инженерами, администраторами и data stewards. Но независимо от формальных ролей, все, кто работает с данными, находятся на стыке технологий и ответственности: он первый, кто может предотвратить риск, и часто последний, кто видит его последствия.

Главные принципы:

1️⃣ Минимальные привилегии.
Дай ровно столько доступа, сколько нужно — и только на время задачи.
“На всякий случай” = источник инцидента.
Работа с суперпользовательскими ролями ради SELECT-запросов, создаёт не гибкость, а дыру.

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

3️⃣ Люди — главный риск.
Большинство утечек — не от взломов, а от человеческих ошибок: фишинг, общий доступ, халатность.
Первая линия обороны — культура безопасности, а не технологии.

4️⃣ Защита на всех этапах.
Данные нужно шифровать и при передаче, и при хранении.
Маскирование, токенизация, аудит действий и контроль видимости — стандарт, а не “доп. опция”.

5️⃣ Понимание IAM.
Любой специалист, работающий с данными, должен понимать роли, политики, пароли, сетевые права и ключи доступа. Без этого невозможно построить безопасную и масштабируемую экосистему данных.

📌 Суть проста: безопасность = доверие.
Если данные не защищены, вся аналитика теряет смысл.

🧭 Управление данными

Data Management — звучит корпоративно, но по сути это просто способ сделать данные понятными, надёжными и согласованными между командами.

Ключевые направления:

1️⃣ Data Governance (руководство данными)

Это не про документы, а про согласованность людей, процессов и технологий вокруг данных.
DG определяет, кто владеет данными, как они определяются, как контролируются доступы и как обеспечивается их качество. Когда DG нет — появляются “серые зоны”: дубли, противоречия, отчёты, которым никто не верит, и вечные “откуда эти цифры?”.

DG включает в себя роли (Data Owner, Data Steward), политики, контрольные процедуры и технические инструменты (каталоги, lineage, data contracts).

На практике же в крупных компаниях часто есть отдельно выделенная ставка под stewardship, к которому можно заходить по вопросам данных/их качеству/происхождению и тд.

2️⃣ Изучаемость (Data Discoverability) и подотчётность (Accountability)

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

Data Governance. Изучаемость достигается через data catalogs, документацию, lineage, и систему data stewardship, где за каждый домен отвечает конкретный человек.
Примеры дата каталогов - OpenMetaData/ dbt docs

3️⃣ Metadata Management — управление метаданными

Метаданные — это нервная система платформы.
Они обеспечивают прозрачность и повторное использование данных.

Они бывают четырёх типов:
*️⃣Бизнес-метаданные: определения, владельцы, правила, контекст.
*️⃣Технические: схемы, data lineage, ETL-логика, связи между объектами.
*️⃣Операционные: логи, job ID, SLA, статусы процессов.
*️⃣Справочные: коды, классификаторы, единицы измерения.

Хорошая Metadata Management System связывает инженеров и бизнес: автоматически собирает lineage, но сохраняет человеческий контекст.

Продолжение...

@data_driven_bogdan

Теория о данных.

Безопасность и управление данными — Ч.2

4️⃣ Data Quality Management — управление качеством данных
Качество — это не абстракция, а чёткий набор характеристик:

*️⃣Accuracy (точность),
*️⃣Completeness (полнота),
*️⃣Timeliness (своевременность).

Проверка качества должна быть частью пайплайна: тесты данных, SLA и мониторинг аномалий.
“Проверим потом” = потеря доверия к платформе

5️⃣ Master Data Management (MDM)

MDM отвечает за согласованность “основных сущностей”: клиентов, продуктов, контрагентов, филиалов.
Это система и процесс, создающие “золотые записи” (Golden Records) — единые определения для всей организации.

MDM устраняет расхождения между системами и делает возможным единый аналитический контур: CRM, DWH и отчёты работают с одними и теми же объектами.

MDM всегда завязан на бизнес — именно он определяет, что считается «основными данными». Например, для ритейла это может быть каталог товаров и магазинов, для банка — клиенты и счета, для логистики — маршруты и склады.

📌 Управление данными делает платформу предсказуемой.
Без него каждый отчёт — гадание на данных, где никто не уверен, откуда взялись цифры и можно ли им верить.

📚 Главные выводы

*️⃣Безопасность — часть инженерного мышления.
*️⃣Управление данными — способ сохранить смысл данных.
*️⃣Метаданные — память платформы.
*️⃣MDM — источник единой истины.

С этими практиками работа с данными становится системной, а не хаотичной.

📘 Пост основан на книге «Основы инженерии данных»
Разбираем первый два блока из схемы “Основные фоновые процессы жизненного цикла инженерии данных”.

А как в вашей компании устроены процессы безопасности, управление качеством и MDM❓👇

@data_driven_bogdan

Теория о данных

DataOps и архитектура данных — Ч. 2

🧩DataOps

Если DevOps ускорил выпуск кода, то DataOps делает то же для данных.
Он переносит принципы Agile, DevOps и Statistical Process Control (SPC) в работу с данными — чтобы информационные продукты создавались быстро, качественно и предсказуемо.

Ключевые принципы DataOps

1️⃣ Автоматизация

*️⃣CI/CD для данных, тесты пайплайнов, версионирование.
*️⃣Контроль зависимостей, блокировка «хрупких» изменений.
*️⃣Проверка качества, дрейфа данных, целостности метаданных.

Пример: раньше выгрузки крутились на локальном Cron/Планировщике — «в 03:00», пока включен ноут, независимо от того, готовы ли данные. После перевода в Airflow/Dagster запуск идёт через сенсор, который ждет обновления таблицы, те задачи стартуют по готовности данных, а не по времени, что убирает ложные запуски и снижает число инцидентов

2️⃣ Наблюдаемость и мониторинг (Data Observability)

Данные ломаются тихо, а ошибки могут жить и накапливаться месяцами.
DataOps ставит наблюдаемость в центр: логи, SLA, алерты, SPC, аномалии.
Подход DODD (Data Observability Driven Development) — наблюдаемость проектируется заранее, а не «когда всё упало».

3️⃣ Реакция на инциденты

Зрелая команда ловит проблему раньше бизнеса.
Автоматические уведомления, быстрый ретроанализ, прозрачная коммуникация.
Цель — сохранить доверие к платформе.

📌 Итог: DataOps = скорость + надёжность + предсказуемость.

🏗 Архитектура данных

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

Ключевые элементы архитектуры

1️⃣ Анализ компромиссов

Каждое решение — баланс между стоимостью, скоростью и поддержкой.
Например, модель Data Vault дает гибкость, но усложняет ETL;
Подход Kimball проще, но менее адаптивен к изменениям и хуже масштабируется при большом количестве СИ по одной сущности

2️⃣ Проектирование для гибкости

Архитектура должна «переживать» изменения бизнеса.
Помогают:
*️⃣многослойность (raw → stage → core → mart),
*️⃣контрактность (data contracts),
*️⃣слабая связанность доменов (DDD),
*️⃣модульность пайплайнов.

💡 Хорошая архитектура позволяет поменять источник без слома десятков отчётов.

3️⃣ Внедрение в бизнес (domain-driven data)

Архитектура отражает бизнес-домены: продажи, логистика, финансы.
Именно поэтому доменная архитектура (Data Mesh, DDD) сегодня так важна.
Она позволяет командам владеть своими данными как продуктом.

4️⃣ Эволюционность

Архитектура — живой организм:
— инструменты меняются,
— паттерны устаревают,
— домены растут.
Зрелая система допускает расширение без «удалить и переписать всё».

📌 Хорошая архитектура данных — это та, которую можно объяснить не только инженеру, но и бизнесу.

📚 Главные выводы

*️⃣ DataOps — это Agile для данных: автоматизация, наблюдаемость, реакция.
*️⃣ Архитектура — это скелет платформы: гибкость, масштабируемость и связь с бизнесом.
*️⃣ Вместе они делают экосистему данных живой и предсказуемой.

📘 Пост основан на книге «Основы инженерии данных».

👉 В следующей части — Оркестрация и программная инженерия: как пайплайны оживают и почему код остаётся сердцем всей data-системы.

🙌 Подпишись и при желании поддержи канал бустом.
P.S. Сделать это можно здесь (для tg premium — бесплатно).

@data_driven_bogdan

Теория о данных

Оркестрация и программная инженерия — Ч. 3

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

⚙️ Оркестрация

Оркестрация — это способ управлять потоком работ: определять порядок выполнения, зависимости, условия, расписание и поведение системы при сбоях. Проще: она отвечает на вопрос «когда и что должно произойти, чтобы данные дошли до бизнеса вовремя».

Чтобы понять, как это работает, нужно объяснить базовый элемент — DAG (Directed Acyclic Graph).
Это просто граф из задач, связанных зависимостями: что должно выполниться до чего.
DAG описывает логику работы пайплайна так, чтобы система могла его корректно и предсказуемо исполнять.

Что делает оркестратор:
*️⃣ запускает задачи в нужном порядке по зависимостям DAG;
*️⃣отслеживает их статус (успех/ошибка/ожидание);
*️⃣реагирует на внешние условия (например, появление данных в хранилище);
*️⃣поднимает тревогу, если пайплайн выбивается из SLA;
*️⃣даёт историю выполнения и визуализацию.

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

Сейчас наиболее распространены Airflow, Prefect, Dagster и Argo.
Инструменты разные, задача одна — превратить хаотичный набор скриптов в управляемую систему.

💻 Программная инженерия

Вот тут важно объяснить что это вообще такое в контексте данных.
В книге программная инженерия поднимается как фундаментальная дисциплина, которая отвечает за создание надёжного, поддерживаемого и воспроизводимого кода — независимо от того, Spark это, SQL, Beam, Python или real-time логика.

Про что программная инженерия в данных:

1️⃣ Про сам код обработки данных
Даже если инструменты стали абстрактными — DataFrame API, SQL-движки в облачных DWH — код писать всё равно нужно. Логика преобразований, бизнес-правила, расчёты, агрегации — это всё инженерная работа.

2️⃣Про качество и надёжность
Пайплайны чаще ломаются не из-за «плохих данных», а из-за кода. Задача инженера — писать предсказуемый, тестируемый код.

3️⃣ Про управление сложностью
Чем больше данных и процессов — тем важнее архитектура кода: модули, структуры, слои трансформаций, единые правила именования, обработка ошибок.
Это не про «программистские практики ради практик»: только так пайплайны можно поддерживать годами.

4️⃣ Про взаимодействие с инструментами
Инженер работает не только с кодом, но и с фреймворками: Spark, Beam, Flink, функции в облаках, API-коннекторы. Всё это требует понимания, как устроена обработка под капотом: распределение, партиции, память, сериализация.

5️⃣ Про инфраструктуру
Сегодня инфраструктура — тоже код: Terraform, Helm, Kubernetes.
IaC (Infrastructure as Code) — это когда конфигурации описываются в файлах, а не вручную.
Так система становится воспроизводимой и не зависит от «настроек на сервере, которые никто не помнит».

В итоге программная инженерия — это не «уметь писать на SQL и Python».
Это способность создавать устойчивый процесс обработки данных, который работает предсказуемо под нагрузкой, в потоке и в долгой эксплуатации.

📚 Главные выводы

*️⃣Оркестрация — делает пайплайны управляемыми: порядок, зависимости, SLA, ошибки.
*️⃣Программная инженерия — делает пайплайны надёжными: код, качество, предсказуемость и инфраструктура.
*️⃣Вместе они превращают хаос скриптов в стабильную платформу данных.

📘 Пост основан на книге «Основы инженерии данных».

Как отметил в начале, это финальный пост по жизненному циклу на уровне концепций — дальше будем разбирать его глубже уже через DAMA-DMBOK, где эти процессы разложены куда детальнее.

🙌 Подпишись и при желании поддержи канал бустом.
P.S. Сделать это можно здесь (для Premium — бесплатно).

@data_driven_bogdan

🤨SQL-практика: сколько строк вернет JOIN?

Возвращаемся к практическим задачам - а то мы с вами последнее время залипли в теорию. И начнем с темы, которая встречается почти на каждом собесе - поведение JOIN-ов.

Смотрим, что происходит со строками в разных типах соединений.
Представим две таблицы по ключу id:

t1 — 10 строк
t2 — 10 строк

И дальше важный момент: итог зависит не от того, «сколько строк в таблицах», а от того, как распределены значения ключей внутри таблиц. Поэтому min/max у каждого JOIN-а - это про математику, но на радость - 2го класса😁

1️⃣ INNER JOIN

Минимум — 0 строк.
Если пересечений нет, результат пустой.

Максимум — 100 строк.
Если каждая строка в t1 соединяется с каждой строкой в t2 (кейс «все id одинаковые»).

2️⃣ LEFT JOIN

Минимум — 10 строк.
Даже если совпадений нет, все строки левой таблицы остаются.

Максимум — 100 строк.
Та же логика перемножения при одном повторяющемся значении в 2х таблицах.

3️⃣ RIGHT JOIN

Аналогично LEFT, только «базовая» таблица — правая.

Минимум — 10 строк
Максимум — 100 строк

4️⃣ FULL JOIN

Вот здесь часто допускают ошибку...

Минимум — 10 строк.
Минимальное количество — это объём большей таблицы.
Если обе по 10, минимум тоже 10.

Максимум — 100 строк.
Как уже разбирали выше - в случае полного совпадения всех id.

5️⃣ CROSS JOIN

Всегда одно и то же:
100 строк — и min, и max.
Это декартово произведение без условий.

🤨Что происходит с дублями?

Если в t1 три строки с id=1, а в t2 четыре строки с id=1, то на выходе:

3 × 4 = 12 строк

JOIN умножает, если ключ не уникален.
Это главный источник "роста" выборки.

🤔 А что с NULL?

Ещё одна любимая ловушка на собесах:

NULL = NULL → FALSE
NULL != NULL → FALSE

То есть строки с NULL не соединяются друг с другом ни при каком обычном JOIN-е.

INNER JOIN → NULL-ы полностью выпадут
LEFT JOIN → останутся с правой частью NULL
RIGHT JOIN → наоборот, справа
FULL JOIN → попадут как несвязанные строки для каждой из сторон

Это нужно держать в голове, особенно когда строишь витрины с суррогатными ключами.

🧠 Итоговая памятка по JOIN-ам (t1 = 10 строк, t2 = 10 строк)

*️⃣INNER JOIN
min — 0
max — 100

*️⃣LEFT JOIN
min — 10
max — 100

*️⃣RIGHT JOIN
min — 10
max — 100

*️⃣FULL JOIN
min — 10
max — 100

*️⃣CROSS JOIN
min — 100
max — 100

💬 А какие нетривиальные задачи по JOIN-ам попадались вам на собесах? Пишите — будет полезно для всех.

🙌 Подпишись и при желании поддержи канал бустом.
P.S. Сделать это можно здесь (для Premium — бесплатно).

@data_driven_bogdan

Прочитай это перед тем, как идти работать аналитиком в ритейл 🛒📊

Допустим, ты уже разобрал харды - SQL, Питон и, собираешься на собес в крупный ритейл/FMCG: Магнит, X5, Ленту, ВкусВилл и т.д. Чтобы пройти финал с командой, важно понимать не только инструменты, но и какими метриками живет офлайн-ритейл.

Работая аналитиком в большом федеральном ритейле (🧲), я заметил простую штуку: как только ты понимаешь метрики, работа перестает быть механическим подсчётом и превращается в разбор причин и последствий. Понимание метрик ускоряет решение любых задач и позволяет видеть причины, а не просто считать цифры.

🔥 ТОП 10 основных метрик в ритейле / FMCG

1️⃣GMV / RTO (Gross Merchandise Value / Выручка)

Общая сумма продаж за период.
Используется для анализа динамики, план-факт, сезонности, можно разбить по форматам, регионам и тд.

2️⃣Margin

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

3️⃣Back Margin (Бэк-маржа)

Это не наценка от продажи, а дополнительный доход от поставщиков: ретробонусы, бонусы за выполнение объема, маркетинговые выплаты, премии за продвижение SKU и т.п.

4️⃣Количество проданных штук (QNT)

Фактическая штуковая продажа конкретного SKU или целой товарной группы.

5️⃣Количество чеков (Traffic)

Это базовая метрика потока: сколько покупок (чеков) совершили за период.

Используется для анализа:
*️⃣эффективности акций (даёт ли промо рост трафика);
*️⃣изменение поведения покупателей (день недели / часы пиков);
*️⃣сравнения форматов (в формате X трафик выше, в Y ниже);
*️⃣операционки (планирование персонала, касс, выкладки).

Рост чеков ≠ рост выручки → важно держать связку чеков с AOV.

6️⃣ Количество клиентов (QNT client)

Показывает, сколько покупателей совершили покупку за период.

Это важная метрика для:
— лояльности (сколько покупателей возвращается);
— клиентских сегментаций (RFM, CVM и тд);
— частоты (frequency) — напрямую рассчитывается через клиентов;
— оценки удержания (retention на период);
— эффекта промо на клиентскую базу (привели новых или крутили старых).

В офлайне корректно считать клиентов можно только по лояльным (кто показал карту при оплате).

7️⃣ Количество магазинов

Если чеков и клиентов много — нужно понимать, сколько точек генерируют этот поток.

Используется для:
— LFL (like-for-like) — фильтрация только тех магазинов, которые работали в оба периода
(Период X и X-n, где n время до);
— оценки эффективности форматов;
— распределения инвестиций и промо-бюджетов;
— оценки потенциала регионов.

Также помогает отделять структурные эффекты (рост за счет открытия новых точек) от поведенческих (рост среднего чека, частоты и т.д.).

8️⃣Frequency

Частота покупок (посещений). Рассчитывается отношением количества чеков к числу клиентов за период. Показывает удержание и глубину лояльности.

9️⃣ARPPU (Average Revenue per Paying User)

Средняя выручка на "покупающего" клиента.
В офлайн ритейле под “покупающим клиентом” обычно понимают лояльного клиента (с картой) — тех, кого можно идентифицировать. Рассчитывается отношением GMV на одного лояльного клиента. Метрика активно используется в loyalty-аналитике.

1️⃣0️⃣ AOV (Average Order Value / Средний чек)

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

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

💬С какой метрикой у вас были реальные проблемы в задачах или на собесах? Давайте обменяемся опытом. Напишите в комментариях👇

Подпишись и при желании поддержи канал бустом.
P.S. Сделать это можно здесь (для Premium — бесплатно).

@data_driven_bogdan