5 minutes of data

Увидел в Airflow одну очень прикольную фичу — Human-in-the-Loop операторы. Можно просто встроить человеческое подтверждение прямо в DAG. Работает это так: AI или любая задача что-то генерит → Airflow ставит паузу и ждёт решения → человек получает ссылку, жмёт approve/reject → пайплайн продолжает работу. Никаких кастомных сенсоров, костылей и блокировок воркеров — всё из коробки в 3.1. Очень удобная штука для тех, кто запускает AI в проде и хочет держать ручной контроль там, где это реально важно. @five_minutes_of_data

В Postgres count(*) работает так же эффективно, как count(1). Как это возможно? Давайте сравним планы выполнения, показанные на картинках. 1️⃣ SELECT count(order_id) — размер каждой извлеченной строки, удовлетворяющей условию поиска, составляет 4 байта (см. width=4 в плане выполнения). Это размер колонки order_id, которая является 32-битным целым числом. 2️⃣ SELECT count(1) — это известный трюк во многих реляционных базах данных, когда нужно сделать функцию count эффективной. База данных просто находит все подходящие строки и подсчитывает их. Размер строки здесь равен 0 (см. width=0), потому что вы передаете константу в функцию count. Значение константы не важно — можно передать 1, 10, 666 или ваше любимое число. 3️⃣ SELECT count(*) — Postgres применяет специальную оптимизацию для этого случая. Хотя вы передаете *, база данных достаточно умна, чтобы не извлекать все колонки для подходящих строк. Вместо этого размер каждой извлеченной строки равен 0 (см. width=0). Так что оставайтесь спокойны и используйте SELECT count(*) в Postgres. Оно уже оптимизировано для вас. Взято из книги Just Use Postgres @five_minutes_of_data

Stripe's Zero-Downtime Data Movement Platform Migrates Petabytes with Millisecond Traffic Switches На QCon San Francisco 2025 Джимми Морзария, staff software engineer в Stripe, представил платформу Zero-Downtime Data Movement Platform компании — систему, которая позволяет мигрировать базы данных на петабайтном масштабе с переключением трафика, обычно завершающимся за миллисекунды. Платформа поддерживает инфраструктуру Stripe, обрабатывая 5 миллионов запросов к базе данных в секунду по более чем 2000 шардам на базе MongoDB, при этом обеспечивая 99,9995% надежности для транзакций на $1,4 триллиона в год. @five_minutes_of_data

Apache Hudi 1.1 is Here—Building the Foundation for the Next Generation of Lakehouse Apache Hudi 1.1 представляет pluggable table format framework таблиц с адаптерами для Iceberg/Delta, индексацией с учетом партиций, динамическим изменением размера бакетов, блокировкой на основе хранилища и значительными улучшениями для конкретных движков. Он обеспечивает 15-кратное ускорение кластеризации, 4-кратное ускорение поиска и 2–3-кратный рост пропускной способности Flink за счет zero-copy обработки и оптимизированной работы с метаданными. @five_minutes_of_data

DataProjectHunt Находить data engineering проекты — ТРУДНО! Находить актуальные проекты — ЕЩЁ ТРУДНЕЕ! А вот найти хорошо спроектированные — почти невозможно. Но всё, это в прошлом с DataProjectHunt DataProjectHunt — это ProductHunt для data engineers. Там можно: ✅ Найти самые крутые DE-проекты в одном месте ✅ Поделиться своими проектами с сообществом ✅ Получить фидбек и отзывы от коллег ✅ Поставить лайк/дизлайк проектам ✅ Получить признание за свои творения (и попасть в лидерборд ) Кстати, этот проект сделал Marc Lamberti — тот самый чувак из Astronomer, который рассказывает про Airflow на YouTube. @five_minutes_of_data

Apache TsFile TsFile — это columnar storage file format, предназначенный для данных временных рядов, который поддерживает эффективную компрессию, высокую пропускную способность чтения и записи, а также совместимость с различными фреймворками, такими как Spark и Flink. Его легко интегрировать в фреймворки обработки больших данных IoT. @five_minutes_of_data

Привет! Книжного Клуба анонс! У нас с коллегами дата инженерами появилась идея по/перечитать книги, связанные с дата инженерией! Первая книгу, которую мы хотели бы обсудить - Data Engineering Desing Patterns. Планируем делать созвоны на еженедельной основе - вторник 19:30 MSK (17:30 CET). Первый созвон - следующий вторник 25 ноября, разберем первые паттерны по полной и инкрементальным загрузкам. Все детали книжного клуба будут в @de_zoomcamp, если вам интересно, залетайте в канал

Tributary DuckDB Extension Расширение Tributary от Query.Farm обеспечивает seamless интеграцию между DuckDB и Apache Kafka, позволяя проводить реал-тайм запросы и анализ потоковых данных. С этим расширением пользователи могут потреблять сообщения напрямую из топиков Kafka в DuckDB для немедленной обработки, а также записывать обработанные данные обратно в потоки Kafka. Особенности ⦁ Прямая загрузка из Kafka: Потоковая передача записей из топиков Kafka напрямую в таблицы DuckDB с помощью SQL. ⦁ SQL-нативный интерфейс: Интеграция с Kafka полностью доступна через SQL, что упрощает внедрение для data engineers и аналитиков. Query.Farm достаточно интересная компания. Они полностью сфокусировались на расширениях для DuckDB и уже сделали очень интересные решени. Вот что они пишут про себя:

Мы — люди из мира данных: инженеры баз данных, хакеры систем и контрибьюторы DuckDB, сосредоточенные на создании мощных, легковесных решений. Мы помогаем командам выжать максимум из DuckDB: быстрый, открытый и локальный анализ прямо под рукой. Query.Farm — независимая компания. Мы не связаны с DuckDB Labs или Фондом DuckDB. Мы строим на базе открытого проекта DuckDB и глубоко уважаем команду за ним — многих из них мы считаем друзьями и коллегами в более широкой экосистеме DuckDB.

@five_minutes_of_data

DeltaFi: The Open Source Platform for Data Transformation DeltaFi — это гибкая, с минимальным кодом платформа для трансформации и нормализации данных, которая позволяет вам: ⦁ Манипулировать любым типом данных на любом языке программирования ⦁ Исследовать и анализировать ваши данные ⦁ Мониторить потоки данных с точными метриками, оповещениями и уведомлениями ⦁ Захватывать и диагностировать ошибки @five_minutes_of_data

The Swiss Army Knife for Kafka Kafi — это Python-библиотека для всех, кто работает с Kafka (или любым решением на базе Kafka API). Это ваш швейцарский нож для Kafka. Kafi поддерживает два основных режима: Реальный Kafka ⦁ Kafka API через confluent_kafka ⦁ Kafka REST Proxy API Эмулированный Kafka/файлы ⦁ Локальная файловая система ⦁ S3 ⦁ Azure Blob Storage Эмулированный Kafka, например, полезен для отладки, когда не нужно запускать дополнительный кластер Kafka. Его также можно использовать для скачивания снапшотов топиков Kafka или для бэкапов. Kafi полностью поддерживает Schema Registry API, включая полную поддержку Avro, Protobuf и JSONSchema. @five_minutes_of_data

650GB of Data (Delta Lake on S3). Polars vs DuckDB vs Daft vs Spark. Тестирование DuckDB, Polars и Daft на одной ноде EC2 с 32 ГБ ОЗУ против таблицы Delta Lake объёмом 650 ГБ показало, что однопоточные движки могут эффективно обрабатывать большие наборы данных lakehouse: Polars завершил полную агрегацию за 12 минут, DuckDB — за 16, Daft — за 50, а PySpark — более чем за час. Распределённые кластеры, хотя и остаются актуальными, больше не обязательны для таких нагрузок благодаря впечатляющей поддержке данных большего размера, чем память, и простой интеграции. Фреймворки на одном узле обеспечивают существенную экономию затрат, снижение операционной сложности и простой код, бросая вызов традиционным предположениям об архитектуре lakehouse. @five_minutes_of_data

The analyst revolution: Unlocking tomorrow’s AI initiatives Новый исследовательский отчёт от Harris Poll и dbt Labs показывает, что на самом деле происходит внутри дата-команд — и результаты могут заставить вас пересмотреть свой подход к работе. От аналитиков требуют всё более быстрого получения инсайтов, но инструменты и процессы, на которые они опираются, тянут их назад. ИИ обещал помочь, но большинство команд всё ещё завалены рутиной, прыгают между инструментами и обходят ограничения governance-систем, просто чтобы что-то сделать. Этот отчёт, основанный на опросе 510 аналитиков, раскрывает реальную картину в дата-командах: - 78% времени аналитика уходит на подготовку и валидацию данных, а не анализ - 54% используют ИИ-инструменты вне одобренных систем, чтобы работать быстрее - Команды теряют 9,1 часа в неделю и $21 613 на одного аналитика в год из-за неэффективности Полный отчет в комментариях @five_minutes_of_data

From web developer to database developer Вдохновляющая история на выходные. После многих лет в роли веб-разработчика и менеджера автор перешёл на позицию разработчика баз данных в EnterpriseDB, занявшись сайд-проектами, участием в сообществе и нетворкингом, и в итоге получил роль, сосредоточенную на расширениях Postgres, а точнее pglogical. Как пет-проект он сделал in-memory database, о которой он писал в своем блоке. @five_minutes_of_data

Scaling Data Team Dagster выложили в открытый доступ небольшую брошюру с примерами кода, как построить комплексную платформа для data engineering, демонстрирующая лучшие практики и паттерны для команд разного размера. Этот проект показывает, как практики data engineering эволюционируют от индивидуальных специалистов до крупных инженерных организаций. p.s брошюра в комментариях @five_minutes_of_data

Alert fatigue На днях перелистывал книгу Базы данных Инжиниринг надежности и наткнулся там на такую мысль. Звучит знакомо, неправда ли?

Как правило, вскоре после ввода системы в эксплуатацию команды начинают реагировать слишком активно. Им не будет хватать общего видения ситуации, и они будут это компенсировать, отслеживая все и вся и слишком часто оповещая друг друга о разных событиях. Легко перейти от полного отсутствия графиков к буквально сотням тысяч графиков, 99 % которых совершенно бесполезны. Это не лучший, а, возможно, даже худший вариант. Если система генерирует так много шума, что ваши люди не способны найти верный сигнал и вынуждены постоянно отслеживать файлы журналов и пытаться угадать, что случилось, то это ничуть не лучше или даже хуже, чем полное отсутствие графиков.

Оказывается и доклад есть на эту тему. В докладе интересная статистика: от алертов тоже можно выгореть, рассказывают как декомпозировать алерты и различные практики для здорового алерт-менеджмента. Вообщем рекомендую посмотреть. А как у вас с алертами в команде? @five_minutes_of_data

Everyone Loves pgvector (in theory) Хотя pgvector делает векторный поиск простым на вид, расширяя PostgreSQL, в продакшене у него серьёзные пробелы: типы индексов (IVFFlat и HNSW) требуют ручной настройки и сильно нагружают память, вставки в реальном времени приводят к узким местам в сборке/перестройке, фильтрованные запросы страдают от несоответствий в планировщике, а гибридный поиск требует самодельной интеграции. Хотя pgvector работает (и все его обожают за удобство!), это обходится ценой операционной сложности. Для большинства команд dedicated векторная БД может быть проще и надёжнее. @five_minutesof_data

Data Warehouse, Data Lake, Data Lakehouse, Data Mesh: What They Are and How They Differ Познавательный пост от автора Грокаем конкурентность В котором он рассказывает понятным образом про отличия этих подходов. Сэкономит вам несколько часов точно. А если решите углубиться, то стоит прочитать: Decephering Data Architecrire. @5_minutes_of_data

Как я «контрибьютил» в open source Решили мы в компании выбрать инструмент для загрузки данных из внешних источников. Посмотрели на dlt — вроде всё круто: гибкий, понятный, плюс нативно дружит с Dagster. Но, как обычно, всплыл нюанс. dlt не умеет создавать таблицы с нужными параметрами в Greenplum:

  appendonly=true,
  blocksize=32768,
  compresstype=zstd,
  compresslevel=4,
  orientation=column
)
DISTRIBUTED BY (_dlt_id);

Ну, думаю, делов-то — сделаю pull request, пригодится всем. Написал, залил, оформил как положено. Через пару недель приходит ответ: вежливый, благодарственный, но суть такая —

«Отличный PR, спасибо! Но у нас сейчас слишком много контрибьюторов. Может, сам возьмёшься поддерживать этот модуль отдельно?»

И всё На этом мой вклад в open source закончился. PR отклонили, но хоть поблагодарили — уже приятно. В общем, теперь могу честно говорить: тоже писал в open source, просто пулл не приняли Вот тот самый PR Ну ладно, все же один PR у меня приняли в либу dagster-sqlmesh @five_minutes_of_data

XLTable - OLAP Cервер для нового стека данных Кажется, у каждого, кто работает с аналитикой, была эта боль — данные в ClickHouse или BigQuery, а бизнесу нужно просто сделать сводную в Excel. И вот ты сидишь между ними, собирая костыли из выгрузок и Power Query. Недавно наткнулся на XLTable — штуку, которая решает эту проблему максимально нативно. Это OLAP-сервер нового поколения, который позволяет подключить Excel напрямую к ClickHouse, BigQuery или Snowflake через XMLA. По сути, как старый добрый SSAS, но для современного дата-стека. Можно строить кубы, объединять десятки измерений и метрик, всё кэшируется, разграничивается по доступам и при этом работает с миллиардами строк. Причём все вычисления остаются на стороне ClickHouse — Excel только отображает результат. Разворачивается где угодно: в облаке или on-prem. Из коробки — интеграция с LDAP и гибкая настройка прав доступа. Если вы всё ещё вручную таскаете данные из DWH в Excel — советую посмотреть. Это тот случай, когда сводная таблица перестаёт быть синонимом боли. Хочешь получить бесплатную пробную версию на 30 дней? 👉🏻Напиши «OLAP» - покажем демо и поможем с настройкой Контакт: https://t.me/vorobiova_anastasia Сайт с информацией о продукте: https://xltable.com/

Garage — An open-source distributed object storage service tailored for self-hosting После того как MinIO объявили о прекращении поддержки Docker-образов и переходе на модель распространения только из исходников, сообщество self-hosting пришло в замешательство, под эту новсть в GitHub накидали дизлайков. Тысячи установок остались на старых версиях с известными уязвимостями — и многим пришлось искать замену. Одним из самых интересных вариантов стал Garage — распределённое S3-совместимое хранилище, которое можно развернуть у себя. В отличие от MinIO, Garage поддерживает актуальные Docker-образы и ориентирован на кластеры из узлов, расположенных в разных местах. Это позволяет автоматически реплицировать данные между площадками и оставаться доступным, даже если часть серверов недоступна. Garage задумывался как лёгкое, простое в эксплуатации и устойчивое к сбоям решение для небольших и средних кластеров. Для многих пользователей, это может стать отличной альтернативой MinIO. @five_minutes_of_data