Привет, Хабр! Меня зовут Александр, я DevRel команды Selena Lakehouse. Пишу про СУБД StarRocks, архитектуры Lakehouse и Streamhouse в Telegram-канале @starrocks_selena (https://t.me/starrocks_selena).

Полгода назад термин Streamhouse начал всплывать на конференциях и в блогах. При этом многие русскоязычные источники, которые я читал, сводят его к «замене Iceberg на Paimon и обновлению Flink» или путают с обычным Lakehouse. На самом деле за Streamhouse стоит интересная архитектурная логика. Конкретный набор компонентов, где каждый решает свою задачу: Apache Flink для вычислений, Apache Fluss как горячий потоковый слой, Apache Paimon как холодное хранилище. Вместе они дают потоковый Lakehouse с задержкой в секунды вместо минут.

Мне стало интересно: можно ли на этом стеке построить полноценный аналитический конвейер? Не на слайдах, а руками в Docker Compose, с SQL и реальным сценарием.

В этой статье:

tl;dr:

Каждая операция INSERT несет фиксированный overhead (в наших тестах 64–99 ms), независимо от количества строк.

Формула: Total_time = N_statements * fixed_overhead + actual_write_time — подтверждена тестами.

1000 single-row INSERT = 64 секунды (Shared-data) или 100 секунд (Shared-Nothing).

Разница не в диске и не в Docker, а в протоколе commit: TxnLog + publish через BRPC против 2PC + publish_version.

В ANALYZE PROFILE commit overhead прячется в разнице TotalTime - ExecutionTime — это FE overhead.

Батчинг нивелирует разницу: при INSERT SELECT оба режима дают ~0.25 с на 1000 строк.