Apache Iceberg с момента появления вызвала большой интерес в сообществе разработки больших данных и аналитики благодаря своей цели — стандартизировать и оптимизировать работу с метаданными в огромных Data Lake на основе открытых форматов, таких как Parquet. Идея казалась правильной: использовать открытые и самодокументируемые форматы файлов для хранения таблиц и сопутствующей информации вместо закрытых и проприетарных решений. Однако спецификация Iceberg, по мнению многих экспертов, включая опытных разработчиков баз данных, оказалась далеко не совершенна и демонстрирует значительные слабости и узкие места, предупреждающие о реальных проблемах при масштабировании и эксплуатации. В данном анализе мы подробно рассмотрим технические ограничения и особенности спецификации Iceberg, чтобы понять, почему она оказалась не лучшим решением для систем управления метаданными большого масштаба. Начнем с ключевой проблемы, которую пытается решить Iceberg — превращение набора Parquet-файлов в полноценную структуру таблицы.
Parquet, как формат, действительно отлично подходит для хранения табличных данных с возможностью колоночной компрессии и минимизации чтения. Однако обычная папка с Parquet-файлами не гарантирует, что они составляют единую таблицу, объединенную по схеме и версии, а также не обеспечивает транзакционной целостности данных при изменениях. Спецификация классической системы управления базами данных решает этот вопрос через хранение метаданных в базе с высокой степенью согласованности и эффективным контролем конкуренции. Iceberg стремится решить эту проблему с помощью файловых структур — Manifest файлов и списков Manifest List. Клиент при внесении изменений должен записать новые Parquet-файлы, затем создать Manifest файл, который указывает на эти файлы с детальной метаинформацией, а затем написать Manifest List, ссылающийся на все Manifest файлы, которые составляют текущий срез таблицы.
И наконец, новый метафайл таблицы (metadata.json), содержащий ссылки на Manifest List и всю историю снимков (snapshots), публикуется в Object Storage. Такая архитектура сразу порождает несколько проблем. Во-первых, метаданные оказываются раздутыми и сложными для эффективной обработки. Каждый Manifest файл хранится в AVRO, что добавляет по меньшей мере килобайт оверхеда на файл, а их число растет пропорционально количеству коммитов.
Для систем с высокой частотой записи это означает десятки миллионов таких файлов и, как следствие, гигабайты дополнительных метаданных, которые нужно постоянно читать и обновлять. Во-вторых, управление транзакционной целостностью сделано в виде оптимистической конкурентной модели, где каждый коммит конкурирует за замену указателя на метафайл. Если два клиента одновременно меняют таблицу, побеждает тот, чей коммит успевает первым, а другой обязан заново прочитать всё состояние, пересоздать свои Manifest и метафайлы и повторить попытку. Эта схема не исключает голодовку клиента и приводит к высокой нагрузке на сеть и storage, особенно в условиях интенсивных параллельных изменений. Кроме того, такая модель приводит к узкому месту в производительности — поскольку все коммиты синхронизируются через один файл метаданных в Object Storage, масштабируемость ограничена скоростью атомарной замены этого файла, что в оптимальных условиях можно оценить примерно в 1000 коммитов в секунду на таблицу, но на практике это будет еще меньше.
В-третьих, Iceberg, как минимум в спецификации, практически не уделяет внимание вопросам безопасности и контролю доступа на уровне строк. В сценариях, где важна конфиденциальность данных — например, под влиянием стандартов GDPR в Европе — необходимость разграничивать доступ к частям таблиц критична, но описанных механизмов для обеспечения такой безопасности в ICEBERG нет. Клиенты просто видят все файлы, и манифесты раскрывают полные местоположения всех данных, что может привести к проблемам с утечкой информации. Следующий аспект — проблема фрагментации и управления ростом метаданных. Поскольку каждый новый снимок (snapshot) таблицы содержит ссылки ко всем предыдущим Manifest List и метафайлам, количество метаданных растет без ограничений.
Системы с постоянным потоком небольших добавлений создают лавинообразное увеличение числа метаданных, что негативно влияет на время планирования запросов. Iceberg предлагает метод слияния мелких файлов и удалением старых снимков, однако этот процесс также происходит через тот же механизм коммитов и контенций, что ограничивает эффективность и реализацию этих операций на больших нагрузках. При обработке запросов клиенты вынуждены читать сначала Manifest List, затем множество Manifest файлов, чтобы определить, какие именно Parquet файлы содержат нужные данные. В условиях миллиона манифестов это становится узким местом с высокой задержкой, особенно если рассматривать работу с облачными Object Storage, где чтение каждого файла занимает несколько миллисекунд и при последовательном доступе может накопить значительную латентность. Разумеется, кеширование помогает, но поддержание актуальности кэшей при постоянных изменениях и большом объеме метаданных также является проблемой, особенно если необходимо обеспечить строгую согласованность данных.
Интересна также дискуссия о подходе Iceberg к отказу от традиционных баз данных в пользу управления метаданными через файловую систему. Несмотря на свою декларативную направленность, спецификация по сути требует наличия компонента «каталога» — метастора, который обеспечивает атомарность коммита. Такая зависимость, хоть и замаскирована, фактически возвращает нас к использованию систем управления базами данных или хранилищ, ставящих под сомнение изначальные преимущества файлового подхода. Все перечисленное приводит к выводу, что Iceberg, будучи формальным стандартом, зачастую добавляет сложности и ограничения вместо упрощения. Многие современные решения пытаются бороться с подобными проблемами, в том числе такие проекты, как DuckLake, который ставит своей целью использовать базы данных для хранения метаданных с более естественным и оптимальным управлением транзакциями и порядком данных.
Тем не менее принятие таких систем с «D-словом» (базы данных) сталкивается с культурными и техническими барьерами, поскольку многие специалисты избегают SQL и традиционных методов БД, предпочитая обходные пути и «оптимистические» файлы. Итоговой задачей для индустрии остается создание формата, который сочетает открытые стандарты хранения, масштабируемость, безопасность и простой протокол управления метаданными без излишней нагрузки на клиентов и без узких мест в масштабировании. Iceberg пока не сумела этого достичь и служит скорее примером того, как сложность и «дизайн по команде» могут привести к противоречивому и непрактичному решению. Перспективы прозрачных и эффективных Data Lake систем зависят от способности разработчиков учиться на ошибках и выбирать архитектуры, хорошо зарекомендовавшие себя в системах управления базами данных, адаптируя их под современные требования облаков и распределённых вычислений.
