Open Table Formats are not built for streaming

Open Table Formats плохо сочетаются с real-time стримингом, изначально они проектировались под batch-нагрузки.

При этом 85% Kafka sink-трафика уходит в lake, так что неудивительно, что все пытаются решить эту проблему интеграции.

Идеальный размер файлов в таких форматах (например, Apache Parquet) — около 0.5 GB.
Но если писать данные часто (как в real-time), файлы получаются маленькими → медленное чтение + рост затрат на S3.

Какие решения есть?
• batching - писать сразу более крупные файлы
• compaction - потом склеивать мелкие файлы в крупные

Что есть на рынке?

• (free) Kafka Connect → Apache Iceberg, по умолчанию батчит раз в 5 минут
• (paid, $) Kafka Connect → Delta Lake, пишет во временный S3, потом перекладывает
• (paid + lock-in, $$$) Confluent Tableflow, свои компоненты для batching/compaction, работает через S3
• (paid + lock-in, $$$) Databricks Zerobus, простой API для записи в Delta
• (paid + lock-in, $) Bufstream, zero-copy, по сути замена Kafka
• (paid + lock-in, $) Streambased, работает поверх Kafka, дает Iceberg API
• (free, сырой) Aiven Iceberg Topics, использует tiered storage, но кладет данные как Iceberg-таблицы
• (free) Apache Spark Structured Streaming, micro-batch из Kafka в Iceberg; те же проблемы с мелкими файлами, нужны отдельные compaction job’ы
• (радикально другой подход) Apache Paimon

Apache Paimon - альтернативный table format, изначально заточенный под стриминг.

Ключевое отличие, слой хранения на базе LSM-деревьев (Log-Structured Merge).
Новые данные сначала буферизуются и пишутся в level-0 файлы.

Система изначально предполагает много маленьких файлов:
- level-0 → компакция → level-1
- дальше → level-2 и т.д.

За счет этого запись оптимизирована под high-throughput.

Также у Paimon есть эффективный streaming reader:
он читает только дельту между снапшотами.
Это быстрее, чем incremental scan в Iceberg, потому что Paimon хранит manifest delta, а Iceberg вынужден читать много файлов из S3, чтобы понять, что изменилось.

хотя Paimon, это спецификация формата, он вырос из Apache Flink (раньше назывался Flink Table Store), поэтому лучше всего работает именно с ним.

Без Flink это будет ощущаться примерно как Kubernetes без Docker:
- чекпоинты
- управление топологией
- сериализация записи
все завязано на Flink.

У нас на работе используется связка Kafka Connect+Iceberg Sink.
Пришлось писать свое решение с использованием Spark, для maintenance iceberg tables.
А когда у тебя 2к+ таблиц, получается тот еще квест.

@tldr_data