Инжиниринг Данных

23 June 2026 17:47

Meta уволила половину команды безопасности, перевела инженеров на разметку данных, и получила крупнейший взлом в своей истории.

Решение руководства? Больше снеков в офисе.

Инжиниринг Данных

23 June 2026 02:14

Циклы позволяет агентам работать автономно. Я пока еще не использовал, но пора уже.

Видео про циклы: https://youtu.be/F4a8aMLb678?si=poI883i6sIutHQso

Используете?

Инжиниринг Данных

20 June 2026 01:30

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

Так, ну и что там такого важного?

Ну, вы задумывались, какие навыки и задачи в вашей корпоративной роли аналитика станут дороже, а какие обесценятся с постепенным переходом на агентские фреймворки? Тут об этом целая статья хайпится Some Simple Economics of AGI, и я бы хотел разобрать график оттуда

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

Итого имеем 4 квадранта

Q1 (нижний левый) — автоматизация дешёвая, проверка дешёвая. Сюда падают всякие дашборды, регулярные выгрузки, базовые ETL, расчёт A/B через готовый калькулятор (когда дизайн уже задан), ad-hoc запросы под звонок. В расчётах авторов в этом квадранте лежит s_v ≈ 0.59 всей работы (s_v это доля задач, у которых обе стоимости дешёвые одновременно), и именно эту долю агенты автоматизируют первой

Q2 (верхний левый) — автоматизация дешёвая, проверка дорогая. В этот скоуп задач можно отнести оценки causal effect, дизайн рекомендательных систем, агентные пайплайны принятия решений, долгосрочные A/B с метрикой через квартал (изменение subscription pricing, retention 12M, ранкер ленты), оценка incrementality от brand-маркетинга
Формула c_H = w · t_fb / S_nm объясняет, почему здесь бывает жить: t_fb — сколько надо ждать результата, w зарплата эксперта, который проверяет, S_nm запас экспертизы в экономике. Длинный лаг умножается на дорогого эксперта, а делится на тающий запас экспертов. В пределе проверять некому, агенты летают без надзора

Q3 (нижний правый) — автоматизация дорогая, проверка дешёвая. Качественный user research и интервью с пользователями, ручной разбор отзывов и NPS с пониманием контекста, конкурентный анализ, подготовка слайдов для C-level с правильным месседжингом, разметка эджевых кейсов в данных. Зона временно живая, пока стрелка K_C на графике (рост компьюта) не сдвинет её содержимое влево, в Q1, и LLM в разбор отзывов и в классификацию уже зашли

Q4 (верхний правый) — автоматизация дорогая, проверка дорогая. Дизайн самой системы измерения продукта, то есть что считать North Star, перевод мутного запроса от CEO «надо увеличить engagement» в конкретные гипотезы и план измерений, дизайн экспериментальной программы на год с выбором guardrail-метрик, стратегические решения о приоритизации продуктовых направлений на данных плюс контексте, который нигде не записан

Погоди, а в чем тут новость? С джунами также ведь! Это база!

В целом я тоже так думал — замените агентов на джунов и суть же не изменится: джун делает Q1, мидл Q2, сеньор Q4, это карьерная лестница из любого учебника, какая там новизна вообще? Но есть три места, где аналогия агенты = джуны ломается, и из-за них статью, собственно, и написали:

1️⃣Verification не масштабируется, а execution масштабируется
Один сеньор мог проверять пару джунов в день, и количество джунов было ограничено физикой найма. Сегодня сеньор должен проверять выход агента, который генерирует в тысячи раз больше за тот же час. Execution капасити экспоненциальная, verify капасити линейная, упирается в одного человека. С джунами этой асимметрии не было, потому что джун тоже ограничен временем

2️⃣Codifier's curse
С джунами было так: сеньор обучает джуна, наращивает свой статус (становится ментором), джун через 5 лет становится мидлом, рынок экспертизы расширяется. С агентами: сеньор обучает модель, перекладывает свою интуицию в обучающие данные, и его собственная ценность падает. Аналога в карьерной лестнице нет, механизм работает в обратную сторону

Инжиниринг Данных

18 June 2026 19:19

Сегодня попробовал Omni. Подключил его к Snowflake и dbt.

Напомнил Looker с LookML, но удобней, что он сразу умеет читать из dbt моделей и более удобно интегрируется с git.

Короткое демо https://youtu.be/9GduXHYYGbU?si=FcmQdlnoj36xbhdN

Инжиниринг Данных

17 June 2026 06:59

Обновил сайт Rock Your Data https://rockyourdata.cloud/, добавил сервисы по AI, и Space Analytics (IoT, Earth Observation), чтобы была лучше трансформация в https://playeronespace.com/ (сайт, и что делаем, тоже поменял).

И конечно, поменял https://surfalytics.com/, но пока еще надо настроить личный кабинет, в котором будет roadmap, задания и тп. У меня большой backlog фич завязанных на AI (чтобы попробовать разные инструменты), но пока время не хватает.

Для всего использовал Astro фреймворк. RYD и P1S у меня живут на Github pages. Surfalytics на Netlify + Supabase как back-end.

Лишний раз подтверждение, сколько всего можно реализовать с AI.

Инжиниринг Данных

16 June 2026 19:57

Кто-то завайбкодил 3х мерный веб-сайт https://messenger.abeto.co/

Технологии: WebGL и Three.js

Инжиниринг Данных

15 June 2026 19:11

Snowflake начал активно контрибьютить в Apache Spark https://careers.snowflake.com/us/en/blogarticle/building-apache-spark-in-the-open-at-snowflake

Статья рассказывает о подходе Snowflake к интеграции Apache Spark в свою экосистему. Вот ключевые моменты:

• Главный герой — Holden Karau, Principal Software Engineer в Snowflake и коммиттер Apache Spark.
• Цель Snowflake — адаптировать Spark API для улучшения возможностей дата-инженерии и создания более целостного опыта для пользователей.
• Open Source подход — компания активно участвует в разработке открытых проектов, таких как Apache Spark и Apache Iceberg, что помогает лучше соответствовать потребностям клиентов.
• Культура сотрудничества — Karau подчёркивает важность вклада в open source ради общего блага, а не личной выгоды, и делится опытом работы в открытых сообществах.
• Если коротко: статья о том, как Snowflake строит интеграцию с Apache Spark через активное участие в open source разработке, а не просто использует готовые решения.

Snowflake создал Snowpark — свой собственный developer API (Python, Scala, Java) с DataFrame-подобным синтаксисом, похожим на Spark. Но это не Spark — весь код выполняется внутри движка Snowflake, никакого Spark-кластера не нужно. По сути, Snowflake пытался предложить альтернативу Spark, не требующую внешней инфраструктуры.

В Apache Spark 3.4 появился Spark Connect — архитектура с разделением клиента и кластера. Snowflake воспользовался этим, чтобы сделать Snowpark Connect for Spark: теперь можно писать настоящий PySpark-код, а выполняться он будет на движке Snowflake — без Spark-кластера. Это уже настоящий Apache Spark API, а не собственный аналог.

Инжиниринг Данных

11 June 2026 18:39

Вчера посмотрел про история Антропика и их основателей
Inside Anthropic, the $965 Billion AI Juggernaut | The Circuit, узнал про их культуру и рост. Отличное видео, особенно если вы изучаете английский или не работали еще с Claude Code.

Инжиниринг Данных

09 June 2026 19:49

Dagster и цены мы тут обсуждали в прошлом. Походу еще дороже стал. Полностью поддерживаю, если у вас с бюджетом напряг не используйте Dagster. Airflow или AWS Step functions и AWS Batch (если надо совсем дешево и вы на AWS)

Инжиниринг Данных

09 June 2026 08:59

Атака на корпоративного ИИ-ассистента: разбор уязвимостей в прямом эфире

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

16 июня MWS AI (входит в МТС Web Services) покажут живое демо атаки на корпоративного ИИ-ассистента, подключенного к внутренним базам данных. Разберут конкретные векторы, слабые места архитектуры и что именно приводит к раскрытию лишнего контекста.

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

Будет полезно ML-инженерам, архитекторам ИИ-систем и техническим лидерам, которые проектируют или внедряют решения с доступом к корпоративным данным.

🗓 16 июня, 16:00 мск

→ Зарегистрироваться

Инжиниринг Данных

08 June 2026 22:24

Закончилась экспедиция на sup. 5 дней и 4 ночи вокруг Vargas Island, это на острове Ванкувер со стороны Тихого океана. Погода была разная от +4 до +20, были и дожди и ветра. По расстоянию мы не очень много проплывали в день. В основ упор был на изучение навигации, карт, компаса, погоды и планирования. Группа была маленькая- 5 человек и 2 организатора. С одной стороны это очень дорогой тур, чтобы пожить в палатке и мерзнуть под дождем, с другой стороны он бесценный с точки зрения опыта и эмоцией. Следующим летом обязательно запишусь еще раз, но уже в другой локации.

Инжиниринг Данных

01 June 2026 21:21

Наш любимый dbt стал еще лучше - встречайте dbt core v2

• dbt Core v2.0 — это новая open-source (Apache 2.0) основа, которая теперь написана на Rust вместо Python. По сути, dbt Labs взяли движок Fusion (который они разрабатывали отдельно), открыли его исходники и сделали новым фундаментом dbt Core. Сейчас в альфе.

Fusion vs Core v2 — в чём разница?
• dbt Core v2 — open-source Rust-движок, быстрый парсинг, новые артефакты. Это база.
• dbt Fusion — надстройка над Core v2 с пониманием SQL, column-level lineage, богатым dev-опытом в VS Code. Это расширенная версия.

Грубо говоря: Core v2 = фундамент, Fusion = фундамент + суперспособности.

Что нового в Core v2:
⚡ Скорость — парсинг до 30x быстрее, чем в старом dbt Core на Python. Компиляция всего проекта в 2x быстрее. Это ощущается сразу.
📐 Строгая языковая спецификация — теперь нельзя случайно написать ⁠desciptin вместо ⁠description и не заметить. Чёткая схема языка = меньше глупых ошибок, стабильный интерфейс для интеграций.
📦 Parquet-артефакты — вместо огромных JSON-файлов. Можно напрямую запрашивать через DuckDB или любой AI-агент. Намного быстрее и удобнее для больших проектов.
📚 Новый локальный docs-опыт — полностью переработан, работает на новых артефактах, масштабируется на проекты любого размера.
🦀 Весь Rust-код теперь в репозитории dbt-core — то, что раньше было в dbt-fusion под лицензией ELv2, теперь открыто под Apache 2.0.

Нужно ли мигрировать?
Пока v2 в альфе. dbt Labs выпустили инструменты для миграции (⁠dbt-autofix), которые помогут подготовить проект. Python-версии dbt Core никуда не делись — они остаются доступными.

Я пока мигрировать не собираюсь. Проблем в старых версиях нет. В dbt core вообще проблем нет, поэтому никто не хочет покупать платную версию.

Инжиниринг Данных

28 May 2026 20:08

Сегодня был еще один собес. На входе 5 лет опыта.

Задачка такая же - платформа на AWS.

Кандидат прыгал с Postgres на Snowflake и Databricks. Про dbt не слышал, Airflow мельком.

5 лет это реальный опыт. То есть можно работать годами и ничего не знать, а можно за 6 месяцев качнуться на Surfalytics или самому, построить несколько типовых решений и уже будете знать больше чем 90% кандидатов с 5-10 лет опыта.

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

Но лучше гулять и кайфовать в рабочее время🎃 Но для этого надо бы сначала качнуться как следуют, чтобы потом на “чиле, на раслабоне”🛌

Инжиниринг Данных

27 May 2026 17:53

Послушал подкаст Data Engineering Central - там разговор с Джейкобом Мэтсоном, Developer Advocate из MotherDuck (это облачная версия DuckDB).


1. Индустрия устала от сложности
После лет оверинжиниринга (Spark, Kafka, огромные кластеры) - маятник качнулся обратно. Всё больше задач решается на одной машине. DuckDB - яркий пример: просто, быстро, без инфраструктуры.

2. AI не убьёт дата-инженеров - наоборот
Казалось бы, если AI генерирует SQL - зачем инженеры? Но тезис обратный: AI будет генерировать больше запросов, значит нужно больше людей, которые следят за качеством данных и моделями. Роль дата-инженера вырастет, а не исчезнет.

3. Data Modeling снова в моде
Когда AI пишет запросы, он опирается на структуру данных. Если модель данных плохая - AI будет давать мусорные ответы. Хорошая модель данных становится критически важной. По сегодняшнему опыту, AI очень хорошо помогает в моделировании. Ведь моделирование - это набор правил, которым следуют разработчики. Если мы создадим правила для AI, добавим необходимый контекст, то получится очень эффективно.

4. DuckDB vs Spark
Spark всё ещё нужен для реально больших данных. Но огромная часть "больших" задач на практике - это просто неоптимизированные маленькие задачи. DuckDB справляется с ними в разы проще и дешевле.

Вывод: Простота побеждает. AI не заменяет инженеров, а меняет их фокус - от написания SQL к проектированию данных и контролю качества.

Инжиниринг Данных

26 May 2026 08:59

Поиск работы за рубежом часто выглядит как хаос: десятки джоб-бордов, LinkedIn, рефералы, противоречивые советы

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

AgileFluent вот уже 5 лет помогают IT и Digital специалистам искать работу на международке: 800+ офферов в 32 странах, большая команда топовых экспертов и собственная платформа по откликам и нетворку.

Ребята ведут крутой канал про международку, где делятся:
✔️ историями тех, кто переехал и зарабатывает в валюте,
✔️ разборами резюме и LinkedIn профилей,
✔️ гайдами, статьями и чек-листами, которые кратно упрощают поиски

Если давно думаешь о работе за рубежом — это хороший момент начать. Подписывайся на ребят🙂

👉 Подписаться

Реклама. ООО «Эджайл», ИНН 7810964334, erid:2VtzqxL664g

Инжиниринг Данных

23 June 2026 04:44

В одной компании VP Engineering поделился документом «Как работать со мной».

Делюсь ключевыми тезисами.

🎯 Роль лидера — не контролировать, а разблокировать
Его приоритеты: дать тебе возможность работать, помочь с аналитикой и поддержать твой карьерный рост. Он заходит в проект на старте, но как только видит, что ты взял ownership — отступает. Если начинает микроменеджить — ему можно прямо написать в Slack: «Слушай, я справлюсь, не нужно».

📡 Никаких сюрпризов — ни вверх, ни вниз
Главный принцип: держи в курсе. Не нужно писать эссе — достаточно короткого сообщения в Slack. Но он никогда не должен узнавать о проблемах или рисках последним.

✍️ Коммуникация: сначала письменно, потом голосом
Формат по умолчанию — краткие буллеты. Полные предложения не нужны. Если переписка становится запутанной — переходим в Slack huddle. Любой апдейт строится по схеме: что случилось → почему это важно → что делаем дальше.

📋 Еженедельные рефлексии — обязательно
Каждую неделю — короткий документ: достижения, проблемы, вызовы, кого хочется отметить. Не более 15 минут. Можно использовать AI. Зачем это нужно?

🧠 Для директоров и senior-менеджеров — отдельная планка
Приходи с проблемой — приноси и решение. Хотя бы черновое. Просто «пожаловаться» — это не лидерство. Принимай решения самостоятельно там, где у тебя есть контекст и полномочия. Эскалируй осознанно — только если исчерпал варианты и у тебя есть рекомендация.

Инжиниринг Данных

20 June 2026 02:11

🔥 Разбор AWS-стека от и до (часть 4) — 2,5 часа живого кодинга

Видео 👉 https://youtu.be/nWn_hDuL4jc

Провели мощную сессию по AWS Glue, MWAA Airflow, dbt Core и Iceberg Lakehouse. Всё строилось с нуля через CloudFormation с AI-агентом (Claude в Cursor) — отличный пример того, как выглядит AI-assisted инфраструктура на практике.

⚙️ Glue & Spark
• Glue Data Catalog — управляемый Hive-style метастор; краулеры автоматически обнаруживают схемы в S3
• Типы Glue-джобов: визуальный редактор, ноутбуки, Python Shell и PySpark-скрипты
• GlueContext vs SparkContext и DynamicFrame vs DataFrame — и почему большинство команд остаётся на чистом Spark
• Подбор размера кластера, query plans и Spark UI — та же логика применима к Snowflake-вархаусам
• coalesce vs repartition — управление количеством и размером выходных файлов в распределённых вычислениях
• Код Glue-джобов хранится как файлы в S3 — это открывает возможности для версионирования и release-стратегий
• Glue Docker-образ для локального запуска и тестирования Spark-джобов в CI/CD

🏔️ Athena & Lakehouse
• Amazon Athena — serverless SQL-движок на базе Presto/Trino; оплата за TB отсканированных данных + S3
• Partition projections vs Hive-style partition metadata; обработка JSON SerDe
• dbt + Apache Iceberg lakehouse через dbt-athena-community (Docker-образ на ECR)
• Внутренности Iceberg: папки data и metadata, manifest-файлы, manifest lists и снапшоты
• Один dbt-проект, нацеленный одновременно на Athena, Redshift и Snowflake

🔄 Оркестрация & MWAA
• Managed Airflow (MWAA): синхронизация DAG'ов через S3, интеграция с Secrets Manager и CloudWatch
• Почему MWAA — это НЕ serverless: VPC, биллинг 24/7 и когда локальный Airflow выгоднее
• Как хостить dbt с Airflow: DAG'и в S3 vs запуск dbt в контейнере на ECS/Batch
• EcsRunTaskOperator — стандартный production-паттерн для связки dbt + Airflow
• Добавили Airflow MCP-сервер, чтобы AI-агент мог инспектировать и триггерить DAG'и

💡 Главный вывод: AI строит инфраструктуру быстро — но именно понимание сервисов, трейдоффов и стоимости отличает инженера, который шипит проекты, от того, кто просто копирует код.

Код здесь 👉 https://github.com/surfalytics/data-ingestion-github-to-snowflake/pull/1

Инжиниринг Данных

19 June 2026 17:55

Сейчас самый большой hype это дата центры и AI в космосе. Bloomberg выпустил небольшое видео https://youtu.be/cNI4N3-FcEI?si=JFuu3XZSf2eIbbfv

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

Инжиниринг Данных

17 June 2026 16:47

Spark Connect для ИТ-команд: упрощаем разработку и работу с данными 😎

Многие компании уже используют Apache Spark для обработки и трансформации данных, но часто только в привычных сценариях.

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

▶️

Интерактивная разработка со Spark через локальную IDE и Spark Connect;

▶️

Анализ и визуализация данных в Jupyter Notebooks;

▶️

Построение ETL‑процессов в dbt на чистом SQL;

▶️

Сценарии использования Spark для разработчиков, аналитиков и специалистов Data Lakehouse;

▶️

Возможности Evolution Managed Spark для интерактивной работы с данными.

Инжиниринг Данных

16 June 2026 21:22

Недавно у одного душного менеджера возник вопрос — почему я иногда опаздываю на митинги, почему иногда камера выключена и т.п. Он рассказал, что у него низкий порог терпимости ко всяким махинациям (намекая на возможные посторонние дела).

При этом компания уволила 600 инженеров неделю назад и закрыла один из офисов.

Возможно, такой наезд был бы ОК лет 5–6 назад. Но сегодня подобные наезды лишь подчёркивают, что команде и компании непонятно, в каком направлении двигаться и что делать. Задача менеджера — создавать бурную деятельность, и он будет измерять её через активность в Slack и количество Zoom-встреч с включённой камерой.

Что мы имеем по факту? Ни одна компания не даст вам гарантий, что вас не уволят в течение 6–12 месяцев, но при этом каждая компания ожидает, что вы — «их собственность», и если вам платят зарплату, то вы должны быть благодарны и жертвовать своими интересами ради высшей миссии.

Это не значит, что можно не работать. Работать нужно, но нужно работать так, чтобы было интересно и ненапряжно. И если у вас есть возможность заниматься чем-то ещё в свободное время — это замечательно, даже если это время приходится на середину рабочего дня. Ведь вам платят не за часы, отсиженные на Zoom, а за результат.

Инжиниринг Данных

16 June 2026 05:07

Как там уже запустили курсы AI разработчик - от 0 до 1млн рублей за 3 месяца?

Инжиниринг Данных

12 June 2026 17:17

🚀 Быстрый старт в AI-аналитику с DataLens

16 июня в 12:00 (мск) — вебинар о том, как работает AI-аналитика в DataLens.

Разберём всё по делу:
🤖 Большое обновление Нейроаналитика — агентский режим под капотом
📊 Новые сценарии: виджеты дашборда, рассылки, встройки, публикации
🔧 Внешние AI-инструменты для эффективной работы с DataLens
☁️ Облако и on-premises — что доступно и как
🗺 Планы развития встроенных AI-возможностей и инфраструктуры для внешних AI

Регистрируйтесь — и приходите с вопросами 👇

Инжиниринг Данных

11 June 2026 10:11

📚 Вышел очень крепкий хэндбук по A/B-тестам — его подготовили в команде платформы Trisigma от Авито Тех.

Обычно такие материалы уходят либо в сухую теорию, либо в абстрактные примеры. Здесь наоборот все завязано на реальных продуктовых кейсах и практических ошибках, с которыми сталкиваются команды в продакшне.

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

Отдельно разобраны:
– классификация метрик (goal, proxy, guardrail, debug);
– закон Кэмпбелла;
– OEC;
– атомарный дизайн метрик;
– Central Limit Theorem без академической духоты.

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

Хэндбук бесплатный. Получить можно через бота. Да, там встроена подписка на канал, но контент у ребят действительно достойный.
К тому же, команда Trisigma отдает его бесплатно.

Инжиниринг Данных

09 June 2026 19:12

Очевидный факт - рост AI инженеров. Сейчас это уже не LLM researcher, и человек, который знает как работать с моделями, как их выбирать, настраивать, проверять качество, и отслеживать стоимость.

Сейчас отличное время войти в эту профессию и уже на месте разбираться как лучше это использовать.

Инжиниринг Данных

09 June 2026 05:31

Сегодня прошла замечательная история. На моем любимом проекте в Technical Safety BC, где работают пенсионеры и полу пенсионеры (в прямом смысле ждут свою пенсию), где текущий дата инженер использует голосовые помощники, чтобы делать пайплайны в SSIS, потому что потерял зрение на старости лет - меня уволили одним днем, за то, что в проекте по миграции on-premises на AWS я сделал s3 bucket public.

Хотел визуализировать excel табличку с прогрессом как сайт в тестовом AWS аккаунте.

PS скорей всего они просто устали, что я слишком на них газовал и говорил, что они некомпетентные и ленивые бараны.

Инжиниринг Данных

03 June 2026 06:11

В наше время самый кайф это попасть в зону, где нет сети. Следующие 5 дней буду плавать на paddle board в тихом океане и ничего делать🏄‍♂️

Инжиниринг Данных

30 May 2026 01:18

Почему ваша команда дата-инженеров всегда выглядит несчастной и выгоревшей:
1. Они тратят большую часть времени на переработку плохо спроектированных таблиц в SQL
2. На них кричат, когда ломается чужой код
3. Никто не пишет тесты, но все ожидают, что они будут отлаживать сбои
4. Дежурство — это кошмар
5. Качество данных не ценится так, как функции с очевидным ROI
6. Сколько бы времени они ни тратили на сокращение облачных расходов — этого всегда мало
7. Им редко удаётся заниматься инновационной работой
8. Они — одна из наименее публично признаваемых инженерных команд (привет, Безопасность)
9. Это крайне сложная роль для замещения = долгое время с открытыми вакансиями
10. У них маленький бюджет для огромной и дорогостоящей проблемы
11. Они чаще всего первыми получают обвинения и последними — похвалу
12. Количество сервисных тикетов никогда не уменьшается
13. Плохое моделирование данных делает их жизнь радикально сложнее
14. «Больших побед» для празднования значительно меньше
15. Им не хватает контроля для внедрения лучших практик управления данными
16. Управление данными никогда не в приоритете… пока внезапно не становится им
17. Их редко привлекают, когда стартует новый крупный дата-проект…
18. …но в итоге именно им приходится разгребать весь беспорядок
19. Их редко уведомляют об изменениях в upstream-системах, вызывающих сбои пайплайнов
20. Никаких контрактов с поставщиками данных!

Инжиниринг Данных

27 May 2026 23:39

Сегодня проводил собес по system design DE. У Кандидата было резюме на 10 страниц текста! Сами понимаете серьезный кандидат. Я приложил задачку и результат.

Чувак не в теме особо про dbt, Snowflake и тп. Прям как из нашего отечественного дата инжиниринга, но нет, он был из Индии и уже много лет работает дата инженером. Как я понял весь его опыт был про Spark Jobs на Hadoop. И в основном на этапе data ingestions.

Нужно ли знать dbt и Snowflake всем? Нет не нужно. Но это, как бы, самое популярное на рынке и для общего развития неплохо бы знать в общих чертах, как и duckdb, и тп. Это называется grow mindset. Сейчас вообще можно ничего не знать, но работу делать. А если вы еще и понимаете, что делаете, то тогда работа приносит удовольствие.

Идеально, когда вы понимаете и знаете, а ваша команда не знает и не понимает, как и ваш менеджер😁

PS я еще провожу собеседование на CTO и инженера по спутникам.

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

Инжиниринг Данных

27 May 2026 06:46

В cвой личный slack добавил себе Notion бота из Notion Calendar, который собирает все встречи и присылает мне список на завтра и время во сколько вставать (за 15 минут до 1й встречи). Notion Calendar позволяет собрать все календари вместе, а если календарь закрыт, я вручную дублирую событие в личный календарь.

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

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

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

Но я пока по старинке! А как вы себе упростили рабочий процесс?

PS reschedule конфликты - для слабаков🍪🍪

Инжиниринг Данных

25 May 2026 18:15

Если вам интересен соревновательный ML — у Яндекса скоро завершается регистрация на Yandex ML Challenge.

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

Из задач:
— LLM / foundation models
— CV
— RL
— оптимизация нейросетей

Старт — 21 мая. На всё дают 11 дней и 40 сабмитов на каждую задачу.

Топ-100 участников попадут в очный финал на Young Con в Москве.
Победителю — 1 млн рублей, топ-15 получат устройства от Яндекса.

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

Регистрация ещё открыта.