Блоги разработчиков | dbt

👋 Приветствуем, dbt’еры! Это Фейт и Джерри, и мы снова здесь, чтобы предложить тактические советы о том, где разместить тесты в вашем конвейере.

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

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

Сначала вот наши мнения о том, где должны находиться конкретные тесты:

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

Цикл разработки аналитики (ADLC) — это рабочий процесс для улучшения зрелости и скорости работы с данными. Тестирование является ключевой фазой здесь. Многие разработчики dbt склонны сосредотачиваться на первичных ключах и свежести источников. Мы считаем, что существует более целостный и глубокий путь. Тестирование — это ключевой элемент ADLC, и оно должно способствовать качеству данных.

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

• выявление проблем гигиены данных
• выявление проблем аномалий, ориентированных на бизнес
• выявление проблем аномалий, ориентированных на статистику

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

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

На прошлой неделе, летя домой в Детройт и работая над этой статьей в самолете, я впервые увидел недавно соединенную палубу Международного моста Горди Хоу, который пересекает реку Детройт и соединяет США и Канаду. Этот образ запомнился, потому что, в некотором смысле, хранилище признаков является мостом между чистыми, согласованными наборами данных и моделями машинного обучения, которые зависят от этих данных. Но более интересным, чем сам мост, является огромный процесс координации, необходимый для его строительства. Это строительное усилие, как мне кажется, может научить нас многому о процессах и необходимости хранилищ признаков в машинном обучении (ML).

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

Если вы не следите за новостями в индустрии данных, вы могли пропустить недавний ажиотаж вокруг открытого формата таблиц под названием Apache Iceberg™. Это один из многих открытых форматов таблиц, таких как Delta Lake, Hudi и Hive. Эти форматы меняют способ хранения данных и доступа к метаданным. Они во многом революционны.

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

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

Ранее это выглядело как работа команды в одном проекте dbt для создания набора преобразованных объектов в их платформе данных.

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

Семантический слой 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 Server?​

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

Ранее dbt Server поддерживал наш устаревший Семантический слой, который был полностью устаревшим в декабре 2023 года. В октябре 2023 года мы представили GA обновленного Семантического слоя dbt с значительными улучшениями, ставшими возможными благодаря приобретению Transform и интеграции MetricFlow в dbt.

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

Устаревание dbt Server и обновления Семантического слоя означают эволюцию экосистемы dbt в сторону большего внимания к встроенным и готовым к использованию возможностям в области подключения, масштабируемости и гибкости. Мы рады, что вы с нами на этом пути.

Представьте себе — у вас огромный проект 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.