5 minutes of data

Fast, scalable, enterprise-grade Postgres natively integrated with ClickHouse ClickHouse анонсировали managed Postgres с нативной интеграцией в ClickHouse. Теперь можно объединить транзакционные и аналитические нагрузки без обычной возни с отдельными системами. Postgres для транзакций, ClickHouse для аналитики, всё на open-source основе. Сервис работает на локальном NVMe storage и обещает до 10X прирост производительности для disk-bound нагрузок. В несколько кликов можно настроить CDC из Postgres в ClickHouse через нативные возможности - данные синхронизируются в реальном времени и становятся готовыми для аналитики. Говорят про 100X ускорение аналитических запросов по сравнению с чистым Postgres. Репликация работает через Postgres CDC коннектор в ClickPipes, который уже обкатан сотнями энтерпрайзных клиентов, которые прогоняют через него сотни терабайт в месяц. Поддерживается initial load для миграции существующих данных и CDC для инкрементальных синков. Планируют добавить sub-second latency репликации и репликацию ongoing транзакций через logical replication v2 для надёжного slot flushing - это будет эксклюзивно для их Postgres сервиса. Каждый Postgres сервис идёт с расширением pg_clickhouse, которое позволяет запрашивать ClickHouse напрямую из Postgres. Postgres становится единым query layer и для транзакций, и для аналитики. Расширение делает comprehensive query pushdown в ClickHouse, включая FILTERs, JOINs, SEMI-JOINs, агрегации, функции. Сейчас 14 из 22 TPC-H запросов полностью пушатся вниз, и это даёт больше 60X прирост производительности по сравнению со стандартным Postgres. Дальше планируют расширить pushdown на более сложные запросы - CTEs, window functions и дальше. Можно создавать foreign tables в Postgres, которые под капотом указывают на таблицы ClickHouse, и запускать аналитику через эти foreign tables. В планах сделать UX попроще, автоматическое создание foreign tables для реплицированных данных, автороутинг транзакций и аналитики на нужный движок, Postgres или ClickHouse. @five_minutes_of_data

Spark Pipeline Visualizer (DAG, YAML, SQL) Расширение для VSCode, которое визуализирует граф выполнения в Apache Spark. ✔ Instantly understand complex Spark pipeline dependencies ✔ Navigate tables, views, and transformations visually ✔ Jump from DAG nodes to source code with one click @five_minutes_of_data

По следам Postgres в OpenAI

AliSQL - форк MySQL от Alibaba, созданное на основе официальной MySQL и широко используемое в производственной среде Alibaba Group. Оно включает в себя различные оптимизации производительности, улучшения стабильности и функции, разработанные специально для крупномасштабных приложений. Основное различие от оригиналамв том, что для OLTP используется InnoDB, а для OLAP - всроенный в ядро движок DuckDB что дает существенный прирост в скорости на сложных запросах https://github.com/alibaba/AliSQL Опубликовано в @gitgate #mysql #olap #oltp #duckdb

The Part of PostgreSQL We Hate the Most Когда читаешь технические блоги компаний, там всегда куча ссылок на дополнительные материалы. Иногда проваливаешься в кроличью нору, так и вышло с прошлым постом про масштабирование Postgres в OpenAI. Там была ссылка на статью от Carnegie Mellon University и разработчика из OpenAI Bohan Zhang. Называется The Part of PostgreSQL We Hate the Most. В посте разбирают проблему в реализации MVCC Postgres, которую спроектировали еще в 80-х, и это тянет за собой целую цепочку неприятностей. Тема MVCC как-то всегда обходила меня стороной, но статья оказалась интересной и позволила в общих чертах понять, что это такое. MVCC нужен для того, чтобы несколько запросов могли одновременно читать и писать в базу без блокировок. Базовый принцип - система никогда не перезаписывает существующие строки, а создаёт новые версии. Когда приходит запрос, Postgres определяет, какую версию вернуть, в зависимости от момента начала транзакции. Первая проблема - Version Copying. При апдейте Postgres копирует все колонки в новую версию, даже если изменилась только одна. Если в таблице 1000 колонок и ты обновил одну, система скопирует все тысячу. MySQL и Oracle хранят дельту изменений, как git diff. В EnterpriseDB пытались переделать это через проект zheap в 2013 году, но последнее обновление было в 2021, проект заглох. Вторая проблема - Table Bloat. Мёртвые версии занимают место, и autovacuum не всегда успевает их убирать при write-heavy нагрузках. Мёртвые версии перемешаны с живыми в страницах, поэтому система загружает их в память при table scan. Если в таблице 10 миллионов живых строк и 40 миллионов мёртвых, Postgres всё равно загрузит все 50GB в память при сканировании. Даже когда autovacuum отработает, он не возвращает место операционной системе - для этого нужен VACUUM FULL или pg_repack, а это тяжёлые операции. А для pg_repack нужно еще и свободное место.

Make sure the cluster has enough free storage space: at least twice the total size of the tables and indexes to repack.

Третья проблема - Secondary Index Maintenance. При каждом апдейте строки Postgres обновляет все индексы таблицы, потому что и в primary, и в secondary индексах хранятся физические адреса версий. Исключение - HOT update, когда новая версия попадает в ту же страницу, что и старая. У Oracle и MySQL этой проблемы нет, потому что их secondary индексы хранят не физические адреса, а логические идентификаторы - tuple id или primary key. Система потом резолвит этот идентификатор в физический адрес актуальной версии. Четвёртая проблема - Vacuum Management. Дефолтные настройки не подходят для больших таблиц. Параметр autovacuum_vacuum_scale_factor по умолчанию стоит 20%, то есть для таблицы в 100 миллионов строк autovacuum запустится только после апдейта 20 миллионов строк. Ещё autovacuum может блокироваться долгими транзакциями, мёртвые версии накапливаются, это приводит к ещё более долгим транзакциям - замкнутый круг, приходится убивать запросы вручную. Из-за этих проблем Uber мигрировали с Postgres на MySQL, у них была write-intensive нагрузка, и write amplification из-за MVCC стал критичным. Авторы статьи говорят, что это не значит, будто не надо использовать Postgres - это всё ещё их любимая СУБД. Просто у любой системы есть компромиссы в дизайне, и для конкретных workload'ов эти особенности MVCC могут стать проблемой. @five_minutes_of_data

Scaling PostgreSQL to power 800 million ChatGPT users OpenAI опубликовали разбор про их Postgres под ChatGPT. Интересно, что архитектура там довольно простая: один primary на запись, куча read-реплик по регионам. Шардинг не стали делать - пишут честно, что слишком затратно менять сотни endpoint'ов в приложении. Может, займутся позже, но сейчас нагрузка в основном на чтение, так что пока хватает. Основная идея - писать в Postgres как можно меньше. Всё, что можно шардировать и где много записи, переносят в другие хранилища вроде Cosmos DB. Новые таблицы в основной кластер добавляют редко и неохотно. Бэкфиллы делают медленно, иногда неделями, чтобы не создавать write-спайки. С учётом того, как в Postgres работает MVCC, это логично - лишние версии строк потом замедляют чтение. Много времени тратят на запросы. Был случай, когда нашли join на 12 таблиц, который периодически клал всю систему. Теперь стараются такое не допускать, разбивают сложные запросы, переносят логику джойнов в приложение. Ещё следят за тем, что генерит ORM - там часто вылезает неожиданная дрянь. Idle-транзакции принудительно режут по таймауту, иначе они блокируют autovacuum. По соединениям всё понятно: managed Postgres в Azure имеет лимиты, и без пула легко упереться. Поставили PgBouncer как обязательный слой, иначе база просто тратила время на новые коннекты вместо работы. С кэшем такая история, когда много запросов одновременно пытаются пересобрать одно и то же из базы. Решают через cache locking: один запрос идёт в базу, остальные ждут обновления кэша. Реплик сейчас почти 50, но это тоже не бесконечно. Каждая тянет WAL с primary, и в какой-то момент нагрузка упрётся в это. Смотрят на cascading replication, чтобы промежуточные реплики раздавали WAL дальше. Но это добавит сложности с failover'ами, так что пока в тестировании. За год был один критический outage - когда запустили генерацию изображений. Запуск стал вирусным, за неделю зарегистрировались 100 млн новых юзеров. Каждая регистрация - это запись в БД, нагрузка выросла в 10 раз за короткий срок, и база не выдержала. @five_minutes_of_data

DE за работой #пятничное @five_minutes_of_data

Как устроен AWS S3 Взгляд изнутри на то, как проектируется и эксплуатируется крупнейшая в мире система хранения данных: экстремальный масштаб, надёжность, строгая корректность и использование формальных методов в продакшене. Amazon S3 - одна из самых больших распределённых систем, когда-либо созданных. Она хранит и обслуживает данные значительной части интернета. За внешне простым API скрываются годы инженерной работы, жёсткие компромиссы и архитектурные решения, принятые с расчётом на постоянные отказы. Этот разбор основан на разговоре с Mai-Lan Tomsen Bukovec, VP of Data & Analytics в AWS, которая руководит Amazon S3 уже более десяти лет. Она рассказывает, как строить системы на миллионах серверов, почему отказ - это базовое состояние системы, и как математика и формальные методы становятся необходимостью на таком масштабе. 1. Непостижимый масштаб S3 S3 обрабатывает сотни миллионов операций в секунду по всему миру и хранит более 500 триллионов объектов - это сотни эксабайт данных 2. Инженерный подвиг: переход к строгой консистентности При запуске в 2006 году S3 использовал eventual consistency ради высокой доступности, жертвуя строгими гарантиями согласованности данных. Позже команда смогла внедрить строгую консистентность, не ухудшив доступность и не увеличив стоимость для клиентов, что само по себе крайне сложно. 3. Тихая экспансия Rust S3 изначально не был написан на Rust, но сегодня почти весь performance-critical код в request path переписан именно на нём. Причина проста: максимальная производительность и минимальная латентность. Сейчас в S3 работает большое количество инженеров Rust, которые постоянно занимаются оптимизацией. 4. 11 девяток надёжности - это измеряемая величина S3 заявляет 99.999999999% durability. В системе есть специальные аудиторские микросервисы, которые непрерывно проверяют каждый байт данных по всему флоту. При обнаружении проблем автоматически запускаются repair-системы. Отказы происходят постоянно и система спроектирована, исходя из предположения, что сбои неизбежны. 5. Формальные методы в проде S3 активно использует формальные методы в продакшене. Когда инженер коммитит код в подсистему индексации, отвечающую за консистентность, автоматически запускаются формальные доказательства, проверяющие, что модель согласованности не деградировала. 6. Главная угроза — коррелированные отказы Одиночные сбои норма и хорошо обрабатываются. Реальная угроза коррелированные отказы, когда несколько компонентов падают одновременно из-за общего домена отказа (стойка, AZ, питание и т. д.). 7. S3 состоит из 200+ сервисов За каждым региональным endpoint S3 стоит множество сервисов всего порядка 200+ микросервисов. Для сравнения: у Uber их более 4 500. Это хороший пример того, что количество сервисов никак не коррелирует с масштабом системы. 8. S3 Vectors: создание нового примитива данных В отличие от S3 Tables (которые используют объекты и Parquet), S3 Vectors - это полностью новая структура данных. Основная сложность - поиск ближайших соседей в высокоразмерном векторном пространстве. 9. Crash consistency как философия Инженеры S3 глубоко продумывают crash consistency - способность системы возвращаться в корректное состояние после fail-stop отказа. Подход простой и жёсткий: рассмотреть все возможные состояния, в которые система может попасть при сбое, и проектировать микросервисы так, будто отказ присутствует всегда. 10. Принцип Scale Is to Your Advantage Одна из ключевых идей S3:

Масштаб должен работать на вас.

Это означает, что система не может деградировать по мере роста. Напротив, увеличение масштаба должно улучшать свойства системы. Например, чем больше становится S3, тем сильнее декоррелируются нагрузки, а это повышает общую надёжность для всех пользователей. текстовая версия видео на youtube @five_minutes_of_data

Alternatives to MinIO for single-node local S3 В конце 2025 года компания, стоящая за MinIO, решила фактически забросить проект ради других коммерческих интересов. Это не только расстроило многих, но и серьёзно встряхнуло экосистему: огромное количество демо и build-пайплайнов использовали MinIO для локальной эмуляции S3 и проверки S3-совместимости. В этом посте рассмотрим альтернативы MinIO. S3Proxy Очень просто в использовании, выглядит как лёгкое и аккуратное решение. Единственное, что я заметил: один из проектов, на котором основан S3Proxy jclouds - был отправлен в Apache Attic (то есть признан завершённым) в середине 2025 года. Впрочем, если использовать это только для локального стораджа, скорее всего, это не проблема. RustFS Стоит учитывать, что недавно в RustFS нашли довольно серьёзную уязвимость, из-за чего некоторые отказались от его использования. Сайт выглядит очень аккуратно, но несколько ссылок ведут на одну и ту же страницу, чувствуется запах нового проекта. Для демо это может быть не так критично, если его легко заменить. Также стоит отметить, что проект пока находится в статусе alpha. SeaweedFS Quickstart довольно полезный, позволяет быстро поднять минимальную S3-функциональность. Аутентификация требует отдельного конфигурационного файла. Zenko CloudServer Ранее известный как S3 Server, CloudServer является частью набора инструментов Zenko от компании Scality. Он довольно легко заменяет MinIO, но поначалу мне было сложно разобраться в названиях (cloudserver / zenko / scality) и понять, что именно нужно запускать. Есть и странное ощущение, что документация ссылается на устаревший Docker-образ. Garage Мог ли я сесть и внимательно прочитать документацию, чтобы во всём разобраться? Да. Есть ли у меня дела поважнее? Тоже да. Garage работает, но это совсем не drop-in replacement с точки зрения кода. Требуется другая инициализация, причём довольно сложная. Простой пример:

The specified key ID is not a valid Garage key ID (starts with GK, followed by 12 hex-encoded bytes).

Отлично с точки зрения production-гигиены, но для локальных демо перебор и, честно говоря, мешает. Многие качественные распределённые системы имеют крутую кривую входа. Но мой кейс простой drop-in replacement для MinIO, и в этом качестве Garage не подходит. Apache Ozone Ozone был выделен из Apache Hadoop (помните такой?) в 2020 году, изначально разрабатывался как часть HDFS ещё с 2015 года. Он может работать как замена MinIO, но это совсем не лёгкое решение. Очень сильные вайбы Hadoop и я бы точно не стал использовать его для своего кейса. Ceph Object Gateway Я увидел инструкцию по установке и сразу сказал нет. Даже Ozone достаточно тяжеловесен. Оба решения хороши в своих сценариях, но они точно не подходят как лёгкий контейнер для Docker Compose в локальных демо. Несколько финальных моментов, которые стоит учитывать при выборе замены MinIO: Governance. Хотя все проекты open source, только Ozone находится под управлением фонда (ASF). Все остальные теоретически могут сменить лицензию в любой момент — как это сделал MinIO. Здоровье сообщества. Каков bus factor У некоторых проектов долгая и успешная история, но фактически с одним основным контрибьютором. Если он уйдёт подхватит ли сообщество развитие проекта? Примеры со всеми обьектными хранилищами можно посмотреть в репо Оригинальный пост тут @five_minutes_of_data

📊 Я работал в Wheely 6 лет и вот результаты Результат - единственная валюта, которую принимают в банке жизни 😌 — Спроектировал и реализовал миграцию аналитической платформы Redshift → Snowflake: -45% расходов в моменте ($3.6k → $2k/мес), без простоя бизнеса. — Построил self-hosted платформу real-time streaming (Kafka + Debezium) вместо SaaS-инжеста: ~$20,000/год экономии и полный контроль по security/PII. — Оптимизировал использование и лицензии Looker: ~50% (~$40,000/год) экономии при продлении без ущерба для процессов, и далее переход на Metabase (Open Source) — Участие в разработке MetricView — высокопроизводительный BI-инструмент для C-level (на базе Observable Framework) с надежным CI/CD. — Вёл функцию Data Engineering для компании из 150+ сотрудников; обеспечил 100% покрытие мониторингом пайплайнов и <1 минуты задержку данных для критичных операционных потоков. — Стандартизировал DevEx через DevContainers (онбординг с дней до ~1 часа) и инженерные процессы для data/BI (CI/CD, monitoring, alerting). 🟡 Как всё начиналось На момент найма: — Практики и стандарты Data Engineering не соответствовали реалиям и вызовам — Требовался человек plug-n-play, который придет и быстро наведет порядок — Возьмет под контроль дальнейшее развитие И я им стал. — Сначала у меня было 3 месяца на offboarding ELT SaaS Alooma (куплен Google) без affecting business — Затем оптимизации и устойчивость к ошибкам в dbt (Redshift) - все устали от ежедневных падений и отсутствия данных — Затем миграция с Amplitude на Snowplow — И далее, далее, не останавливаемся Было динамично и интересно. Каждый день новое сражение, перспективные технологии, высокая ответственность и свобода выбора решений (покуда ты создаешь ценность и результаты). ➕ Плюсы 🔵 Гибкость и живость Нужен результат – делаем, чего ждать. Минимум бюрократических процедур, задержек и прочего bullshit. После работы в корпорациях было удивительно, что так быстро можно создавать результаты и влиять на процессы. Буквально в течение дня можно было вывести в прод несколько фичей. Конечно, это нравилось. 🟢 Современные технологии Я работал с dbt, Looker, AWS, Redshift, впоследствии Snowflake. Крутейшие технологии, с которыми приятно работать. Одним из первых я написал на Хабр про dbt. Я буквально видел их путь развития от нишевого тула до техногиганта. 🩷 Ответственность и Impact Сколько свободы, столько и ответственности. Если не я, то никто не починит и не сделает. Если не исправлю, в Пн все увидят кривые графики. Отчасти я сравниваю это с ролью SRE, но в Data. Здорово чувствовать, что ты влияешь на работу других людей, что твой труд уважаем и необходим. 🟤 Также: — Лимит на обучение. Я его тратил на подписку издательство O’Reilly - считаю, что это лучшее вложение — В месяц у меня было около 10К руб. на пользование сервисом (2-4 поездки). Но их меня впоследствии лишили 😂 — ДМС - стандарт. По больницам я не ходок, но и ДМС меня позже лишили 🤪 Продолжение далее ⬇️

Вчера искал, какие есть инструменты для maintenance / compaction в Apache Iceberg помимо стандартных решений в Trino и Spark. Неожиданно выяснилось, что RisingWave пошёл дальше простой поддержки Iceberg и добавил нормальный, встроенный maintenance-слой. Причём без изобретения новых абстракций синтаксис максимально знакомый:

-- Компактация мелких файлов
VACUUM my_iceberg_table;

-- Компактация + удаление снапшотов старше 2 дней
VACUUM my_iceberg_table RETAIN 2 DAYS;

По бенчмаркам RisingWave оказался быстрее Spark: выигрыш не за счёт I/O или компрессии, а за счёт меньшего framework overhead, нет JVM startup, нет тяжёлого task scheduling, нет Spark-экосистемной инерции. На текущий момент RisingWave умеет работать: - с internally managed Iceberg tables - с externally managed Iceberg tables То есть это не ещё один closed engine, а инструмент, который можно аккуратно встроить в существующий lakehouse-стек. @five_minutes_of_data

Dignified Python: 10 Rules to Improve your LLM Agents Современные LLM обучаются на огромном и неуправляемом наборе кода: сомнительных фрагментах со StackOverflow, недоделанных проектах и ​​любительских репозиториях. Когда агенты генерируют код на основе такого набора данных, результаты могут быть быстрыми, но не сфокусированными. Даже если вы не полностью доверяете им, постоянный цикл корректировок, исправлений и переписывания может привести к тому, что разработка будет ощущаться фрагментированной, а не целостной. Для решения этой проблемы в Dagster Labs систематизировали представления о том, как следует писать код на Python, в набор правил. Вместо того чтобы полагаться на последующую очистку посредством проверок или переписывания, правила загружаются непосредственно в контекст модели с самого начала. Это дает агентам четкое представление о стандартах, соглашениях и философии проектирования. Примеры правил можно посмотреть в этом репо. А для подготовки всего проекта с правилами используют ERK - CLI tool for plan-oriented agentic engineering, тоже интересный проект. @five_minutes_of_data

3 способа работать с Iceberg из Postgres: pg_mooncake, pg_lake и Supabase ETL За последнее время вокруг Iceberg-экосистемы заметно ускорилось движение: • pg_mooncake - покупка Databricks (октябрь 2025) • pg_lake - релиз (ноябрь 2025) • Supabase ETL - релиз (декабрь 2025) Все три open source и Apache-лицензия. Объединяет их главное: - использовать Postgres как единую точку управления - синхронизировать данные из Postgres в Iceberg Что делают инструменты и чем отличаются: 🥮 pg_mooncake Заявляет real-time ingestion из Postgres в Iceberg через logical replication. Работает отдельный Rust-движок Moonlink: буферизация, индексация в памяти, union-чтения с Iceberg + S3 через кастомный протокол. Но по факту проект выглядит заброшенным после поглощения: релиз v0.2 обещан, ключевые возможности - WIP. ❄️ pg_lake Расширение Postgres, которое поднимает DuckDB как отдельный сервер. Переводит Postgres-запросы в DuckDB SQL и позволяет совмещать чтения: - Iceberg-таблицы под управлением pg_lake - внешние Iceberg-таблицы - локальные таблицы Postgres Ingestion возможен из файлов и из самих таблиц Postgres. Есть собственный Iceberg-catalog + авто-обслуживание таблиц. Самый мощный и при этом самый простой в установке вариант. ➡️ Supabase ETL Отдельный сервис, а не расширение Postgres. Стримит данные из logical replication слота в Iceberg в реальном времени. Чтения не поддерживает - только ingestion. FDW у Supabase есть отдельно, но без vectorized execution, поэтому на больших объемах он тупо медленный. Зато умеет грузить не только в Iceberg, но и в BigQuery, и задуман как платформенный ETL. @five_minutes_of_data

Databases in 2025: A Year in Review Большой обзор от Carnegie Mellon University о состоянии баз данных за 2025 год. В 2025 году PostgreSQL продолжил свое доминирование на рынке, что подтверждается приобретениями у крупных технологических компаний и новыми распределенными проектами. В этом году также получило широкое распространение протокол контекста модели (MCP) от Anthropic для взаимодействия LLM с базами данных, а также развернулась ожесточенная борьба за новые открытые форматы столбцовых файлов, бросающие вызов Parquet. @five_minutes_of_data

Claude Code creator Boris shares his setup with 13 detailed steps,full details below Интересный пост на Reddit от одного из создателей Claude Code. TLDR; Борис, автор Claude Code, использует его не как помощник для автокомплита, а как рабочую среду. У него постоянно запущены несколько Claude’ов в терминале, ещё несколько - в вебе и иногда на телефоне. Сессии живут параллельно, контекст между ними перекидывается туда-сюда. Самое неожиданное - сетап при этом максимально простой. Без хитрых memory-плагинов, без 17 сабагентов, без переусложнённых схем. Обычный, почти скучный набор возможностей Claude Code. Именно это и зацепило людей в треде: на фоне того, как многие городят сложные AI-воркфлоу, его подход выглядит подозрительно простым. (Я и сам когда смотрел различные туториалы по настройке workflow быстро их закрывал, потому что казалось слишком заморочено) Отсюда и главная реакция в комментариях: круто, конечно… но с таким токен-бюджетом любой будет минималистом. И да, он действительно может спокойно сжигать миллионы токенов. Для обычных Pro-пользователей с лимитами такой режим работы выглядит скорее теоретическим. Поэтому ценность тут не в копировании сетапа, а в логике, которая за ним стоит. Он использует одну модель - Opus с thinking-mode вообще для всего. Медленнее, чем Sonnet, но за счёт нормального планирования и работы с инструментами в итоге выходит быстрее. Его тезис простой: чем меньше ты руками рулишь моделью, тем выше итоговая скорость. Ключевая вещь в командной работе CLAUDE.md. Это обычный файл в репозитории, который постоянно обновляется. Во время code review его прямо тегают в PR’ах и дописывают новые правила. Почти каждая задача начинается с Plan mode. План могут гонять туда-сюда несколько раз, пока он не станет нормальным. После этого Claude часто делает PR за один проход. Хороший план здесь реально решает больше, чем любой изощрённый промпт. Всё, что повторяется каждый день, автоматизировано: slash-команды (он же называет их skills), subagents, хуки. Отдельный акцент на верификации. В комментариях Борис несколько раз повторяет одну и ту же мысль: люди слишком усложняют feedback loop. На практике достаточно дать Claude способ увидеть результат своей работы запустить сервер, открыть UI, выполнить команду. Если инструмент нормально описан, дальше он разберётся сам. Когда нужно делать несколько фич параллельно, каждый агент живёт в своём git checkout’е, просто изоляция. Claude активно ходит во внешние системы: Slack, логи, аналитику, базы данных. Для долгих задач фоновые проверки и sandbox-режимы, чтобы не упираться в permission prompts. Финальный факт, который окончательно добил тред: Борис закрывает 50–100 PR в неделю. И это, пожалуй, лучшее объяснение, зачем весь этот сетап вообще существует. @five_minutes_of_data

В новогодние праздники разработчики делиться на 2 типа. 1. Чиллят на диване и смотрят новогодние фильмы. 2. Подключаются к удаленному серверу по ssh и восстанавливаются из бэкапов. Хороших праздников)

Tansu - is a drop-in replacement for Apache Kafka Tansu - это готовая замена Apache Kafka, использующая в качестве движков хранения PostgreSQL, libSQL (SQLite), S3 или memory storage. Топики со схемами (Avro, JSON или Protocol Buffers) могут записываться как таблицы Apache Iceberg или Delta Lake. Особенности: - Совместимость с API Apache Kafka. - Поддержка движков хранения: PostgreSQL, libSQL, S3 или память. - Топики, проверяемые с помощью JSON Schema, Apache Avro или Protocol Buffers, могут записываться как таблицы Apache Iceberg или Delta Lake. Интересно, что проект делает всего лишь один человек Peter Morgan, невероятно продуктивный разработчике на Rust, который стремится создать удобный и современный UX для Kafka-брокера, оптимизированный под нужды разработчиков. @five_minutes_of_data

Advent of Code в ClickHouse Advent of Code декабрьский марафон алгоритмических задач, которые обычно решают на Python, Rust или Go. Инженеры ClickHouse решили все 12 задач марафона на чистом SQL. Использовали векторизированный движок и встроенные функции: массивы, строки, рекурсивные CTE, пространственные и битовые операции. Запросы выглядят устрашающе, не хотел бы я такое дебажить 😅 @five_minutes_of_data

[2/2] 10 прогнозов для data-инфраструктуры в 2026 6. Multi-engine data-стеки становятся нормой Когда storage и compute реально развязаны, и данные лежат в нейтральном формате, становится странно быть привязанным к одному движку потому что так исторически. В 2026 будет больше стеков несколько движков под разные задачи: тяжёлый batch остаётся на больших кластерах, а быстрые и гибкие сценарии (интерактив, локальная аналитика, embedded‑вычисления) всё чаще закрываются DuckDB/DataFusion и похожими лёгкими движками, не только из‑за стоимости, но и из‑за скорости релизов и доступа к фичам раньше монолитов. 7. Компонуемые open source-движки ускоряют взрыв инноваций Ключевая роль DuckDB и DataFusion проявляется не столько в прямом использовании командами, сколько в том, как на их основе вендоры собирают новое поколение data-инфраструктуры. Монолитные черные ящики уступают место компонуемым системам из открытых компонентов(GizmoData, Query.Farm). В 2026 году этот эффект усилится: низкий порог входа и зрелость базовых движков приведут к появлению большего числа нишевых и специализированных продуктов, которые смогут быстрее экспериментировать и все увереннее конкурировать с крупными, традиционными игроками. 8. Open-стандарты окажутся между стабильностью и инновациями По мере массового распространения Arrow, Parquet и Iceberg перед ними все острее встает системное противоречие: необходимость сохранять простоту и совместимость с десятками реализаций сталкивается с давлением быстро развиваться и закрывать новые сценарии. В 2026 ключевой вопрос будет не какую фичу добавим, а как управлять эволюцией стандарта так, чтобы индустрия не скатилась в несовместимые форки и полуработающие адаптеры. Это хорошо описывает классический конфликт простота/совместимость vs скорость инноваций. 9. Высокая ценность в совместимости и стандартах Самые заметные улучшения в инфраструктуре данных будут идти не от новых систем, а от работы над интероперабельностью, стандартами и базовой инфраструктурой. Когда создание приложений с помощью LLM становится простым, ключевой ресурс - это координация. Миллионы независимых решений важны только если они могут безопасно и надёжно взаимодействовать. В 2026 году скучная работа по согласованию и стандартизации станет самой высокоэффективной инженерной деятельностью. 10. Табличные данные для AI-агентов С развитием AI-агентов ключевым станет обеспечение быстрого, безопасного и управляемого доступа к табличным данным. Большинство внимания в AI-сфере сосредоточено на неструктурированных данных, но для практических рабочих процессов агентам нужны детерминированные, типобезопасные и управляемые таблицы. В 2026 станет очевиднее, что просто прикрутить MCP‑сервер поверх DWH недостаточно. Нужны быстрые, типобезопасные и управляемые workflow: какие таблицы доступны, в каком виде, с какой агрегацией, с какой политикой, с какой трассировкой и стоимостью. Плюс придётся думать о том, как эффективно отдавать табличный контекст под tool calls и ограниченные контекстные окна. Если 2025 был годом экспериментов, то 2026 станет годом операционной дисциплины. От зрелости фундаментальных open-стандартов до массового внедрения мультидвижковых архитектур на раздельном хранении — индустрия движется к инфраструктуре, которая надежна, эффективна и готова поддерживать новые автономные приложения. @five_minutes_of_data

[1/2] 10 прогнозов для data-инфраструктуры в 2026 Подводя итоги 2025 года, заметно, что ландшафт data-инфраструктуры сильно изменился за год. Индустрию определяли как громкие события, так и тихие фундаментальные сдвиги. На фоне этого становится понятно, куда движется отрасль в 2026 году. 1. Аналитические системы всё чаще используются не для отчётов, а как часть операционных и пользовательских приложений. Старый спор OLTP vs OLAP и вечная мечта про HTAP никуда не делись, аналитические движки всё чаще живут в проде как часть пользовательских сценариев. Они становятся фундаментом для AI-агентов и data-heavy продуктов, обслуживая больше пользователей и более непредсказуемые нагрузки. Большие аналитические вендоры начали активно покупать Postgres‑компании (например, Neon ушёл в Databricks, Crunchy Data в Snowflake) и строить гибриды вокруг Postgres + DuckDB (pg_duckdb, pg_mooncake, pg_lake). В 2026 году эта трансформация ускорится: аналитика окончательно выйдет за рамки back-office и закрепится в продакшен-контуре. 2. Apache Arrow повсюду и это начинает быть проблемой Apache Arrow стал базовой инфраструктурой всего data-стека: он встроен почти в каждый современный продукт и используется повсеместно, часто незаметно для пользователей. Экосистема Arrow быстро растёт, но вместе с этим обостряется системная проблема - нехватка устойчивого финансирования и ресурсов на сопровождение. Разработка Arrow во многом держится на всплесках инвестиций от венчурных компаний, а повседневная поддержка и безопасность проекта ложатся на ограниченное число мейнтейнеров. В 2025 году приток новых контрибьюторов усилился, что увеличило нагрузку на ревью и поддержку. В 2026 году напряжение между масштабом использования Arrow и возможностями его сопровождения станет особенно заметным, делая вопросы устойчивого управления критичными для всей экосистемы. 3. ADBC становится стандартом для подключения к аналитическим базам ADBC быстро выходит из статуса экспериментального проекта и превращается в общий слой подключения для аналитических систем. Поддержка со стороны крупных вендоров и рост числа драйверов и клиентов ускоряют его принятие как более производительной и современной альтернативы ODBC и JDBC. В 2026 году ADBC будет всё чаще использоваться как стандартный интерфейс для передачи колоночных результатов запросов не только в аналитике, но и в операционных, AI- и пользовательских приложениях. Важно, что это не игрушка энтузиастов: поддержку и интерес к ADBC уже показывают крупные игроки (Databricks, dbt Labs, Microsoft, Snowflake), и это ускоряет стандартизацию. 4. Arrow приходит в JavaScript и TypeScript До сих пор JS‑мир жил в парадигме JSON везде. Это удобно, пока вы не начинаете строить data‑heavy UI, интерактивные ноутбуки/дашборды, агентские тулкиты и всё, что требует гонять большие табличные объёмы быстро. Формально Arrow для TS/JS есть давно, но исторически он был недоинвестирован по сравнению с другими реализациями. При этом примеры передаём колонки в браузер и не страдаем уже есть (Streamlit, Perspective). В 2026 вы чаще будете видеть: почему мы снова сериализуем таблицу в JSON, если можно передать колонки нормально. Экосистема ещё дозревает, но тренд уже читается. 5. Open table formats выходят из хайпа в прод, Iceberg в лидерах После волны противоречивых заявлений и перегретых ожиданий в 2025 году open table formats, и особенно Apache Iceberg, переходят в фазу зрелости. За пределами публичных дискуссий Iceberg активно внедряется в продакшене, формируется сильное сообщество и наращивается реальный масштаб использования. В 2026 году фокус сместится с споров и хайповых анонсов на практическую эксплуатацию: развитие стандарта, расширение типов данных и устойчивый рост количества production-нагрузок подтвердят Iceberg как базовую инфраструктуру для современных data-платформ. @five_minutes_of_data