The State of Streaming to Apache Iceberg in July 2026: Every Path, Its Latency, and What to Do When Seconds Are Not Fast Enough

Прочитал большую статью от Alex Merced, о состоянии стриминга в Apache Iceberg.

За право записывать потоковые данные в Iceberg сегодня конкурируют десятки решений:
Apache Flink, Spark Structured Streaming, Kafka Connect, брокеры с нативной поддержкой Iceberg, управляемые облачные сервисы и специализированные CDC-платформы.
Но как бы они ни отличались, все упираются в одни и те же фундаментальные ограничения.

Во-первых, данные становятся доступны только после создания нового snapshot.
Пока commit не выполнен, можно записать сколько угодно Parquet-файлов, но ни один движок запросов их не увидит.
Поэтому реальная задержка складывается не только из скорости записи, но и из времени буферизации, выполнения commit и обновления метаданных.
Любые заявления о задержке без упоминания commit стоит воспринимать с осторожностью.

Во-вторых, commit — дорогая операция.
Он обновляет метаданные таблицы, манифесты и каталог.
Если выполнять commit слишком часто, именно метаданные становятся главным узким местом.
На практике комфортный диапазон сегодня — от нескольких секунд до нескольких минут.
Формат Iceberg продолжает развиваться и постепенно снижает стоимость commit, но полностью избавиться от этого ограничения пока невозможно.

Третья проблема — мелкие файлы.
Чем чаще выполняются commit, тем больше появляется небольших Parquet-файлов.
В результате растет количество обращений к объектному хранилищу, увеличивается объем метаданных и замедляется выполнение запросов.
Поэтому потоковая загрузка в Iceberg всегда состоит из двух частей: самой загрузки данных и обслуживания таблиц — compaction, удаления старых snapshot и оптимизации файлов.
Именно отсутствие регулярного обслуживания автор называет самой распространенной ошибкой в реальных проектах.

Если говорить о конкретных инструментах, то Apache Flink остается эталоном для низкой задержки.
Он обеспечивает свежесть данных примерно от 10 секунд до минуты, поддерживает exactly-once и отлично подходит для CDC, но требует серьезной экспертизы и постоянного обслуживания. Spark Structured Streaming предлагает более простой путь для команд, уже использующих Spark, с типичной задержкой от десятков секунд до нескольких минут.
Kafka Connect Iceberg Sink — самый простой вариант с минимальным объемом разработки, однако обычно речь идет уже о задержке в несколько минут.

Самый интересный вывод статьи касается сценариев, где даже несколько секунд — слишком долго.
Для антифрода, операционного мониторинга или пользовательской аналитики автор не рекомендует пытаться выжать максимум из Iceberg.
Вместо этого стоит использовать двухуровневую архитектуру:
горячий слой на Pinot, ClickHouse, StarRocks или Druid для обслуживания запросов в реальном времени, а Iceberg оставить в роли долговременного хранилища истории.
Другой вариант — использовать потоковые базы данных вроде RisingWave или Materialize, которые обрабатывают данные практически мгновенно и параллельно сохраняют результаты в Iceberg.

P.S.
В комментариях бонус.
Книга Alex Merced
Architecting an Apache Iceberg Lakehouse

@tldr_data