Платформа o_rabbit для экспорта в Iceberg

MindWise построила инструмент o_rabbit, который переносит данные из разных источников в Parquet-файлы на S3, регистрирует их как таблицы Iceberg и делает доступными для запросов через Project Antalya. Это не просто замена вставок в ClickHouse, а перестройка всего ETL-контура под открытый data lake. Parquet здесь выступает как колоночный формат хранения, позволяющий эффективно сжимать и читать большие объемы информации без загрузки всего содержимого в память. Iceberg добавляет к этим файлам слой управления таблицами с поддержкой снимков и атомарных изменений. Project Antalya обеспечивает быстрый доступ к таким таблицам через swarm-кластеры. Главное преимущество — отказоустойчивость при выгрузках больших объемов и возможность масштабировать параллельную обработку без переписывания пайплайнов. При выборе решения важно понимать, что o_rabbit ориентирован именно на миграцию в открытый lake, а не на сохранение привычных вставок в ClickHouse, поэтому он подходит командам, готовым перестроить ETL-процессы под файловое хранение и последующее использование Iceberg.

Разделение на мастера и исполнителей

o_rabbit разделяет управление и выполнение работы. Мастер хранит состояние заданий, отслеживает прогресс, управляет повторами и артефактами, но не перемещает данные. Исполнители (workers) сами запрашивают задачи, читают источники, пишут Parquet в S3 и отчитываются о результатах. Такая модель убирает зависимость от одного долгоживущего процесса, который легко падает при обрыве соединения или нехватке памяти. При принятии решения стоит учитывать, что отказ от центрального процесса снижает риск потери всего потока при единичном сбое, но требует наличия нескольких workers, способных работать независимо.

Pull-подход упрощает масштабирование: добавление новых workers не требует перенастройки заданий или ребалансировки. Если worker пропадает, мастер просто передает задачу другому по истечении lease. Это особенно важно при работе с десятками разнородных источников, где сбои происходят регулярно и предсказуемо. Для оценки применимости важно проверить, есть ли в инфраструктуре ресурсы для запуска нескольких workers и достаточно ли стабильна сеть между ними и источниками данных.

Управление состоянием и обработка сбоев

Все шаги экспорта записываются в SQLite: соединения, задания, запуски, задачи и артефакты. После сбоя не нужно гадать, что именно было сделано — достаточно запросить таблицу и продолжить с известной точки. Планировщик заранее делит крупные выгрузки на диапазоны по курсору, поэтому разные workers обрабатывают разные части таблицы одновременно. SQLite как метастора снижает сложность развертывания, поскольку не требует отдельного кластера баз данных, но при этом фиксирует достаточно информации для восстановления.

Это дает два эффекта. Во-первых, скорость растет линейно с числом workers. Во-вторых, отказ одной задачи не ломает весь запуск — остальные артефакты остаются, а потерянная часть перезапускается изолированно. Автоматический подбор размера задач работает в большинстве случаев, но при ограничениях на нагрузку источника параметры можно задать вручную. При решении о внедрении важно оценить, насколько источники допускают разбиение по курсорам и параллельное чтение; если такой поддержки нет, прирост скорости окажется меньше ожидаемого, а настройка планировщика потребует больше усилий.

Переход на Iceberg и ClickHouse

Вместо прямых вставок в ClickHouse данные теперь пишутся как Parquet, регистрируются в Iceberg и становятся доступны сразу после загрузки. Project Antalya (swarm-кластеры) используется для ускорения запросов к этим таблицам. Сама ClickHouse остается основным аналитическим движком, но основная масса хранения уходит в открытый lake. Это снижает нагрузку на кластер и упрощает обмен данными с другими системами. При выборе подхода следует учитывать, что хранение перемещается в S3-совместимое объектное хранилище, что меняет требования к емкости и пропускной способности сети.

Ограничения проявляются при сложных трансформациях на лету и при необходимости строгой консистентности в момент записи. Iceberg дает snapshot и time travel, но требует аккуратной настройки compaction и cleanup, иначе растет количество мелких файлов. Перед внедрением стоит оценить, насколько часто данные будут запрашиваться сразу после загрузки и есть ли ресурсы на регулярную оптимизацию таблиц Iceberg.

Применимость в российских контурах

В изолированных средах без доступа к облачным ETL-сервисам o_rabbit дает готовый каркас для построения собственного ingestion. SQLite-метасто́р снижает операционную нагрузку, а workers можно запускать в контейнерах на имеющихся мощностях. Главный риск — зависимость от качества коннекторов к legacy-источникам и необходимость самостоятельно отлаживать обработку ошибок при экспорте из проприетарных СУБД. При принятии решения важно проверить совместимость существующих коннекторов и наличие экспертизы для доработки обработки сбоев.

Перед внедрением стоит проверить, насколько источники поддерживают упорядоченные курсоры и параллельное чтение. Если таких возможностей нет, выигрыш от параллелизма будет меньше, а сложность планировщика — выше. В остальном инструмент решает именно те задачи, которые обычно возникают при миграции хранилища на Iceberg в условиях ограниченного бюджета на инфраструктуру. Командам, планирующим миграцию, рекомендуется оценить объемы данных и частоту сбоев, чтобы понять, оправдает ли отказоустойчивость модели мастера и workers дополнительные усилия по настройке.

Источник

Это краткий разбор материала Altinity. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Платформа o_rabbit для экспорта в Iceberg.

Курс по теме — Построение DWH на ClickHouse