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

Новое в dbt: разрешение моделям Python в Snowflake доступ к интернету​

С выпуском dbt 1.8, dbt добавил поддержку интеграций внешнего доступа Snowflake, что позволяет использовать dbt + AI для обогащения ваших данных. Это позволяет выполнять запросы к внешним API в моделях Python в dbt, что было необходимо для клиента dbt Cloud, EQT AB. Узнайте, почему им это было нужно и как они помогли разработать и внедрить эту функцию!

В dbt Labs мы всегда стремились поддерживать аналитиков там, где они находятся. Поэтому мы рады сообщить, что теперь аналитики в экосистеме Microsoft могут использовать dbt Cloud не только с Microsoft Fabric, но и с Azure Synapse Analytics Dedicated SQL Pools (ASADSP).

С самого начала dbt люди проявляли интерес к платформам данных MSFT. Огромная благодарность Mikael Ene и Jacob Mastel за их усилия в 2019 году по созданию оригинальных адаптеров SQL Server (dbt-sqlserver и dbt-mssql, соответственно).

Путь адаптера dbt для Azure Synapse, dbt-synapse, тесно связан с моим путем в dbt. Я был тем, кто форкнул dbt-sqlserver в dbt-synapse в апреле 2020 года. Я узнал о dbt всего за месяц до этого и сразу понял, что моей команде нужен этот инструмент. С большой помощью от Джереми и экспертов из Microsoft моя команда и я запустили его и начали использовать. Когда я покинул свою команду в Avanade в начале 2022 года, чтобы присоединиться к dbt Labs, я пошутил, что на самом деле не покидаю команду; я просто временно встраиваюсь в dbt Labs, чтобы ускорить внедрение dbt Labs в Cloud. Два года спустя я могу сказать своей команде, что миссия выполнена! Спасибо всем, кто внес вклад в адаптеры TSQL, как напрямую в GitHub, так и в каналах Slack сообщества. Интеграция не существовала бы без вас!

Вам когда-нибудь снились кошмары о "плохих данных"? Или я единственный, у кого такие повторяющиеся кошмары? 😱

Вот один из них, который мне приснился прошлой ночью:

Все началось с ночной охоты на баги. Угрожающее насекомое заперло моих коллег в подземелье, и они умоляют меня помочь им выбраться. Найти ключ оказывается сложно, и он всегда кажется чуть-чуть недосягаемым. Стресс ощутим, как физический груз на моей груди, пока я соревнуюсь со временем, чтобы освободить их.

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

Хорошие новости: начиная с dbt v1.8, мы вводим полноценный фреймворк модульного тестирования, который может справиться с каждым из сценариев из моих кошмаров о данных.

Прежде чем углубиться в детали, давайте быстро посмотрим, как мы к этому пришли.

Введение​

Как архитектор решений в dbt Labs, моя роль заключается в том, чтобы помогать нашим клиентам и потенциальным клиентам понять, как лучше всего использовать платформу dbt Cloud для решения их уникальных задач с данными. Эта уникальность проявляется по-разному — зрелость организации, стек данных, размер и состав команды, технические возможности, случаи использования или их комбинация. Однако, несмотря на все эти различия, в большинстве моих взаимодействий присутствует одна общая нить: генеративный ИИ и большие языковые модели (LLM). Команды по работе с данными либо 1) проактивно думают о применении этих технологий в контексте своей работы, либо 2) их подталкивают к этому их заинтересованные стороны. Это стало "слоном в комнате" в каждом (zoom) разговоре, в котором я участвую.

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

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

Но теперь это в прошлом. Сегодня мы готовы объявить о доступности новой опции в dbt Cloud: трек релизов "Latest".

Теперь dbt Cloud включает в себя набор новых функций, которые позволяют настраивать точные и уникальные подключения к платформам данных на уровне окружения и пользователя. Это позволяет создавать более сложные конфигурации, такие как подключение проекта к нескольким учетным записям хранилищ, полноценная поддержка стейджинговых окружений и пользовательские переопределения для конкретных версий dbt. Это дает разработчикам dbt Cloud необходимые функции для решения более сложных задач, таких как рабочие процессы Write-Audit-Publish (WAP) и безопасное тестирование обновлений версий dbt. Хотя вы все еще настраиваете подключение по умолчанию на уровне проекта и для каждого разработчика, теперь у вас есть инструменты для более продвинутой и безопасной работы. Вскоре dbt Cloud пойдет еще дальше, позволяя устанавливать несколько подключений глобально и повторно использовать их с помощью глобальных подключений.

Облачные платформы данных открывают новые возможности; dbt помогает внедрить их в производство​

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

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

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

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

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

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

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

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

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

Проблема, разработчик и инструменты​

Проблема: Мы с партнершей рассматриваем возможность покупки недвижимости в Португалии. Здесь нет справочных данных по рынку недвижимости — сколько домов продается, по какой цене? Никто не знает, кроме агентств недвижимости и, возможно, банков, и они неохотно делятся этой информацией. Единственный источник данных, который у нас есть, — это Idealista, портал, где агентства недвижимости размещают объявления.

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

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

Инструменты: Я хочу запустить свой проект на Google Cloud Functions из-за щедрого бесплатного уровня. dlt — это новая библиотека на Python для декларативной загрузки данных, которую я давно хотел протестировать. Наконец, я буду использовать dbt Core для трансформации.

Резюме​

Мы объявляем, что dbt Server официально устарел и больше не будет поддерживаться dbt Labs. Вы можете продолжать использовать репозиторий и форкать его для своих нужд. Мы также ищем поддерживающего из нашего сообщества! Если вы заинтересованы, пожалуйста, свяжитесь с нами, открыв issue в репозитории.

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

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

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

Обзор​

За три года работы в команде Partner Engineering в dbt Labs, самый частый вопрос, который мне задавали, это: как мы можем интегрироваться с dbt? Поскольку эти разговоры часто начинаются с одного и того же, я решил создать это руководство, чтобы больше не быть препятствием для получения основной информации. Это также позволяет нам пропустить вводную часть и быстрее перейти к интересным обсуждениям, например, как может выглядеть совместное решение для наших клиентов.

Это руководство не включает информацию о том, как интегрироваться с dbt Core. Если вас интересует создание адаптера dbt, пожалуйста, ознакомьтесь с руководством по разработке адаптеров.

Вместо этого мы сосредоточимся на интеграции с dbt Cloud. Интеграция с dbt Cloud является ключевым требованием для того, чтобы стать технологическим партнером dbt Labs, открывая двери для различных совместных коммерческих возможностей.

Здесь я расскажу, как начать, какие потенциальные случаи использования вы хотите решить и точки интеграции для этого.

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

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

:::

Сегментация сред всегда была важной частью рабочего процесса аналитической инженерии:

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

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

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

Явное разделение ваших производственных нагрузок позволяет dbt Cloud быть более умным с метаданными, которые он создает, и особенно важно для двух новых функций: dbt Explorer и пересмотренных рабочих процессов CI.

Привет всем, я Кшитидж, старший инженер-программист в команде Core в dbt Labs. Одним из самых крутых моментов в моей карьере здесь было внедрение новой команды dbt clone в рамках выпуска dbt-core v1.6.

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

1. Что такое dbt clone?
2. Чем это отличается от откладывания?
3. Должен ли я откладывать или клонировать?

Введение​

Год был 2020. Я жила в доме, где были только котята, а dbt Labs все еще называлась Fishtown Analytics. Один из корпоративных клиентов, с которым я работала, Jetblue, попросил меня помочь запускать их модели dbt каждые 2 минуты, чтобы соответствовать SLA в 5 минут.

После преодоления первоначального ужаса мы обсудили случай использования и вскоре поняли, что есть лучший вариант. Вместе с моей командой я создала lambda views, чтобы удовлетворить потребность.

Перенесемся в 2023 год. Я пишу это, пока мой огромный пес храпит рядом со мной (не волнуйтесь, коты тоже размножились). Jetblue переросла lambda views из-за ограничений производительности (представление может быть только настолько производительным), и мы находимся на очередной вехе в пути dbt к поддержке потоковой передачи. Какое время!

Сегодня мы объявляем, что теперь поддерживаем материализованные представления в dbt. Итак, что это значит?

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

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

Data Vault 2.0 — это техника моделирования данных, разработанная для масштабирования крупных проектов по созданию хранилищ данных. Это строгая, предписывающая система, подробно описанная в книге, ставшей библией для этой техники.

Так почему же Data Vault? Вы сталкивались с проектом по созданию хранилища данных с более чем 50 источниками данных, с более чем 25 разработчиками данных, работающими на одной платформе данных, или с данными, охватывающими более 5 лет с двумя или более поколениями исходных систем? Если нет, то может быть сложно изначально понять преимущества Data Vault, и, возможно, моделирование по Кимбаллу будет лучше для вас. Но если вы находитесь в любой из перечисленных ситуаций, то эта статья для вас!

Введение​

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

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

Улучшением этого подхода было бы приоритизировать заявки на основе сегмента клиента, отвечая сначала нашим наиболее ценным клиентам. Инженер-аналитик может построить сегментацию для идентификации активных пользователей (например, с помощью подхода RFM) и сохранить ее в хранилище данных. Команда по обработке данных затем может экспортировать этот атрибут пользователя в CRM, позволяя команде по работе с клиентами строить правила на его основе.