5 minutes of data

Data Engineering Design Patterns: Глава 2 — Data Ingestion Designe Patterns Продолжаю читать Data Engineering Design Patternsy, краткое summary по паттерну Compactor. Даже идеально построенный датасет со временем может превратиться в узкое место — особенно по мере его роста за счёт новых данных. В какой-то момент операции с метаданными (например, перечисление файлов) начинают занимать больше времени, чем собственно трансформации данных. Ситуация из практики. У вас стриминг из брокера в объектное хранилище, цель — чтобы batch-джобы видели данные в течение ~10 минут. Первые недели всё летает. Через три месяца выясняется, что датасет состоит из множества мелких файлов, и batch-процессы тратят львиную долю времени на перечисление и открытие файлов. Типичная картина — около 70% времени уходит на метаданные и только 30% на реальную обработку. Почему так происходит. Потоковые пайплайны и простые passthrough-загрузки рождают много мелких объектов. Объектные сторы масштабируются по объёму, но не любят избыточное количество файлов: листинг становится длиннее, I/O на открытие/закрытие растёт, а вычисления стоят на месте. Логичное решение - объединять мелкие файлы в более крупные. Этим и занимается Compactor. Он снижает накладные расходы при чтении за счёт уменьшения количества файлов. Реализация зависит от технологии: - Apache Iceberg выполняет компактизацию через rewrite data file action. - Delta Lake использует команду OPTIMIZE. Компактизация применяется не только в lakehouse, но и в других системах. Например, в Apache Kafka, который хранит только логи с ключами. Здесь процесс управляется конфигурацией: указывается частота компактизации, и система сама запускает процесс. Но принцип другой — хранится только последнее значение для ключа, что уменьшает объём, но перезаписывает данные. Баланс между стоимостью и производительностью Компактизация — это вычислительно затратная задача, особенно для больших таблиц. Поэтому её часто запускают раз в день, вне рабочих часов и отдельно от ingestion-процесса. Но у этого есть минус: потребители, которые читают ещё «несжатые» данные, не получают выгоды от оптимизации. Иногда приходится включать компактизацию прямо в ingestion-пайплайн, если это важнее, чем скорость записи. Универсального решения нет — стратегия зависит от нагрузки и сценария. Очистка После компактизации мелкие файлы могут оставаться в хранилище и продолжать влиять на операции с метаданными. Поэтому компактизация сама по себе недостаточна — её нужно дополнять очисткой. Для этого в современных хранилищах используются команды вроде VACUUM (PostgreSQL), REMOVE_ORPHANS_FILES (Iceberg). Они освобождают место, но есть риск: после удаления файлов невозможно будет откатиться к старым версиям датасета. Вывод: Паттерн Compactor помогает справиться с проблемой множества мелких файлов, снижая затраты на I/O и ускоряя работу batch-задач. Но он требует балансировки между стоимостью и производительностью, внимательного подхода к консистентности и обязательного дополнения задачами очистки. @data_whisperer

Machine Learning Zoomcamp: A Free 4-Month Course on ML Engineering 15 сентября стартует очередной zoomcamp. Это практический курс, где вы научитесь создавать и развёртывать системы машинного обучения. Авторы делают упор на инженерную часть — от обучения моделей до их внедрения в production. На youtube доступна Pre-Course Live Q&A на которй рассказывают про курс и необходимые требования.

Data Engineering Design Patterns: Глава 2 — Data Ingestion Designe Patterns Продолжаю читать Data Engineering Design Patternsy, краткое summary по паттерну Passthrough Replicator. DATA LOADING vs REPLICATION

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

Passthrough Replicator — данные без искажений В инженерии данных не всегда нужно трансформировать информацию. Иногда ключевая задача — реплицировать её в разные среды как есть, сохраняя полный контекст. Именно для этого используется паттерн Passthrough Replicator. Когда он нужен Представьте, что у вас есть три среды: development, staging и production. В production ежедневно загружается датасет с параметрами устройств из внешнего API. API неидемпотентный: один и тот же запрос может вернуть разные данные в течение дня. Для тестирования и поиска ошибок важно, чтобы во всех средах данные совпадали с production. Но воспроизвести пайплайн загрузки в dev и staging невозможно — результаты будут отличаться. Тут и приходит на помощь Passthrough Replicator. Как это работает Идея проста: копировать данные без изменений, минимизируя вмешательство. Это можно делать: На уровне кода — с помощью простых EL job (чтение → запись). Главное — избегать ненужных преобразований, чтобы случайно не сломать данные (например, не округлить числа или не конвертировать строки в даты). На уровне инфраструктуры — с помощью механизмов репликации (например, AWS S3 Replication или Kafka MirrorMaker), где всю работу выполняет сам провайдер хранилища. На что обратить внимание Простота — чем меньше логики в репликации, тем ниже риск искажений. Безопасность — лучше использовать push-подход: production сам копирует данные в другие среды и контролирует процесс. Метаданные — не стоит игнорировать. В Kafka важно сохранить порядок сообщений и заголовки, а в Delta Lake — не только Parquet-файлы, но и служебную информацию. Latency — инфраструктурные решения могут добавлять задержку, поэтому всегда проверяйте SLA. PII — если данные содержат персональную информацию, лучше использовать Transformation Replicator, который позволяет её анонимизировать. Вывод Passthrough Replicator — это про консистентность и предсказуемость. Если нужно, чтобы dev и staging имели такие же данные, как production, и при этом любые трансформации нежелательны, этот паттерн — оптимальное решение. @data_whisperer

Data Engineering Roadmap Step by step guide to becoming a Data Engineer in 2025 Вроде бы очередной роадмап со списком инструментов, которые востребованы на рынке в 2025 В этот раз roadmap сделали интерактивным. Переходите в каждый пункт roadmap и читаете краткое обьяснения скилла, который предлагают выучить, а так же ссылки на ресурсы для изучения. Появился прогресс прохождения roadmap, для каждого скилла можно выставлять статус. Появилась персонализации плана, которая подстроит roadmap под вас. Опишите свой опыт работы и AI добавит либо удалит скиллы для изучения. Вообщем выглядит круто. @data_whisperer

Data Engineering — это не Software Engineering Читал эту статью на английском, но руки так и не дошли написать краткий пост в телеграм. Оказывается, что перевод уже есть на хабре. От себя добавлю, что полностью согласен с тезисами статьи. Уже пару лет назад, я понимал, что процессы в Data мире отличаются от процессов в software engineering, но не мог полностью сформулировать свои мысли по этому поводу. Автор статьи все раскладывает по полочкам. Конечно можно еще подискутировать про различные аспекты разработки и процессов в Data Engineering. Какое мнение у вас по этому поводу? @data_whisperer

Искали кино на выходные? На YouTube вышла полуторачасовая документалка про Python Фильм про историю развития языка. В нем снялся создатель – Гвидо ван Россум. – Проект начинался как стороннее хобби где-то в Амстердаме в 1990-х годах – Сначала язык никто не понял, и в какой-то момент от чуть не изчез На Python написана четверть всего публичного кода: это рекордная доля для любого языка за всё время существования программирования Сейчас Python на первом месте по популярности в мире. Он несколько лет находился на 3-5 местах, но в 2025 популярность ИИ и ML наконец вывела его в лидеры. Смотреть тут

Hamilton - DBT for python functions Фокусируясь на функциях, Apache Hamilton избегает громоздкой иерархии кода и формирует плоские потоки данных. Функции с четко определённой областью действия упрощают добавление новых возможностей, проведение код-ревью, отладку сбоев в пайплайнах. Визуализации могут генерироваться напрямую из вашего кода для лучшего понимания и документирования. Интеграция с Apache Hamilton UI позволяет отслеживать происхождение данных, каталогизировать код и артефакты, а также мониторить ваши потоки данных. Apache Hamilton сам по себе не является макросистемой, то есть системой оркестрации задач высокого уровня. Несмотря на то, что он оркеструет функции и абстракция DAG очень мощная, он не управляет вычислительными ресурсами и не планирует длительно работающие задачи. Apache Hamilton хорошо работает в тандеме с такими макросистемами(Airflow/FastApi/Luigi). Он обеспечивает возможности детального отслеживания происхождения данных, высокочитаемого кода и само документируемых пайплайнов, чего многим из этих систем не хватает. @data_whisperer

Первые 3 главы Designing Data-Intensive Applications, 2nd Edition Глава 1. Компромиссы в архитектуре систем данных Глава 2. Определение нефункциональных требований Глава 3. Модели данных и языки запросов

Iceberg Topics for Apache Kafka: Zero ETL, Zero Copy Apache Kafka теперь поддерживает Iceberg Topics, что позволяет пользователям загружать и обрабатывать данные как таблицы Apache Iceberg без необходимости в ETL или копировании данных. Это улучшение значительно снижает затраты, упрощает работу с данными и устраняет избыточность примерно 60% Kafka sink-коннекторов, обеспечивая нативный SQL-доступ для аналитики и повышая эффективность работы инженеров данных. подробнее тут репозиторий с кодом @data_whisperer

Redpanda Connect - это декларативный сервис потоковой передачи данных, который решает широкий спектр задач дата-инжиниринга с помощью простых, stateless-шагов обработки. Он позволяет гарантировать доставку сообщений по принципу «at-least-once» при подключении к источникам и приёмникам с аналогичной гарантией, без необходимости сохранения сообщений во время передачи. Сервис прост в развертывании, поставляется с широким набором коннекторов. Redpanda Connect частично пересекается по функциональности с интеграционными фреймворками, агрегаторами логов и движками ETL-воркфлоу, поэтому может дополнять эти традиционные инструменты дата-инжиниринга или выступать в качестве более простого альтернативы. Изначально это Benthos, про него был пост в канале. Но его поддержку забросили и panda-connect начал развивать свое решения. Так же есть платное решение, очень похоже panda-connect, WarpStream, но думаю стоимость решения для потоковой обработки данных будет космической. @data_whisperer

dbquacks DuckDB сделали приложение для изучения SQL прямо в браузере. Учебник в ретро-аркадном стиле поможет освоить SQL и возможности DuckDB. 38 уровней с использованием DuckDB WASM, работает полностью в браузере, в том числе на мобильных устройствах. Обучение SQL тоже может быть увлекательным.

Bodo + Iceberg: Сверхбыстрая и масштабируемая обработка данных в Python Работа с большими данными в Python — это вызов. PyIceberg удобен, но не масштабируется за пределы одного узла. Spark масштабируется, но теряет Python-стиль. Daft пробует устранить разрыв, но его API и производительность пока неясны. Bodo — open-source библиотека DataFrame, заменяющая Pandas. Она ускоряет и масштабирует Python-задачи от ноутбука до кластера без переписывания кода. Благодаря MPI и автопараллелизующему JIT-компилятору, Bodo в 20–240 раз быстрее альтернатив, включая Spark.

Nimtable — Control Plane for Apache Iceberg Nimtable — это самый быстрый способ развертывания, управления и масштабирования Apache Iceberg без потери гибкости и контроля. Это решение с открытым исходным кодом, альтернативное управляемым табличным сервисам на базе S3. Создано для команд, которые хотят использовать мощь Iceberg с прозрачностью самостоятельного хостинга и без операционных сложностей.

2025 Stack Overflow Developer Survey: Admired and Desired Databases Ежегодный отчет Stack Overflow, который показывает тренды в IT на основании опроса разрабочиков. В опросе много интересного, но здесь оставлю только основное. Database PostgreSQL сохраняет лидерство, оставаясь наиболее востребованной (65,5%) и желанной (46,5%) СУБД среди разработчиков, демонстрируя значительную долю использования (28,3%) и устойчивый интерес (59%) сообщества. Другие базы данных, такие как Supabase, SQLite и Redis, также показывают высокое соотношение желания к использованию, что свидетельствует о набирающем обороты росте. DuckDB и Databricks SQL, хоть и остаются нишевыми решениями, все активнее привлекают внимание в современных рабочих процессах обработки данных. Programming, scripting and markup language После более чем десятилетия стабильного роста, внедрение Python резко ускорилось. С 2024 по 2025 год его популярность выросла на 7 процентных пунктов; это говорит о его способности быть основным языком для ИИ, Data Science и бэкенд-разработки. Cloud Development Docker превратился из популярного инструмента в практически повсеместный. После многолетнего роста его использование совершило скачок на +17 пунктов с 2024 по 2025 год — это самый резкий рост за год среди всех исследованных технологий. Отчасти это объясняется перегруппировкой некоторых технологических категорий в опросе этого года. Dev IDEs Среди IDE с большим отрывом лидирует VSCode, так же в топ 5 Vim. А вот AI IDE пока что находяться в конце рейтинга, самой большей популярностью пользуется Cursor

Современный дата инжиниринг

CocoIndex - Open source ETL framework designed for AI workloads CocoIndex — это сверхпроизводительный фреймворк для преобразования данных с ядром, написанным на Rust. Он делает обработку данных для задач ИИ невероятно простой и обеспечивает синхронизацию исходных и целевых данных без малейших усилий. Будь то создание векторных представлений (эмбеддингов), построение графов знаний или любые другие преобразования данных — выходите за рамки традиционного SQL.

DLT workspace dltHub Workspace — это новая среда для создания, отладки и управления данными пайплайнов dlt, запускаемая с поддержкой разработки на основе больших языковых моделей (LLM), способных генерировать коннекторы для более чем 1000 источников REST API. Она позволяет одному разработчику переходить от кода пайплайна к загрузке данных и готовым для ноутбуков отчетам в едином потоке, с результатами, адаптированными для пользователей данных. Доступна большая и постоянно пополняемая библиотека шаблонов источников, назначений и пайплайнов, а новые функции появятся в ближайшее время. @data_whisperer

Amazon S3 Vectors Команда Amazon Web Services представила сервис S3 Vectors - первое в отрасли облачное хранилище объектов со встроенной поддержкой векторных операций. Новый сервис обеспечивает масштабируемое хранение и эффективный поиск векторных данных, что критически важно для современных ИИ-приложений. S3 Vectors предлагает глубокую интеграцию с другими сервисами AWS для работы с искусственным интеллектом, включая Amazon Bedrock, SageMaker и OpenSearch, позволяя разработчикам создавать комплексные решения без необходимости построения сложных инфраструктурных компонентов. Особенностью S3 Vectors стала возможность выполнения векторных запросов непосредственно на уровне хранилища, что устраняет необходимость в дополнительных слоях обработки данных. Это решение особенно актуально для разработчиков, работающих с RAG-архитектурами, рекомендательными системами и другими приложениями, требующими эффективной работы с векторными представлениями.

OLake - Built on Iceberg.Born for Scale. OLake - высокопроизводительный open-source инструмент для репликации данных из OLTP БД в Data Lake в форматах Open Table (Apache Iceberg). Оптимизирован для масштабирования и скорости. В данный момент поддерживает репликацию данных из Postgres, MongoDB, MySQL в Apache Iceberg. Performance Benchmarks 1. Postgres -> Apache Iceberg: ◦ Full load: Syncs at 46,262 RPS for 4 billion rows. (101x Airbyte, 11.6x Estuary, 3.1x Debezium) ◦ CDC: Syncs at 36,982 RPS for 50 million changes. (63x Airbyte, 12x Estuary, 2.7x Debezium) 2. MongoDB -> Apache Iceberg: ◦ Syncs 35,694 records/sec, replicating a 664 GB dataset (230 million rows) in 46 minutes. (20× Airbyte, 15× Debezium, 6× Fivetran) OLake демонстрирует значительное преимущество в пропускной способности при репликации больших объемов данных в Apache Iceberg по сравнению с существующими решениями, позиционируясь как высокопроизводительная замена Airbyte и альтернатива Debezium (благодаря CLI для CDC). @data_whisperer

Supabase MCP can leak your entire SQL database Уязвимость в интеграции протокола Model Context Protocol (MCP) от Supabase позволяет злоумышленникам получать доступ к конфиденциальным SQL-данным путем внедрения вредоносных инструкций (prompt injections) в сообщения поддержки, отправленные пользователями. AI-помощник работает с повышенными привилегиями servicerole и не может различать данные и команды, что может привести к непреднамеренному выполнению вредоносных инструкций и раскрытию защищенных таблиц, таких как integration _tokens.