Хранилища, адаптеры, хуки и операции

«Гонец» растёт, и финансовый директор спрашивает, не пора ли переехать из Postgres в облачное хранилище вроде Snowflake. Тебе интересно другое: придётся ли переписывать весь проект dbt. А ещё у тебя копится служебный SQL, который не тянет на модель: проанализировать таблицу после сборки, записать в журнал время запуска, раздать права на схему. Куда его девать?

Переходник для розетки

В поездке за границу ноутбук не переделывают под чужие розетки. Покупают переходник: ноутбук тот же, вилка та же, а переходник подгоняет её под местный стандарт.

dbt устроен так же. Ядро dbt одинаковое для всех хранилищ: проект, граф, Jinja, тесты. А с конкретной базой разговаривает адаптер, переходник под её диалект SQL.

Адаптеры

Адаптер ставится отдельным пакетом рядом с dbt Core, и его тип указывают в профиле в ключе type:

Хранилище	Пакет	Где живёт
PostgreSQL	dbt-postgres	своя база, как у «Гонца»
Snowflake	dbt-snowflake	облачное хранилище
Google BigQuery	dbt-bigquery	облако Google
Amazon Redshift	dbt-redshift	облако Amazon
Databricks	dbt-databricks	лейкхаус на Spark
DuckDB	dbt-duckdb	файл на ноутбуке, удобно для учёбы

При переезде модели почти не меняются: ref(), source(), материализации и тесты работают везде. Переписывать придётся места, где ты писал диалект руками, например at time zone или ::date из Postgres. Поэтому такие вещи прячут в макросы: поменял макрос, и проект заговорил на новом диалекте. Пакет dbt_utils из урока про макросы так и сделан.

Хуки модели

Хук это SQL, который dbt выполнит сам в нужный момент. Хуки модели задаются в конфиге:

{{ config(post_hook="analyze {{ this }}") }}

select ...

pre_hook выполняется до сборки модели, post_hook после. analyze обновляет статистику таблицы, чтобы Postgres выбирал хорошие планы запросов. {{ this }} внутри хука подставит полное имя модели.

Хуки можно писать и для целой папки в dbt_project.yml, ключом +post-hook.