Dave Connors

Новый движок — кто это у нас?​

Вряд ли кто-то из читателей этого блога ещё не слышал о новом движке dbt Fusion — о нём говорят все в мире данных с января прошлого года, а кульминацией стала легендарная живая демонстрация Элиаса на Coalesce 2025, показавшая невероятные возможности, которые открывает встроенное понимание SQL в dbt. Если вы были на Coalesce или уже перевели свой проект на Fusion, то, скорее всего, слышали и об изменениях, которые мы внесли в средства описания проектов dbt (то есть непосредственно в код, который вы пишете в проекте). Выпуская новую мажорную версию, мы воспользовались возможностью упростить и стандартизировать язык конфигурации dbt, чтобы он был готов к масштабированию в новую эпоху аналитической инженерии.

В частности, мы хотели пересмотреть подход к определению метрик в dbt Semantic Layer. На протяжении многих лет мы слышали от участников сообщества, что определять метрики попросту сложно. Обсудив это с внутренними и внешними пользователями, а также с нашими новыми друзьями из SDF, мы разработали обновлённую спецификацию YAML: она проще, лучше вписывается в привычный и любимый нами подход к настройке dbt и рассчитана на будущее.

Вы когда‑нибудь задумывались, что на самом деле происходит в базе данных, когда вы отправляете туда (идеальный, эффективный, полный инсайтов) SQL‑запрос?

Ладно, скорее всего — нет 😅. Как бы то ни было, в dbt Labs мы очень много говорим об инструментах SQL Comprehension после приобретения SDF Labs и считаем, что сообществу тоже будет полезно участвовать в этом разговоре. Недавно мы опубликовали пост в блоге о разных уровнях инструментов SQL Comprehension. Если вы его читали, то могли столкнуться с несколькими новыми терминами, с которыми раньше были не очень знакомы.

В этом посте мы подробнее разберём технологии, лежащие в основе инструментов SQL Comprehension. Надеемся, что в итоге у вас появится более глубокое понимание — и уважение — к той непростой работе, которую выполняет компьютер, превращая ваши SQL‑запросы в прикладные бизнес‑инсайты!

Что такое платформа данных?​

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

Когда проект смог самостоятельно одеваться и питаться, мы также усердно работали, чтобы заручиться поддержкой наших коллег, которые доверяли нашему маленькому проекту. Без глубокого доверия и понимания того, что мы построили, наши коллеги, которые зависят от ваших данных (или даже те, кто участвует в их разработке вместе с вами — в конце концов, это требует усилий всей команды!), скорее всего, будут обращаться к вам с вопросами, чем использовать свои BI-инструменты для генерации инсайтов.

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

Встречайте dbt Explorer! dbt Explorer централизует документацию, зависимость и метаданные выполнения, чтобы уменьшить объем работы, необходимой для быстрой доставки надежных продуктов данных.

Представьте себе — у вас огромный проект dbt, тысячи моделей работают, создавая полезные инсайты для ваших заинтересованных сторон. Вам поступает запрос — модель нужно переработать! "Нет проблем," думаете вы, "Я просто внесу изменения и протестирую их локально!" Вы смотрите на свою родословную и понимаете, что эта модель находится на многих уровнях глубоко, погребенная под длинной цепочкой таблиц и представлений.

"Хорошо," думаете вы дальше, "Я просто выполню dbt build -s +my_changed_model, чтобы убедиться, что у меня все построено в моей dev-схеме, и я могу протестировать свои изменения". Вы запускаете команду. Ждете. Ждете еще. Берете кофе и полностью выходите из своего потока разработки dbt. Много времени и денег потрачено впустую, чтобы добраться до точки, где вы можете начать свою работу. Это не годится!

К счастью, функциональность defer в dbt позволяет вам строить только то, что вам нужно, и ничего больше. Эта функция помогает разработчикам тратить меньше времени и денег на разработку, помогая быстрее выпускать надежные продукты данных. dbt Cloud предлагает нативную поддержку этого рабочего процесса в разработке, так что вы можете начать использовать defer без дополнительных затрат!

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

Иногда нам везет, и у нас есть источники данных с уже встроенными ключами — например, данные Shopify, синхронизированные через их API, имеют простые в использовании ключи на всех таблицах, записанных в ваше хранилище. Если это не так, или если вы строите модель данных с составным ключом (то есть данные уникальны по нескольким измерениям), вам придется полагаться на какую-то стратегию для создания и поддержания этих ключей самостоятельно. Как это сделать с помощью dbt? Давайте разберемся.

Измерение количества рабочих часов между двумя датами с использованием SQL — это одна из тех классических задач, которая звучит просто, но мучает аналитиков с незапамятных времен.

Эта задача возникает в нескольких местах в dbt Labs:

• Расчет времени, необходимого для решения заявки в службу поддержки
• Измерение производительности команды в соответствии с соглашениями об уровне обслуживания (SLA) по времени ответа

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

Тем не менее, вам придется выполнить довольно сложные SQL или dbt-манипуляции, чтобы сделать это правильно, включая:

1. Определение, как исключить ночи и выходные из ваших SQL-расчетов
2. Учет праздников с использованием пользовательского календаря праздников
3. Приспособление к изменениям в расписании рабочих часов

Эта статья предоставит обзор того, как и, что важно, почему рассчитывать время выполнения задачи и как мы используем его здесь, в dbt Labs.

[Мы бы хотели иметь] кривую зрелости для реализации dbt от начала до конца для каждой версии dbt .... Сейчас в dbt так много функций, но было бы здорово понять, "какой минимальный набор функций/компонентов dbt должен быть в базовой реализации dbt?... а что является дополнительным бонусом?" -Will Weld на dbt Community Slack

Один из вопросов, который мы слышим снова и снова, - как выглядит прогресс через различные стадии зрелости в проекте dbt?

Когда Уилл задал этот вопрос в Slack, я задумался о том, что потребуется для создания структуры зрелости проекта dbt.

Если вы используете dbt более года, ваш проект устарел. Это естественно.

Появились новые функции. Изменяются хранилища данных. Обновляются лучшие практики. За последний год я и другие члены команды Fishtown Analytics (теперь dbt Labs!) провели семь аудитов для клиентов, которые использовали dbt минимум 2 месяца.