Канал про данные как инженерную дисциплину.

Архитектура, модели данных и мышление — из практики.

Реальные кейсы, принципы, ошибки и выводы из них.

🔵Бизнес-модель данных: технические и бизнес-сущности

🔵Изменения: предвидеть или сделать неважными

🔵Airflow как оркестратор, а не буфер данных

🔵Роли инструментов важнее самих инструментов

База

Я считаю, что изучение хард скилов ради изучения - трата времени. Хотя возможно это мое оправдание ленивое субъективное мнение. Я обычно двигался от проблем: есть проблема - изучаю решение. Однако я думаю, что нужна некая база. Попробую порассуждать что же такое эта база.

1️⃣Роли инструментов важнее самих инструментов
Инструментов в дата инжиниринге, да и вообще инжиниринге, создано очень и очень много. Знать все просто невозможно. Лучше знать какие проблемы они решают, то есть понимать место инструментов в архитектуре решения. Например, Apache Airflow - это оркестратор и знание зачем нужен оркестратор и какова его роль важнее самого инструмента или другой пример: брокер сообщений - это база, а apache kafka - инструмент. База данных тоже имеет свою роль, а postgresql, mysql, clickhouse - только инструменты.

2️⃣Архитектурные принципы важнее языков программирования
На меня очень повлияло когда-то изучение принципов SOLID и чистой архитектуры Роберта Мартина. Язык программирования - это деталь реализации. Тем более при растущей эффективности AI.

3️⃣ Проблемы бизнеса важнее приложения/системы
Как работает бизнес лучше спрашивать у бизнеса, а не у разработчиков приложения. Любое приложение - это инструмент, автоматизация, надстройка над бизнесом, которую сделали какие-то разработчики, принимая какие-то технические решения - интерпретация бизнеса. Пользуйтесь первоисточником информации. Лучше изучить бизнес процесс, чем базу данных приложения. Первоисточник важнее интерпретации.

📄 Получилось в стиле agile манифеста
Принципы написаны по формуле важно/важнее, это значит что правая часть утверждений тоже очень важна, но левая важнее.

Автоматизация и интеграция

⭐️ Делаем свои потоки данных удобными для контроля, развития, изменения.

Сегодня немного порассуждаю о разделении автоматизаций и интеграций.

Если коротко, то автоматизация - это про бизнес логику, а интеграция это про технику. Одна интеграция может использоваться в нескольких автоматизациях и наоборот - одна автоматизация дергать несколько интеграций.
Я заметил что дата инженеры и даже software инженеры склонны смешивать эти понятия как у себя в голове, так и в реализации. Хотя по-моему это разные вещи и стоит их чётко разлелять.
Предположим если вы реализуете задачу типа передай данные во внешний сервис, когда мы закрыли продажу (конверсия). Слово "когда" здесь чёткая граница. То что до - интеграция, а остальное автоматизация.

Разделять это нужно из-за разных причин для изменения (привет принцип S - single responsibility в SOLID). Бизнес логика может меняться так как это угодно бизнесу: правила будут добавляться и изменяться. А вот интеграция изменится только если изменится контракт (api интерфейс например).

На практике нужен отдельный сервис, который может быть отдельным микросервисом, например с HTTP API, или частью приложения, например отдельный класс на python с каким-то методами.

Если продолжить пример выше, то можно создать класс, предоставляющий интерфейс с методом upload_conversion - это и есть интеграция. А в оркестраторе (например в популярном Airflow) создать DAG, один или несколько, которые будут дергать интерфейс (метод класса) столько раз и в тех местах как нужно - это автоматизация.

#датаинженер

Про Jupyter Notebook. Нужен дата инженеру?

В работе с данными много разных инструментов, которые где-то помогают, а где-то мешают. Каждому инструменту свое место и время.

Сейчас я бы хотел поделиться своим мнением о пайтон блокнотах. Это удобный интерфейс для работы с пайтон скриптами. Можно запускать код частями, перезапускать отдельные части, выводить результаты и тд. Есть разные способы работы с ними: jupyter, vscode, google colab и другие. Вы найдёте множество хвалебных отзывов этому инструменту в сети, а я хотел бы поговорить о том, когда его использование вредно.

Можно выделить 3 применения блокнотов: анализ данных, разработка потока данных (инжиниринг), обучение.

📎 Анализ данных
Здесь все ок. Это именно то, почему блокноты популярны. Если бы я делал классификацию инструментов для работы с данными, то поставил бы пайтон блокноты в один ряд с инструментами анализа и визуализации такими как Power BI или Tableau. Смысл ведь тот же. Да и порядок работы тоже: подключился к источнику, взял данные, объединил, трансформировал, сделал отчет с графиками и таблицами.
Вывод - использовать ✔️

📎 Разработка и инжиниринг
Вот тут обратная сторона популярности. Аналитики или инженеры начинают писать в блокноте логику потока данных (ETL процесса), получают какой-то скрипт и запускают его периодически, чтобы получить данные в каком-то целевом месте назначения (база данных ил файл). Проблема в том что скрипт - это такой монолит кода, который работает только здесь и сейчас. Любое его изменение дорого и рискованно. Когда скриптов много, даже у одного аналитика, неизбежно будет дублирование кода и логики. Изменение одного правила требует пересмотра множества скриптов, при этом в каждом из них еще несколько мест, которые тоже надо поправить, все эти места нужно найти и не забыть. По этой причине на практике, когда используют скрипты, они становятся личными - конкретный аналитик его написал и вроде понимает, как и что и может что-то поменять пока помнит, другой аналитик даже не лезет туда. И даже если вроде удалось внести изменения можно ли гарантировать, что результат скрипта соответствует требованиям и изменение правила для колонки А не повлияло на качество данных в колонке Б? Нельзя. Логика не изолирована. Соответственно за этим следует полная проверка качества (QA).
Обманчивая простота ведет к огромным затратам на поддержку.
Еще один поинт сюда: согласитесь будет странно, удивительно и даже смешно, если бэкенд разработчик вдруг возьмет пайтон блокнот и напишет в нем REST API для приложения. Кажется очевидным, что так делать никто не будет. Так почему тогда разработчик ETL должен наступить на эти грабли?
Вывод - не использовать ❌

📎 Обучение или черновик
Блокноты удобны для обучения, так как можно легко запускать или перезапускать отдельные части кода, или как черновик, когда разработчик не уверен в том, что делает и хочет видеть результат каждого блока кода. Но это формирует вредную привычку. Я рекомендую для инженерных задач сразу отказаться от блокнотов и использовать инструмент для дебага с точками останова (есть в каждой IDE, например в Pycharm), которые позволяют увидеть состояние в некоторой точке процесса.
Вывод - можно, но не рекомендую ❗️

Пайтон блокноты полезны, если правильно использовать.
Для анализа данных? Берем!
Для инжиниринга? Спасибо, не надо.

#датаинженер

Airflow только оркестратор

Airflow очень популярный инструмент для управления ETL процессами. Я буду часто упоминать его, потому что он достаточно прост для начала работы и достаточно интересен для построения правильных потоков данных. Сегодня я хотел бы немного поговорить о его роли.

Airflow - это оркестратор. И нужно следить за тем, чтобы он оставался только оркестратором и не залазил на территорию других участников.

📄 Функция оркестратора запускать операции в заданной последовательности по расписанию.

И эта последовательность в Airflow называется DAG (Directed Acyclic Graph).

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

Если все сделано правильно можно:
🔸 Запустить логику без запуска airflow
🔸Переиспользовать эти независимые функции в других процессах (дагах)
🔸Написать тесты для логики
🔸Независимо менять логику отдельных частей процесса

И все это еще и укладывается в solid принципы как я люблю ☝️

Падает процесс, не хватает ресурсов. Давай увеличим ресурсы!

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

📝 Обычно это примерно такой кейс: в etl происходит несколько запросов к каким-то базам, которые вытаскивают данные за сутки, потом это все объединяется, есть какая-то логика для фильтрации и агрегации и затем это все должно быть загружено в целевую базу. И тут два варианта: 1) на каком-то из этапов данные не влазят в память (например, воркера в airflow/виртуальной машины/вашего личного пк) и таким образом разработчик приходит к выводу, что надо увеличить ресурсы. 2) запрашиваемые данные не влазят в память источника и тут разработчик думает, что надо увеличить ресурсы там.

💔 Во-первых это подмена проблемы решением (есть такая ошибка в решении проблем). Проблема здесь: количество ресурсов для выполнения превышает доступное количество ресурсов. Такая постановка проблемы заставляет подумать не только о том, что ресурсов мало, а ещё и о том что потребление ресурсов большое.

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

1️⃣ Почему выбран для одновременной обработки именно тот период, который выбран? Есть ли причина на то, что данные должны быть обработаны одновременно?

Обычно тут выясняется что период (например сутки) выбран, потому что заказчик хочет смотреть свежие данные раз в сутки. Но это совсем не значит, что и обрабатывать весь объем мы должны одним махом раз в сутки. Это требование, которое ограничивает решение только с одной стороны. Больше нельзя, меньше можно.

Самое простое тут разбить обработку по периодом, то есть просто настроить расписание оркестратора на выполнение процесса чаще, например раз в час или два.

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

2️⃣ Есть ли в данных колонка/ключ/дименшн, который позволит сделать срезы и выделить независимые данные? Например это может быть project, store, product, tenant, type, region и тд.

Это снова про уменьшение совместно обрабатываемого объема данных. Вы уже догадались: разделяем весь объем на несколько срезов и обрабатываем отдельно.

3️⃣ Для обработки ресурсов хватает, а вот источник не может вернуть данные, потому что у него ответ не влазит в память или он ушел в таймаут?

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

4️⃣ Простые решения не подходят?

Тогда уже стоит подумать об увеличении ресурсов.

А если увеличивать некуда/слишком дорого? Подумать о применении big data инструментов для распределенной обработки или real time процессах. Тут важно именно хорошо подумать, потому что это резко усложняет ваш стек и инфраструктуру. Не стоит внедрять новые инструменты без веской причины.

©️Вообще обычно такие проблемы решаются по п 1 или п 2, иногда по п 3.

Неточные данные! Смотреть нельзя!

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

Перфекционистам дальше не читать 😁

Мне вспомнилась шутка про часы:

- Какие часы лучше: те что стоят или те что отстают?
- Те что стоят, так как показывают точное время два раза в сутки.

Я думаю, что все сводится к тому что считать "точными" данными. Здесь я немного порассуждаю.
Данные лишь отражают реальный мир. В той степени, которая нам нужна для принятия решений. При этом данные собираются какими-то способом: может руками, а может техническими устройствами (в широком смысле). Любой способ имеет свою точность или погрешность. Способов со 100% точностью просто не существует. Лучший в мире датчик давления, который, например, поставят на ракету для отправки в космос будет иметь точность 0,999999. При этом чем точнее способ, тем он дороже. Любые IT системы, на данные которых мы смотрим, тоже имеют некоторую гарантированную точность, имеют контракт. Потери данных, искажения данных возможны всегда.

Такие рассуждения подводят к выводу, что мы всегда работаем с некоторой неточностью, которая нас устраивает. Это значит что точность не должна быть максимальной, она должна быть необходимой и достаточной. Точность - это бизнес требование к системе. Я пишу системе, потому что невозможно от DWH требовать точность выше, чем она есть у источника данных. Система может обеспечить точность, которую обеспечит "худший" участник. Когда мы работаем с данными мы стремимся не ухудшать уже имеющуюся точность, но к сожалению иногда приходится делать допущения при обработке данных или добавлять сложную логику обработки, увеличивая риск ошибки...

Вернемся к изначальному вопросу.
Нужно для начала определить требуемую точность для бизнеса, зафиксировать требование, затем измерить точность, которую вы даете и измерять ее периодически - мониторить (уф, это тема достойна отдельного длинного поста). После этого ответ на вопрос "можно ли показывать неточные данные" очень прост:
В пределах требований? Все ок, показываем.
Нарушает требование - инцидент и на этот случай тоже должна быть договоренность с бизнесом - SLA.

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

🕒 Продолжая шутку с часами.
Если заиграться в перфекционизм, то получите часы, которые показывает точное время два раза в сутки. Лучше дайте мне часы которые постоянно показывают "неправильное" время, но с отклонением не более 10 минут, тогда придя на встречу я либо успею попить кофе, либо извинюсь за опоздание, либо приду на 20 минут раньше, если встреча важная. То есть смогу принять решение. 👌