Как сказано в заголовке, существует ли обходной путь с jOOQ, который позволил бы мне использовать DuckDB для запроса файлов паркета, хранящихся в объектном хранилище?
Пример: read_parquet(s3://path/to/my/parquet_file)
У меня есть схема файлов паркета, которую я определил в скрипте для создания классов jOOQ.
Я могу придумать один из способов избежать использования jooq-codegen и сделать все это вручную, определяя константы, преобразователи записей и построители запросов.
Есть ли лучший способ сделать это, используя автоматически сгенерированные классы?
🤔 А знаете ли вы, что...
Java обеспечивает платформонезависимость, что означает, что программа может быть написана один раз и запущена на разных платформах.
Предположительно, jOOQ 3.19 поддерживает DuckDB: https://www.jooq.org/doc/latest/manual/reference/supported-rdbms/
Это должно означать, что вам понадобятся только расширение httpfs DuckDB и, конечно же, необходимые разрешения.
Подробности смотрите https://duckdb.org/docs/guides/network_cloud_storage/s3_import.html, но вкратце:
import httpfs; -- need only be done once (per user per machine)
load https;
# set up the credentials and S3 region to read data
SELECT * FROM read_parquet('s3://⟨bucket⟩/⟨file⟩');
jOOQ ничего не знает об этих динамических внешних таблицах. Но вы, возможно, создадите представление, которое считывает из файла паркета и вместо этого запрашивает это представление, предполагая, что DuckDB может обнаружить метаданные паркета при описании представления для jOOQ, используя его представления INFORMATION_SCHEMA.
Другой подход — создать фиктивную таблицу (или представление), описывающую файл паркета, а затем использовать сопоставление схемы времени выполнения для сопоставления фиктивной таблицы с вызовом функции. При этом обязательно отключите кавычки идентификаторов, иначе весь вызов функции будет заключен в кавычки.
Вы также можете использовать замену API модели VisitListener или , чтобы заменить фиктивную таблицу вызовом функции. Это было бы немного более надежно, поскольку не требовало бы отключения кавычек идентификаторов.
Фиктивная таблица даже не обязательно должна существовать в вашей схеме. Вы можете определить второй запуск генерации кода, который использует DDLDatabase только для этого:
<configuration>
<generator>
<database>
<name>org.jooq.meta.extensions.ddl.DDLDatabase</name>
<properties>
<property>
<key>sql</key>
<value>create table dummy (col1 int, col2 int);</value>
</property>
</properties>
</database>
</generator>
</configuration>
Конечно, генерация кода с помощью jOOQ действительно полезна, но если ничего не помогает, простые шаблоны SQL здесь являются прагматичным решением. Вы все равно можете комбинировать этот подход с приведенной выше фиктивной таблицей, если присвоите псевдоним простого шаблона SQL фиктивной таблице.