Apache Iceberg V3

Apache Iceberg V3 приносит значительные улучшения, такие как векторы удаления, lineage строк, лучшая поддержка полуструктурированных данных и основы шифрования.

На практике он готов к продакшену в основном, если вы используете Spark или Flink, с частичной поддержкой в других местах и заметными пробелами в движках вроде Athena, Trino и Snowflake.

V3 явно будущее, но для большинства команд это пока ждём и наблюдаем в плане adoption, а не безопасный дефолт на сегодня.

@five_minutes_of_data

Интересные Python библиотеки

🕵️ Skylos - ещё один инструмент статического анализа на Python, но с ИИ‑поддержкой.
Находит мёртвый код и типовые уязвимости безопасности.
Быстрее и умнее аналогов.

🧠 complexipy - измеряет когнитивную сложность кода - то, сколько усилий нужно, чтобы его понять.
Помогает находить реально запутанные участки для рефакторинга и держать кодовую базу чистой.

⚡ ty - сверхбыстрый type checker и language server для Python, написанный на Rust.
Альтернатива mypy, Pyright и Pylance, уже готовая к продакшену.

На когнитивной сложности можно остановится отдельно, есть хорошая статья, которую я рекомендую прочитать.
Круто, когда появляются такие инструменты как complexipy, чтобы снижать когнитивную нагрузку вашего кода.

Cognitive load is how much a developer needs to think in order to complete a task.

@five_minutes_of_data

Rosetta DBT Studio
The Open Source IDE for dbt Core

Создавайте, тестируйте и управляйте проектами dbt Core с лёгкостью.

Rosetta DBT Studio предлагает мощный графический интерфейс для запуска трансформаций, интеграции с Git и поддержки нескольких баз данных — всё в одном месте.

@five_minutes_of_data

Walrus: A Distributed Message Streaming Engine

Walrus - это распределённая платформа потоковой обработки сообщений, построенная на высокопроизводительном движке журнального хранения. Она обеспечивает отказоустойчивый стриминг с автоматической ротацией лидера, сегментным разбиением разделов и консенсусом Raft для координации метаданных

@five_minutes_of_data

Apache DevLake(Incubating)

Apache DevLake - это open-source платформа для работы с данными из DevOps-инструментов.

DevLake собирает разрозненные данные из Git, CI/CD, трекеров задач и других DevOps-систем, приводит их в нормальный вид, анализирует и визуализирует.
В итоге вместо кучи несвязанных метрик получается цельная картина того, как реально работает разработка.

По сути, DevLake - это способ начать задавать правильные вопросы про свой дев-процесс и наконец получать на них внятные ответы.

@five_minutes_of_data

GizmoSQL — High-Performance SQL Server for the Cloud

GizmoSQL — это open-source SQL database engine, работающий на базе DuckDB и Apache Arrow Flight SQL.
По бенчмаркам Gizmo опережает Trino и DataFusion.
Есть адаптеры к DBT и PySpark DataFrame API.
Есть как open-source вариант так и платная версия в облаке.

Выполняйте запросы к терабайтам данных за секунды при затратах на 90% ниже, чем у традиционных платформ.

@five_minutes_of_data

Kafka 2025 Wrapped: что произошло со стримингом за год

Годовой обзор экосистемы стриминга: громкие сделки, резкие повороты и медленное, но уверенное движение в сторону табличных форматов.

В 2025 году в игру зашёл IBM, а diskless-архитектуры окончательно вышли из экспериментов в open source.

------------------------------

Snowflake почти купил Redpanda (январь 2025)

Это вскрыло неприятную деталь: у Redpanda всего около $20 млн ARR.
Уже осенью компания резко развернулась в сторону AI и agent-подходов.

Aiven анонсировал Diskless Topics KIP (май 2025)

Diskless Kafka перестал быть экзотикой и начал оформляться в стандарт.

IBM покупает Confluent за $11 млрд (декабрь 2025)

Самая громкая сделка года, после которой стало ясно: Kafka - это уже не просто open-source проект, а стратегический актив.

------------------------------

Databricks активно зашёл в стриминг:

Zerobus - Kafka-подобная шина для ingestion прямо в Lakehouse в формате Unity Tables

Spark Real-Time Structured Streaming — новая фича Structured Streaming с задержками в десятки миллисекунд.

Snowflake не стал ждать и запустил Snowpipe - real-time ingestion, позволяющий приложениям писать строки напрямую в таблицы Snowflake.

Cloudflare представил Pipelines и Cloudflare Data Platform:
приём событий по HTTP → SQL-трансформации → загрузка в R2 (object storage) в формате Iceberg.

S2 официально вышел в релиз.

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

------------------------------

Kafka Ecosystem

В самом Kafka-мире год тоже был насыщенным:

Вышел Kafka 4.0

- KIP-848 (новый consumer group protocol) — GA

- KIP-932 (Queues) — EA

- ZooKeeper официально полностью удалён

- Вышел Kafka 4.1

------------------------------

Iceberg и Lakehouse - повсюду

- Confluent Cloud Tableflow вышел в GA (Iceberg)

- WarpStream выпустил свой Tableflow

- Aiven выложил open-source Iceberg Topics

Iceberg всё активнее претендует на часть use-case’ов Kafka как single source of truth, и индустрия явно ускоряется в этом направлении.

------------------------------

S3 съедает Kafka

- S3 Express снизил цены на 30–85%, сделав diskless Kafka на object storage заметно дешевле

- Предложены два KIP’а для эффективного чтения холодных данных из object storage:

- KIP-1255 (Remote Read Replicas)

- KIP-1248 (Consumers reading from Object Storage)

На текущий момент существует 10 diskless Kafka-реализаций с прямой записью в S3, включая:
Confluent Freight, WarpStream, AutoMQ, Bufstream, Tansu, Aiven Inkless, Kafka Diskless Topics, StreamNative Ursa, Kafscale, Redpanda Cloud Topics.

------------------------------

Все строят AI Agent infra

- Confluent выпустил Streaming Agents и Confluent Intelligence

- StreamNative - Orca Agent Engine

- Redpanda полностью развернулась в сторону Agentic Data Plane

При этом звучит и скепсис:

Последнее, что нужно AI-агентам - это Kafka.

2025 год показал, что стриминг больше не живёт в вакууме.
Kafka остаётся ядром экосистемы, но вокруг него быстро растёт мир:
Iceberg, object storage, diskless-архитектуры, AI-агенты и альтернативные пути ingestion.

Экосистема явно входит в следующую фазу - менее монолитную и гораздо более гибридную.

@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

[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

Advent of Code в ClickHouse

Advent of Code декабрьский марафон алгоритмических задач, которые обычно решают на Python, Rust или Go.

Инженеры ClickHouse решили все 12 задач марафона на чистом SQL.
Использовали векторизированный движок и встроенные функции: массивы, строки, рекурсивные CTE, пространственные и битовые операции.

Запросы выглядят устрашающе, не хотел бы я такое дебажить 😅

@five_minutes_of_data

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

В новогодние праздники разработчики делятся на 2 типа.

1. Чиллят на диване и смотрят новогодние фильмы.

2. Подключаются к удаленному серверу по ssh и восстанавливаются из бэкапов.

Хороших праздников)

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

Databases in 2025: A Year in Review

Большой обзор от Carnegie Mellon University о состоянии баз данных за 2025 год.

В 2025 году PostgreSQL продолжил свое доминирование на рынке, что подтверждается приобретениями у крупных технологических компаний и новыми распределенными проектами.

В этом году также получило широкое распространение протокол контекста модели (MCP) от Anthropic для взаимодействия LLM с базами данных, а также развернулась ожесточенная борьба за новые открытые форматы столбцовых файлов, бросающие вызов Parquet.

@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

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

Вчера искал, какие есть инструменты для 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

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

Как устроен 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