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

Мы все, вероятно, были в такой ситуации: Таблица A содержит 56 столбцов, и мы хотим выбрать все, кроме одного из них (column_56). Итак, начнем...

select
	column_1,
	column_2,
	column_3,
	please_save_me…
from {{ ref('table_a') }}

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

Но что, если бы был способ сократить эти 56+ строк кода до нескольких? Вот тут-то и приходит на помощь удобный макрос dbt.

Если вы читаете эту статью, вероятно, вы хотите узнать, как лучше оптимизировать ваши запросы в Redshift, и, возможно, вы хотите узнать, как это сделать в сочетании с dbt.

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

Инженеры по аналитике (AEs) постоянно работают с названиями моделей в своем проекте, поэтому именование важно для поддерживаемости вашего проекта в том, как вы к нему обращаетесь и работаете в нем. По умолчанию, dbt будет использовать имя файла вашей модели в качестве имени представления или таблицы в базе данных. Но это означает, что имя имеет жизнь за пределами dbt и поддерживает многих конечных пользователей, которые, возможно, никогда не узнают о dbt и откуда взялись эти данные, но все равно будут обращаться к объектам базы данных в базе данных или инструменте бизнес-аналитики (BI).

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

Существует множество различных функций для работы с датами в SQL — например, DATEDIFF, DATEADD, DATE_PART и DATE_TRUNC. У каждой из них свои случаи использования, и понимание того, как и когда их использовать, является основой работы с SQL. Является ли какая-либо из них такой же простой в использовании, как функция EXTRACT? Ну, это тема для другого обсуждения...

В этом посте мы подробно рассмотрим функцию EXTRACT, как она работает и почему мы её используем.

Привет, чемпион данных — так рад, что ты здесь! Иногда для работы с наборами данных требуется команда инженеров, чтобы справиться с их дедупликацией (да, это реальное слово), и именно поэтому мы записали это. Для тебя, друг, мы записали это для тебя. Пожалуйста!

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

Мы все были в такой ситуации:

• В форме регистрации пользователь A ввел своё имя как Kira Furuichi, пользователь B ввел его как john blust, а пользователь C написал DAvid KrevitT (что это было, Дэвид??)
• Ваши инженеры бэкенда настаивают, чтобы электронные адреса клиентов были написаны заглавными буквами
• Все ваши имена для отслеживания событий написаны строчными буквами

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

Итак, как создать единообразие для строковых значений, которые вы собираете из всех ваших источников данных? Функция LOWER!

❓ Для кого это: Это для опытных пользователей dbt Cloud, которые хотят расширить свои знания об API dbt с помощью интерактивной коллекции Postman. Мы рекомендуем углубляться в это только после того, как у вас будет прочное знание dbt + dbt Cloud. У вас есть несколько вариантов для изучения коллекции:

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

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

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

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

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

Непрерывная интеграция (CI) настраивает систему для тестирования каждого pull request перед слиянием. Непрерывное развертывание (CD) развертывает каждое одобренное изменение в производственной среде. "Упрощенный CI" означает запуск/тестирование только измененного кода, тем самым экономя вычислительные ресурсы. Вкратце, CI/CD автоматизирует тестирование и развертывание dbt конвейеров.

dbt Cloud, популярный метод развертывания dbt, поддерживает CI/CD на основе GitHub и Gitlab из коробки. Он не поддерживает Bitbucket, AWS CodeCommit/CodeDeploy или другие сервисы, но даже если вы привязаны к неподдерживаемой платформе, не стоит отчаиваться.

Хотя в этой статье используется Bitbucket Pipelines в качестве вычислительного сервиса и Bitbucket Downloads в качестве сервиса хранения, эта статья должна служить шаблоном для создания dbt-основанного упрощенного CI/CD где угодно. Идея всегда одна и та же:

dbt Cloud — это хостинговый сервис, который многие организации используют для своих развертываний dbt. Среди прочего, он предоставляет интерфейс для создания и управления заданиями развертывания. Когда задания запускаются (например, по расписанию cron или через API), они генерируют различные артефакты, содержащие ценную метадату, связанную с проектом dbt и результатами выполнения.

dbt Cloud предоставляет REST API для управления заданиями, артефактами выполнения и другими ресурсами dbt Cloud. Инженеры по данным/аналитике часто пишут пользовательские скрипты для автоматизированных вызовов API, используя инструменты cURL или Python Requests. В некоторых случаях инженеры копируют/переписывают их между проектами, которым нужно взаимодействовать с API. Теперь у них есть куча скриптов, которые нужно поддерживать и развивать, если изменяются бизнес-требования. Если бы только существовал специальный инструмент для взаимодействия с API dbt Cloud, который абстрагировал бы сложности вызовов API за простым в использовании интерфейсом... О, подождите, он есть: dbt-cloud-cli!

"Я забыл упомянуть, что мы удалили этот столбец и создали новый для него!"

“Хм, я на самом деле не совсем уверен, почему customer_id передается как int, а не как строка.”

“ для этой на самом деле order_id, а не поле id.”

Думаю, многие аналитики, включая меня, получали подобные комментарии от своих бэкенд-разработчиков.

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

Так что же делает возможным сильное сотрудничество между аналитиками и бэкенд-разработчиками?

Особая благодарность: Emilie Schario, Matt Winkler

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

Я люблю называть эту интероперабельность "передачей эстафеты". Как в эстафетной гонке, здесь есть четкие точки передачи и явное владение на всех этапах процесса. Но есть одна передача эстафеты, которая все еще относительно болезненна и не определена: передача между инженерами машинного обучения (ML) и аналитическими инженерами.

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

В этой статье мы исследуем реальную передачу эстафеты между ML-инженерами и аналитическими инженерами, подчеркивая, где все пошло не так.

Краткое содержание:

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

Введение​

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

Примечание редактора: В этом руководстве Донни рассказывает вымышленную историю SaaS-компании под названием JaffleGaggle, которой необходимо сгруппировать своих индивидуальных пользователей freemium в аккаунты компаний (так называемый обзор клиентов 360), чтобы стимулировать рост, основанный на продукте.

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

Измерение количества рабочих часов между двумя датами с использованием SQL — это одна из тех классических задач, которая звучит просто, но мучает аналитиков с незапамятных времен.

Эта задача возникает в нескольких местах в dbt Labs:

• Расчет времени, необходимого для решения заявки в службу поддержки
• Измерение производительности команды в соответствии с соглашениями об уровне обслуживания (SLA) по времени ответа

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

Тем не менее, вам придется выполнить довольно сложные SQL или dbt-манипуляции, чтобы сделать это правильно, включая:

1. Определение, как исключить ночи и выходные из ваших SQL-расчетов
2. Учет праздников с использованием пользовательского календаря праздников
3. Приспособление к изменениям в расписании рабочих часов

Эта статья предоставит обзор того, как и, что важно, почему рассчитывать время выполнения задачи и как мы используем его здесь, в dbt Labs.

[Мы бы хотели иметь] кривую зрелости для реализации dbt от начала до конца для каждой версии dbt .... Сейчас в dbt так много функций, но было бы здорово понять, "какой минимальный набор функций/компонентов dbt должен быть в базовой реализации dbt?... а что является дополнительным бонусом?" -Will Weld на dbt Community Slack

Один из вопросов, который мы слышим снова и снова, - как выглядит прогресс через различные стадии зрелости в проекте dbt?

Когда Уилл задал этот вопрос в Slack, я задумался о том, что потребуется для создания структуры зрелости проекта dbt.

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

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

Без команды для их запуска, модели и тесты dbt просто занимают место в репозитории Git.

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

Мы все это делали: расширяли данные во время объединения, создавая дублирующиеся записи (иногда дублирующиеся в нескольких экземплярах).

Тот случай, когда исторические данные о доходах удвоились в понедельник? Классический пример расширения.

Можно ли было этого избежать? Да, очень просто: определив уникальность для с помощью первичного ключа и обеспечив её с помощью теста dbt.

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

Почему первичные ключи важны​

Мы все знаем одно из самых фундаментальных правил в данных: каждая должна иметь . Первичные ключи важны по многим причинам:

• Они гарантируют, что в вашей таблице нет дублирующихся строк
• Они помогают устанавливать связи с другими таблицами
• Они позволяют быстро определить таблицы (например, таблица customers с PK customer_id имеет одну строку на каждого клиента)
• Вы можете тестировать их в dbt, чтобы убедиться, что ваши данные полные и уникальные