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

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

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

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

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

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

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

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

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

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

Кейс с TEMP TABLE

Кейс скорее про разовую ручную проверку данных, чем про потоки данных.

📄 Предположим у нас есть какой-то процесс, который должен делать записи в базе данных при наступлении каких-то условий. Это может быть бизнес логика или реакция на события другого приложения или интеграция. Каждая такая запись имеет в данных идентификатор связанной сущности, а сущность эта вообще в другой базе (или вообще у партнера). У нас есть список идентификаторов сущностей, по которым должны быть записи, и вот мы хотим узнать для каких именно сущностей НЕ была создана запись.

©️Вот конкретный кейс: приложение отправляет событие в event stream (например kafka), когда создается sale. К event stream подключен Clickhouse как Event storage, который читает и сохраняет события. Мы знаем, что по какой-то причине не была отправлена часть событий (мониторинг есть). У нас есть список sale id (например 2-5К), и мы хотим узнать по каким именно из них не были отправлены события, то есть получить список идентификаторов.

💬 Звучит просто на первый взгляд. Нам нужно сравнить два списка: список сущностей, со списком событий. Но сложность в том, что списка сущностей нет в базе. Тут может прийти мысль написать скрипт на пайтон и сравнить списки, но мы сделаем проще и быстрее - используем Temp table.

Temp table - существует в рамках сессии и автоматически удаляется при завершении сессии.

Создаем пустую табличку (синтаксис clickhouse, в postgresql тоже самое только вместо TEMPORARY используется TEMP)

CREATE TEMPORARY TABLE IF NOT EXISTS sales (
    sale_id int
)

Вставляем значения из предварительно подготовленной переменной. Так как это разовая задача создаем переменную ручками из списка сущностей приведя к виду (1), (2), (3).

INSERT INTO sales VALUES :sales

Проверим. Должен быть весь ваш список

SELECT * FROM sales

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

SELECT *
FROM sales
WHERE sale_id not in (
  SELECT sale_id
  FROM events
  WHERE type = 'some/event/type'
)

✔️ Так мы быстро получили список идентификаторов сущностей, который можно передать разработчикам для поиска багов.

©️TEMP TABLE удобная штука, если нужно быстро что-то исследовать не делая выгрузки, трансферы, дополнительные скрипты.

Псевдокод - прием инженера.

🔍 Дата инженеры много работают с кодом. В этом посте я хочу поделиться простым лайф хаком, который мне не раз сохранил нервы и время.

Попроси джуна и он сразу пойдет писать код, попроси сеньора и он сначала продумает решение от начала до конца (может для нескольких вариантов) и только потом напишет код.

💬 А продумывать помогает очень простой и удобный прием - псевдокод.

Псевдокод - описание простым человеческим языком конкретных шагов и действий, которые должны быть выполнены, чтобы мы получили желаемое поведение кода (метода, sql запроса). По сути мы отбрасываем синтаксис языка программирования и пишем с синтаксисом естественного языка 😉

❗️Не путать с докстринг (docstrings). Докситринг для клиентов метода/класса - описание как использовать метод и для чего он нужен. А псевдокод для разработчиков - отражает конкретные действия в коде, то есть то как именно выполняется задача.

Вот пример псевдокода в методе класса на пайтоне. Хотя можно использовать везде и в sql запросах тоже.

   def set_lead_id(self, *, crm_uri, calls_storage_uri):
        """
        Performs actions to enrich calls data by lead_id and project_key
        """
        # pseudocode
        # Option 1:
        # group calls in the same time range 
        # (half an hour) in order to reduce count of requests to crm
        # reduce calls by caller number
        # execute as many requests to crm as groups passing time range and phone. get lead_id, project.
        # assign lead_id and project to every call in the initial calls list matching by phone. 
        # The assumption: all calls with the same phone number within a half an hour will have the same lead_id
        # Option 2:
        # get calls without lead within time range
        # prepare request for every call with time range as call datetime +/- 2 minutes
        # combine requests with UNION clause
        # execute combined request to crm. get lead_id, project.
        # push data to calls table

        # Use option 2
        # дальше пишем код, используя вариант 2

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

Псевдокод позволяет:
🔸продумать цепочку действий от начала до конца не отвлекаясь на синтаксис языка
🔸увидеть логические противоречия до того как вы уже написали половину кода.
🔸увидеть допущения и спорные моменты, которые были не очевидны
🔸увидеть плюсы и минусы разных вариантов, оценить их потенциальное быстродейтсвие, выбрать лучший
🔸делегировать написание самого кода кому-то (так еще не пробовал, но идея хорошая. Сюда же входит использование AI. А что? Чем псевдокод не промпт для chat gpt? 🤔)

📎 Псевдокод имеет еще один очень приятный и важный бонус. После завершения работы сохраните его - это же готовая документация к методу! Показывает как он работает и какие были рассмотрены варианты. Вы сами или кто-то другой сможете легко разобраться в коде, когда откроете код через несколько месяцев.

Так и получилось в моем недавнем кейсе. Метод стал медленно работать. Я прочитал псевдокод, понял работу метода, понял в каком месте есть потенциальная проблема, затем внес изменения сначала в псевдокод, убедился что логически это будет работать, затем легко нашел нужное место в коде и быстро внес изменения. Готово! 5 минут потратил, закрыл и забыл еще на месяц, на полгода или больше, пока логика снова не поменяется. 🙌

‼️И еще помните! Комментарий, который не соответствует коду хуже, чем отсутствующий комментарий.

“Правильность” данных

Осторожно! Душный пост! 🧐

Я заметил, что в общении с коллегами часто использую словосочетание - консистентность данных. Обычно все это понимают как некая “правильность” данных и в общем-то так и есть, но нам как инженерам, ответственным за эту правильность, стоит задуматься над тем что это такое. ☝️

Можно найти по этой теме с десяток понятий в разных публикациях типа consistency, integrity, quality, correctness, validity и тд. Определения этих понятий смешаны: где-то используются как синонимы, где-то имеют отдельные смыслы. И я вряд ли могу внести тут полную ясность, но свое мнение в общую массу мнений закину 😁

Я бы выделил как минимум согласованность (consistency) и целостность (integrity).

📝 Согласованность - состояние, при котором все копии данных одинаковы во всех связанных приложениях, базах данных и тд. (сайт IBM).
Для дата инженера это значит, что данные в хранилище (DWH или Data mart) или в отчёте не должны противоречить источникам данных.

🔖 Организовывая трансфер данных и выполняя трансформации, дата инженер должен быть аккуратен и безпристрастен. Есть риск увлечься! Нельзя допустить вольных изменений для красоты или для соответствия чьим-то личным ожиданиям и тд. Все операции в коде должны быть подкреплены бизнес логикой или логикой трансформации, то есть по каждой строчке можно обоснованно ответить на вопрос “почему так?”

Достаточно абстрактная штука и
даже не знаю как это контролировать и гарантировать. На ум приходит только внимательность дата инженера и проверка старшими товарищами.

📝 Целостность - состояние, при котором данные записаны именно в том виде, в котором было задумано. (В википедии неплохо написано). Такое определение очень широкое. С точки зрения дата инженера то, как “задумано” - это модель данных. То есть данные целостносты, когда они соответствуют модели данных (пост данные без модели - деньги на ветер).

🔖 Тут у меня хорошие новости. 😋 Соответствие модели можно и нужно гарантировать технически! Модель можно превратить в набор правил/требований к сущностям, к их свойствам, их типам, обязательности, наличии связей между сущностями и тд.

🤔 Подумаем про контроль. С архитектурный точки зрения должен быть некий “участник”, который возьмёт на себя эту функцию и ответственность гарантировать соответствие модели или целостность. Это может быть приложение, сервис, микросервис, непосредственно база данных, какой-то подключаемый инструмент и тд. Тут главное сделать так, чтобы был только один ответственный - одно место в архитектуре, которое держит необходимую для этого логику.

©️Держа в уме согласованность с источниками и технически гарантируя соответствие данных модели, вы предоставите бизнесу достаточно “правильные” данные. 🙌 Хотя это конечно не все...

Кайфанул от PostgreSQL Extensions

Я - сижу и читаю что-то в телефоне с довольным видом и издаю звуки удивления или восхищения.
Жена - Что читаешь?
Я - про PostgreSQL extensions. 😁

Тут я ловлю себя на мысли, что реально кайфанул от возможностей, которые дают расширения 😄

Читал я вот эту статью. В начале автор пишет:

Расширения PostgreSQL - это лучшая часть PostgreSQL. Они добавляют функционал в вашу базу данных, изменяя и улучшая выполнение процессов.

Дальше в статье перечислены некоторые расширения с примерами. Мне особенно понравились вот эти
🔸 pg_stat_statements - отслеживает статистику запросов выполняемых базой данных. Дает детальную информацию о плане выполнения. Поможет дебажить запросы, выявлять медленные запросы.
🔸 pg_partman - помогает управлять партициями. Пожалуй самое известное расширение.
🔸 postgres_fdw - позволяет настроить прокси подключение к другой PostgreSQL базе и запрашивать данные из нее так как будто эти данные лежат тут же в обычной таблице.

©️Я со своей командой сейчас активно строим DWH на PostgreSQL и мы обязательно попробуем эти и другие расширения.👍

600К баксов в год дата инженеру

Сегодня попалось видео с коротким интервью Zach Wilson.
Этот парень считается крутым дата профессионалом в сообществе. Впервые я увидел его контент на LinkedIn. Если на LinkedIn начать интересоваться постами о дата инжиниринге, то 100 пудов наткнешься на его профиль.

В этом видео меня зацепили пара моментов. И я решил с вами поделиться.

1️⃣ Во первых конечно - 600К в год! Это он получал, работая в Airbnb (ушёл оттуда год назад и создал свой продукт). Меня впечатлило само число‼️(для особо дотошных после уплаты налогов это примерно 450К. я загуглил 😉) Я конечно знал что могут платить много, но я думал ну 250К ребята в США получают, а тут вот. При этом он сказал что это норма, что его коллеги получали не меньше.

2️⃣ Второе - это его мнение про базовые знания дата инженера. Тут конечно нужно учитывать, что интервью было короткое и ответ был тоже короткий, но тем не менее он назвал вот что:
🔸языки - SQL, Python (scala, rust полезно, но не те как первые два)
🔸оркестрация - Airflow и добавил что в общем-то оркестрация в целом.
🔸 Spark - по его мнению он станет ещё более популярным чем сейчас
🔸Моделирование данных. Тут он сказал, что даже некоторые ребята, которые получают 500К, делают это хреново 😄

Заметьте тут нет упоминаний модных сейчас слов типа lakehouse, apache iceberg или snowflake или hive, hadoop и тд. Наверняка все это важно, но менее важно, чем пункты выше. В этом смысле мое мнение близко к его. Разве что, пожалуй, Spark в этом коротком списке я не ожидал увидеть. Отмечу ещё, что чуть позже в другом контексте он упоминал Data Mesh и Master Data Management. Возьмем на заметку ☝️

©️Так что ребята нам ещё есть ого-го куда расти 📈 💲
❓Что думаете про его мнение о базовых знаниях?

Лучший ETL тот, которого нет

Такой “идеальный” ETL процесс можно получить используя postgres_fdw - расширение PostgreSQL (пост).

postgres_fdw - позволяет настроить подключение к другой postgresql базе и обращаться к таблицам в ней, так как будто они лежат в вашей базе.

При этом:
1️⃣ Данные не копируются. Когда пользователь выполняет запрос, та часть запроса, которая относится к внешним таблицам, “пробрасывается” в другую базу. Можно так работать как с DQL (select) так и с DML (insert, update, delete)
2️⃣Можно выбрать таблицы, к которым подключаться.
3️⃣Настройка расширения необходима только на стороне запрашивающей базы данных. Для базы данных-источника все выглядит как обычные запросы, она и не знает что вы какое-то хитрое соединение настроили.
4️⃣Множество баз может быть подключено к одной основной базе.

При использовании fwd (foreign data wrapper) создаются внешние таблицы (foreign table). Такие таблицы отлично заменяют ETL процесс или трансфер данных, в котором нет трансформации (как бы EL процесс без T - трансформации) 😉. Другими словами, когда вы извлекаете данные откуда-то и загружаете куда-то “как есть”, можно просто использовать внешние таблицы с postgres_fdw и получить плюшки:
✔️ Гарантия согласованности (пост). Никакого физического процесса перекладывания данных нет, все успешно завершенные операции с данными в базе-источнике тут же доступны через базу, которая подключена через внешние таблицы. Это даже круче чем real-time.
✔️ Все обработки, трансформации, вычисляемые колонки (measures, metrics) и другие манипуляции с данными выполняются в одном месте - в основной базе, которая является источником для других.
✔️ Отсутствие лишнего ETL процесса, который нужно поддерживать, который потребляет ресурсы и тд.
✔️ Нет необходимости в бэкфиле данных в случае изменений в основной базе источнике

Есть и минусы конечно.🫣
🔵Вся вычислительная нагрузка ложится на основную базу. Если это проблема, можно рассмотреть репликацию. Мы пока что наблюдаем.
🔵Данные каждый раз проходят по сети между базами. Это не проблема, если базы у вас в одном месте (например в одном кубернетес кластере или в одном регионе AWS и тд). В других случаях есть риск недоступности из-за проблем с сетью, но это в общем-то касается любых способов как ETL, так и репликации.

Сама техническая реализация супер простая.

-- устанавливаем расширение
CREATE EXTENSION postgres_fdw;


-- создаем подключение к базе-источнику.
-- Этот шаг выполняется только один раз и в дальнейшем
-- может использоваться для добавления таблиц
CREATE SERVER dwh
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (dbname 'dwh', host 'your-host.rds.amazonaws.com', port '5432');


-- ваша база ходит к базе источнику с запросами и поэтому ей нужны креды
-- можно настроить для каждого пользователя индивидуально (для роли кстати нельзя)
-- или указать PUBLIC - все пользователи вашей базы будут обращаться ко внешним таблицам используя указанные креды
CREATE USER MAPPING FOR PUBLIC
 SERVER dwh
 OPTIONS (user 'data_mart', password '');
-- ВАЖНО! Создайте юзера с read only правами, чтобы избежать неожиданностей, когда кто-то сделает вам Insert, Update, Delete в вашей основной базе


-- создаем внешние таблицы, выбирая какие именно таблицы хотим из внешней базы и куда именно их определить в вашей
-- убрать limit to, чтобы забрать всю схему
IMPORT FOREIGN SCHEMA "foreign_schema_name" limit to (table1, table2)
FROM SERVER dwh INTO local_schema_name;

©️Благодаря postgres_fdw мы отключили сразу ряд ETL процессов (дагов в Airflow)

➡️ PS. У Postgres есть и другие fwd (foreign data wrapper) для такого же хитрого подключения почти к любым источникам. Я видел, что есть к MySQL и к AWS S3 например 👍.
У нас в инфраструктуре есть mysql базы у приложений и я думаю мы ещё попробуем часть данных использовать оттуда без копирования🙌.
А возможность так подключаться к Aws s3 - это же вообще пушка! Это же получается Postgres можно использовать как вычислительный движок, физически разделив вычисление и хранение (архитектурный паттерн: separate compute and storage), но это уже другая история.🤓

Логи! Если хочешь потратить время

Иногда у инженеров или аналитиков возникает идея извлечь полезные данные из логов. Иногда даже разработчики приложений сами говорят нам: ну вот же логи! там есть данные.

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

Логи существуют для дебага работы приложения. Реже для целей мониторинга и алертов.
Таким образом, логи - технические данные для разработчиков и причины их изменения могут быть самые непредсказуемые.
На логи:
❌НЕ пишут бизнес требования
❌НЕ пишут документацию
❌НЕ делают контракты на пейлоад
❌НЕ проверяют качество и не тестируют.

а если все это делают то это уже не логи

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

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

Особенности foreign data wrapper

Ранее я писал о плюсах использования внешних таблиц, теперь хочу написать об особенностях, которые в нашем use case приводят к проблемам. Спойлер: мы отказались от использования внешних таблиц.🙁

У foreign data wrapper есть особенность:
Fdw запрашивает фул таблицу с удалённого сервера, даже если вы применили фильтры в запросе.😮 Очевидно, что если внешняя таблица на миллионы строк, то ждать придётся очень долго пока вы получите всю таблицу. Эту особенность можно обойти, если “помочь” fdw понять как правильно подготовить запрос ко внешней таблице. Вот здесь хорошо описано и приведены способы написания запроса оптимального для внешних таблиц.🙌 Поэтому я назвал это особенностью. Сама по себе особенность не проблема, работать можно.☝️

А проблема обусловлена именно нашим кейсом.👀

📝 Ситуация (Кейс):
У нас есть DWH на Postgresql и есть Data Marts тоже на Postgresql. Дата марты содержат сабсеты данных специфические для какой-то задачи/домена/департамента. В тех случаях, когда данные в дата марте полностью совпадают с данными в двх как раз возникает отличная возможность избавиться от лишних ETL процессов. Тут то мы и применили внешние таблицы.
В нашем кейсе дата март - конечный продукт для пользователей. Туда приходят делать запросы для анализа, ресерча, построения отчётов и тд. Дата март как продукт должен предоставить возможность работать с данными, делать простые или сложные запросы, оптимальные или неоптимальные.

📝 Проблема:
Пользователям все равно какие там технологии применили под капотом дата инженеры. Естественно они не должны держать в голове, что там какие-то внешние таблицы и как-то правильно надо писать запросы, более того они вообще не должны знать о таких подробностях.☝️ В итоге это привело к резкому падению скорости обработки запросов, жалобам пользователей и отказу от использования внешних таблиц в этом кейсе.💔

📝 Решение:
Физическое хранение данных в самом дата март. Мы перешли к плану Б и настроили логическую репликацию на те таблицы, схема которых совпадает в двх и дата март, то есть там же где были внешние таблицы. 🙌

©️Но мы не убираем foreign data wrapper “на помойку”! В других кейсах, где такими внешними таблицам будут пользоваться инженеры можно работать эффективно. Так что отложили пока в сторонку.
Кстати mysql_fdw тоже попробовал и он тоже отлично работает и настраивается так же легко как и postgres_fdw.

Занимайтесь творчеством!

Когда я пробовал генерировать картинки с AI с меня слетели розовые очки.🫣 Я почему-то думал, что я дам ему текст поста и он что-то интересное нарисует. Как я ошибался! Ему нужно точное описание что нужно сделать: стиль композиция, фон, цвета, детали, эмоции, элементы, формы и все все. Получается нужно в голове полностью придумать изображение и описать его! Творческий процесс! И тут я наткнулся на мысль, а ведь творчество - это про придумать, а не про сделать.

Я порассуждал на эту тему и склоняюсь к тому, что продумать само решение - вот творчество! И с этим AI пока не справляется. Он может заменить последний этап, этап производства.

На самом деле так было всегда. 🤔
💃 Дизайнер одежды не шьёт, а сначала рисует, потом берет разные лоскуты и иголками или ещё как-то закрепляет на манекене, что-то меняет, думает, а готовый вариант может сшить подмастерье.
🏡 Дизайнер (домов, интерьера, рекламы, машин и т.д.) тоже продумывает композицию стиль, потом делает эскизы, рисует, а затем в заданном стиле можно создать множество изображений и добавить деталей.
🎨 Художник тоже изобретает стиль и какой-то уникальный подход. Знаменитые художники знамениты за их "новинки", уникальность, которую они придумали, а репродукцию (копию картины) могут сделать сотни или тысячи художников в мире. Насколько я знаю (где-то читал), у знаменитых художников были подмастерья, которые помогали писать, добавляли какие-то простые делали, фон типа неба или земли - делали рутину. Сегодня это может делать AI.
🎹 Композитор не играет сам партию каждого инструмента, он придумывает главную тему используя как правило только пианино, описывает ее, а потом ее можно масштабировать меняя оркестровку, темп, инструменты и тд (послушайте Ханса Циммера и его саундртеки к фильмам).

👨‍💻У нас как инженеров тоже такой процесс. У нас есть творчество! Придумать решение - творчество, написать код - рутина. Больше занимайтесь творчеством! Опустите технические детали до того момента, когда будете писать код. Опишите проблему и решение естественным языком. Нарисуйте ваше решение с простыми квадратиками и стрелочками (инструменты типа uml придут позже, когда вы сами поймете что они вам нужны), затем уже опишите конкретные шаги (пост про псевдокод). Решение готово! Кода нет? Напишите сами или отдайте AI - это рутина. ☝️

©️Занимайтесь творчеством ребята!

Ситуация©️ Проблема ©️Решение

Большая часть работы состоит из решения проблем и различных коммуникаций по поводу их решения. Часто нужно описать проблему, поставить задачу так, чтобы твой коллега все понял. А чтобы объяснить кому-то нужно ещё понять проблему самому, добраться до сути. 🧐

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

📝 Ситуация-Проблема-Решение или The "Situation-Complication-Resolution" (SCR) фреймворк широко используется в бизнес коммуникациях, сторителлинге, решении проблем.

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

По сути это метод рассуждения, который можно применять везде, а рассуждать я люблю и умею🤓. Я им пользуюсь часто для сложных и простых ситуаций, для постановки задач, для переписки в рабочих чатах или каналах и даже вот применил в посте. При этом не обязательно описывать (проговаривать) каждый из пунктов явно, можно о них подумать, а описать уже просто в виде нескольких связанных предложений.

И самое лучшее во фреймворке то, что применять его очень легко! Можете попробовать в понедельник описать таск используя СПР (SCR) фреймворк.

Кстати у нас в компании head of engineering так любит этот фреймворк, что у нас тикеты на команду девопсов имеют обязательные поля для заполнения Situation, Complication, Resolution.☝️

Пример есть в посте и еще пример в комментариях для простой технической задачи из недавних 👇

Отношение меняет все

Как бы по инфоцыгански это не звучало, это так. Наши установки меняют мышление и настрой.

Плохие установки приводят к проблемам в коммуникации, к проблемам в доведении проекта до результата и тд.

Вот плохие установки, которые часто встречаются. И у меня тоже🙁, но я с ними борюсь

❌Легаси код - плохой код. Есть такая цитата: легаси - это снизсходительное название того, что прямо сейчас приносит деньги.
❌Заказчик/клиент глупый и не знает чего хочет. Классика. Лучше исходить из того, что заказчик - эксперт в своей области и нужно его понять и направить в нужное русло.
❌ Хочешь сделать хорошо, сделай сам. А потом выгори, сорви сроки, оттолкни от себя людей, которые хотят и могут помочь.
❌ Это не моя проблема, это их проблема. Все проблемы - это проблемы бизнеса. А мы работаем на бизнес. Это не значит что все нужно делать самому (смотри предыдущий пункт), но подсветить проблему, поделиться мнением, создать таск в беклог 😁.
❌ Правила мешают работать. Однако их придумали неспроста. Они написаны кровью, пОтом и матами инженеров, которые были вынуждены разгребать хаос.
❌ Безопасники мешают работать (долго доступ дают и вопросы какие глупые задают). Во-первых смотри предыдущий пункт. Во-вторых тема безопасности данных вообще очень важна для нас и тут, наоборот, мы, как дата инженеры, должны первые встать и сказать, что с безопасностью что-то не так. Кстати в Fundamentals of Data Engineering безопасность данных - часть работы дата инженеров и их ответственность тоже .

Modern data stack

Цитата из книги Fundamentals of Data Engineering о современном дата стеке.

the main objective of the modern data stack is to use cloud-based, plug-and-play, easy-to-use, off-the-shelf components to create a modular and cost-effective data architecture.

Меня позабавило скопление в одном предложении всех этих словосочетаний подчеркивающих простоту и быстроту развертывания и использования 😄. Может даже показаться что и дата инженеры-то не нужны😯. Но нам не о чем беспокоиться! Даже при использовании таких компонентов остаётся сложность создания собственно архитектуры с правильными компонентами и с правильным взаимодействием. Нужно стремиться стать гибким инженером (это я самому себе 😉), способным эффективно использовать модерн дата стек, не застревая в двух крайностях:

😡Олдскул: берём только проверенные временем компоненты, а все чего не хватает пишем сами.

😡 Resume-driven development - выбор исключительно крутых новейших технологий, забывая конечные цели проекта. Вот ещё одна цитата из той же книги.

There’s also a temptation to do resume-driven development, stacking up impressive new technologies without prioritizing the project’s ultimate goals.

©️Перечитал пост и понял, что как и всегда все снова сводится к балансу и здравому смыслу 🤔

Мониторинг и алерты

Я очень люблю эту тему и почему-то о ней несправедливо мало говорят в контексте дата инжиниринга и вообще работы с данными. 

📝 Я убежден, что мониторинг и алерты неотъемлемая часть хорошего инженерного решения.

Мы стараемся закрыть мониторингом и алертами все, за что отвечает наша команда. Иногда ребята меня спрашивают зачем нам приоритезировать работы по настройке мониторинга и алертов. Я обычно отвечаю, что задача алертинга уведомить нас о проблеме до того, как о ней узнает бизнес. Алерты работают на качество нашего сервиса (даже если вы работаете всегда внутри своей компании, заказчики - это аналитики или стейкхолдеры и вы оказываете им услуги). Все это правильно, но я чувствовал что тут есть что-то ещё, что меня беспокоит, когда нет алертов. И вот мне наконец удалось порассуждать, добраться до сути и сформулировать ее 🙌.

Пассивная уверенность vs активная уверенность.

Пассивная уверенность - состояние, при котором в любой момент времени, не предпренимая никаких действий, точно известно, что все работает хорошо. Например CEO подошел и спросил "все работает?" и ты через секунду уверенно отвечаешь - да.

Активная уверенность - состояние при котором, чтобы убедиться что все работает хорошо, нужно предпринять какие-то действия: открыть ui оркестратора, проверить наличие ошибок в логах и тд.

Вот оно! Я понял, что меня психологически не устраивает активная увереность. Поэтому я стремлюсь к состоянию пассивной уверенности.

Ксати я раньше не встречал нигде такие понятия и определения. Возможно я даже что-то новое сформулировал😎. 

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

Лучший друг человека

Вчера весь день работал с другом. Я изучал работу со spark на aws emr serverless, aws glue, data catalog, а он мне помогал. Я говорю дай скрипт, который будет делать вот это, он даёт, я говорю, а почему вот тут не сделал проще? Он: точно! и поправляет. Я: вот тут какие ещё варианты? Уточни как это работает. А что под капотом по факту происходит? А вот тут похоже будут проблемы в таких-то кейсах? И тд...

Наверное вы уже догадались, что это ai chat. В этот раз конкретно я общался с windows copilot, а вообще я и с другими друзьями общаюсь 😂: с chatgpt, amazon q (когда в aws console), githab copilot (когда работаю в ide). Эта компания мне здорово помогает! 👍 Но у этих ребят конечно надо знать, что спрашивать! И я даже не про промпты, а про то, что нужно понимать контекст и главное понимать свою цель. ☝️

Раньше процесс изучения новых для меня технологий я начинал с обзорных статей, потом к статьям уже более детальным - туториалам, потом уже к документации или к еще более глубоким статьям. Теперь я заметил, что следующий шаг после обзора хорошо заменяют такие чаты, так как дают быстрый доступ к нужной информации (что логично ведь на основе открытой информации в интернете они и обучены). Таким образом сначала все таки статьи, чтобы знать что к чему и знать, что спрашивать у друга. Потом ai друг. Ну а глубже пока эти друзья не тянут. Не то чтобы ошибаются, но скорее привирают или обобщают/упрощают. Для начального этапа погружения это ок, но для решения сложных проблем уже не то.

В итоге мой план на любой новый инструмент:
1️⃣несколько обзорных статей наискосок,
2️⃣пообщаться с ai другом и проба что-то сделать вместе с ним,
3️⃣сделать рабочее решение моей задачи
4️⃣уточнить детали в документации по мере необходимости.
5️⃣А уж если цель - экспертность, тогда книга.

В прошлом посте я упомянул, что изучал некоторые инструменты на aws для работы с данными. За один день я потрогал AWS EMR, AWS EMR Serverless, AWS Data Glue (catalog, crawler).

Как и всегда изначально у меня была четко сформулированная проблема, а точнее две. Это потом я уже выдвинул гипотезу, что эти проблемы можно решить на aws и потому туда и пошёл. Просто я свое время ценю и инвестирую его осознанно 😉

📝 Итак проблемы:
1. Compute выполняется на воркерах airflow, что очевидно ограничивает работу с большими данными.
Гипотеза: перенести работу в spark, а aws emr упростит поддержку кластера.
2. Зависимость от Postgresql. У нас DWH на Postgresql и архитектурно это ограничивает свободу выбора инструментов работы с данными.
Гипотеза: отделить слои трансформации+хранения от репрезантативного слоя, организовать data lakehouse с данными в открытом формате (iceberg) на aws s3, а postgresql сделать опцией.

✏️ Далее мои выводы и впечатления. Вкратце в виде обзора. Для тех кто уже знает эти инструменты ничего нового не скажу.

Пару слов о spark. Я думаю все как минимум слышали о нем. Это compute engine для распределенной обработки данных. Он изолирует все сложности под капотом, а снаружи дает простой интерфейс для разных языков программирования. Ему нужен кластер.

Aws emr как раз дает кластер, но он хоть и облачный, но все равно требует поддержки (конфигурация, мониторинг, деплой и тд), а мы этого делать не хотим, нам же надо modern data stack, значит сразу идем смотреть serverless. Тут aws даёт возможность забыть о кластере и просто слать ему job 👍. Aws при этом предоставляет библиотеку для airflow, в которой есть операторы для работы с Aws emr serverles. Супер! Все что нужно - это выполнить submit job!

В нашем случае мы уже изолировали оркестратор и даги строятся автоматически из конфигов и все что нужно сделать - это подготовить универсальный spark job script и подложить его в билдер. И вуаля! Десятки наших дагов начнут работать на spark и даже об этом не узнают 😁 - решение проблемы 1️⃣. А так же здесь можно перенаправить поток данных в aws s3 в файлы iceberg, так как spark умеет с ними работать - решение проблемы 2️⃣. В общем-то уже тут я понял что не зря пришёл и с этим можно работать. 🙌

Продолжение в следующем посте ⬇️

Продолжение предыдущего поста

AWS Glue даёт возможность изолировать зоопарк ваших дата источников/дестинейшнов сколько бы их ни было. Базы данных, event stream (kafka), файлы любых форматов в aws s3 или где-то ещё. Он все это может понять и позволить работать со всем этим взаимодействуя только с одним интерфейсом, одной точкой - aws glue.

Это возможно при создании дата каталога - такое хранилище мета данных или другими словами схем данных: какие таблички в базе да с какими колонками и тд. При этом есть специальный инструмент - crawler, который по запросу или расписанию ходит везде и обновляет мета данные ⛏ . Таким образом aws glue знает, что вот тут postgresql база и в ней такие таблицы и колонки, а вот тут mysql, а вот ещё kafka и тд. Это и позволяет Data Glue сидя сверху на каталоге делать грязную работу работать со всем многообразием за вас. И круто ещё и то, что под капотом spark! Все таблички из каталога уже в контексте! Вы в скрипте обращайтесь к чему угодно как к таблице, а дальше уже происходит магия и данные подтянутся будь-то csv файл, будь-то mysql табличка! (Сам на проде не пробовал пока, интересно как он будет билдить запросы. Поглядим 🤔).

В нашем случае ещё сильнее упрощается скрипт и упрощается работа с sql, так как не нужно думать о подключениях, базах, отличиях синтаксиса и тд. Звучит круто! Потом попробую на проде, расскажу 😄 У aws glue ещё есть свой etl оркестратор типа для визуального построения флоу, но он что-то с первого взгляда меня не впечатлил.

Ну и вишенкой на торте на дата каталоге лежит AWS Athena. Если Glue даёт возможность работать со спарк скриптами, то этот инструмент даёт обычный sql интерфейс над всем каталогом 💪. Можно подключиться через ваш любимый database клиент, типа dbeaver или datagrip и работать с sql консолью, не думая о том, что там могут быть десятки баз данных и файлов! 😮 (тут я немного переживаю, не получится ли как с foreign data wrapper и его далекими от оптимальности запросами, пробрасываемыми непосредтсвенно в базу-источник, но есть надежда что в aws сделали получше)

Должен ещё упомянуть, что все это добро стоит недешево. Порядок чисел начинается с сотен долларов на минималках. Если мы решим туда идти, то обязательно будем внимательно следить за стоимостью и переходить постепенно. К слову есть такая штука как FinOps (что? Уже есть devops, dataops, а это ещё что? 😳). Да, оказывается дата инженеры ещё и немного финопсы! (Книга Fundamentals of data engineering). За modern data stack со всеми этими off-the-shelf, easy-to-use, plug-and-play надо платить. 💰

©️В итоге я понял, что обозначенные мной проблемы можно решить красиво, молодежно в AWS.

Спасибо, что прочитали этот длинный двойной пост 🤗