#dbt
#dbt
Вопрос:
Моя цель — иметь возможность иметь «динамические» источники в зависимости от типа запуска DBT, который я выполняю. Если быть более точным, я пытаюсь найти решение для сквозного бизнес-тестирования наших моделей DBT. Я имею в виду не схемы или простые тесты данных, а тесты бизнес-логики. Что-то вроде того, что у меня есть несколько входных таблиц с тестовыми данными, я запускаю модели DBT, а затем утверждаю, что конечные таблицы содержат желаемые результаты. Я могу создать все целевые таблицы в отдельной схеме, используя другой профиль «тест», но мне все равно нужно иметь возможность выбирать из другого набора источников, которые будут тестовыми таблицами, которые я создаю с помощью тестовых данных.
Я предполагаю, что могу использовать jinja в исходных файлах в сочетании с некоторыми переменными, чтобы это произошло, но мне интересно, есть ли еще лучший способ сделать это без изменения исходных файлов вообще. Например, разработчикам не пришлось бы беспокоиться о написании кода, который также работает для тестов. Для этой цели мне было интересно, можем ли мы переопределить исходный макрос или сделать что — то в этом роде, чтобы включить это поведение-аналогично тому, когда мы переопределяем generate_schema_name макрос. Что-то вроде (в псевдокоде python):
def source(schema_name, table_name): if env('is_test') == true: return schema_name table_name '_test' else: return schema_name table_name Я предполагаю, что сложность здесь также заключается в том, что исходный макрос делает больше, чем это, например, устанавливает некоторую информацию о происхождении документов, которую я определенно хотел бы сохранить.
Любые предложения, выходящие за рамки этого метода, более чем приветствуются!
Ответ №1:
Мое мнение, что у вас должна быть отдельная база данных(базы данных) для тестирования, а также переменная для настройки имени базы данных в dbt_project.yml файле
Поэтому, когда нужно запускать тесты, вы должны иметь возможность использовать --vars опцию.
Комментарии:
1. Я думаю, что это, вообще говоря, хорошее решение, но, к сожалению, я не думаю, что оно применимо к нашему случаю, поскольку мы находимся на AWS Athena и AFAIK, у нас есть только 1 база данных (каталог данных) для региона. Мы можем играть только со схемами, но не с базами данных — отсюда и проблема с источниками.
2. @Catazza: Я еще не работал с AWS. Но если это так, то можем ли мы использовать схему в качестве переменной?
Ответ №2:
Не уверен, что это то, что вы искали, но я уже работал с динамическими источниками раньше. Мне нужно было объединить 5 таблиц, которые жили в 5 отдельных схемах, но имели одно и то же имя таблицы. Я надеюсь, что то, что я предоставлю, по крайней мере, поможет вам двигаться в правильном направлении.
У вас есть два стола:
my_database.my_schema.tableA
my_database.my_schema.tableA_test
Итак, ваш исходный файл выглядит примерно так:
-- src.yml sources: - name: my_schema database: my_database tables: - name: tableA - name: tableA_test Вы спросили, есть ли какой-либо способ переопределить существующие макросы, такие как создание макросов. К сожалению, я лично не реализовал его таким образом для своей ситуации, потому что не хотел применять его в большем масштабе (только небольшая часть моделей).
Тогда у меня есть моя модель:
-- my_model.sql {%- set tbl = get_source(table_name) -%} select '{{tbl}}' as source, column1, column2, column3 from {{ source( 'my_schema' , tbl ) }} i и эта модель вызывает этот макрос для настройки имени таблицы:
-- my_macro.sql {% macro get_source(table_name) %} {% if target.name = 'test' %} {% set output = table_name ~ '_test' %} {% else %} {% set output = table_name %} {% endif %} {{ return(output) }} {% endmacro %} Я не проверял это точно, но я получил некоторую версию динамических схем для работы, так что здесь есть потенциал. Возможно, я тоже неправильно понял вопрос, так что дайте мне знать, если это полностью не так.