Каталог над озером данных в DuckDB

DuckDB научился хранить в файле базы только определения представлений, которые указывают на Parquet-файлы в объектном хранилище. Такой файл остаётся размером в сотни килобайт независимо от объёма данных и позволяет любому потребителю подключаться к готовым именованным отношениям. Решение снимает задачу раздачи списков путей к файлам и поддержания единой семантики запросов поверх меняющегося озера данных. Озеро данных здесь означает централизованное хранилище сырых файлов в формате Parquet, где информация лежит без предварительной загрузки в базу. DuckDB выступает как аналитическая система, способная читать такие файлы напрямую, а представления служат механизмом, который скрывает технические детали доступа.

Как представления заменяют таблицы

Обычная таблица в DuckDB хранит строки внутри файла базы. Представление хранит только текст запроса, который выполняется при обращении. Когда запрос внутри представления читает удалённый Parquet, сами данные остаются в хранилище, а база содержит лишь инструкцию чтения. В результате файл базы не растёт с увеличением объёма данных и превращается в каталог именованных отношений. Parquet — это колоночный формат хранения, оптимизированный для аналитических запросов: он позволяет считывать только нужные колонки и строки, что снижает сетевой трафик при работе с удалёнными файлами.

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

Создание и размещение каталога

Сначала устанавливается расширение httpfs, после чего создаётся постоянный файл базы и в нём определяются представления над удалёнными файлами. Важно указывать полные пути, чтобы представление работало независимо от рабочей директории клиента. Готовый файл загружается в то же хранилище, где лежат Parquet-файлы, и раздаётся по единственному URL. Расширение httpfs обеспечивает возможность чтения файлов по протоколам HTTP и S3-совместимым интерфейсам без необходимости загружать данные локально.

Получатель подключает каталог в режиме только чтения и работает с представлениями как с обычными таблицами. Каждый запрос читает актуальные данные из хранилища, поэтому результат отражает текущее состояние файлов. Для работы с S3-совместимыми источниками требуются соответствующие права, но сами запросы скачивают только нужные колонки и группы строк. При оценке решения стоит учитывать, что все потребители должны уметь работать с расширением httpfs и иметь ключи доступа; если права различаются по командам, это может усложнить внедрение. Каталог в одном файле упрощает распространение, но его нужно обновлять централизованно при изменении структуры данных.

Устойчивость к изменениям в хранилище

Если исходные файлы приходится разбивать по годам или перемещать в другую директорию, достаточно обновить определение представления внутри каталога. Потребители продолжают выполнять прежние запросы без изменений. Аналогично можно переименовывать колонки или менять схему файлов: представление отображает новые имена обратно на привычные потребителям. Схема файлов — это описание колонок и типов данных в Parquet; при её изменении без обновления представления запросы могут возвращать ошибки или неверные результаты.

Таким образом, все корректировки схемы и разметки файлов сосредотачиваются в одном месте. Это особенно полезно, когда данные обновляются несколькими командами или приходят из разных источников. Каталог становится единственной точкой, через которую проходит семантический слой, и не требует перераспространения новых путей или скриптов. Для решения о внедрении важно, что такой подход снижает риск расхождения семантики между потребителями, но накладывает ответственность за своевременное обновление представлений на владельца каталога. Если изменения происходят редко и контролируются, выгода очевидна; при хаотичных правках файлов без единой координации эффект может быть обратным.

Применение в российских контурах

В отечественных инфраструктурах такой паттерн удобен при работе с S3—совместимыми хранилищами внутри периметра или на мощностях, где уже размещены большие объёмы Parquet. Команды избегают копирования данных между зонами и получают возможность публиковать единый каталог для аналитиков и витрин. Поскольку DuckDB работает локально, не требуется внешних сервисов, а сам файл каталога легко разместить рядом с данными или в корпоративном репозитории артефактов. S3-совместимые хранилища — это объектные системы, поддерживающие тот же API, что и Amazon S3, но развёрнутые внутри организации или на российских площадках.

Ограничением остаётся необходимость поддерживать httpfs и права доступа к исходным файлам у всех потребителей. Если файлы часто меняют структуру без обновления представлений, запросы могут начать падать. Перед внедрением стоит проверить, что все клиенты используют версию DuckDB с поддержкой удалённого чтения и что объём метаданных в представлениях остаётся приемлемым для частых обновлений. Решение подходит, когда требуется единый семантический слой без дублирования данных и когда изменения в расположении файлов происходят регулярно; оно менее удобно, если клиенты не могут обеспечить стабильный доступ или если обновления представлений невозможно централизовать.

Источник

Это краткий разбор материала DuckDB. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Каталог над озером данных в DuckDB.

Курс по теме — Каталог курсов Школы Больших Данных