Проблема, которую решает dbt

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

Три выручки

Неделя с 1 по 7 июня 2026 года. Маркетинг считает выручкой все оформленные заказы: клиент нажал «заказать», значит, деньги наши. Операционная команда Отто берёт только доставленные. Финансы ещё строже: доставка засчитывается, только если в ней нет сбоя, то есть время доставки записано и оно не раньше времени, когда курьер забрал заказ.

Одна неделя, три выручки

База · courier

На весь экран

ТаблицыВыбери таблицу

-- Маркетинг: все оформленные заказы SELECT sum(price_rub) AS revenue FROM orders WHERE created_at >= '2026-06-01' AND created_at < '2026-06-08'; -- Операционная команда: только доставленные SELECT sum(price_rub) AS revenue FROM orders WHERE status = 'delivered' AND created_at >= '2026-06-01' AND created_at < '2026-06-08'; -- Финансы: доставленные без сбоев в данных SELECT sum(price_rub) AS revenue FROM orders WHERE status = 'delivered' AND delivered_at >= picked_up_at AND created_at >= '2026-06-01' AND created_at < '2026-06-08';

Загружаю редактор…

ВыполнитьОткрыть базуСбросить базуВернуть запрос

База загрузится, когда ты выполнишь запрос или откроешь таблицы.

РезультатГрафикДанныеСтруктура

Выполни запрос, чтобы увидеть результат.

Выполни весь запрос кнопкой или Ctrl/Cmd+Enter. Ctrl+Space открывает подсказки. Можно писать несколько команд через точку с запятой, менять данные и открывать транзакции. У каждой песочницы своя база, изменения живут до ухода со страницы. «Сбросить базу» возвращает учебные данные, но не меняет SQL.

Получается 475 610, 452 996 и 452 811 рублей. Никто не ошибся в SQL. Каждый запрос верно отвечает на свой вопрос. Беда в том, что вопрос у всех назывался одинаково: «выручка за неделю».

Сборник рецептов без оглавления

Представь бабушкину тетрадь рецептов. Рецепт пирога ссылается на «тесто, как на странице 12», тесто ссылается на «закваску, см. выше», а закваску бабушка однажды переписала и не сказала, какую версию теперь использовать. Чтобы испечь пирог, надо знать, в каком порядке готовить, какую закваску брать и не испортилась ли она. Всё это держится в голове у одного человека.

SQL-запросы в компании растут так же. Сначала их пять, потом пятьдесят. Запрос выручки читает представление «чистые заказы», которое кто-то сделал год назад. Потом его поменяли, и сломались три отчёта, о которых никто не знал.

Пять болей

Если собрать жалобы любой команды с кучей SQL, получится примерно такой список.

1. Логика повторяется. Перевод часовых поясов и отбор чистых доставок скопированы в десятки запросов. Нашёл ошибку: ищи все копии.
2. Непонятен порядок. Представления и таблицы зависят друг от друга. Чтобы пересобрать витрину, нужно знать, что пересобрать раньше. Обычно это знает один человек.
3. Нет тестов. Дубль заказа или пустой курьер обнаруживает Отто, глядя на дашборд, а не проверка до него.
4. Нет документации. Что значит колонка late? Опоздание больше нуля минут или больше пяти? Ответ в голове у автора.
5. Нет истории правок. Кто и когда поменял определение выручки? Запросы живут в BI-системе, и прошлую версию не вернуть.