Квантовая аналитика 😄

Такой перл у нас родился сегодня на дейлике 😆

А тема вообще очень серьёзная. И это я не про квантовую физику😁.

Auditability - полная прослеживаемость и проверяемость данных: почему, в какой момент менялись. И как следствие этого свойства — возможность получить данные на определённый момент времени.

©️Чтобы получать предсказуемые отчеты, а не квантовую аналитику, всегда собираем историю изменений и метаданные 🙌

Без паники!

Пост про траблшутинг и проблем солвинг.

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

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

Ошибка на проде, из-за которой может быть упущена прибыль, конечно, ситуация критическая, и тут важно сохранять спокойствие. Все как на ОБЖ учили😁

Вот что поможет избежать паники:
1️⃣ Доверяй себе — если исходить из того, что вы хороший инженер и просто так на удачу ничего не релизите, то значит, вы всё сделали правильно.
2️⃣ Доверяй коллеге — это следующий шаг от доверия себе — он/она тоже хороший инженер и т. д.

Так что вместо того, чтобы сразу по умолчанию признавать всю работу некачественной, стоит потратить немного времени на поиск причины.

Несколько возможных сценариев:

©️ Причина может вообще не быть связана с последними изменениями непосредственно (см. пост). Например, кто-то где-то что-то поменял и то, что вы сделали релиз - просто совпадение.

©️ Причина может быть связана косвенно: изменения выявили скрытую проблему в другом месте.

©️ Причина в небольшой ошибке в релизе - баг.

©️ Причина в критической ошибке в релизе.

Очевидно, что в зависимости от причины будут предприняты разные действия. И да, бывает, что откатить все - лучшее решение, однако и оно должно быть принято спокойно на основе анализа ситуации, а не паники.

Берите пример с кота на картинке: без паники! ❤️

Google, heavy is the crown?

Раньше я думал, что гугл это идеал, если бы это был человек, то у него был бы нимб или корона. Но поработав с сервисами гугла, я понял, что ничего там особенного:
🔸ошибки (да, я и 503 видел от одного из их сервисов в течение нескольких часов😳),
🔸странное поведение,
🔸запутанная и где-то неполная документация

Все как у людей. 😁 То же самое могу сказать и про facebook, bing и ещё ряд разных не таких известных сервисов. Google — просто яркий пример, чтобы донести саму идею.

Я осознал что все это просто сервисы, написанные простыми разработчиками, которые не факт, что умнее меня или вас. 🧐 (Дисклеймер: я сейчас не имею ввиду топ инженеров того же гугла, которые меняют мир, я имею ввиду ребят, которые работают "в поле" и каждый день пишут код)

Мы как дата инженеры часто делаем интеграции с другими сервисами, API, приложениями, собираем данные из баз и тд. То есть пользуемся результатом работы других разработчиков. Так вот мы часто склонны думать, что если что-то не получается, то обязательно виноваты мы. Я тоже был таким раньше, особенно в отношении гигантов. Но со временем, с опытом, с тонной прочитанной документации, с общением с поддержкой разных сервисов я понял, что чудес не бывает. Везде просто люди. Везде есть ошибки и неточности.

То же самое и в базах данных приложений: колонка имеет именно такое значение просто потому, что какой-то разработчик написал код, какие-то условия, правила. То есть всё это ничто иное, как его интерпретация бизнес правил. Если значение вам кажется странным, то, возможно, вы правы.

❌Опасно! Есть риск уйти в крайность и стать вечно ворчащим разработчиком, который ругает всё, кроме того, что сделал сам! 🙅‍♂

©️Я разработчик ©️ Я могу ошибаться ©️ Все сделали люди ©️Они такие же разработчики как я ©️Они могут ошибаться 🙌

Дата инженерная доля

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

Ошибки, неточности могут быть в любом сервисе, с которым мы интегрируемся. Но это не всё...

📖 Проблемное поведение сервисов, приложений, источников данных:

🔸Ошибки - сервис не выполняет предъявляемые ему требования

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

🔸Неполные данные - сервис выполняет все известные требования, но в данных не хватает деталей, однако сервис не может добавить эти детали в принципе. Например, есть три внешних сервиса, выполняющие одинаковую функцию. Сервис 1 предоставляет свойства A, B, C; сервис 2 - тоже A, B, C; сервис 3 только A, B.

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

🔸Разные комбинации всего этого одновременно в рамках одного сервиса

А теперь самое интересное.

Бизнес требует полные, точные данные без ошибок и стабильно.😐

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

➡️ Ошибки? Ну вы же их видите - добавьте в код костыль, фильтраните, пока мы делаем фикс.
➡️ Ошибку исправили. В исторических данных она осталась? Конечно, как мы в прошлом ошибку исправим. Проблема была такая-то - исторические данные исправьте сами.
➡️ Неточности? Да, знаем — добавьте логику на своём уровне, пока у нас руки не дошли туда (никогда не дойдут).
➡️ Неполные данные? Заполните. Сделайте допущение, мы и правила вам расскажем. Примерно.
➡️ Нестабильный источник? Ну есть же второй еще. Берите из него, если первый недоступен, да смотрите, чтобы дублей не было.

⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️

Бизнес:
- В общем сделайте так, чтобы данные отвечали на наши вопросы.
Дата инженеры:
- ок

Такая вот дата инженерная доля. 🥲🫡

Data Maturity Levels

Прошлый пост получился немного грустный. Дата инженерная доля... 🫡

✅ То, какая она эта доля у дата-инженера зависит от уровня зрелости компании в отношении работы с данными - Data Maturity Level.

Мне очень нравится модель зрелости, предложенная в книге Fundamentals of Data Engineering. И я хочу привести её в этом посте в сокращенном виде ✏️

Важный момент! уровень зрелости не зависит от возраста компании: компания, существующая полгода, может быть более зрелой, чем компания, существующая много лет. ☝️

1️⃣ Starting with data
Архитектура и инфраструктура данных находятся на начальных стадиях планирования и разработки. (дополнение от меня: Если какие-то инструменты и сервисы и внедрены, то разрознены)
Уровень внедрения и использования данных низкий.
Практическое понимание ценности данных невелико, но стремление к этому есть.
Отчеты и аналитика не имеют формализованной структуры, а большинство запросов к данным выполняется в режиме ad hoc.
На этом этапе дата-инженер обычно выступает как универсальный специалист и берет на себя сразу несколько ролей, например, аналитика или разработчика. Цель дата-инженера — двигаться быстро, добиться первых результатов и принести пользу. Задача здесь - заложить прочный фундамент для работы с данными.

2️⃣ Scaling with data
Компания уходит от разовых запросов к данным и формирует формальные практики работы с ними. Теперь главная задача — создание масштабируемой архитектуры данных и подготовка к будущему, в котором компания действительно будет управляться на основе данных. Роль дата-инженеров постепенно переходит от универсального специалиста к фокусированию на определённых аспектах жизненного цикла работы с данными.
Основным узким местом масштабирования является не число узлов в кластере, не хранилище и не сама технология, а команда дата-инженеров. Нужно делать ставку на решения, которые просто внедрять и поддерживать, чтобы увеличить пропускную способность команды. Внедрять DevOps и DataOps практики.
При этом важно общаться с другими командами о практической пользе данных, обучать организацию тому, как использовать и извлекать ценность из данных (дополнение от меня: правильно использовать).

3️⃣ Leading with data
На этом этапе компания уже действительно управляется данными. Автоматизированные пайплайны и системы, созданные дата-инженерами, позволяют сотрудникам самостоятельно выполнять аналитику и использовать ML. Подключение новых источников данных происходит бесшовно, и из данных извлекается реальная ценность. Дата-инженеры внедряют необходимые механизмы контроля и практики, чтобы данные всегда были доступны людям и системам: governance, catalog, lineage, metadata management, etc.
Дата-инженер на этот этапе может уделять много времени разработке кастомных инструментов и систем, которые используют данные как конкурентное преимущество. Однако здесь возникает соблазн браться за дорогие «хобби-проекты», которые не приносят ценности бизнесу.
Серьёзную угрозу представляет самоуспокоенность. Достигнув третьего уровня зрелости, организации должны постоянно уделять внимание поддержке и улучшению процессов, иначе есть риск отката на более низкий уровень.

Когда я впервые прочитал об этой модели уровней зрелости, всё понял: почему некоторые вещи двигаются тяжелее, чем хотелось бы, почему не хватает времени на какие-то красивые практики дата-менеджмента и т. д. 😕

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

А ещё, по-моему, такого чистого разделения на этапы в реальном мире не существует: всегда будут признаки разных уровней одновременно, особенно в рамках целой компании. Наверное уровень можно примерно определить по правилу большинства признаков. Я бы сказал, что мы год-полтора назад были в большей степени на уровне 1, а сейчас основной массой перевалили на уровень 2, и, хотя кое-где нога застряла еще на 1, смотрим на уровень 3. 🫣😋

На каком уровне ваша компания? ⬇️

Профессиональная независимость

* это я сфотал картину Tennis Player в музее Современного искусства в Мюнхене.

Я занимаюсь большим теннисом с тренером. Как любитель. 😎 Иногда мы разговариваем с ним о его тренерской жизни, и однажды он поделился со мной интересной мыслью об отношениях тренер<>спортсмен которую, если подумать, можно распространить и на отношения сотрудник<>компания.

То, что тренеры конкурируют за спортсмена, особенно в любительском секторе, очевидно: такая модель продавец услуг -> клиент. Но что, если есть и обратная конкуренция?

Дальше примерно его мысль: ⬇️

С одной стороны выглядит хорошо, когда тренера нанимает богатая семья, чтобы он тренировал и детей и немного родителей тоже. Работа только на них - удобно. Платят много. Стабильный доход. Есть одно но. Со временем спортсмены (и дети, и взрослые) начинают лениться, меньше выкладываться на тренировках и даже пропускать их. Чтобы этого не произошло, нужна конкуренция: спортсмен (клиент) должен конкурировать за тренера (исполнитель). Другими словами у тренера должна быть реальная возможность сказать "до свидания" и пойти работать с тем, кто хочет расти. И все стороны должны это понимать.

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

©️Перейдем на отношения компания<>сотрудник.
В этой аналогии сотрудник - это тренер/исполнитель, а компания - спортсмен/клиент.

Майндсет зависимого, наемного, удобного мешает обеим сторонам и приведет к деградации. Поэтому я люблю рассматривать найм как партнерство, договоренность, где я предоставляю услуги и получаю вознаграждение. Работаю плохо? Можете меня выгнать. Работаю хорошо? Платите.
При этом "хорошо" — это не просто "сделал как попросили", а ещё и про профессиональный уровень, принятый в индустрии 🧐

Дисклеймер: Я не предлагаю работать на нескольких работах одновременно или идти во фриланс. Речь о майндсете.

Профессиональная независимость - уверенность в своих компетенциях, понимание их ценности на рынке и способность донести эту ценность. Рост вознаграждения за счет роста качества работы. 🚀

©️Хороший тренер специалист всегда найдет работу 😉 💯

Маленькая инженерная задача. Часть 1. Контекст.

На гифке выше — голова Франца Кафки в Праге.

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

📝 Задача связана с Apache Kafka — брокером сообщений, частым участником архитектуры приложений и дата-платформ.

Брокер сообщений работает в producer-consumer схеме, то есть продюсер закидывает туда сообщение (публикует), а получить его может множество подписчиков (консьюмеров) – сервисов, которым нужно как-то использовать этот опубликованный факт: запускать внутреннюю логику или просто сохранять данные.

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

Еще одна важная особенность. Мы используем один общий поток для всех событий (в kafka это называется топик). Решение со своими плюсами и минусами. И именно с минусами этого подхода и связана задача, о которой я пишу.

Плюс единого потока:
🔵участникам легко интегрироваться (всегда только один поток),
🔵 легко поддерживать инфраструктуру (не нужно добавлять топики),
🔵 команда продюсера ни о чем не думает, не делает запросов на создание топиков в команду поддержки (девопсы или дата инженеры), а просто начинает отправлять события.
Все очень просто, а значит надёжно.
Минус:
🔸 консьюмер вынужден читать весь поток и выбирать из него только интересующие его события. Вполне может быть так, что подписчик "пропускет" 90% всех событий в ожидании "того самого". 😵‍💫

Вот история с применением СПР паттерна (писал про него тут).

📝 Ситуация: есть kafka с одним общим топиком, в который попадают все события. Еще есть http proxy микросервис (написан на Go), который принимает http post запрос, валидирует пейлоад и отправляет его в kafka. Все события имеют единую схему метаданных и пейлоад. Есть несколько продюсеров и несколько консьюмеров. kafka и прокси развернуты в кубернетес (aws eks).

🐞 Проблема: есть флоу, которые выполняются с превышением SLO, то есть end-to-end время превышает требование бизнеса.

End-to-end для бизнеса означает от одного бизнес-события до другого. Например, клиент на сайте нажал кнопочку "купить" и через 5 секунд получил email с подтверждением. Заметьте, что бизнесу пофиг: Kafka там или что-то ещё под капотом (пост бизнесу пофиг).

💡 Решение: 1) предоставить консьюмерам возможность потреблять часть событий; 2) организовать мониторинг каждого шага, времени работы каждого участника, чтобы такие вопросы не возникали в будущем, чтобы точно знать, кто и где даёт задержки; 3) переключить консьюмера на "урезанный" топик и наблюдать за флоу, так как есть вероятность, что задержки в этом конкретном флоу были вызваны чем-то другим.

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

Дальше я буду писать о создании урезанных топиков (п. 1 решения), а мониторинг в этой истории опустим.

Итак, ситуация, проблема и решение определены. Теперь можно уже делать? Нет. Ещё подумать ☝️ 😁

Продолжение следует...

Маленькая инженерная задача. Часть 2. Решение

Дальше рассуждения о том, как именно реализовать решение. 🤔

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

Вот некоторые из рассмотренных подходов:
©️ топик под требования консьюмера, то есть консьюмер приходит и говорит "меня интересуют конкретно события А, B, C" и создаем соответствующий топик именно под него. Отмели сразу, потому что на ровном месте вносит зависимость разработчиков консьюмера от команды поддержки инфраструктуры. К тому же задач может быть множество, и каждый раз создавать топик — перебор.
©️ топики под каждый тип события. Многовато получится топиков. У нас более 100 сейчас разных событий и постоянно добавляются еще.
©️ топики по группам событий. У нас события могут быть разделены по контекстам. Их около 20. А консьюмеры подписываются на контекст и получают сабсет событий и чувствуют себя лучше. Выбрали этот вариант.✔️

Идем дальше: создавать топики динамически или предварительно? Динамически звучит лучше: появился новый контекст, автоматически создался топик. Так участие инженеров нужно только один раз при запуске, а потом все работает само - красота. 🤤

Теперь детали: инструменты, языки и тд. Тут тоже варианты.
🔵 внешние saas инструменты. Отмели сразу, что я даже не искал такие. Kafka у нас в AWS EKS кластере (Kubernetes), поэтому подключение внешнего инструмента потребует "открыть" инфраструктуру в мир. Плюс такие тулы не могут дать 99% гарантию, что все события попадут в нужные топики, по крайней мере банально из-за добавления общения по сети, не говоря уже о внутренних делах того сервиса. Ну и конечно saas стоит денег 💰
🔵 расширить функции уже имеющегося http proxy микросервиса, чтобы обрабатывая событие, он сразу записывал его в два топика: общий и специальный. Тоже отклонили по архитектурной причине: из простого "деревянного" прокси он превратится в сервис с логикой. Сломается принцип единой ответственности (SOLID). Сейчас его простота даёт гарантию доставки событий, а добавление логики внесёт риск. И это потребует вмешательства в то, что уже работает.
🔵 готовый open-source инструмент, развёрнутый внутри того же кластера Kubernetes и того же namespace, где и Kafka. Цельная инфраструктура работает слаженно. Исключаются любые внешние "помехи", а вся работа происходит в одном и том же изолированном namespace. Вот это нам понравилось. 👍
🔵 кастомный микросервис внутри кластера. Очевидный минус: нужна разработка, а потом поддержка.

В итоге техническая задача звучала так:
✏️ подобрать и внедрить инструмент, который будет из общего топика динамически генерировать топик для каждой группы событий (или типу событий) так, чтобы при появлении нового типа автоматически создавался отдельный топик без вмешательства инженеров.

Вот теперь можно делать. 😁 Спойлер: такого инструмента нет

Продолжение следует...

Маленькая инженерная задача. Часть 3. Реализация

Из предыдущего поста:

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

Звучит несложно, подумал я, с учётом огромной популярности Kafka, с учётом всех этих разговоров о modern data stack, где на каждую идею уже придуман off-the-shelf (прямо с полки), plug-and-play инструмент. По крайней мере такое сложилось у меня впечатление, когда я последнее время читал разные статьи, посты и тд. (пост про modern data stack)

Оказалось, что не существует готового инструмента, закрывающего данный вопрос, чтобы разработка не нужна была вообще, а только конфигурация (например тераформ, хелм и всё). 😳🫣😞

Вот что есть:
🟣Ksql – популярный и не требующий разработки open source инструмент. Есть официальный helm. Удобно создавать топик по условиям, но динамически он не умеет. 🤬

🟣Kafka Streams – библиотека, которая позволяет накодить что угодно на python или java, но ключевое слово накодить, то есть это будет кастомная разработка, которую надо поддерживать. 💔

🟣Apache Flink – стриминг инструмент с широкими возможностями и, конечно, умеет динамически, но тяжелый и требует сложной конфигурации – для данной простой задачи это перебор. 🤯

Есть еще парочка вариантов, которые накидал gpt, но все они примерно о том же. 🤨

©️В итоге пошли на компромисс. Отказались от идеи динамической генерации с необходимостью разработки в пользу предварительно настроенных топиков с использованием готового инструмента – ksql. Новые контексты добавляются относительно редко (может, раз в несколько месяцев), и да, придётся зайти в конфиг ksql и добавить ещё один стрим, но это на данный момент показалось проще, чем делать разработку.

Ksql развернули через helm внутри существующего неймспейса в кубернетес рядышком с kafka и proxy сервисом. Прямо там же, через helm, на языке SQL описали новые стримы в интуитивно понятном формате select запроса типа: выбрать из топика A, где контекст равен B, и отправить в топик C. 🙌

Я намеренно не добавлял здесь код конфигурации ksql. Суть истории не в коде, а в процессе решения проблемы и в том, что изначальную идею пришлось в пересмотреть. Не исключено, что будут ещё и другие итерации.

〰️〰️〰️〰️〰️

Часть 4. Рефлексия

Завершу я эту историю 3 финальными мыслями.

1️⃣ Описание относительно маленькой задачи растянулось аж на 3 поста. Да, я мог бы просто написать: нам нужны были топики в kafka и мы внедрили kqsl. Уложился бы в один пост. Но упустил бы самое главное: в реальной работе редко бывает так, что решение очевидно и однозначно. Любую проблему можно решить множеством способов. Более того, ещё и саму проблему нужно правильно определить.

2️⃣Минусы есть всегда. Наш архитектор сказал такую мысль:

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

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

3️⃣"Накликать" не получилось. В последнее время я много читал про modern data stack, off-the-shelf инструменты, и создалось впечатление, что на любой каприз уже есть проверенное готовое решение с открытым кодом. А тут вдруг облом с супер популярной кафкой: отсутствие возможности создавать топики динамически без кастомного кода. Получается, еще далеко до того, чтобы инженер только сидел и "накликивал" себе решение на готовых инструментах.

©️Может быть вы заметили, что в той истории я упоминал разные термины и концепты: брокер сообщений, at least once доставка, принципы SOLID, асинхронный API и другие. Ставьте ❤️ если хотите, чтобы я кратко объяснил их в одном из следующих постов. Хотя я все равно опишу, потому что хочу😁

Теория разбитых окон

"Теория разбитых окон" появилась в США в начале 1980-х годов.

Суть теории в том, что признаки беспорядка (разбитое окно, граффити, мусор) сигнализируют: за этим местом не следят.
Наблюдали такую картину: рядом могут стоять два здания — одно ухоженное, другое с разбитым окном. И именно второе продолжали портить снова и снова. Если разбито одно окно, то вскоре разобьют и другое, а потом и третье и здание быстро приходит в упадок.

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

По-моему, теория работает много где, в том числе и в инжиниринге данных.

У меня есть пунктик по поводу порядка в нейминге (таблиц, свойств, типов), в синтаксисе, в структуре директорий в репозитории и тд. Это как порядок дома или в городе: разбитое окно нужно менять сразу.

Вот пример.
Мы пишем события. У события есть свойство type. Обычно его пишем в snake_case: something_occured. Но однажды кто-то пишет someThing_occured. Мне такие вещи режут глаз. Смешение camelCase и snake_case в одном значении - перебор. Мы это сразу поправили. А оставили бы так и завтра пришел бы другой, посмотрел и написал в новом событии Smth Occured. Потом третий добавил бы "smth occured_new Final 2025". Окна начали бы разбивать.

Когда я вижу такое в чужих реализациях, у меня сразу снижается уровень доверия. Если ребята не отнеслись серьезно к порядку, то как я могу доверять тому, что они сделали внутри? Это как зайти в автомастерскую и увидеть верстак заваленный хламом и грязные инструменты на полу. Мало вероятно, что работу тут сделают хорошо...

©️Окна будут разбивать. Может парочку разобьете даже вы сами. 🫣 Главное — заметить это и быстро навести порядок!

Ловушка кодера

Писать код или использовать готовый инструмент? 🤔

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

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

Это я назвал ловушкой кодера. 👇⏭

📎 В отдельно взятой ситуации решение принимается правильное — «взять известное», но в долгосрочной перспективе понятно, что никогда не будет задачи с достаточным временем, чтобы изучить новое. То есть снова и снова будет приниматься "правильное" решение....

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

Если инструмент нужен прямо сейчас, то уже поздно разбиратся, лучше кодить. Но только инструмент надо тоже изучить в спокойном режиме. Это инвестиция в будущее – выход из ловушки.🙌

Это все равно что пытаться вдруг заговорить на итальянском, когда ты уже в италии и тебе нужно купить еду, чтобы не помереть с голода. Просто покажи пальцем на пиццу! Да, так от голода, может, и не помрёшь, но качество жизни будет так себе — завтра начинай учить язык.

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

Материализация vs стриминг в ETL: контроль потребления памяти в Airflow

Рассмотрим простой ETL-процесс, реализованный в Airflow.

Есть источник и назначение. На практике это может быть база приложения → DWH или DWH → какая-то система (reverse ETL). Посередине есть оркестратор, который отправляет запрос в источник, получает результат и отправляет его в назначение.
Если вы используете встроенные операторы Airflow, то это будут две разные задачи: extract и insert. Задачи выполняются последовательно, и результат первой часто полностью материализуется в памяти воркера. Вот тут и кроется крайне невыгодное использование ресурсов: если у вас много DAG'ов или объём данных достаточно большой, Airflow начинает активно потреблять память воркеров.
В итоге вы либо
🔸платите больше за ресурсы,
🔸играете с расписанием, чтобы в один момент времени было меньше данных в памяти и воркер не падал,
🔸режете объём данных.
Все варианты плохие хотя бы потому, что ресурсы воркера вообще начинают участвовать в уравнении. Зависимость от памяти становится ограничивающим фактором.

Эту проблему можно решить, если сделать так, чтобы оркестратор оставался оркестратором, а не буфером между источником и назначением.
Суть решения — организовать процесс как микробатч-стриминг. Тогда в памяти воркера в любой момент времени будет только один микробатч (например, 1000 строк).
Достичь этого можно с помощью специального Python-объекта — Generator.
Для тех, кто хорошо разбирается в программировании, я нового ничего не открою.

Такой подход даёт две серьёзные возможности:
1️⃣Можно делать трансфер практически любого объёма без роста потребления памяти воркера.
2️⃣Можно запускать больше процессов трансфера параллельно, потому что они почти не конкурируют за память (память ограничена размером микробатча).

Дальше — техническая часть.

Многие встроенные операторы и хуки в Airflow по умолчанию материализуют результат запроса в памяти воркера. Поэтому потребуется написать немного кода.

Я опишу вариант зрелой, универсальной реализации — с возможностью расширения и переиспользования. Для разовой задачи решение может быть проще.

Итак, что нам нужно.
Во-первых, убрать разрыв на две задачи (извлечение/вставка) и обеспечить одну — трансфер. Это позволит контролировать использование памяти внутри одного процесса на одном воркере.
Во-вторых, нужен адаптер для источника. Его задача — получить запрос и вернуть не данные, а специальный Python-объект — Generator.
Generator не содержит сами данные. Он лишь определяет, как их получать. При итерации он каждый раз возвращает очередную порцию данных.
Большинство баз поддерживают серверные курсоры или потоковую выдачу результатов. Адаптер делает запрос к источнику, но не забирает всё сразу — он получает данные частями.
Например, SQLAlchemy умеет работать в streaming-режиме через соответствующие параметры соединения.
Далее этот Generator передаётся адаптеру назначения. Он итерируется по нему и за раз обрабатывает только небольшой батч данных, освобождая память после каждой обработки.
В любой момент времени в памяти воркера находится только микробатч. 🙌

Для непрограммиста это может выглядеть необычно: фактическое извлечение данных происходит в момент вставки, а до этого между функциями передаётся лишь абстрактный объект, который сам по себе почти ничего не весит.🤯

Примерно год назад мы реализовали такой подход у себя.🧐

С тех пор ошибки DAG'ов из-за нехватки памяти на воркерах перестали быть проблемой.
Сейчас у нас есть универсальный оператор и набор адаптеров для баз и сервисов, реализующих потоковое поведение. Адаптеры инкапсулируют логику стриминга за простыми интерфейсами extract/insert, поэтому оркестратор остаётся только управляющим слоем.

Это уже архитектурный подход — разделение orchestration и data transfer.

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

Попробовал code agent

На неделе впервые попробовал code agent. Пока что не multi agent со множеством ролей (к этому ещё приду), а просто один агент, который выполняет задачу полностью, даже вместе с деплоем.

Я, конечно, много видел упоминаний и описаний того, как оно работает, но пока сам не попробуешь на своей реальной задаче, всё равно непонятно. Тут как раз появилась простая задачка – идеальная, чтобы начать работать с агентом. И результат превзошёл мои ожидания!

Мне нужно было сделать простой прокси-микросервис, который состоит из AWS API Gateway и одной AWS Lambda. Всё, что делает сервис, — это принимает POST-запрос, проверяет аутентификацию и передаёт его дальше на внутренний API endpoint. Мне нужно было, чтобы агент написал terraform, саму лямбду, тесты. Про то, что он может и задеплоить, я даже и не думал, когда начал.

В пустом репозитории я создал readme файл, описал там задачу сервиса примерно так же, как описал выше. Открыл чат с агентом и попросил его создать сервис. И он реально начал создавать файлы! Не примеры кода, а зависимые друг от друга файлы, которые вместе представляют собой работающий сервис. Я, в общем-то, так и хотел, но увидеть на практике - другое дело. Он уже был не чатом, не ассистентом, а разработчиком.

Затем мне было интересно увидеть, как он будет взаимодействовать со внешними элементами. Я просил его:
▫️задеплоить сервис (stage).
▫️сделать git операции: commit и push в удаленный репозиторий.
▫️провести интеграционный тест: запустить код лямбды локально, отправить реальный запрос на реальный endpoint и оценить результат.

Он выполнял команды terraform, aws cli, git, запускал .py файлы, получал ответы, адаптировался, пробовал снова и... успешно справлялся.

‼️Среди всей этой магии был один важный момент. Он совершил глупую, но серьезную ошибку: в одной из итераций он удалил проверку токена авторизации, оставив только проверку наличия заголовка. Ошибка опасная. Я заметил это, просматривая код наискосок (я не читал каждую строку), попросил его поправить, и он конечно признал ошибку и поправил. Да, наверное можно в конце попросить его же самого сделать ревью и, возможно, он такое заметит сам (в тот момент я не подумал это попробовать).
Главное – остаётся риск ошибки, если "оставить его одного". При этом не стоит проваливаться слишком глубоко в ревью и переписывать всё доводя до идеала. Без перфекционизма. Иначе вместо помощника, который даёт результат, вы сами себе создадите лишнюю работу.


©️В итоге я остался под впечатлением.
(Даже жене вечером рассказал, хоть она и не поняла половину терминов😁).

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

Я точно буду использовать его больше. Следующий интересный шаг – пробовать подключать его напрямую к базе данных.

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

Кстати, я использовал бесплатный vs code и gpt codex, включённый в gpt plus подписку.
.