В 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 по всей галактике.

После того как ваше data warehouse будет построено, подавляющее большинство ваших данных будет поступать из других SaaS-инструментов, внутренних баз данных или платформ данных клиентов (CDP). Но есть еще один незамеченный герой в наборе инструментов аналитической инженерии: скромная электронная таблица.

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

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

Данные — это индустрия обходных путей. Большинство людей в этой области случайно попадают в нее, осматриваются, и если им нравится то, что они видят, они строят здесь карьеру. Это особенно верно в области аналитического инжиниринга. Каждый аналитический инженер, с которым я разговаривала, представлял себя занимающимся чем-то другим, прежде чем случайно найти эту работу. Это поднимает вопрос: как можно стать аналитическим инженером намеренно? Это вопрос, на который стремится ответить Программа Foundry от dbt Labs.

Давайте обсудим, как преобразовать события из архитектуры микросервисов, управляемой событиями, в реляционные таблицы в хранилище данных, таком как Snowflake. Вот несколько вопросов, которые мы рассмотрим:

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

Много лет, работая в области данных и аналитической инженерии, я ценил ежедневное общение в небольшом офисе с талантливыми людьми, использующими различные инструменты — от аналитиков, работающих с SQL и Excel, до дата-сайентистов, работающих с Python. Я всегда чувствовал, что у нас есть много возможностей для совместной работы, но изолированные данные и инструменты делали это гораздо сложнее. Разнообразие наших инструментов и языков делало потенциал для сотрудничества еще более интересным, поскольку у нас могли быть люди с разными областями экспертизы, каждый из которых вносил бы свой уникальный вклад в проект. Но с логистической точки зрения это просто не могло быть реализовано в масштабируемом виде.

Поэтому я не могу быть более взволнован возможностями полиглотности dbt, которые появились в dbt Core 1.3. Этот релиз приносит библиотеки датафреймов Python, которые важны для дата-сайентистов, и позволяет использовать Python общего назначения, но при этом использует общую базу данных для чтения и записи наборов данных. Аналитические инженеры и дата-сайентисты сильнее вместе, и я не могу дождаться, чтобы работать бок о бок в одном репозитории со всеми моими друзьями-дата-сайентистами.

Переход на полиглотность — это важный следующий шаг в развитии dbt Core. Хотя это расширяет возможности, мы также признаем потенциал для путаницы. Когда они объединены намеренно, SQL, датафреймы и Python также сильнее вместе. Полиглотный dbt позволяет информированным практикам выбирать язык, который лучше всего подходит для вашего случая использования.

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

Мы также предоставим вам интеллектуальные ресурсы для сравнения:

• различных реализаций датафреймов в разных платформах данных
• датафреймы против SQL

Наконец, мы поделимся "подводными камнями" и лучшими практиками, которые мы узнали до сих пор, и пригласим вас участвовать в поиске ответов на нерешенные вопросы, которые нас самих все еще интересуют.

На основе нашего раннего опыта, мы рекомендуем вам:

✅ Делайте: Используйте Python, когда он лучше подходит для задачи — обучение моделей, использование предсказательных моделей, матричные операции, исследовательский анализ данных (EDA), пакеты Python, которые могут помочь с комплексными трансформациями, и другие случаи, когда Python является более естественным решением для проблемы, которую вы пытаетесь решить.

❌ Не делайте: Используйте Python там, где решение на SQL столь же прямолинейно. Хотя чисто Python проект dbt возможен, мы ожидаем, что наиболее значимые проекты будут смесью SQL и Python.

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

Итак, у вас есть бизнес-вопрос, у вас есть сырые данные в вашем data warehouse, и у вас настроен dbt. Вы в идеальной позиции, чтобы быстро завершить создание этого подготовленного набора данных! Или нет?