5 minutes of data

Что, на самом деле происходит в слиянии 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 Возвращаясь к 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

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

Что, на самом деле происходит в слиянии Fivetran и dbt? Думаю, все уже слышали о самом свежем слиянии в мире data-индустрии. Было довольно трудно собрать воедино всю картину — зачем это делается и что на самом деле стоит за этим шагом. Попробую объяснить, как я это вижу и почему это происходит. Коротко (TL;DR): Fivetran зажимают с двух сторон, а dbt достиг потолка роста. Они объединяются, чтобы попытаться забрать часть денег у вендоров хранилищ данных и приблизиться к оценке Databricks — с нынешних ~$10 млрд до уровня Databricks/Snowflake (~$100 млрд). Несколько исходных предположений 1. Fivetran зажимают сверху — со стороны хранилищ (Databricks, Snowflake), которые всё чаще включают функциональность EL (extract-load) прямо в свои корпоративные контракты. Зачем вашей IT-команде просить юристов рассматривать ещё один вендорский договор (и тратить на это сотни тысяч долларов), если можно просто взять один контракт, где уже всё есть? Тем более что выгода не в ETL, а в вычислениях — именно там зарабатываются основные деньги. 2. Fivetran зажимают снизу — со стороны более дешёвых и массовых решений вроде Airbyte, DLTHub, Sling и других. 3. У dbt рост практически остановился — проект достиг своего пика. Подтверждение (из блога 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) пытается перевернуть игровое поле в отношении хранилищ данных. Обычно именно хранилище — это центр вселенной, а все остальные инструменты (каталоги данных, слой трансформаций, семантический слой и т.д.) работают вокруг него и постепенно становятся частью предложения этих вендоров. DBTran же хочет сделать наоборот — сделать хранилище товаром (commodity) и взять под контроль всё остальное. Как это возможно Главная технологическая ставка здесь — Apache Iceberg. Когда используется Iceberg, вычисления (compute) и хранение (storage) разделены. Традиционные вендоры хранилищ — BigQuery, ClickHouse, Snowflake и другие — становятся просто вычислительными движками, которые можно менять местами. Хранилище — это обычный S3-бакет. А всё остальное берёт на себя DBTran: - Хранилище: S3, GCS и т.д. - Вычисления: Snowflake, BigQuery и др. - Каталог Iceberg: DBTran - ETL/EL: DBTran - Слой трансформаций: DBTran - Семантический слой: DBTran И при желании — добавить ещё больше.

How Not to Partition Data in S3 (And What to Do Instead) Рано или поздно каждый data engineer сталкивается с этим моментом: вы проектируете новый data lake, и кто-то уверенно предлагает — давайте партиционируем по году, месяцу и дню! На первый взгляд идея кажется идеальной — ведь именно так мы привыкли структурировать данные по времени. Но в реальности S3 и облачные lake-хранилища играют по другим правилам, и такое решение может обернуться настоящей болью: перегрузкой метаданных, медленными запросами и лишней сложностью в управлении. Автор поста прошёл через это на практике и делится тем, что сработало (и не сработало) в реальных системах. @data_whisperer

Опрос по зарплатам в индустрии Data. Опрос проводится для понимания кто сколько платит и в каких индустриях зарплаты больше. Пройти опрос: Ссылка Результаты будут анонимные: 1. В случае если по одной компании будет менее 3 анкет, то результат будет учтен только в средней по рынку. 2. В случае набора более 3 анкет по компании, будет сформирована вилка от и до. Публикация результатов будет в сообществах: https://t.me/get_rejected https://t.me/get_offered

Антипаттерны не щадят даже лучших. С 13 по 17 октября пройдет новый сезон Podlodka Techlead Crew “Архитектурные антипаттерны”. Обсудим ошибки, которые ломают архитектуру, и как их избежать. В программе: 🛠️ Модульный монолит: убийца микросервисов. Какие плюсы микросервисов реально доступны и без них и как монолит снижает сложность и экономит ресурс — Денис Цветцих 📑 Дизайн-доки — инженерная культура в FAANG. Как обсуждать архитектуру до кода, избегать холиваров и делать дизайн-доки полезными — Дмитрий Волыхин ⚡ Error Handling: от боли к порядку. Стандарты обработки ошибок вместо хаоса при интеграциях через API — Евгений Лукьянов 🔍 Круглый стол. Архитектурные антипаттерны: как вовремя распознать. Первые звоночки анти‑паттернов, практические примеры и стратегии их предотвращения — Алексей Кашин, Салих Фахрутдинов, Андрей Шарапов 🧠 Всё, что обсудим, реально применимо и пригодится уже в следующем спринте Отдельно выделю доклад, который будет интересен всем, кто работает с данными. Архитектура хранилища данных для вашего проекта: Обсудим, как устроены DataWarehouse (DWH), DataLake (DL), Lakehouse (LH) и Streamhouse (SH), какие технологии для них используются и какие задачи позволяют решать эти концепции. Разберем, почему хранилище данных - это не только storage и compute, но и DataGovernence (DG), DataLineage, DataCatalog, DataQuality (DQ), которые не дают превратить ваше хранилище в "DataTrash". Подробности и билеты: https://podlodka.io/techcrew

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

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

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

Пока я отчаянно пытаюсь найти время на продолжение цикла постов про 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 почти готов, скоро будут посты. Будем велосипедить примитивы синхронизации с нуля и сравнивать с эталонными реализациями заодно щупая на практике все проблемы конкурентного программирования.

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

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

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

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 день первый Первый день оставил неоднозначные впечатления. Большинство докладов оказались очень поверхностными и пресными. От такой конференции ожидаешь большего, а не рассказов о том, как люди изобретают велосипед для data quality. Сразу вспоминается один из моих старых постов. Что понравилось: Доклад от Владимира Озерова про развитие и перспективы Apache Iceberg и почему DuckLake это пока что просто хайп а не production-ready решение. Доклад от MWS . DataRentgen: как запилить yet another lineage, не привлекая внимания санитаров. Как сделать data lineage удобным для твоей команды и выкатить его в open-source. Доклад от Navio(беспилотные авто). От бакета в S3 к Data Lakehouse: эволюция платформы данных в гонке за автономией. Ребята рассказали про переход со Spark на Polars для обработки огромных обьемов данных и как они используют Rust для ускорения Polars. Доклады второго дня кажутся более интересными. Завтра посмотрим. @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

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

Индекс страха dbt резко вырос Количество форков dbt стремительно увеличивается на фоне слухов о возможном приобретении компанией Fivetran. Ситуация становится особенно показательной в преддверии конференции Coalesce. В моменты неопределённости трейдеры выбирают золото, сторонники криптовалют — токены, а специалисты по данным — делают форки dbt. Очевидно, что в дальнейшем 90% этих форков не будут активно использоваться. Однако сам факт их появления отражает стремление сообщества к дополнительной безопасности. Сигнал очевиден: когда возникают слухи, затрагивающие инфраструктурный стек, инженеры хотят сохранить контроль. dbt-core является центральным элементом современных дата-пайплайнов, и его значимость трудно переоценить. В подобных условиях всё чаще поднимается вопрос о рисках, связанных с платформами. Положительная сторона ситуации в том, что сама технология достаточно проста. Уже дважды доказано, что можно создать интерфейс, совместимый с dbt (пример — решение SDF Labs Tobiko, ныне принадлежащее Fivetran или Lea). Поэтому остаётся лишь наблюдать за развитием событий. Вопросы к вам: Сделали ли вы форк? Рассматриваете альтернативы? @data_whisperer

Uber's Strategy to Upgrading 2M+ Spark Jobs Uber обновил Spark с версии 2.4 до версии 3.3, мигрировав более 40 000 Spark-приложений и 2 100 приложений всего за шесть месяцев. Для автоматизации процесса использовался Polyglot Piranha — инструмент с открытым исходным кодом, который парсит и переписывает код, преобразуя его в абстрактное синтаксическое дерево (AST) и применяя правила трансформации для массового внесения изменений в приложения. В результате миграции команда увидела значительные улучшения в эффективности, продолжительности и стоимости выполнения задач, включая: - 85% миграции задач: благодаря автоматизациям, таким как Iron Dome, и оркестрациям, большинство из 20 000 задач перешли на Spark 3 в течение 6 месяцев. - Улучшение производительности: более 60% задач показали прирост производительности более чем на 10%, что привело к экономии в миллионы долларов. - Рост продуктивности: автоматизация обновления сэкономила тысячи часов работы разработчиков и дата-инженеров, которые в противном случае мигрировали бы задачи вручную. В рамках этой работы несколько патчей попали в open-source. Миграция также открыла возможности для использования Kubernetes и JDK17. @data_whisperer

Вот это по настоящему Big Data. Uber Data Infrastructure part 1 part 2