Analytics craft

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет всем, я Кшитидж, старший инженер-программист в команде 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, и, возможно, моделирование по Кимбаллу будет лучше для вас. Но если вы находитесь в любой из перечисленных ситуаций, то эта статья для вас!

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

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

Alteryx — это платформа визуальной трансформации данных с удобным интерфейсом и инструментами перетаскивания. Тем не менее, Alteryx может испытывать трудности с увеличением сложности в рамках конвейера данных организации и может стать неоптимальным инструментом, когда компании начинают работать с большими и сложными преобразованиями данных. В таких случаях переход на dbt может быть естественным шагом, поскольку dbt предназначен для управления сложными конвейерами преобразования данных более масштабируемым, эффективным и явным образом. Также этот переход включал миграцию с локального SQL Server на облачные вычисления Snowflake. В этой статье мы описываем различия между Alteryx и dbt и как мы сократили время выполнения клиента в Alteryx с 6 часов до 9 минут с помощью dbt и Snowflake в Indicium Tech.

Команды процветают, когда каждому члену команды предоставляются инструменты, которые наилучшим образом дополняют и усиливают их навыки. Вы бы не дали Криштиану Роналду теннисную ракетку и не ожидали бы идеальной подачи! В Roche предоставление правильных инструментов нашим коллегам было критически важным для того, чтобы увеличить нашу команду по работе с данными с 10 основных инженеров до более чем 100 участников всего за два года. Мы приняли как dbt Core, так и dbt Cloud в Roche (решение dbt-squared, если хотите!) для быстрого масштабирования нашей платформы данных.

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

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

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

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

Аудит таблиц — это важная часть ежедневных задач аналитиков данных, особенно при рефакторинге таблиц, созданных с использованием SQL-хранимых процедур или Alteryx Workflows. В этой статье мы представляем, как пакет audit_helper может (как следует из названия) помочь в процессе аудита таблиц, чтобы убедиться, что рефакторинг модели дает (почти) такой же результат, как и оригинальная, основываясь на нашем опыте использования этого пакета для поддержки наших клиентов в Indicium Tech®.

В Teads мы используем BigQuery (BQ) для построения нашей аналитической платформы с 2017 года. Как было представлено в предыдущей статье, мы разработали конвейеры, которые используют множественные свертки, агрегируемые в витринах данных. Большинство из них вращаются вокруг временных рядов, и поэтому разделение на основе времени часто является наиболее подходящим подходом.

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

За последние несколько месяцев Montreal Analytics, консалтинговая компания полного цикла в области данных, обслуживающая организации по всей Северной Америке, сертифицировала более 25 инженеров аналитики dbt, что принесло им награду dbt Platinum Certification 2022 года.

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

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