Команда DuckDB утверждает, что объединение крошечных изменений в пакеты обеспечивает огромный прирост производительности в lakehouse-системах, решая проблему неэффективности Parquet. — theregister.com
Команда, стоящая за in-process OLAP базой данных DuckDB, представила решение проблемы «небольших изменений», которая, по их мнению, преследует реализации lakehouse, основанные на таких технологиях, как Databricks, Snowflake, Google и других.
Консалтинговая и сервисная компания, стоящая за открытой реляционной СУБД (RDBMS), только что выпустила первую готовую к промышленному использованию итерацию своего формата lakehouse DuckLake после запуска манифеста в прошлом году. Майский манифест DuckLake 2025 года обещал переосмыслить концепцию объединения хранилищ данных (data warehouses) и озер данных (data lakes) в единой системе.
По сути, она предложила использовать RDBMS для управления метаданными в реализациях lakehouse, основанных на общих открытых форматах таблиц Apache Iceberg и Delta Lake (введенном Databricks, управляемом Linux Foundation), показывая инженерам, как они могут использовать PostgreSQL, SQLite или DuckDB в качестве каталоговой базы данных для этой задачи.
С выпуском DuckLake v1.0, спецификации формата lakehouse, готовой к промышленному использованию, на этой неделе гуру баз данных демонстрируют, как базу данных можно использовать для решения так называемой проблемы «небольших изменений», общей для систем lakehouse, основанных на открытых форматах таблиц, которые полагаются на файловый формат Parquet.
Ханнес Мюлейзен, соучредитель и генеральный директор DuckDB Labs, сообщил The Register: «Вы вносите небольшое изменение в свою таблицу, добавляя одну строку, и это влияет на производительность озера данных, потому что, из-за принципа их работы, необходимо записать новый файл, который… содержит одну строку, а затем необходимо записать кучу метаданных… и затем каталог должен внести обновление. Это очень неэффективно, потому что форматы вроде Parquet действительно не хотят хранить одну строку, они хотят хранить миллион строк, а извлечение всех этих крошечных файлов из объектных хранилищ крайне неэффективно, поскольку вы выполняете все эти передачи».
Подход DuckLake использует RDBMS для метаданных, чтобы объединить эти небольшие изменения в пакеты, а затем передает их в Parquet относительно большими порциями, — сказал Мюлейзен, который также является профессором Амстердамского научно-исследовательского центра математических и теоретических вычислений Centrum Wiskunde & Informatica.
«Ключевое проектное отличие между другими форматами озер данных и DuckLake заключается в том, что у нас есть база данных, и мы не боимся ее использовать. У нас есть все эти метаданные об озере данных в каталоге в базе данных DuckLake, где мы знаем, какие таблицы существуют; какие файлы существуют; как они все связаны между собой; какие изменения произошли с течением времени — все это. Теперь вы добавляете одну строку, и вместо записи нового файла в объектное хранилище мы добавим ее в таблицу в базе данных. Ключевая идея здесь в том, что системы баз данных, такие как PostgreSQL, а также DuckDB и другие, намного, намного лучше справляются с небольшими изменениями, чем объектные хранилища», — сказал он.
База данных метаданных хранит небольшие изменения, такие как добавление и удаление строк, до тех пор, пока они в конечном итоге не будут «сброшены» обратно в Parquet в виде относительно большого файла, оставаясь при этом «полностью прозрачными для пользователя», — добавил он.
В записи в блоге, сопровождавшей запуск версии 1.0, Педро Оланда, ведущий инженер DuckDB Labs, заявил, что тесты компании показывают ускорение запросов в 926 раз и ускорение приема данных в 105 раз по сравнению с Iceberg, открытым форматом таблиц.
«Когда я писал в блоге о том, что у нас разница в 1000 раз, я чувствовал, что, о, некоторые люди разозлятся, но никто не разозлился. Они говорят: «Это реальная проблема». Мне даже кто-то сказал, что они жульничают с архитектурой. В этом вся суть: жульничать с лучшим дизайном», — сказал он The Register.
Однако инженеры продолжают работать вокруг существующей архитектуры lakehouse и пытаются решить те же проблемы. По поводу запуска DuckLake в прошлом году Джейк Йе, ветеран AWS и инженер-программист в компании AI database LanceDB, написал в блоге, что индустрия «все больше консолидируется вокруг протоколов на основе JSON в качестве основы для совместимости». В то же время, по его словам, существовали проблемы с внедрением DuckLake из-за отсутствия хорошей структурированной расширяемости, версионирования и разделения транспортного уровня.
Рассел Шпицер, ведущий инженер Snowflake, в то время сообщил нам, что многие проекты «уже далеко продвинулись с Iceberg, и сообщество Iceberg уже занимается проблемами каталога метаданных. DuckDB все еще зарождающаяся база данных, в то время как существующие игроки уже прочно укрепились на рынке. Возможно, нам придется подождать некоторое время, чтобы узнать, взлетит ли концепция DuckLake». ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Lindsay Clark