Что такое dbt?

dbt (data build tool) — это open-source инструмент командной строки, с помощью которого аналитики и дата инженеры могут эффективно преобразовывать данные в своих хранилищах.

То есть этот инструмент предназначен именно для преобразования необработанных данных в таблицы хранилища данных (этап T в ELT или ETL схемах) непосредственно в самом хранилище данных. В том числе для нарезки витрин данных (data marts).

Достаточно написать оператор SELECT, а dbt преобразует этот оператор в таблицу или представление в хранилище данных, то есть материализует запрос в виде таблицы или представления. По сути на основе одного запроса SELECT будет сгенерирован дополнительный код SQL (по созданию таблиц, вставки данных, инкрементального обновления данных и т.п.).

Проект dbt-core на github с лицензией Apache-2.0:

DBT использует концепцию DRY или «Не повторяйся» благодаря использованию файлов YAML и языка шаблонов Jinja.

dbt — это не хранилище данных или сама база данных, а скорее инструмент, который можно использовать вместе с хранилищем данных, чтобы упростить работу с данными и управление ими. Кроме того, dbt не является языком программирования , но он использует синтаксис, подобный программированию, чтобы указать, как данные должны быть преобразованы и загружены в хранилище данных.

У dbt Labs есть 2 основных продукта:

• dbt Core: это бесплатный инструмент с открытым исходным кодом, который включает в себя все необходимое техническим командам для преобразования данных. Он предоставляет вам возможность разворачивать собственные конвейеры ELT, логику компиляции SQL, шаблоны Jinja, адаптеры баз данных, среды тестирования и документацию.
• dbt Cloud: это их платный продукт, который отлично подходит для команд, которые хотят действовать быстро и с высокой скоординированностью. Он быстрый и надежный, имеет удобную для пользователя среду разработки, позволяет планировать задания, централизованно вести журналы и оповещения, а также, среди прочего, обеспечивает CI/CD с Slim CI.

Преимущества использования DBT

• Организация кода: DBT поощряет использование модульных сценариев SQL для преобразований, что приводит к лучшей организации кода и простоте обслуживания. Хорошо структурированная кодовая база способствует сотрудничеству между членами команды и упрощает процесс разработки.
• Возможности тестирования: Одной из выдающихся особенностей DBT является встроенная среда тестирования. Инженеры по обработке данных могут определять тесты для обеспечения целостности и точности преобразованных данных, снижая риск ошибок и несоответствий.
• Контроль версий: DBT рассматривает преобразования данных как код, а это означает, что их версии можно контролировать с помощью стандартных систем контроля версий, таких как Git. Это позволяет группам данных отслеживать изменения, просматривать историю и эффективно сотрудничать.
• Автоматическое документирование: DBT предоставляет функцию автоматического создания документации, которая создает полную и актуальную документацию для datasets и моделей данных. Эта документация невероятно полезна как для потребителей данных, так и для тех, кто их поддерживает.
• Повышенная производительность: Используя возможности SQL непосредственно в хранилище данных, DBT сводит к минимуму перемещение данных и оптимизирует производительность, что приводит к более быстрому преобразованию данных и повышению общей эффективности.

Внедрение DBT, несомненно, может дать командам данных возможность создавать надежные, масштабируемые и обслуживаемые конвейеры данных. Его бесшовная интеграция с различными хранилищами данных и совместимость с Apache Airflow открывают безграничные возможности, что делает DBT ценным дополнением к набору инструментов любого инженера по обработке данных.

Что включает в себя проект dbt

Пример структуры проекта

Общая схема dbt проекта и его компоненты

Проект dbt — это каталог файлов SQL и YAML, используемый для преобразования ваших данных. Файл YAML содержит информацию о конфигурации проекта. Каждая модель содержит один оператор SQL SELECT, который каким-либо образом преобразует данные.

SQL уже давно является языком выбора для аналитиков, разрабатывающих преобразования и выполняющих анализ. Таким образом, решение dbt использовать файл модели в виде оператора SQL SELECT означает, что аналитикам не нужно изучать новый язык или инструмент, и они могут свободно преобразовывать данные так же, как они делали это раньше. Использование SQL упрощает совместную работу и позволяет лучше понять ваши преобразования.

packages dbt — это автономные проекты dbt, которые используют преимущества модульности проектов, чтобы сделать модули, решающие конкретную проблемную область, доступными для будущего использования, во многом подобно библиотеке кода. Эти пакеты содержат предварительно созданный SQL, что значительно снижает необходимость ручного преобразования кода.

Файлы YAML используются не только для настройки вашего проекта dbt, но также для управления словарем исходных и преобразованных данных, а также для применения тестов целостности данных. При эффективном использовании конечный результат вашего проекта dbt будет содержать определение каждой необработанной таблицы из источника и преобразованной таблицы из вашей размерной схемы, а также описание каждого поля в этих таблицах. Кроме того, вы можете применять тесты к определенным полям (т.е. поле первичного ключа всегда должно быть уникальным) и проверять свои данные, чтобы убедиться в отсутствии проблем с целостностью данных.

Модели (sql код) являются модульными, поэтому трансформацию можно воспроизвести в нескольких проектах. Любой разработчик скажет вам, насколько ценно повторное использование кода с точки зрения экономии времени и усилий. Проект также может включать файлы тестов, макросов и документации.

Seeds (Сиды) — это способ загрузки данных из csv-файлов в наше хранилище данных (документация dbt). Поскольку эти файлы CSV расположены в нашем репозитории dbt, они контролируются версиями и подлежат проверке кода. Этот метод подходит для загрузки статических данных, которые изменяются нечасто. CSV-файл длиной до ~1 тыс. строк и размером менее нескольких килобайт, вероятно, является хорошим кандидатом для использования с этой dbt seed командой.

Теги в dbt — это способ обозначить различные части проекта. Эти теги затем можно использовать при выборе наборов моделей, снимков или начальных значений для запуска. Теги можно добавлять в файлы YAML или в настройки конфигурации любой модели. Просмотрите dbt_project.ymlфайл и найдите несколько примеров использования тегов.

Snapshots: Атрибуты бизнес-субъекта со временем меняются. Эти изменения должны быть зафиксированы в нашем хранилище данных. Например, пользователь может переехать на новый адрес. В моделировании хранилища данных это называется медленно меняющимися измерениями.

Dbt позволяет нам легко создавать эти медленно меняющиеся таблицы измерений (тип 2) с помощью функции Snapshot (dbt snapshot). При создании моментального снимка нам необходимо определить базу данных, схему, стратегию и столбцы для идентификации обновлений строк.

Документация и Data Lineage: при создании документации мы получаем помимо автоматически сгенерированного документа, со всеми зависимостями между моделями, источниками — еще и Data Lineage.

Пример:

Hooks (Хуки) — это фрагменты SQL, которые выполняются в разное время:

• pre-hook: выполняется до построения model, seed или snapshot.
• post-hook: выполняется после построения model, seed или snapshot.
• on-run-start: выполняется в начале, dbt build, dbt compile, dbt docs generate, dbt run, dbt seed, dbt snapshot или dbt test.
• on-run-end: выполняется в конце dbt build, dbt compile, dbt docs generate, dbt run, dbt seed, dbt snapshot или dbt test.

Хуки — это более продвинутая возможность, которая позволяет вам запускать собственный SQL и использовать действия, специфичные для базы данных, помимо того, что dbt предоставляет «из коробки» со стандартными материализациями и конфигурациями.

Целью dbt является предоставление всего необходимого шаблонного SQL-кода (DDL, DML и DCL) посредством готовых функций, которые можно быстро и лаконично настроить. В некоторых случаях может существовать SQL, который вы хотите или должны запустить, в зависимости от функциональности вашей платформы данных, который dbt (пока) не предлагает в качестве встроенной функции. В таких случаях вы можете написать именно тот SQL, который вам нужен, используя контекст компиляции dbt, и передать его в pre-hook или post-hook для запуска до или после вашей model, seed или snapshot.

Operations (Операции) — это макросы, которые можно запускать с помощью run-operation команды. Таким образом, операции на самом деле не являются отдельным ресурсом в вашем проекте dbt — это просто удобный способ вызвать макрос без необходимости запуска модели.

Jinja

• Выражение {{ ... }}: выражения используются, когда вы хотите вывести строку в скомпилированный файл. Вы можете использовать выражения для ссылки на переменные и вызова макросов.
• Оператор {% ... %}: этот оператор не выводит строку. Он используется для потока управления, например, для настройки for циклов и if (условных) операторов, для установки или изменения переменных или для определения макросов.
• Комментарий {# ... #}: комментарии Jinja используются для предотвращения выполнения текста внутри комментария или вывода строки.

Примеры:

Макросы в Jinja — это фрагменты кода, которые можно использовать многократно. Они аналогичны «функциям» в других языках программирования и чрезвычайно полезны, если вы обнаружите, что код повторяется в нескольких моделях. Макросы определяются в .sqlфайлах, обычно в вашем macros каталоге.

Пример макроса macros/cents_to_dollars.sql:

Вызов макроса в модели:

Конфигурация проекта dbt

Каждый проект dbt включает файл конфигурации проекта с именем dbt_project.yml. Он определяет каталог проекта dbt и другие конфигурации проекта.

Пример dbt_project.yml

Поддерживаемые платформы данных (dbt adapter plugins)

dbt подключается к вашей базе данных, warehouse, lake или query engine и запускает SQL. Эти платформы, использующие SQL, вместе называются платформами данных. dbt подключается к платформам данных, используя для каждой отдельный плагин-адаптер. Плагины создаются как модули Python, которые dbt Core обнаруживает, если они установлены в вашей системе.

Типы адаптеров

• Verified — Verified adapters (Проверенные адаптеры) — это те адаптеры, которые прошли строгий процесс проверки в сотрудничестве с dbt Labs.
• Trusted — Trusted adapters (Доверенные адаптеры) — это адаптеры, сопровождающие которых согласились соответствовать более высоким стандартам качества.
• Community — Community adapters (Адаптеры сообщества) — имеют открытый исходный код и поддерживаются членами сообщества.

Философия проектирования dbt

Кодоориентированный подход
Основой философии дизайна dbt является кодоориентированный подход к моделированию и преобразованию данных. Вместо того, чтобы полагаться на графические интерфейсы или ручные сценарии SQL, dbt предлагает пользователям определять преобразования данных с помощью кода. Переход к разработке на основе кода способствует сотрудничеству, контролю версий и автоматизации.

Модульность для повторного использования
dbt способствует модульности, позволяя специалистам по работе с данными создавать код многократного использования. Модели, макросы и тесты можно организовать в пакеты, что упрощает обслуживание и масштабируемость кода. Этот модульный подход соответствует лучшим практикам и повышает возможность повторного использования кода.

Преобразования как операторы SQL SELECT
Модели dbt определяются как SELECT операторы в SQL, что делает их доступными для аналитиков и инженеров, владеющих навыками SQL. Такой выбор конструкции упрощает разработку и гарантирует, что моделирование данных точно соответствует передовым практикам SQL.

Декларативный язык
dbt использует декларативный язык для определения преобразований данных. Аналитики определяют желаемый результат, а dbt занимается базовой реализацией. Эта абстракция упрощает написание сложного кода SQL и повышает читаемость.

Инкрементальные сборки
Эффективность – это ключевой фокус дизайна dbt. DBT поддерживает инкрементные сборки, что позволяет инженерам данных обновлять только затронутые части конвейера данных, а не повторно обрабатывать весь набор данных. Это ускоряет разработку и сокращает время обработки.

Документация как код
DBT выступает за документирование моделей данных и преобразований в виде кода. Описания, пояснения и метаданные хранятся вместе с кодом проекта, что упрощает понимание и эффективное сотрудничество членов команды.

Качество данных, тестирование и проверка
dbt делает значительный упор на тестирование данных. Он предоставляет среду тестирования, которая позволяет аналитикам определять тесты качества данных и правила проверки. За счет этого повышается надежность и качество данных на протяжении всего конвейера, что гарантирует соответствие данных заранее определенным критериям и бизнес-правилам.

Интеграция контроля версий
Бесшовная интеграция с системами контроля версий, такими как Git, является фундаментальным аспектом dbt. Эта функция обеспечивает совместную разработку, отслеживание изменений и возможность отката изменений, гарантируя, что конвейеры данных остаются под версионным контролем.

Встроенная интеграция с платформами данных
dbt предназначен для беспрепятственной работы с популярными платформами данных, такими как Snowflake, BigQuery, Redshift, PostgreSQL, ClickHouse. Он использует собственные возможности этих платформ для масштабируемости и производительности.

Открытый исходный код и расширяемый
dbt — это открытый исходный код с растущим сообществом. Пользователи могут расширить его функциональность, создавая собственные макросы и пакеты. Такая расширяемость позволяет организациям адаптировать базу данных к своим конкретным потребностям в данных.

Краткое описание WorkFlow при работе с DBT для новичков (первые шаги)

1. Установка dbt
2. Установите dbt adapter plugin, например:
   • Если у вас PostgreSQL, то pip install dbt-postgres
   • Если у вас ClickHouse, то pip install dbt-clickhouse
3. Настройте profiles.yml для подключения к базе данных
4. Проверьте подключение к БД, в котором dbt будет запускать sql. После того как вы настроили profiles.yml, запустите следующую команду в командной строке или терминале
   dbt debug
5. Инициализируйте свой проект dbt с помощью команды
   dbt init
6. Cоздайте вашу первую модель dbt. Для этого в директории models создайте новый файл с именем model_name.sql и добавьте код SQL
7. Проверьте модель. Для этого нужно запустить команду dbt run. Эта команда скомпилирует и запустит все модели вашего проекта, включая model_name.sql (вашу созданную модель). Если все настроено правильно, вы должны увидеть в своем терминале сообщение о том, что модель скомпилирована и успешно запущена.
8. Скомпилируем документацию проекта, с помощью команды
   dbt docs generate
9. Запустим документацию с использованием порта 8081
   dbt docs serve --port 8001

Усложненная схема, глазами разработчиков, выглядит следующим образом:

Все проекты dbt должны управляться с помощью системы контроля версий. Ветки Git следует создавать для управления разработкой новых функций и исправлением ошибок. Все изменения кода должны быть проверены коллегой (или вами) в запросе на включение перед слиянием с master.

Стили SQL, соглашения об именах полей и другие правила вашего проекта dbt должны быть систематизированы, особенно в проектах, в которых код пишут несколько пользователей dbt.

Почитайте раздел официальной документации: How we style our dbt projects

Описание основных команд dbt для запуска моделей, тестов, снепшотов

Общие команды dbt

• dbt run: эта команда выполняет все модели в вашем проекте dbt. Это основной способ запустить преобразования и загрузить преобразованные данные в хранилище данных.
• dbt test: После запуска моделей очень важно протестировать их. Эта команда запускает тесты, определенные в вашем проекте, для обеспечения целостности и согласованности данных.
• dbt build: Комплексная команда, которая запускает модели, тесты и исходные данные в правильном порядке на основе графа зависимостей вашего проекта.
• dbt compile: перед запуском моделей вы можете скомпилировать их для проверки сгенерированного SQL. Эта команда делает именно это, не выполняя SQL для вашей базы данных.

Расширенное использование dbt

• dbt deps: Управляет зависимостями проекта. Запустите эту команду перед другими командами, чтобы убедиться, что у вас установлены последние версии всех пакетов, от которых зависит ваш проект.
• dbt seed: загружает файлы CSV в вашу базу данных, которые могут быть полезны для справочных данных, таких как таблицы сопоставления.
• dbt snapshot: фиксирует историческое представление ваших данных через определенные промежутки времени, что позволяет отслеживать изменения с течением времени.

Установка dbt с помощью pip install и virtual environment

# Создаем директорию проекта
mkdir my_dbt_prj

# Переходим в директорию проекта dbt
cd my_dbt_prj

# Создаем виртуальную среду dbt-venv с помощью пакета venv
python3 -m venv dbt-venv

# Активируем среду
source dbt-venv/bin/activate

# Установка dbt-core:
# 1) pip install dbt-core — это установка последней версии
# 2) pip install dbt-core==1.7.0 — установка какой-то конкретной версии dbt
# Всегда проверяйте в плагине, который хотите использовать совместимость с версией dbt

pip install dbt-core==1.7.0

# Проверка установленной версии dbt
dbt --version

# Обновить версию dbt

python3 -m pip install --upgrade dbt-core==1.7.2

Полный код примера инсталляции в одном блоке

Инициализация проекта dbt

todo

Materializations (Материализация данных в хранилище)

Материализации — это стратегии сохранения моделей dbt в warehouse. В dbt встроено пять типов материализаций:

1. Table (Таблица) — это модель, которая удаляет и воссоздает всю таблицу каждый раз при запуске модели.
2. Incremental Model (Инкрементная модель) — вставляет или обновляет таблицу постепенно в зависимости от того, когда модель запускается.
3. View (Представление) — это модель, которая создает данные «на лету», когда это необходимо. Он материализован, и к нему можно получить доступ, как если бы это была физическая таблица.
4. Ephemeral Model (Эфемерная модель) — содержит подзапросы SQL, которые используются моделями других типов. SQL генерируется «на лету» при использовании других моделей dbt. Он не материализован в физическую таблицу, и к нему нельзя получить доступ за пределами dbt.
5. Source (Источник) — это физическая таблица, на которую может ссылаться dbt, но которая создается и контролируется извне.

View

При использовании view материализации ваша модель перестраивается в представление при каждом запуске с помощью create view asоператора.

Плюсы: Никакие дополнительные данные не сохраняются, представления поверх исходных данных всегда будут содержать самые последние записи.

Минусы: представления, которые выполняют значительные преобразования или накладываются поверх других представлений, выполняются медленно.

Совет:
Обычно начинайте с представлений для своих моделей и переходите к другой материализации только тогда, когда заметите проблемы с производительностью.
Представления лучше всего подходят для моделей, которые не выполняют существенных преобразований, например переименования или изменения столбцов.
При использовании tableматериализации ваша модель перестраивается в виде таблицы.при каждом запуске с помощью create table asоператора.

Table

Плюсы: таблицы быстро запрашиваются.

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

Совет:
Используйте материализацию таблицы для любых моделей, запрашиваемых инструментами BI, чтобы ускорить работу конечного пользователя.
Также используйте материализацию таблицы для любых более медленных преобразований, которые используются во многих последующих моделях.

Incremental Model

incremental модели позволяют dbt вставлять или обновлять записи в таблицу с момента последнего запуска этой модели.

Плюсы: вы можете значительно сократить время сборки, просто преобразовав новые записи.

Минусы: инкрементные модели требуют дополнительной настройки и представляют собой расширенное использование dbt. Подробнее об использовании инкрементных моделей читайте здесь.

Совет:
Инкрементальные модели лучше всего подходят для данных в стиле событий.
Используйте инкрементальные модели, когда ваши dbt runпрограммы становятся слишком медленными (т. е. не начинайте с инкрементальных моделей).

Ephemeral Model

ephemeral модели не встроены непосредственно в базу данных. Вместо этого dbt будет интерполировать код из этой модели в зависимые модели в виде общей таблицы.выражение.

Плюсы:
Вы все еще можете писать многоразовую логику
Эфемерные модели могут помочь сохранить ваше хранилище данныхочистить, уменьшив беспорядок (также рассмотрите возможность разделения ваших моделей на несколько схем с помощью пользовательских схем).

Минусы:
Вы не можете выбрать непосредственно из этой модели.
Операции (например, макросы, вызываемые с использованием dbt run-operation невозможных ref() эфемерных узлов)
Чрезмерное использование эфемерной материализации также может затруднить отладку запросов.
Эфемерная материализация не поддерживает модельные контракты .

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

Materialized View

Материализация materialized view позволяет создавать и поддерживать материализованные представления в целевой базе данных. Материализованные представления представляют собой комбинацию представления и таблицы и служат сценариям использования, аналогичным инкрементным моделям.

Плюсы:
Материализованные представления сочетают в себе производительность запросов таблицы и актуальность данных представления.
Материализованные представления работают во многом аналогично добавочной материализации, однако их обычно можно обновлять без ручного вмешательства с регулярной частотой (в зависимости от базы данных), отказываясь от регулярного пакетного обновления dbt, необходимого для добавочной материализации.
dbt runв материализованных представлениях соответствует развертыванию кода, как и в представлениях.

Минусы:
Поскольку материализованные представления представляют собой более сложные объекты базы данных, платформы баз данных, как правило, имеют меньше доступных вариантов конфигурации; дополнительную информацию см. в документации вашей платформы базы данных.
Материализованные представления могут поддерживаться не всеми платформами баз данных.

Совет:
Рассмотрите материализованные представления для случаев использования, когда инкрементных моделей достаточно, но вы хотите, чтобы платформа данных управляла инкрементной логикой и обновлялась.

DBT Command line cheat sheet (Шпаргалка по командной строке дбт)

• dbt clean — this will remove the /dbt_modules (populated when you run deps) and /target folder (populated when models are run)
• dbt run — regular run
• Model selection syntax (source). Specifying models can save you a lot of time by only running/testing the models that you think are relevant. However, there is a risk that you’ll forget to specify an important upstream dependency so it’s a good idea to understand the syntax thoroughly:
  • dbt run --models modelname — запустится только модель modelname
  • dbt run --models +modelname — запустится модель modelname и все родительские модели
  • dbt run --models modelname+ — запустит модель modelname и все дочерние (последующие) модели
  • dbt run --models +modelname+ — запустит модель modelname, а также все родительские и дочерние модели (все зависящие потоки до и после)
  • dbt run --models @modelname — will run modelname, all parents, all children, AND all parents of all children
  • dbt run --exclude modelname — will run all models except modelname
  • Note that all of these work with folder selection syntax too:
    • dbt run --models folder — will run all models in a folder
    • dbt run --models folder.subfolder — will run all models in the subfolder
    • dbt run --models +folder.subfolder — will run all models in the subfolder and all parents
• dbt run --full-refresh — will refresh incremental models
• dbt test — will run custom data tests and schema tests; TIP: dbt test takes the same --model and --exclude syntax referenced for dbt run
• dbt seed — will load csv files specified in the data-paths directory into the data warehouse. Also see the seeds section of this guide
• dbt compile — compiles the templated code within the model(s) and outputs the result in the target/ folder. This isn’t a command you will need to run regularly as dbt will compile the models automatically when you to ‘dbt run’. One common use-case is the compiled code can be run in Snowflake directly for debugging a model.

Полный список команд можно скачать в файле DBT Command line cheat sheet.pdf >>>

Расширение VSCode: dbt Power User

dbt Power User позволяет VScode беспрепятственно работать с dbt.

dbt-clickhouse adapter plugin Tutorial

Ссылка на плагин: dbt-clickhouse

Пример проекта DWH dbt clickhouse на GitHub: dbt_clickhouse_lab DWH powered by Clickhouse and dbt

GitHub dagster_clickhouse_dbt DBT and clickhouse test project with dagster — пример автоматизации с помощью Дагстера

Курс по dbt с нуля. Занятие 1. Преимущества dbt. Запускаем dbt из docker в связке с ClickHouse

Видео на английском: Using dbt to Transform Data in ClickHouse

Установка плагина dbt ClickHouse

pip install dbt-clickhouse

Поддерживаемые фичи в dbt-clickhouse

• Table materialization
• View materialization
• Incremental materialization
• Materialized View materializations (uses the TO form of MATERIALIZED VIEW, experimental)
• Seeds
• Sources
• Docs generate
• Tests
• Snapshots
• Most dbt-utils macros (now included in dbt-core)
• Ephemeral materialization
• Distributed table materialization (experimental)
• Distributed incremental materialization (experimental)
• Contracts

База данных ClickHouse

Идентификатор связи модели dbt database.schema.table несовместим с Clickhouse, поскольку Clickhouse не поддерживает формат schema. Поэтому мы используем упрощенный подход schema.table, где schemaнаходится база данных Clickhouse. Использование default базы данных не рекомендуется.

Конфигурация модели

Incremental Model Strategies

Default (Legacy) Strategy (устаревшая стратегия)

Исторически ClickHouse имел лишь ограниченную поддержку обновлений и удалений в форме асинхронных «мутаций». Чтобы эмулировать ожидаемое поведение dbt, dbt-clickhouse по умолчанию создает новую временную таблицу, содержащую все незатронутые (не удаленные, не измененные) «старые» записи, а также любые новые или обновленные записи, а затем заменяет или заменяет эту временную таблицу существующими инкрементными таблицами.

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

Delete+Insert Strategy

ClickHouse добавил «облегченное удаление» в качестве экспериментальной функции в версии 22.8. Облегченные удаления выполняются значительно быстрее, чем операции ALTER TABLE … DELETE, поскольку они не требуют перезаписи частей данных ClickHouse. Инкрементная стратегия delete+insertиспользует облегченные удаления для реализации инкрементальной материализации, которая работает значительно лучше, чем «устаревшая» стратегия. Однако есть важные предостережения относительно использования этой стратегии:

• Облегченное удаление должно быть включено на вашем сервере ClickHouse с помощью настройки allow_experimental_lightweight_delete=1 или вы должны установить use_lw_deletes=true это в своем профиле (что включит этот параметр для ваших сеансов dbt).
• Облегченное удаление теперь готово к работе, но в версиях ClickHouse, предшествующих 23.3, могут возникнуть проблемы с производительностью и другие проблемы.
• Эта стратегия работает непосредственно с затронутой таблицей/отношением (с созданием любых промежуточных или временных таблиц), поэтому, если во время операции возникнет проблема, данные в инкрементальной модели, скорее всего, окажутся в недопустимом состоянии.
• При использовании упрощенного удаления dbt-clickhouse включил настройку allow_nondeterministic_mutations. В некоторых очень редких случаях использование недетерминированных инкрементальных_предикатов может привести к состоянию гонки для обновленных/удаленных элементов (и связанных с ними сообщений журнала в журналах ClickHouse). Чтобы обеспечить согласованность результатов, инкрементные предикаты должны включать только подзапросы к данным, которые не будут изменены во время инкрементальной материализации.

Append Strategy (inserts_only)

Эта стратегия заменяет inserts_only настройку в предыдущих версиях dbt-clickhouse. Этот подход просто добавляет новые строки к существующему отношению. В результате повторяющиеся строки не удаляются, а временная или промежуточная таблица отсутствует. Это самый быстрый подход, если дубликаты либо разрешены в данных, либо исключены с помощью предложения/фильтра WHERE добавочного запроса.

Пример материализации таблицы для модели актеров

Схема покрытия данных тестами (Golden Data Coverage)

С помощью DBT можно реализовать 12 категорий мониторов и тестов Trusted Data Framework (TDF) (мониторы создаются и выполняются в Monte-Carlo , тесты создаются и выполняются в dbt):

1. Freshness monitors Отслеживайте необычные задержки в обновлении таблиц и полей.
2. Schema monitors Отслеживайте поля, которые добавляются, удаляются или изменяются.
3. Volume monitors Отслеживайте необычные изменения размера таблицы в зависимости от количества строк.
4. Field health Monitor Отслеживайте поля на предмет провалов или скачков статистики, таких как % null, % уникальности и т. д. Наше машинное обучение устанавливает пороговые значения.
5. SQL rule monitor Напишите оператор SQL для проверки любого выражаемого условия в одной или нескольких таблицах ваших данных.
6. JSON schema monitor Отслеживайте изменения схемы в данных JSON, добавленных в поле таблицы.
7. Dimension tracking Отслеживайте изменения в распределении значений в поле таблицы с низкой мощностью.
8. Тесты схемы для проверки целостности схемы.
9. Значение столбца проверяет , соответствует ли значение данных в столбце заранее определенным пороговым значениям или литералам.
10. Тесты Rowcount  определяют, соответствует ли количество строк в таблице за заранее определенный период времени заранее определенным пороговым значениям или литералам.
11. Пользовательский SQL проверяет любой допустимый SQL, который не соответствует вышеуказанным категориям.

Тесты можно хранить в двух основных местах — либо в файле YAML в основном проекте, либо в  проекте тестов данных.

Тесты схемы и значения столбца обычно находятся в основном проекте. Они будут находиться schema.yml в sources.ymlтом же каталоге, что и модели, которые они представляют.

Rowcount и любые другие пользовательские тесты SQL всегда будут в проекте Data Tests.

Подборка видео по dbt на YouTube

DataLearn Channel: ВВЕДЕНИ В DBT / СОЗДАНИЕ МОДЕЛЕЙ ПРИ ПОМОЩИ DBT / УПРАВЛЕНИЕ ТРАНСФОРМАЦИЕЙ ДАННЫХ / РИШАТ МИНГАЗОВ

M&H Corporate Channel

Введение в dbt. Что это такое и зачем нужно

Модели в dbt

dbt: источники и сиды

dbt. Снэпшоты и метрики

dbt. Jinja и шаблоны

Прагматичный подход к трансформации данных: dbt и Python — Ярослав Телишевский, независимый эксперт

Марк Порошин — Data Vault на Greenplum c помощью DBT

Intro to Data Build Tool (dbt) // Create your first project!

PlayList: dbt (data-build-tool)

Плейлист по DBT на английском

Introduction to dbt (data build tool) from Fishtown Analytics

dbt Tutorial (Data Build Tool) — Beginners and Advanced | in 1 hour

Airflow with DBT tutorial — The best way!