По следам SmartData посмотрим, что происходит на западных конференциях.

Наткнулся на пост Giacomo Barone (CEO & Co-Founder hiop) — 5 Takeaways from Big Data London 2025 You’ll Soon Regret Reading

Очень меткое отражение того, что происходит сегодня в мире data engineering.
Бароне пишет, что конференция напоминала Чайнатаун в Новый год — шум, огни, бренды и маркетинг под видом науки.

Многие доклады, по его словам, выглядели как README, зачитанные со сцены.
Вместо реальных кейсов — красивые слайды и фразы вроде наш новый AI-фичер, которые по сути означают поверьте в магию и купите.
Даже противостояние Databricks и Snowflake, некогда символ технологического прогресса, превращается в сериал с предсказуемыми сюжетами.

Но за всей этой иронией у статьи есть более глубокая мысль.
Бароне говорит, что инженерии в data engineering становится всё меньше, а overengineering — всё больше.
Мы строим сложные системы, чтобы компенсировать не технические, а организационные проблемы.
И, похоже, именно это наконец начинают понимать даже на больших сценах.

Он также подмечает, как слово AI стало универсальным маркетинговым штампом.
Им теперь называют всё подряд — от версий файлов до визуализаций.
Когда каждый заявляет о революции, революции уже не происходит.
И возможно, пользователи действительно начинают видеть сквозь этот шум.
(Лично у меня уже возникают сомнения при появлении нового инструмента для DE — настолько ли он хорош или это очередной вайб-продукт, который может все сломать.)

Самый сильный тезис статьи — Big Data мертвы.
Бароне напоминает: лишь доли процента аналитических запросов действительно нуждаются в распределённых системах вроде Spark.
Основные проблемы — не в масштабе, а в смысле, качестве и связи данных с реальными бизнес-целями.
(На SmartData деды все еще обсуждают, с какого объема начинается биг дата?)

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

Кстати запись прошлогодней Big Data London можно посмотреть на youtube

@data_whisperer

Arc — новый time-series warehouse на базе DuckDB, Parquet и MinIO

Появился интересный проект — Arc, хранилище временных рядов, ориентированное на высокую скорость загрузки и аналитических запросов через SQL.
В основе — знакомый стек:
DuckDB как движок запросов, Parquet для хранения и MinIO как S3-совместимый стор для масштабирования.

Проект пока в alpha-версии, так что его стоит рассматривать как технический превью, а не готовое решение для продакшена.
Разработчики активно добавляют фичи и оптимизируют API, поэтому сейчас Arc подходит скорее для тестовых и исследовательских задач.

Из заметного: быстрая загрузка данных через бинарный протокол MessagePack, поддержка InfluxDB Line Protocol (можно использовать как drop-in replacement) и JSON, кэширование результатов запросов, импорт из InfluxDB, TimescaleDB и HTTP-источников.
Развёртывание через Docker, с health-чеками и мониторингом из коробки.

Если упростить — это попытка сделать лёгкий, современный time-series warehouse без громоздкости классических TSDB, но с возможностью горизонтального роста за счёт MinIO и гибкости DuckDB.

@data_whisperer

Пока я отчаянно пытаюсь найти время на продолжение цикла постов про Concurrency & Consistency хочу поделиться классной методичкой по потоковой обработке данных от признанного специалиста в этой области. Считаю что она незаслуженно обделена вниманием, поэтому исправляю это.

Making Sense of Stream Processing. The Philosophy Behind Apache Kafka and Scalable Stream Data Platforms

В далеком 2016м, Мартин Клепманн (да, это автор того самого кабанчика) написал методичку на 180 страниц в которой очень понятно и доступно рассказывает про:
- События, потоки данных.
- DDD, CQRS.
- Change Data Capture паттерн и при чем тут Kafka.
- Как тюнить базы данных под разные сценарии, особенно аналитические.

Чем хороша книга - в ней много понятных примеров и иллюстраций. Именно её я советую сейчас и советовал ранее своим менти, когда получал запрос на материалы про потоки данных "понятным языком".

Скачать книгу можно бесплатно с сайта автора: https://martin.kleppmann.com/papers/stream-processing.pdf

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

P.S. Материал для постов по Concurrency почти готов, скоро будут посты. Будем велосипедить примитивы синхронизации с нуля и сравнивать с эталонными реализациями заодно щупая на практике все проблемы конкурентного программирования.

Apache Iceberg vs Delta Lake vs Apache Hudi - Feature Comparison Deep Dive

С ростом популярности архитектуры data lakehouse интерес к сравнению трёх ключевых open source-проектов — Apache Hudi, Delta Lake и Apache Iceberg — только усиливается.
В октябре 2025 года статья была обновлена с учётом последних релизов и новых возможностей каждого из форматов.

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

Основной вывод остаётся прежним: формат таблиц — это только основа, но реальная сила в том, насколько богаты инструменты, которые строятся поверх него. Hudi, например, активно развивает полноценные платформенные сервисы, делающие работу с lakehouse-данными проще и управляемее.

И наконец, важный показатель — сообщество. От его активности зависит не только темп развития, но и зрелость экосистемы в целом. В статье приведено сравнение динамики коммитов, числа контрибьюторов и вовлечённости комьюнити Hudi, Delta и Iceberg за последние 12 месяцев — и именно здесь видна настоящая картина того, кто задаёт ритм в мире open data lakehouse.

Apache Hudi пока что не так популярен, как Iceberg но по заявленным фичам выглядит интереснее.
Если вы еще не знакомы с этим форматом, то на канале был пост Apache Hudi - From Zero To One - 10-part series

@data_whisperer

Building a Better Lakehouse: From Airflow to Dagster

Нашёл ещё один отличный туториал по Modern Data Stack — на этот раз про то, как развернуть локальный lakehouse с нуля.

Автор вдохновился известным постом Build a lakehouse on a laptop with dbt, Airflow, Trino, Iceberg, and MinIO (тоже очень советую почитать), но пошёл дальше: заменил Airflow на Dagster и подробно показал, где Dagster выигрывает — от удобства разработки до более прозрачного мониторинга пайплайнов.

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

Чего не хватает в туториале, дак это — UV и Ruff

@data_whisperer

S3Sync - действительно быстрый инструмент синхронизации для S3

Основная особенность: очень высокая скорость. Средняя скорость листинга составляет около 5 тыс. объектов/сек для S3. При 128 рабочих процессах средняя скорость синхронизации составляет около 2 тыс. объектов/сек (небольшие объекты 1–20 кб) (ограничено скоростью восходящего канала 1 Гбит).

Возможности:
- многопоточная загрузка/выгрузка файлов
- возможна синхронизация несколькими способами:
* S3 в локальную FS
* Локальная FS в S3
* из S3 в S3
- повторная попытка при ошибках
- текущая статистика
- ограничение скорости по объектам
- ограничение скорости по полосе пропускания
- гибкие фильтры по расширению, Content-Type, ETag и mtime объекта

https://github.com/larrabee/s3sync

Посвящается южнокорейским коллегам.

Опубликовано в @gitgate

#s3 #sync

Осень — время конференций.

Не успел отойти от SmartData, как на горизонте уже новая интересная серия — Podlodka Techlead Crew.

С 13 по 17 октября выйдет новый сезон, посвящённый теме «Архитектурные антипаттерны».

Будут говорить про ошибки, которые ломают архитектуру, и о том, как их не допустить.

В программе — практичные и очень прикладные темы:

Модульный монолит: убийца микросервисов.

Почему часть преимуществ микросервисов можно получить и без них, и как монолит помогает снизить сложность и экономить ресурсы — Денис Цветцих

Дизайн-доки: инженерная культура в FAANG.

Как обсуждать архитектуру до кода, избегать холиваров и сделать дизайн-доки реально полезными — Дмитрий Волыхин

Error Handling: от боли к порядку.

Как превратить хаос в интеграциях через API в систему с понятными стандартами — Евгений Лукьянов

Круглый стол.

Архитектурные антипаттерны: как их вовремя распознать, какие бывают «звоночки» и как действовать, когда уже поздно — Алексей Кашин, Салих Фахрутдинов, Андрей Шарапов

Все темы максимально прикладные — не про красивые слайды, а про то, что можно использовать уже в следующем спринте.

Отдельно отмечу доклад, который будет особенно интересен тем, кто работает с данными.

Архитектура хранилища данных для вашего проекта.

Разберём, как устроены Data Warehouse, Data Lake, Lakehouse и Streamhouse, какие технологии за ними стоят и для чего они нужны. Поговорим о том, почему современное хранилище — это не только storage и compute, но и Data Governance, Data Lineage, Data Catalog, Data Quality — всё, что помогает не превратить ваш DWH в «DataTrash».

Подробности и билеты: https://podlodka.io/techcrew

Опрос по зарплатам в индустрии Data.

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

Пройти опрос: Ссылка

Результаты будут анонимные:
1. В случае если по одной компании будет менее 3 анкет, то результат будет учтен только в средней по рынку.
2. В случае набора более 3 анкет по компании, будет сформирована вилка от и до.

Публикация результатов будет в сообществах:
https://t.me/get_rejected
https://t.me/get_offered

How Not to Partition Data in S3 (And What to Do Instead)

Рано или поздно каждый data engineer сталкивается с этим моментом: вы проектируете новый data lake, и кто-то уверенно предлагает — давайте партиционируем по году, месяцу и дню!

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

Автор поста прошёл через это на практике и делится тем, что сработало (и не сработало) в реальных системах.

@data_whisperer

Что, на самом деле происходит в слиянии Fivetran и dbt

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

Коротко (TL;DR):
Fivetran зажимают с двух сторон, а dbt достиг потолка роста. Они объединяются, чтобы попытаться забрать часть денег у вендоров хранилищ данных и приблизиться с нынешних ~$10 млрд до уровня Databricks/Snowflake (~$100 млрд).

Несколько исходных предположений

1. Fivetran зажимают сверху со стороны хранилищ (Databricks, Snowflake), которые всё чаще включают функциональность EL (extract-load) прямо в свои корпоративные контракты.
Зачем вашей IT-команде просить юристов рассматривать ещё один вендорский договор (и тратить на это сотни тысяч долларов), если можно просто взять один контракт, где уже всё есть?
Тем более что выгода не в ETL, а в вычислениях, именно там зарабатываются основные деньги.
2. Fivetran зажимают снизу — со стороны более дешёвых и массовых решений вроде Airbyte, DLTHub и других.
3. У dbt рост практически остановился — проект достиг своего пика.

Вот цитата из поста dbt What is Open Data Infrastructure

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

Вендоры увидели в этом возможность: расширить свои продукты и занять новые ниши. Это не хорошо и не плохо само по себе. Сквозные решения действительно дают более чистую интеграцию, лучший пользовательский опыт и снижают стоимость владения. Но они также ограничивают выбор, создают эффект lock-in и могут повышать цены. Всё зависит от деталей.

За время облачной эры индустрию данных фактически захватили пять гигантов, у каждого из которых выручка давно перевалила за миллиард долларов в год: Databricks, Snowflake, Google Cloud, AWS и Microsoft Azure.
Каждый из них начинал с базового набора — аналитический движок, хранилище и каталог метаданных. Но за последние пять лет, по мере того как развивалась концепция Modern Data Stack, клиенты начали просить их “делать больше”. И они ответили. Теперь каждый из этих пяти игроков предлагает решения по всему стеку: ingestion, трансформации, BI, оркестрация и многое другое.

По сути, они стали всё-в-одном платформами данных: принеси данные — и делай с ними всё внутри их экосистемы.

Возвращаясь к Fivetran

Чтобы понять вторую часть уравнения, достаточно просто зайти на страницу с ценами любого конкурента — Fivetran дорог, и это факт.
Третье утверждение (что dbt достиг пика) формально не доказано, это скорее моё наблюдение.

Что они пытаются сделать

Если принять эти три пункта, становится понятно, куда движется Fivetran + dbt.
Новый игрок (назовём его условно DBTran) пытается перевернуть игровое поле в отношении хранилищ данных.

Обычно именно хранилище — это центр вселенной, а все остальные инструменты (каталоги данных, слой трансформаций, семантический слой и т.д.) работают вокруг него и постепенно становятся частью предложения этих вендоров. Поэтому Snowflake и Databricks оцениваются в сотни миллиардов.

DBTran же хочет сделать наоборот — сделать хранилище товаром (commodity) и взять под контроль всё остальное.

Как это возможно

Главная технологическая ставка здесь — Apache Iceberg.
Когда используется Iceberg, вычисления и хранение разделены.
Традиционные вендоры хранилищ — BigQuery, ClickHouse, Snowflake — становятся просто вычислительными движками, которые можно менять местами.

А всё остальное берёт на себя DBTran:

- Хранилище: S3, GCS и т.д.
- Вычисления: Snowflake, BigQuery и др.
- Каталог: DBTran
- ETL: DBTran
- Трансформация: DBTran
- Семантический слой: DBTran

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

@data_whisperer

MetricFlow

dbt выложили в open-source семантический слой MetricFlow под лицензией Apache 2.0

MetricFlow — это семантический слой, который упрощает определение и управление метриками. Он компилирует эти определения в понятный и переиспользуемый SQL-код, обеспечивая согласованные и точные результаты при анализе данных по нужным атрибутам (измерениям).

Название «MetricFlow» отражает подход: запросы метрик преобразуются в план запроса на основе потоков данных, который затем оптимизируется и переводится в SQL конкретного движка базы данных.

@data_whisperer

Jack Vanlightly: Why I’m not a fan of zero-copy Apache Kafka-Apache Iceberg

Интеграция потоковых и аналитических систем часто соблазняет инженеров стремиться к архитектурам zero-copy, которые обещают эффективность за счёт объединения слоёв хранения.

Автор утверждает, что дизайн Kafka–Iceberg с нулевым копированием вместо этого вводит серьёзные вычислительные накладные расходы, конфликты эволюции схем и тесную связанность, которая размывает чёткие границы систем.

В блоге отстаивается традиционная материализация — поддержание отдельных, но скоординированных копий, — поскольку это сохраняет изоляцию производительности, гибкость схем и операционную ясность в системах Kafka и lakehouse.

Вообщем расходимся, очередной buzzword

@data_whisperer

OpenDbt

Ну вот и начали появляться форки dbt-core.

OpenDBT динамически расширяет dbt-core.
Уже добавляются значительные функции, которых нет в оригинальном dbt-core.
Например интеграция DLT и обновленный UI.
Поддержка нескольких проектов с cross project ref models.
Это путь к полноценному форку, управляемому сообществом.

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

@data_whisperer

Тимлид — быть или не быть?

Пока в тимлиды я не стремлюсь — мне комфортно в роли разработчика.
Но однажды я уже пробовал. И это было… больно.

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

Теперь решил подойти к этому с другой стороны:
записался на курс по тимлидству от Школы Сильных Программистов.

Почему именно курс по тимлидству?

Потому что код сейчас может написать и AI, а вот взаимодействие в команде — эта штука ему уже неподсильна.

Курс по Developer Experience у них уже проходил — формат классный, подача практичная, инсайтов много.
От нового жду не меньше.

Пост не реклама — курс куплен за свои кровные, поэтому ссылки не оставляю😅

Буду делиться впечатлениями по ходу.

@data_whisperer

Дайджест дата новостей за неделю

Pinterest и CDC:
Перенос сотен ТБ данных из MySQL в аналитику через Kafka Connect + Debezium. Разделение конфига и логики позволяет безопасно обновлять коннекторы, перераспределять партиции и обеспечивать exactly-once семантику. Избегают дубликатов с метаданными и идемпотентными реплеями, плюс правила эволюции схем.

Uber и Pinot:
Переход от сложной Presto-архитектуры (Neutrino) к упрощённой без брокеров с Multi-Stage Engine (MSE) Lite. Улучшает надёжность, снижает задержки и масштабирует OLAP-запросы для миллионов ежедневных аналитик пользователей, поиска логов и трейсинга.

Netflix: Рекомендации в реальном времени (Часть 3):
Двухфазный подход для live-событий (типа NFL): prefetch через GraphQL в Domain Graph Service во время просмотра для баланса нагрузки, затем WebSocket-рассылка низко-кардинальных сообщений (ключи состояний + timestamps) на 100M+ устройств в критические моменты, чтобы не пропустить события.

RAG для enterprise: Модульная архитектура с аутентификацией, guardrails, переписыванием запросов, кастомными энкодерами, масштабируемым инжингом документов и выбором векторных БД. Добавьте reranking, hybrid search, chunking; мониторинг LLM, фидбек и кэш для надёжности и экономии.


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

Собери свою БД: Построение key-value БД с нуля показывает эволюцию от простых append-only файлов с компакцией (для durability) к индексации и сортировке (для скорости чтения, но медленнее записи).
Основа LSM-trees, как в LevelDB и DynamoDB.

RAG мёртв? Взлёт Context Engineering и семантических слоёв для Agentic AI:
RAG — только старт; теперь контекст-инжиниринг включает запись, компрессию, изоляцию и селекцию с метаданными, policy-as-code и мультимодальностью. Графовые знания обеспечивают объяснимость и масштабируемость; новые метрики (релевантность, groundedness, provenance, recency) для enterprise.

@data_whisperer

Deploy dlt pipelines

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

Первые 2 модуля по Airflow и Prefect уже доступны.

@data_whisperer

AI Dev Tools Zoomcamp 2025

Уже скоро стартует новый бесплатный курс от Алексея Григорьева — автора легендарных ML Zoomcamp и Data Engineering Zoomcamp. На этот раз тема — ИИ в разработке.

AI уже меняет привычный процесс создания софта:
от генерации и тестирования кода до деплоя и CI/CD — умные инструменты помогают разработчикам работать быстрее, точнее и с меньшими усилиями.

18 ноября начинается AI Dev Tools Zoomcamp 2025 — курс, где вы не просто узнаете про AI-инструменты, а попробуете их в деле:
как встроить ИИ в свой рабочий процесс и даже создать собственного AI-агента, который умеет генерировать реальные приложения.

Если хотите разобраться, как использовать ИИ в инженерной практике — отличная возможность начать.
Регистрация уже открыта и полностью бесплатна.

@five_minutes_of_data

ООП в Python на примере Кошмара перед Рождеством

Обычно перед halloween появляются небольшие тематические курсы или квесты по программированию.
На этот раз наткнулся на такой бесплатный курс на Stepik.

Этот курс даст вам возможность изучить основы ООП на Python через мульт Тима Бёртона "Кошмар перед Рождеством". Вместо традиционных примеров, мы будем использовать историю Джека Повелителя Тыкв, чтобы глубже понять такие ключевые понятия ООП, как наследование, инкапсуляция, полиморфизм и композиция.

@data_whisperer

RustFS — это высокопроизводительное программное обеспечение для распределенного хранения объектов, созданное с использованием Rust, одного из самых популярных языков программирования в мире. Наряду с MinIO, он обладает рядом преимуществ, таких как простота, совместимость с S3, открытый исходный код, поддержка data lakes, искусственного интеллекта и больших данных. Кроме того, он имеет более удобную и либеральную лицензию с открытым исходным кодом по сравнению с другими системами хранения, так как разработан под лицензией Apache. Поскольку Rust является его основой, RustFS обеспечивает более высокую скорость и безопасные распределенные функции для высокопроизводительного хранения объектов.

@data_whisperer

Как DiDi выбрала StarRocks вместо ClickHouse для real-time риск-инжиниринга

DiDi — крупнейший китайский сервис такси с 550 млн пользователей и огромными объёмами транзакций.
Для таких систем real-time риск-инжиниринг — критичный компонент.
Нужно быстро определять подозрительные операции, отклонять заявки по кредитам и анализировать поведение водителей и пассажиров — всё в реальном времени.

Исторически такие задачи решают через Lambda- или Kappa-архитектуры.
Lambda разделяет потоки и батчи, что создаёт дублирование логики и задержки.
Kappa убирает batch-слой, но не справляется с историческими данными и хранением.
DiDi пробовали унифицировать вычисления через Flink и Spark — но оказалось, что поддерживать и мигрировать всё это слишком дорого.

Следующий шаг — поиск движка, который позволит объединить real-time и офлайн фичи.
В списке кандидатов оказались ClickHouse и StarRocks.

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

- обновления и upsert’ы работают неэффективно.
- при большом количестве параллельных запросов растёт латентность.
- слабая интеграция с BI-инструментами без доп. прослоек.

StarRocks, напротив, предложил то, что DiDi как раз искала:

- MPP-архитектура и векторное исполнение, которые дают стабильную производительность при высоких нагрузках.
- реальные апдейты и стриминг-инжест без необходимости пересчитывать всё хранилище.
- умные materialized views и MySQL-протокол, что позволило бизнес-командам писать запросы привычным SQL’ем и использовать стандартные дашборды.
- поддержка lake-форматов, что облегчает интеграцию с существующей инфраструктурой.

В тестах на таблицах с миллиардами строк StarRocks показал более чем 80% сокращение задержек и позволил команде выпускать новые фичи не за 5 дней, как раньше, а за часы.

Сейчас DiDi использует один StarRocks-кластер для risk features и планирует расширять архитектуру, добавляя отказоустойчивость и поддержку log-based источников.

StarRocks для них стал не просто OLAP-движком, а основой новой stream-batch unified архитектуры — реальной альтернативой громоздким Lambda-пайплайнам.

Читать полный пост тут

@five_minutes_of_data

A Great Day Out With... Apache Kafka

Интерактивная карта всей экосистемы Kafka.

В этой карте собрано все, что вам может понадобиться при работе с Kafka.

Это:
- Книги
- Блоги
- Учебные материалы
- Инструменты
и многое другое.

Карту составил Gunnar Morling - разаработчик в Confluent, один из разработчиков Debezium и автор kcctl (open-source CLI тулза для работы с Kafka)

@five_minutes_of_data