DuckLake

Давно хочу написать об утином озере, но я не решался на это, пока сам не взялся за построение своего собственного DuckLake.

Если коротко, то DuckLake — это технология построения простого DataLakeHouse на основе duckdb. Это мощное, очень лёгкое для старта и относительно простое в масштабировании решение.

Речь по факту о построении аналитического хранилища, но без привычных нам СУБД типа Postgres, ClickHouse и тд.

Поговорим о том, из чего состоит аналитическое хранилище.

Как правило оно состоит из табличных данных. Вопрос в том, как их хранить. Пока попытаемся отвлечься от известных нам СУБД, иначе было бы всё слишком просто.

В чём хранить таблички? Например, в csv-файлах. Но так выходит не очень оптимально, однородные данные в одной колонке можно же как-то сжимать. Тогда будем хранить в другом формате, в формате parquet-файлов с поколоночным сжатием.

А если одна таблица, например, fact_orders, разбита на много отдельных паркетов? Значит нужен слой метаданных, т.е. данных о данных, как наши физические паркет-файлики на диске складываются в единые логические таблицы.

Теперь вспоминаем, что для работы с паркетфайлами есть шустрый SQL-движок duckdb. Соединяем duckdb с отдельным слоем хранения метаданных, например, в обычном Postgres и получаем... DuckLake.

Итак, нам для построения простейшего DataLakeHouse хватит всего трёх ингредиентов:

1) диск, где храним данные в паркетах
2) база данных для хранения каталога метаданных
3) SQL-движок duckdb для выполнения запросов к данным

DuckLake в свою очередь является расширением к duckdb, которое позволяет построить всё вышеперечисленное.

При этом назвать duckdb назвать привычной нам СУБД сложно. Мы не подключаемся к duckdb как какой-то внешней базе данных. Мы поднимаем свой экземпляр duckdb и говорим, откуда ему брать данные и метаданные для DuckLake. После того, как duckdb подключился к конкретному DuckLake, мы можем работать с ним как с обычным DWH на любой другой реляционной СУБД. Т.е. писать SQL-запросики к табличкам.

Т.к. duckdb не клиентский сервис, а поднимаемая нами по вызову программа, то можно поднимать много экземпляров duckdb на разных машинах, которые имеют доступ к общим данным. В теории можно масштабировать количество мощностей, главное организовать общий доступ к данным на сетевом диске.

Первые впечатления от построения своего DuckLake — офигеть как всё просто. SQL-диалект гибкий, полный готовых функций на любой случай жизни, а также легко подключаться к любым внешним источникам, никакой ETL инструмент другой и не нужен. Но далее всплывают, конечно, подводные камни: как настроить лимиты по памяти, как подключиться извне через IDE или BI-инструмент, почему падают параллельные DDL-запросы...

Технология пока сыра, но я в ней вижу большое будущее для средних и не очень компаний. Продолжение следует!