Ursa: движок хранения для Kafka с ориентацией на Iceberg

В апрельской заметке 2026 года на topicpartition.io разбирается Ursa - движок хранения, который StreamNative добавила в свой форк Kafka 4.2. Он заменяет локальный диск прямой записью в объектное хранилище в формате Iceberg или Delta Lake. Движок получил награду за лучшую индустриальную статью на VLDB 2025. StreamNative уже дважды обещала выложить его в открытый доступ, но пока этого не сделала.

Что меняет Ursa

Обычная Kafka хранит данные в локальных сегментах лога на диске каждого брокера. Репликация копирует эти сегменты между брокерами (как правило, три копии по разным зонам доступности). Это основной фактор расходов: сетевой трафик между зонами доступности составляет около 90% операционных затрат на Kafka, а тройной счёт за хранилище EBS только усугубляет ситуацию. У каждой партиции есть лидер, принимающий записи, что порождает горячие точки, делает ребалансировку дорогой и превращает брокеры в stateful-узлы - нельзя просто так добавить или убрать брокер без перераспределения данных.

Ursa делает топики "бездисковыми". Записи идут напрямую в объектное хранилище (S3, GCS или аналоги) вместо локального EBS. Репликация между зонами доступности не нужна, так как объектное хранилище само обеспечивает надёжность. Управление ISR (in-sync replicas) тоже не требуется, потому что не нужно синхронизировать реплики. Брокеры для бездисковых топиков не имеют состояния: можно добавить или удалить брокер без ребалансировки. StreamNative заявляет о снижении инфраструктурных затрат в 10 раз.

Компромисс здесь - задержка. Запись в объектное хранилище медленнее записи на локальный диск. Для нагрузок с высокой пропускной способностью, нечувствительных к задержкам (аналитические пайплайны, сбор логов, потоки CDC), это вполне подходит. Для обработки событий с низкой задержкой - нет. Ursa решает это настройкой типа топика: один кластер может содержать как бездисковые топики (дешёвые, с повышенной задержкой), так и обычные дисковые (дорогие, с низкой задержкой). Выбор делается для каждого топика отдельно.

Интеграция с Lakehouse

Куда интереснее то, что Ursa не просто сбрасывает байты в S3: она записывает таблицы Iceberg или Delta Lake с полноценной регистрацией в каталоге прямо на основном пути записи. Это означает, что топик Kafka и есть таблица Iceberg. Больше не нужен Kafka Connect sink, читающий из топика и пишущий в lakehouse. Нет отставания коннекторов. Нет двойного хранения данных. Нет расхождения схем между потоковым и аналитическим слоями.

Автоматический DLQ (dead letter queue) для некорректных схем - небольшая, но критически важная деталь. В пайплайне на коннекторах одно повреждённое сообщение может остановить весь sink. В Ursa невалидные сообщения автоматически отправляются в DLQ, а пайплайн lakehouse продолжает работать. Обработка ошибок встроена прямо в путь записи, а не вынесена в логику повторов отдельного коннектора.

Лишь один другой поставщик - Bufstream - предлагает подобную нативную интеграцию с lakehouse на критическом пути записи. Все остальные (включая Confluent) навешивают её через коннекторы с совершенно другими гарантиями SLA. Коннектор может отставать, терять сообщения при перезапуске или молча отбрасывать записи, не прошедшие эволюцию схемы. Нативный же путь записи либо выполняет запрос produce, либо возвращает ошибку.

Протокол Kafka как стандарт де-факто

Главный тезис публикации: сетевой протокол Kafka победил, тогда как кодовая база Apache Kafka теряет актуальность. Более 20 компаний сейчас конкурируют, реализуя протокол Kafka: WarpStream, Bufstream, Redpanda, AutoMQ и другие. У протокола мощный сетевой эффект: когда критическая масса клиентов говорит на этом формате передачи данных, любому новому вендору дешевле поддержать его, чем изобретать собственный.

IBM, Confluent и Red Hat суммарно контролируют около 80% активности в открытом проекте Apache Kafka, включая Project Management Committee. Сила притяжения опенсорсного репозитория держится на управлении проектом, а не на технологической привязке. StreamNative, пришедшая из мира Pulsar, предпочла форкнуть Kafka вместо попыток протолкнуть Ursa в апстрим - что явно говорит об их оценке открытого процесса разработки в сравнении с жизнеспособностью самого протокола.

Адаптивные топики

Возможность смешивать типы топиков в одном кластере (бездисковые и дисковые) - главная эксплуатационная особенность, определяющая внедрение. В большинстве инсталляций Kafka нагрузки неоднородны: одним топикам нужна задержка меньше 10 мс, другим - просто дешёвая высокая пропускная способность. Держать под каждую задачу отдельный кластер дорого в обслуживании, к тому же это фрагментирует мониторинг, списки доступа (ACL) и реестры схем.

Сегодня такое разделение поддерживают три системы: Aiven Inkless, StreamNative Ursa и Redpanda 26.1. В самой Apache Kafka предложение KIP-1150 преследует ту же цель, но до его реализации пройдёт ещё 1-2 года.

Связи

Текущее хранилище Kafka устроено по лог-структурному принципу из того же семейства, что и lsm-tree: append-only сегменты с периодическим уплотнением (compaction). Ursa заменяет хранение сегментов записью в объектное хранилище, сохраняя саму абстракцию лога. ingodb - ещё один движок хранения, переосмысляющий пути записи, пусть и для другой задачи (документное хранилище с реактивным индексированием).

Опыт StreamNative здесь показателен: они создали Apache Pulsar (первопроходца в разделении вычислений и хранения в потоковой обработке) и Oxia (замену ZooKeeper/etcd, входящую сейчас в инкубатор CNCF). Ursa переносит идею разделения вычислений и хранения из Pulsar в экосистему протокола Kafka.