Индекс страха dbt резко вырос

Количество форков dbt стремительно увеличивается на фоне слухов о возможном приобретении компанией Fivetran.
Ситуация становится особенно показательной в преддверии конференции Coalesce.

В моменты
неопределённости трейдеры выбирают золото, сторонники криптовалют — токены, а специалисты по данным — делают форки dbt.

Очевидно, что в дальнейшем 90% этих форков не будут активно использоваться. Однако сам факт их появления отражает стремление сообщества к дополнительной безопасности.

Сигнал очевиден: когда возникают слухи, затрагивающие инфраструктурный стек, инженеры хотят сохранить контроль.
dbt-core является центральным элементом современных дата-пайплайнов, и его значимость трудно переоценить.

В подобных условиях всё чаще поднимается вопрос о рисках, связанных с платформами.
Положительная сторона ситуации в том, что сама технология достаточно проста. Уже дважды доказано, что можно создать интерфейс, совместимый с dbt (пример — решение SDF Labs Tobiko, ныне принадлежащее Fivetran или Lea). Поэтому остаётся лишь наблюдать за развитием событий.

Вопросы к вам:
Сделали ли вы форк?

Рассматриваете альтернативы?

@data_whisperer

A Practical Guide to Data Lineage on Kafka Connect with OpenLineage

Этот гайд — подробное пошаговое решение для построения real-time data lineage в Kafka Connect.

К концу туториала у вас будет полноценная среда, которая отслеживает путь данных от исходного коннектора — через Kafka — до хранилищ вроде S3 и Apache Iceberg.
Вся цепочка будет наглядно визуализирована в Marquez.

Основу решения составляет OpenLineageLifecycleSmt — кастомная Single Message Transform (SMT), которая позволяет автоматически собирать lineage, не меняя сами данные.

Еще один крутой open-source репозиторий, который советую посмотреть.

@data_whisperer

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

Streaming Database

Книга от автора Streaming DataMesh - который я мельком посмотрел.

Название книги говорит само за себя.
В ней вы узнаете про перспективы развития realtime database, интеграцию с пайплайнами реального времени и построение real-time платформы данных.

Начинается книга с отсылки к выступлению Martin Kleppmann (автор кабанчика), Turning the database inside-out with Apache Samza

В первых двух главах идет обзор real-time пайплайнов, почему для real-time лучше выбирать ETL а не ELT, разбирается пример создания и обогащения clickstream.

В следующих главах идет рассказ про сами Streaming Database и инструменты, которые позволяют доставлять данные в реальном времени.

Книгу определенно стоит читать.

@data_whisperer

SmartData день первый

Первый день оставил неоднозначные впечатления.
Большинство докладов оказались очень поверхностными и пресными.

От такой конференции ожидаешь большего, а не рассказов о том, как люди изобретают велосипед для data quality.
Сразу вспоминается один из моих старых постов.

Что понравилось:

Доклад от Владимира Озерова про развитие и перспективы Apache Iceberg и почему DuckLake это пока что просто хайп а не production-ready решение.

Доклад от MWS .
DataRentgen: как запилить yet another lineage, не привлекая внимания санитаров.
Как сделать data lineage удобным для твоей команды и выкатить его в open-source.

Доклад от Navio(беспилотные авто).
От бакета в S3 к Data Lakehouse: эволюция платформы данных в гонке за автономией.

Ребята рассказали про переход со Spark на Polars для обработки огромных обьемов данных и как они используют Rust для ускорения Polars.
Так же в канале был интересный пост про Polars.

Доклады второго дня кажутся более интересными.
Завтра посмотрим.

@data_whisperer

Mooncake Labs joins Databricks to accelerate the vision of Lakebase

Совсем недавно был пост, про интересный инструмент moonlink и вот Databricks приобрел Mooncake Labs для поддержки Lakebase — базы данных OLTP, созданной на базе Postgres и легко интегрированной в платформу Databricks.

Похоже крупные компании решили скупить весь open-source, а open-source стараются сделать MVP и побыстрее продать свое решение.

@data_whisperer

SmartData второй день

Второй день конференции оказался интереснее.

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

Хороший доклад про debezium.
Из интересного узнал, как настраивать CDC для шардированых таблиц.

YugabyteDB - сходил больше ради интереса, послушать почему выбрали это решение на замену Postgres.

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

Как оцифровать платформу и ввести:
- infrastructure index
- quality index
- table usage index
- dashboard usage index
и другие.

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

В этом году нет докладов про инструменты modern data stack (dbt/dlt/duckdb/sqlmesh).
Хотелось бы послушать более глубокие доклады про Iceberg, с какими проблемами можно столкнуться, как правильно работать с потоковыми данными в Iceberg.

@data_whisperer

По следам 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