Можно бесплатно получить книгу https://buf.build/resources/data-engineering-design-patterns

В комментариях я скачал для вас.

Учите JOINs!

По инженерным командам заметил определенные patterns.

Например, по размеру команды и поведению.

Я могу разделить команды на две большие группы.

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

2) большая команда до 10 человек и выше. Тут уже полная неразбериха, каждые пилит что-то свое, старенькие инженеры не хотят помогать новеньким. Решения принимаются либо очень долго, либо очень быстро и непрозрачно, часто кулуарно. Эксперты становятся bottle neck и могут быть токсичными для всей команды. Особенно их бесит, когда берут новых инженеров с зарплатой на 30% выше, чем у них.

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

->Согласно закону Брукса, каждая “добавленная голова” повышает стоимость координации (n(n-1)/2).

->Согласно эффекту Рингельмана, с ростом группы падает индивидуальный вклад.

->Согласно закону Конуэя, система копирует структуру коммуникаций. Если оргуструктура запутана, продукт тоже будет фрагментирован.

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

Как диагностировать проблему?

- Время принятия решения и кол-во решения принятых без обсуждений с командой. Иначе говоря, отсутствия технических документов - tech spec, RAPID, etc
- Задержка с Code Review и очередь к “экспертам”
- Низкие оценки в опросах про эффективность команды (опросы важный элемент для больших команд)
- Четкие сигналы о проблемах на встречать 1:1
- Отсутствие ownership и инициативы от команды

А как у вас обстоят дела с инженерными командами? Вы эксперт bottle neck? Страдаете от закрытости коллег? Не знаете как расшевелить ваши команды?

👩‍💻👨‍💻 Хочешь узнать, как AI реально меняет работу инженеров в России?

Александр, автор канала Книжный Куб рассказал про исследование в Т-Банке: они собирают данные о том, как компании применяют AI, что работает, а что — просто хайп.

Пройти можно здесь 👉 Ссылка на опрос (≈30 минут).

А в январе–феврале будут результаты + отчёт по методологии.

PS в РФ паттерн использования AI инструментов отличается от того, что я вижу в Северной Америке, поэтому мне будет тоже интересно узнать его результаты.

Всех с пятницей!

Как появляется технический долг? (Technical debt)

Все очень просто - ушлые ребята менеджеры топят за скорость в ущерб качеству.

Вот свежий пример:

would encourage us to bias for speed over accuracy, ship it (Нужно скорее фокусироваться на скорости, чем на точности, и выкатывать)

Это нормально, иногда “срезать” углы, но когда организация сдвигается в сторону скорости, со временем создаются множество проблемных зон, которые никогда не будут решены и могут замедлить рост.

А как у вас со “speed over accuracy”?

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

would encourage us to bias for speed over accuracy, ship it

То получается, все таки время у нас не так много, на написания кода. Я спорить не буду с экспертами, кто будет доказывать, что ❌уйн😮 ваш AI и ничего он не понимает в написании кода😇

Лучше расскажу другую идея, что системный дизайн сейчас очень важен, так как AI (еще) не способен понять бизнес контекст и ему все равно, что там будет Batch или Streaming. С poker face он вам будет доказывать, что Batch лучше, streaming. А если ему сказать, что он не прав, он вам точно также расскажет, что Streaming лучше Batch.

Для меня сейчас самое ценное это System Design. Его намного сложней “списать” и “придумать” на собеседовании, если не было реального опыта. Далее был бы data modelling, но без него можно существовать, а вот без правильной архитектуры совсем сложно.

Для любого собеседования на ML, DE - system design must have. Ну и самим было бы классно разбираться, что зачем и почему. Так что качайте системный дизайн для аналитических и ML систем, и там обязательно должно быть место для GenAI.

Airbyte выпустил версию 2.0. Теперь это end-to-end платформа (data ingestion, data transformation, reverse ETL).

Keynote from CEO

Почти все компании не хотят заморачиваться с интеграцией источников данных и использую Fivetran. Затем узнаю ценообразование и офигевают от Monthly Active Rows (MAR) - за каждую загруженную строчку нужно платить. Получается дорого.

И тут уже начинаются разговоры про альтернативы:
- Airflow + Python
- Metano
- Airbyte
- dltHub
- другие инструменты

Как обычно tradeoff - цена/скорость.

Бесплатный Airbyte был всегда проблемным. Облачный (managed) - работает достойно, по слухам. Отличный вариант для небольших компаний.

Расскажите, как у вас дела с Airbyte?

Интересное обновление на стороне потребления данных. С 24 сентября для всех открывается доступ к Нейроаналитику в BI-платформе DataLens — ИИ-агенту, который умеет "читать" дашборды и генерировать по ним инсайты и даже код.

Фишка в том, что теперь бизнес-пользователи могут напрямую спрашивать у данных: «почему упали продажи?» или «какой канал лучше работает?». Без того, чтобы дергать аналитика за каждую мелочь.

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

Данные перестают быть «табличками для отчёта» и начинают отвечать сами.

Все чаще использую MCP в IDE. В моем случае cursor.

Подключаюсь к Snowflake, BigQuery.

Примеры:
- Вот табличка в snowflake, сделай dbt model для нее
- Можешь взять несколько ID и проверить логику в big query
- Я хочу дать доступ в snowflake terraform, можешь написать запрос и посмотреть права
- dbt test упал, почему?

А если тему развивать, то можно уже делать по другому - prod pipeline упал - нужно разобраться почему и написать возможный путь mitigation.

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

Пример MCP для BigQuery:

{
  "mcpServers": {
    "bigquery": {
      "command": "/opt/homebrew/bin/toolbox",
      "args": ["--prebuilt","bigquery","--stdio"],
      "env": {
        "BIGQUERY_PROJECT": "data-1"
      }
    }
  }
}

Еще нужно добавить правило в репозитория agents.md, где написать инструкции, и все будет в разы удобней.

Есть и другой пример. В AWS, я просто использовал AWS CLI клиент, и он может обращаться к облаку и находить нужную информацию. Но вчера я немного встрял. Точнее встрял сегодня😵.

AI инструменты очень хорошо помогают с неизвестными репозиториями, и вы можете быстро разобраться, что за чем, и для чего. Через AWS CLI я смог найти все нужные AWS ресурсы, и понял, что один из API ключей испортился. Я его обновил руками. Но в какой-то момент AI решило заменить production ключи (удалить их все) на новый пустой key pair. Узнал я об этом сегодня, когд инженеры сказали, что все интеграции в Segment/Braze не работают. Было немного стыдно😳

Поэтому спешка с AI, точно не к чему. Еще и по слухам, инструменты стали хуже работать (cost reduction?)