Benoit Perigaud

Сегодня есть два основных способа получать ответы на вопросы по данным с помощью LLM: поручить модели писать SQL напрямую или выполнять запросы через структурированную онтологию, такую как dbt Semantic Layer. Оба способа работают. Компании получают реальную пользу от каждого из них. Но ошибки у них совершенно разные, и именно понимание этих ошибок по-настоящему важно при выборе подхода.

В 2023 году мы провели бенчмарк, сравнив эти два подхода, и Semantic Layer одержал уверенную победу. Но по меркам развития LLM 2023 год был примерно 10 миллионов лет назад. Модели стали значительно лучше писать SQL. Поэтому мы повторили бенчмарк с моделями последнего поколения, чтобы выяснить, сократился ли разрыв.

Примечание редактора — этот пост предполагает средний уровень знаний Jinja и разработки макросов в dbt. Для введения в Jinja в dbt ознакомьтесь с документацией и бесплатным курсом Jinja, Macros, Packages.

Jinja приносит много возможностей в dbt, позволяя нам использовать ref(), source(), условный код и макросы. Но, хотя Jinja приносит гибкость, она также добавляет сложность, и, как часто бывает с кодом, вещи могут работать не так, как ожидалось.

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

Давайте погрузимся в последний случай, когда я использовал debug() и как он помог мне решить ошибки в моем коде.

Примечание редактора — с момента создания этого поста, владение пакетом pre-commit-dbt перешло к другой команде, и он был переименован в dbt-checkpoint. Настроен редирект, что означает, что приведенный ниже пример кода все еще будет работать. Также можно заменить repo: https://github.com/offbi/pre-commit-dbt на repo: https://github.com/dbt-checkpoint/dbt-checkpoint в вашем файле .pre-commit-config.yaml.

В dbt Labs у нас есть лучшие практики, которым мы предпочитаем следовать при разработке проектов dbt. Одна из них, например, заключается в том, что все модели должны иметь как минимум тесты unique и not_null на их первичный ключ. Но как мы можем применять такие правила?

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