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

Привет всем, я Кшитидж, старший инженер-программист в команде 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, позволяя команде по работе с клиентами строить правила на его основе.

В Lunar большинство наших dbt моделей берут данные из событийно-ориентированной архитектуры. Например, у нас есть следующие модели для папки activity_based_interest в нашем слое загрузки:

• activity_based_interest_activated.sql
• activity_based_interest_deactivated.sql
• activity_based_interest_updated.sql
• downgrade_interest_level_for_user.sql
• set_inactive_interest_rate_after_july_1st_in_bec_for_user.sql
• set_inactive_interest_rate_from_july_1st_in_bec_for_user.sql
• set_interest_levels_from_june_1st_in_bec_for_user.sql

Это приводит к тому, что многие одинаковые колонки (например, account_id) существуют в разных моделях, в разных слоях. Это означает, что я в итоге:

1. Пишу/копирую одну и ту же документацию снова и снова
2. На полпути понимаю, что могу улучшить формулировку, чтобы сделать ее более понятной, и возвращаюсь, чтобы обновить файлы .yml, которые уже сделал
3. Понимаю, что сделал синтаксическую ошибку в своем файле .yml, поэтому возвращаюсь и исправляю ее
4. Понимаю, что колонки определены по-разному с использованием разных формулировок в других папках нашего проекта dbt
5. Переосмысливаю свой выбор карьеры и молюсь, чтобы большая языковая модель украла мою работу
6. Задумываюсь, есть ли лучший способ генерировать документацию, используемую в разных моделях

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

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

Я, Сунг, случайно попал в индустрию данных осенью 2014 года. Я использовал нечто под названием язык команд аудита (ACL) для автоматизации дебетов, равных кредитам, для аналитики бухгалтерского учета (да, это так же утомительно, как звучит). Я помню, как усердно работал в гостиничном номере в Де-Мойне, штат Айова, где самым интересным местом был Panda Express. Было поздно ночью, около 2 часов утра. Я сделал шаг назад и подумал: «Почему я так усердно работаю над чем-то, что мне неинтересно, с инструментами, которые больше вредят, чем помогают?»

Здравствуйте, дорогие специалисты по данным.

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

Сказав это, пришло время попрощаться с нашим любимым пакетом dbt_metrics. С выпуском dbt-core версии 1.6 в конце июля мы прекратим поддержку пакета dbt_metrics.

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

Размерное моделирование — это одна из многих техник моделирования данных, используемых специалистами по данным для организации и представления данных для аналитики. Другие техники моделирования данных включают Data Vault (DV), Third Normal Form (3NF) и One Big Table (OBT), чтобы назвать несколько.

Техники моделирования данных на шкале нормализации и денормализации

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

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

К концу этого руководства вы:

• Поймете концепции размерного моделирования
• Настроите макетный проект dbt и базу данных
• Определите бизнес-процесс для моделирования
• Определите таблицы фактов и измерений
• Создадите таблицы измерений
• Создадите таблицу фактов
• Задокументируете отношения размерной модели
• Используете размерную модель

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

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

Представьте, что вы отвечаете за мониторинг безопасности системы метро. С чего бы вы начали? Скорее всего, вы начнете с размышлений о ключевых рисках, таких как столкновение или сход с рельсов, подумаете о причинных факторах, таких как программное обеспечение для планирования и состояние путей, которые могут привести к плохим результатам, и установите процессы и метрики для обнаружения таких ситуаций. Вы бы не стали слепо применять нерелевантные отраслевые стандарты, такие как тестирование проблем с шасси (отлично для самолетов, неактуально для поездов) или чрезмерно беспокоиться о маловероятных событиях, таких как случайная телепортация, прежде чем вы бы не закрепили основы.

Когда мы думаем о реальных сценариях, мы естественно склонны думать о ключевых рисках и механистических причинах. Однако в более абстрактном мире данных многие наши тесты данных часто склоняются к одной из двух крайностей: применению шаблонных тестов (null, PK-FK отношения и т.д.) из мира традиционного управления базами данных или игре с новыми инструментами, которые обещают поймать наши самые дикие ошибки с помощью обнаружения аномалий и искусственного интеллекта.

Между этими двумя крайностями лежит разрыв, который заполняется человеческим интеллектом. Инженеры аналитики могут создавать более эффективные тесты, внедряя свое понимание того, как были созданы данные, и особенно как эти данные могут пойти наперекосяк (тема, о которой я писала ранее). Хотя такие выразительные тесты будут уникальны для нашей области, скромные изменения в нашем мышлении могут помочь нам реализовать их с помощью наших стандартных инструментов. Этот пост демонстрирует, как простое проведение тестов по группам может расширить вселенную возможных тестов, повысить чувствительность существующего набора и помочь держать наши данные "на правильном пути". Эта функция теперь доступна в dbt-utils.

В седьмом классе я решил, что пора выбрать реалистичную карьеру, к которой я буду стремиться, и поскольку в моей жизни был бухгалтер, которым я действительно восхищался, я выбрал именно это. Примерно десять лет спустя я закончил обучение по специальности бухгалтерский учет с дополнительной специализацией в области бизнес-информационных систем (что по сути означает, что я программировал на C# в четырех или пяти классах). Я быстро сдал экзамены CPA и стал сертифицированным бухгалтером, как только выполнил требование о двухлетнем опыте. Первые несколько лет я работал в небольшой фирме, занимаясь составлением налоговых деклараций, но мне казалось, что я недостаточно учусь, поэтому я перешел в более крупную фирму прямо перед началом пандемии. Факторы, которые привели меня к смене отрасли, многочисленны, но я постараюсь быть кратким: налоговая индустрия полагается на недоплату своим работникам для поддержания маржи и предотвращения избыточности, моя будущая работа в качестве менеджера не привлекала меня, и моя работа двигалась в направлении, которое меня не вдохновляло.

Почему мы это создали: Краткая история команды профессиональных услуг dbt Labs​

Если вы посетили Coalesce 2022, вы знаете, что секрет раскрыт — команда профессиональных услуг dbt Labs — это не просто группа опытных консультантов по данным; мы также межгалактическая группа инопланетян, путешествующих по Млечному Пути с миссией помочь аналитическим инженерам успешно внедрять и управлять dbt по всей галактике.