В последние годы тема больших Data Lakes привлекла огромное внимание экспертов и разработчиков, стремящихся создать надежные, масштабируемые и эффективные решения для хранения и обработки больших объемов данных. Одним из наиболее популярных форматов для управления метаданными в Data Lakes считается Apache Iceberg. Его идеология – обеспечить открытый формат, спроектированный для хранения табличных структур на базе Parquet. На первый взгляд, идея кажется правильной: использовать уже широко принятый формат хранения данных и строить на нем слой, обеспечивающий транзакционность, согласованность и управление версиями. Однако, когда дело доходит до анализа спецификации Iceberg, возникает множество серьезных вопросов, говорящих о пробелах и ошибках реализации, которые существенно ограничивают возможности и эффективное применение данного формата в современных системах больших данных.
Метаданные и проблема их управления Ключевой вызов при работе с Data Lakes – это управление метаданными, которые описывают огромное множество файлов и как они взаимосвязаны, чтобы создавать видимость единой таблицы. Parquet-файлы, хоть и являются табличным форматом, сами по себе не представляют таблицу в полном смысле этого слова. Необходимо иметь список всех файлов, информацию о содержимом каждого из них, механизмы для создания транзакционных снимков и поддержку эволюции схемы данных без необходимости перелопачивать каждый файл. Iceberg ставит своей задачей формализовать этот слой метаданных. Основная архитектура Iceberg опирается на три ключевых сущности: Manifest Files, Manifest Lists и Metadata Files, при этом все эти файлы хранятся в AVRO-формате, что сохраняет их самодокументированность, но одновременно и добавляет значительный размер и накладные расходы на хранение.
Клиент, чтобы добавить новые данные, сначала должен записать Parquet-файлы, затем Manifest File, указывающий на эти файлы, и после этого создать или обновить Manifest List, который агрегирует все Manifest Files, включая новые. Завершающим этапом становится запись Metadata File, содержащего ссылку на актуальный Manifest List и список всех ранее существовавших снимков таблицы. Проблема фрагментации и роста метаданных Одна из основных претензий к Iceberg заключается в том, что метаданные постоянно растут непропорционально объему данных и приведенной активности. В случае интенсивной загрузки данных с интервалами по несколько тысяч файлов в секунду объем манифестов и списков манифестов быстро достигает миллионов, что приводит к гигантскому налогу по памяти и времени доступа. При таком количестве метаданных естественная задача очистки и слияния становится очень сложной, а попытки сделать это фоном сталкиваются с отсутствием гарантий прогресса из-за используемой модели управления конкурентным доступом.
Проблемы с конкурентным доступом и атомарностью Iceberg согласно спецификации реализует оптимистическую модель конкурентного доступа при коммитах метаданных, при которой каждый клиент, пытающийся записать изменения, должен прочитать текущий снимок, построить свой манифест и список манифестов, после чего попытаться атомарно заменить ссылку на метаданные в каталоге. В случае конфликтов или гонок запись откатывается и клиент повторяет попытку. Такой подход не масштабируется при высокой интенсивности операций, вызывает повторные чтения и записи, а также вероятность голодания клиентов, где часть попыток вообще не достигает успеха. Еще более серьезная проблема – отсутствие поддержи транзакций между разными таблицами. В современных распределенных системах невозможность выполнить атомарные изменения для нескольких таблиц ведет к сложностям с согласованностью данных, что весьма актуально для аналитических систем с высокой частотой обновлений.
Безопасность и ограничения спецификации Особая претензия к Iceberg заключается в том, что он практически не уделяет внимания безопасности. Спецификация игнорирует ряд аспектов, связанных с защитой данных на уровне строк, что при наличии нормативных требований вроде GDPR обстоятельства критичны. Клиенты, нуждающиеся в записи данных, вынуждены иметь доступ к полному списку Manifest Files, что открывает данные для потенциального несанкционированного доступа или кражи метаданных и может привести к серьезным уязвимостям. Кроме того, использование «конвенции как конфигурации» внедряет ограниченный и неформализованный способ управления, который в ряде случаев приводит к ошибкам и усложняет работу с массой файлов и версий без поддержки реляционных возможностей базы данных. Накладные расходы на чтение и кэширование Работа с Iceberg требует чтения нескольких слоев метаданных для каждого запроса: сначала Manifest List, затем один или несколько Manifest Files, после чего выбираются конкретные Parquet-файлы для считывания.
Такой процесс состоит из большого количества последовательных HTTP-запросов к объектному хранилищу (например, AWS S3), которые имеют высокую латентность и накладные расходы. Планы запросов становятся тяжелыми и медленными, особенно при большом количестве маленьких файлов и высокой фрагментации метаданных. Кэширование частично решает проблему, однако управление кэшем добавляет уровень сложности и требует обратного контроля за актуальностью данных, что в случае регулярных изменений приводит к значительным накладным расходам. Каждому клиенту необходимо самостоятельно поддерживать согласованность локальных кэшей с последними версиями метаданных, что не совместимо с архитектурами с сотнями и тысячами клиентов. Почему Iceberg выбрал такой путь? Ответы на эту сложность раскрываются в философии Iceberg, стремящейся к максимальному открытию данных и независимости от баз данных.
Специалисты Iceberg пытаются избежать монополии и «замкнутости» баз данных, реализуя управление метаданными через файлы в объектных хранилищах. Однако, такой подход обращается в компромисс, в рамках которого теряется масштабируемость, эффективность и безопасность. Ситуация осложняется тем, что несмотря на попытки обходиться без традиционных баз данных, для некоторых критических операций, например, для атомарного переключения текущего состояния таблицы, все-таки необходима метаструктура, условно именуемая каталогом, которая по своей сути является базой данных с минимально необходимыми функциями. Альтернативы и перспективы развития В обществе Big Data растет осознание проблем Iceberg, что способствует появлению инициатив, стремящихся исправить или заменить его подход. Пример тому – DuckLake, предложенный DuckDB, который вместо попыток уйти от баз данных прямо использует их для управления метаданными, сохраняя при этом открытый формат хранения данных на базе Parquet.
Такой подход обещает лучшие показатели по скорости, эффективности и согласованности. Однако DuckLake и ему подобные решения сталкиваются со своей проблемой – нежеланием разработчиков и инженеров глубоко изучать базы данных и SQL, что вынуждает индустрию повторять ошибки прошлого, создавая сложные, мало управляемые и неэффективные системы для решения проблем, когда эффективное решение уже существует. Заключение Iceberg представляет собой смелую и увлекательную попытку стандартизации управления метаданными для больших Data Lakes. Однако текущая спецификация содержит фундаментальные архитектурные ошибки, которые снижают масштабируемость, эффективность и безопасность этого формата. Зависимость от объемных AVRO-файлов, чрезмерное дублирование информации, неудачная реализация конкурентного контроля, отсутствие поддержки межтабличных транзакций и слабые механизмы защиты – все это превращает Iceberg в не слишком пригодный для серьезных промышленно масштабных решений продукт.
Будущее требует убеждения, что предложения, ориентированные на использование возможностей полноценных систем управления базами данных, будут более продуктивными и практичными. Сохранение открытости форматов хранения, но при этом разработка и внедрение эффективных, проверенных временем стратегий управления метаданными и транзакциями – вот необходимый путь, который способна обеспечить настоящую эволюцию Data Lakes и аналитических систем в целом. Размышляя о судьбе Iceberg, возникает вопрос, почему в индустрии допускаются такие компромиссы, когда проверенные технологии баз данных могли бы решить многие проблемы с меньшими усилиями и намного более элегантно. Возможно, время для переосмысления и возвращения к основам уже настало.
