Современная индустрия обработки данных всё активнее использует форматы таблиц на основе Iceberg и Delta Lake, обеспечивающие концептуальную модель традиционных баз данных поверх объекта хранения. Эта модель включает схему с эволюцией, контроль конкурентного доступа и прозрачное разбиение данных, что позволяет множеству инструментов работать с одним и тем же набором данных, устраняя необходимость создания промежуточных копий. Такой подход способствует устранению зависимости от конкретных вендоров и повышает эффективность управления данными. Однако, несмотря на привлекательность этих таблиц, ключевая проблематика заключается в том, что Iceberg и Delta Lake - это лишь спецификации, а не полноценные решения, которые обеспечивают трансформацию реального поточного потока данных в поддерживаемые таблицы. В частности, вопрос о методах построения и поддержки таких таблиц на основе событий из Kafka остаётся самым дискуссионным в современной data infrastructure сфере.
Традиционно для массовых организаций решение строится вокруг Apache Spark, способного обрабатывать большие объёмы данных пакетно и в микробатчах. Запуск Spark-процессов для преобразования сообщений Kafka в Iceberg таблицы является стандартом, но при этом сопряжён с целым рядом проблем. Необходимо писать обширный, тонко настроенный код для трансформации данных и управления схемами, что усложняет время внедрения и поддержания системы. Отдельно стоит выделить высокую задержку между появлением данных в Kafka и обновлением самой Iceberg таблицы. Это отставание может измеряться часами или даже сутками, что сводит на нет преимущества поточной архитектуры Kafka.
Хотя Spark Streaming теоретически позволяет уменьшить задержки, разбивая поток на микробатчи, практический эффект лимитируется двумя классическими проблемами: накоплением множества мелких файлов и невозможностью параллельных писем в одну и ту же таблицу. Мелкие файлы, которые создаются при частых записях, существенно затрудняют и замедляют последующую аналитическую обработку. Решение в виде периодической компрессии (компактации) данных - отдельный процесс, который не только усложняет архитектуру, но и создаёт конкуренцию за изменение таблицы между процессами записи и сборки фильтров, что часто приводит к конфликтам и отказам. Компактные задания рекомендуется запускать редко, что потенциально вызывает высокое замедление обновлений данных и требует значительных ресурсов вычислений в ограниченные временные интервалы. К тому же, каждая модификация Iceberg таблицы приводит к появлению новых снимков метаданных, которые по мере роста хранятся и могут выйти за пределы управляемых размеров, негативно влияя на доступность и стоимость.
Для поддержания таблиц в активном состоянии требуется дополнительная регулярная очистка старых снимков и удаление неиспользуемых файлов - ещё один времязатратный и ресурсозатратный процесс. Эти сложности объясняются фундаментальным несоответствием формата Iceberg с полноценной системой управления базой данных. И хотя доступны библиотеки, изменяющие файлы Parquet и поддерживающие структуру метаданных Iceberg, эти инструменты не предоставляют всего спектра критичных функций баз данных: многоверсионное управление конкурентностью, управление транзакциями, пул подключения клиентов, уровни изоляции и т.д. Это порождает огромный разрыв между ожиданиями пользователей, стремящихся получить комфортный инструмент, и реальностью, в которой происходит собственное создание "кастомных баз данных" под каждую ETL-задачу.
В поисках решения многие пытались использовать возможности самой Kafka, в частности, её функции теневого хранения (tiered storage). Идея заключалась в том, чтобы использовать объектное хранилище непосредственно как долговременное хранилище для Kafka, сохраняя логи в формате Parquet и гипотетически избавляясь от дублирования копий данных. Появилась концепция "zero-copy" Iceberg, когда одна и та же информация служит и потребителям Kafka, и аналитическим запросам Iceberg, без дополнительных ETL-процессов. На практике эта идея оказывается нереализуемой и даже вредной. Паркетные файлы сильно нагружают Kafka брокеры из-за тяжеловесных вычислительных операций по формированию и повторной декодировке данных, что снижает производительность JMS-кластера и увеличивает его стоимость.
Брокеры, отвечающие за критическую работу оперативного протокола, не предназначены для проведения ресурсоёмких преобразований формата, что ведёт к повышенному риску сбоев и ухудшению отклика в клиентских приложениях. Кроме того, требование полной унификации разбиения Kafka топиков и Iceberg таблиц вводит ограничение, напрямую противоречащее аналитическим требованиям. Kafka партиционируется исходя из потоковых нагрузок и обеспечению высокой доступности, тогда как Iceberg оптимизируется под аналитические модели, нуждающиеся в свёртках и оптимальном срезе по столбцам и времени. Разница лишь в том, что отказ от попыток слияния приводит к необходимости создавать две версии хранения - для Kafka и для аналитики - что требует отдельных ресурсов, но улучшает качество и управляемость данных. Это оставляет неизбежный вопрос о необходимости выделенного, узкоспециализированного решения - "волшебной коробки", которая умеет исключительно читать поток из Kafka и генерировать требуемые Iceberg таблицы с автокомпактацией и управлением всеми побочными процессами, включая очистку и обработку ошибок.
Воплощение данной концепции должно быть простым в сопровождении, масштабируемым, независимым от Spark и интегрируемым с различными Kafka кластерами, включая как облачные сервисы, так и on-premises инстансы. Именно такой подход воплощён в продукте WarpStream Tableflow, который предлагает декларативную настройку и полностью автоматизированные механизмы обеспечения консистентности Iceberg таблиц с минимальной задержкой обновления. Tableflow освобождает инженеров от необходимости погружаться в сложную логику конвейеров Spark, ручного согласования схем и запуска тяжеловесных компактаций. Кроме того, продукт поддерживает множество форматов данных, интеграцию с registry схем и продвинутые модели обработки данных с upsert и DLQ. Это решение можно развернуть в любом облаке, использовать гибкую модель Bring Your Own Cloud (BYOC) и интегрировать с существующими экосистемами Kafka.
Также оно позволяет достичь высоких скоростей обработки данных (гигабайты в секунду) с гарантированной свежестью данных и минимальным вмешательством человека. Несмотря на то, что некоторые функции Tableflow находятся в активной разработке, этот подход представляет собой крупный шаг вперёд по сравнению с существующими архитектурами на базе Spark или попытками переноса функций Iceberg прямо в Kafka брокеры. Создание выделенной, специализированной платформы для трансформации и поддержания Iceberg таблиц снимает множество оперативных и архитектурных проблем и позволяет сосредоточиться на развитии аналитики и быстрых бизнес-решениях. Подводя итог, можно сказать, что следующий виток развития data infrastructure лежит именно в сторону построения нативных Iceberg баз данных, интегрированных с потоковыми системами, но независимых от универсальных вычислительных платформ и инфраструктуры Kafka брокеров. Это открывает путь к эффективной и масштабируемой обработке данных в реальном времени с контролем качества, консистентности и оперативности, необходимой современным бизнесам для принятия решений.
.
