Выбор self-hosted S3 для Iceberg после MinIO

MinIO потерял статус стандартного решения для on-premise lakehouse. Комьюнити-редакция ушла в архив, а Iceberg-таблицы требуют точного набора операций с объектами. Командам нужно оценить альтернативы по реальным паттернам чтения и записи, а не по общей фразе «S3-совместимость».

Что именно нужно Iceberg от объектного хранилища

Чтение Parquet-файлов начинается с суффиксного Range-запроса на последние байты, где лежит футер. Parquet — это колоночный формат хранения данных, в котором метаданные о структуре файла размещаются в конце. Если объектное хранилище не обрабатывает такие suffix-range запросы быстро или вынуждено возвращать весь файл целиком, каждый аналитический запрос превращается в лишнюю нагрузку на сеть и диски. Это напрямую снижает пропускную способность при сканировании больших таблиц.

Далее следуют targeted-чтения отдельных column chunks — фрагментов колонок, нужных для конкретного запроса. Хранилище, которое плохо справляется с частичными чтениями, увеличивает время выполнения запросов и потребление ресурсов. Метаданные Iceberg — это частые GET мелких JSON- и manifest-файлов размером в килобайты. Задержка на таких операциях напрямую влияет на время планирования запросов: чем дольше длится получение метаданных, тем позже начинается само чтение данных. Для команд, где запросы выполняются часто, даже небольшая дополнительная задержка на метаданных заметно ухудшает общую производительность.

Запись создаёт крупные data-файлы через multipart и мелкие метаданные на каждом коммите. Multipart-загрузка позволяет передавать большие файлы частями, снижая риск обрыва соединения. Streaming-записи добавляют частые PUT. Надёжная поддержка multipart и хорошая производительность на мелких объектах становятся обязательными, иначе скорость записи падает и растёт вероятность ошибок при одновременных операциях нескольких процессов.

Delete-операции в Iceberg используют DELETE и LIST. Хранилище должно корректно обрабатывать префиксные списки и удаления без деградации. Если LIST работает медленно или возвращает неполные результаты, операции удаления и оптимизации таблиц (compaction, expire snapshots) становятся ненадёжными. Credential vending через REST-каталог добавляет требование к изоляции учётных данных и к поддержке временных токенов. Эти паттерны уже проверены в интеграционных тестах самого Iceberg, которые ушли с MinIO осенью 2026 года. При выборе хранилища важно понимать, что несоответствие хотя бы одному из перечисленных паттернов приводит к росту latency, потере стабильности или необходимости дополнительных обходов на стороне приложения.

Сравнение RustFS, SeaweedFS, Ceph и Garage

RustFS вышел в GA в сентябре 2026 под Apache 2.0. Проект ориентирован на простоту развёртывания и полную совместимость с нужными Range- и multipart-операциями. SeaweedFS продолжает регулярные релизы и показывает хорошую работу с мелкими объектами, что полезно при частых коммитах метаданных.

Ceph RADOS Gateway остаётся тяжёлым, но проверенным вариантом с богатой экосистемой. Он требует больше ресурсов на развёртывание и администрирование. Garage рассчитан на небольшие геораспределённые кластеры и проще в эксплуатации при ограниченном числе узлов.

Все четыре решения прошли базовую S3-совместимость. Разница проявляется в поведении под реальной нагрузкой Iceberg: скорости suffix-range, задержке мелких GET и надёжности multipart при одновременных коммитах. Оценить это можно только на собственных таблицах и каталоге. При принятии решения стоит учитывать, что простота RustFS и SeaweedFS снижает порог входа для команд без глубокого опыта администрирования распределённых систем, тогда как Ceph даёт больше инструментов мониторинга и отказоустойчивости ценой более высокой операционной сложности. Garage выигрывает в сценариях с географической распределённостью, но может требовать дополнительной настройки при росте объёма данных.

Как это ложится на российский контур

В российских инфраструктурах важны открытая лицензия и возможность собрать образ самостоятельно. RustFS и SeaweedFS дают такую свободу без зависимости от коммерческих образов. Ceph уже присутствует во многих контурах и имеет локальную экспертизу, но требует пересмотра capacity-планов при переходе с MinIO.

Команды, которые раньше использовали MinIO в Helm-чартах и CI, теперь вынуждены либо собирать образы из архивного кода, либо мигрировать. Форки сообщества существуют, однако несут риск доверия к небольшой группе мейнтейнеров. При выборе стоит учитывать доступность специалистов по Ceph и готовность команды тестировать новые хранилища на реальных workload. Открытые лицензии позволяют избежать юридических ограничений, но увеличивают ответственность команды за сборку, обновление и безопасность образов.

Тестирование и миграция таблиц

Перед продакшеном нужно проверить три сценария: полное сканирование с множеством Range-запросов, планирование запросов с частыми метаданными и стриминговую запись с частыми коммитами. Метрики — время планирования, пропускная способность и стабильность при одновременных операциях. Такие тесты показывают реальную пригодность хранилища именно под Iceberg, а не только общую совместимость с S3 API.

Миграция выполняется через перепривязку каталога к новому endpoint с последующей проверкой метаданных. Iceberg позволяет менять storage location без перезаписи данных, но требует валидации всех manifest и удаления старых объектов после подтверждения работоспособности. Операционные риски включают потерю данных при некорректной обработке multipart и рост latency на метаданных при неправильной настройке кэша. Перед миграцией важно оценить, есть ли в команде экспертиза по новому хранилищу и достаточно ли времени на нагрузочное тестирование.

Источник

Это краткий разбор материала Dremio. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Выбор self-hosted S3 для Iceberg после MinIO.

Курс по теме — Каталог курсов Школы Больших Данных