Пользовательские алиасы
Обзор
Когда dbt выполняет модель, он обычно создает отношение (либо table, либо view) в базе данных, за исключением случая эфемерной модели, когда он создаст CTE для использования в другой модели. По умолчанию dbt использует имя файла модели в качестве идентификатора для создаваемого отношения или CTE. Этот идентификатор можно переопределить, используя конфигурацию модели alias.
Зачем использовать псевдонимы для имен моделей?
Имена схем и таблиц фактически являются "пользовательским интерфейсом" вашего data warehouse. Хорошо названные схемы и таблицы могут помочь обеспечить ясность и направление для потребителей этих данных. В сочетании с пользовательскими схемами псевдонимы моделей являются мощным механизмом для проектирования вашего хранилища данных.
Схема именования файлов, которую вы используете для организации своих моделей, также может конфликтовать с требованиями вашей платформы данных к идентификаторам. Например, вы можете захотеть использовать точку (.) для пространственного именования ваших файлов, но SQL-диалект вашей платформы данных может интерпретировать точки как разделение между именами схем и таблиц в идентификаторах, или может запретить использование точек в идентификаторах CTE. В таких случаях использование псевдонимов моделей может позволить вам сохранить гибкость в именовании файлов моделей, не нарушая требований к идентификаторам вашей платформы данных.
Использование
Конфигурация alias может быть использована для изменения имени идентификатора модели в базе данных. Следующая таблица показывает примеры идентификаторов базы данных для моделей как с указанным alias, так и без него, и с различными материализациями.
| Loading table... |
Чтобы настроить псевдоним для модели, укажите значение для параметра конфигурации alias модели. Например:
-- Эта модель будет создана в базе данных с идентификатором `sessions`
-- Обратите внимание, что в этом примере `alias` используется вместе с пользовательской схемой
{{ config(alias='sessions', schema='google_analytics') }}
select * from ...
Или в файле schema.yml.
models:
- name: ga_sessions
config:
alias: sessions
При обращении к модели ga_sessions из другой модели используйте функцию ref() с именем файла модели, как обычно. Например:
-- Используйте имя файла модели в ref, независимо от любых конфигураций псевдонимов
select * from {{ ref('ga_sessions') }}
union all
select * from {{ ref('snowplow_sessions') }}
generate_alias_name
Псевдоним, создаваемый для модели, контролируется макросом под названием generate_alias_name. Этот макрос можно переопределить в проекте dbt, чтобы изменить способ, которым dbt присваивает псевдонимы моделям. Этот макрос работает аналогично макросу generate_schema_name.
Чтобы переопределить генерацию псевдонимов в dbt, создайте макрос с именем generate_alias_name в вашем проекте dbt. Макрос generate_alias_name принимает два аргумента:
- Пользовательский псевдоним, указанный в конфигурации модели
- Узел, для которого генерируется пользовательский псевдоним
Стандартная реализация generate_alias_name просто использует указанный alias (если он присутствует) в качестве псевдонима модели, в противном случае возвращаясь к имени модели. Эта реализация выглядит следующим образом:
{% macro generate_alias_name(custom_alias_name=none, node=none) -%}
{%- if custom_alias_name -%}
{{ custom_alias_name | trim }}
{%- elif node.version -%}
{{ return(node.name ~ "_v" ~ (node.version | replace(".", "_"))) }}
{%- else -%}
{{ node.name }}
{%- endif -%}
{%- endmacro %}
💡 Используйте управление пробелами Jinja, чтобы упорядочить ваши макросы!
Когда вы изменяете макросы в вашем проекте, вы можете заметить лишние пробелы в вашем коде в папке target/compiled.
Вы можете удалить ненужные пробелы и строки с помощью управления пробелами Jinja, используя знак минус. Например, используйте {{- ... -}} или {%- ... %} вокруг определений ваших макросов (таких как {%- macro generate_schema_name(...) -%} ... {%- endmacro -%}).
Макрос Dispatch - управление SQL псевдонимами для баз данных и пакетов dbt
См. документацию по макросу dispatch: "Управление различными глобальными переопределениями в пакетах"
Предостережения
Неоднозначные идентификаторы базы данных
Используя псевдонимы, можно случайно создать модели с неоднозначными идентификаторами. Учитывая следующие две модели, dbt попытается создать два представления с точно такими же именами в базе данных (т.е. sessions):
{{ config(alias='sessions') }}
select * from ...
select * from ...
Та из этих моделей, которая будет выполнена второй, "победит", и, как правило, результат работы dbt не будет тем, что вы ожидали. Чтобы избежать этого режима сбоя, dbt проверит, являются ли ваши имена моделей и псевдонимы неоднозначными по своей природе. Если это так, вы получите сообщение об ошибке, подобное этому:
$ dbt compile
Encountered an error:
Compilation Error
dbt нашел два ресурса с представлением базы данных "analytics.sessions".
dbt не может создать два ресурса с идентичными представлениями базы данных. Чтобы исправить это,
измените конфигурацию "schema" или "alias" одного из этих ресурсов:
- model.my_project.snowplow_sessions (models/snowplow_sessions.sql)
- model.my_project.sessions (models/sessions.sql)
Если эти модели действительно должны иметь один и тот же идентификатор базы данных, вы можете обойти эту ошибку, настроив пользовательскую схему для одной из моделей.
Версии моделей
Связанная документация:
По умолчанию dbt создаёт версионированные модели с алиасом <model_name>_v<v>, где <v> — это уникальный идентификатор соответствующей версии. Вы можете настроить это поведение так же, как и для неверсированных моделей, задав пользовательский alias или переопределив макрос generate_alias_name.
Связанные материалы
- Настройка базы данных, схемы и алиаса моделей dbt — о том, как настраивать базу данных, схему и алиас моделей dbt
- Пользовательские схемы — о том, как настраивать схему dbt
- Пользовательские базы данных — о том, как настраивать базу данных dbt