Почему люди используют cherry pick для верхних веток?​

Самая простая стратегия ветвления для внесения изменений в код вашего репозитория dbt проекта — это иметь единственную основную ветку с кодом уровня продакшн. Чтобы обновить ветку main, разработчик должен:

1. Создать новую ветку для функции непосредственно от ветки main
2. Внести изменения в эту ветку для функции
3. Протестировать локально
4. Когда будет готово, открыть pull request для слияния изменений обратно в ветку main

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

• Быстрый процесс продвижения для внесения новых изменений в продакшн
• Простая стратегия ветвления для управления

Основной риск, однако, заключается в том, что ваша ветка main может стать уязвимой для багов, которые могут проскользнуть через процесс утверждения pull request. Чтобы провести более интенсивное тестирование и контроль качества перед слиянием изменений в коде в продакшн, некоторые организации могут решить создать одну или несколько веток между ветками для функций и main.

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

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

Давайте поговорим о том, как применить метод КонМари к новому проекту миграции. Возможно, вам поручили распаковать кухню в вашем новом доме; другими словами, вы инженер, нанятый для переноса ваших устаревших SQL-запросов в dbt и обеспечения их бесперебойной работы. Это может означать, что вы берете запрос из 1500 строк SQL и перерабатываете его в модульные части. Когда вы закончите, у вас будет производительный, масштабируемый, легкий для навигации поток данных.

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

Этот процесс может включать множество вариаций, но обычно он предполагает часы, дни или недели работы с финансовым отделом для:

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

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

Семантический слой, поддержка моделей на Python, новый интерфейс dbt Cloud и IDE... наша команда с нетерпением ждет возможности поделиться с вами всем этим на Coalesce через несколько недель.

Но как все это сочетается — в связи с тем, куда движется dbt Labs — это то, о чем я больше всего хочу поговорить.

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

ЗАРЕГИСТРИРУЙТЕСЬ СЕЙЧАС

Примечание редактора - этот пост предполагает знание разработки dbt пакетов. Для введения в dbt пакеты ознакомьтесь с So You Want to Build a dbt Package.

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

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

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

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

Иногда нам везет, и у нас есть источники данных с уже встроенными ключами — например, данные Shopify, синхронизированные через их API, имеют простые в использовании ключи на всех таблицах, записанных в ваше хранилище. Если это не так, или если вы строите модель данных с составным ключом (то есть данные уникальны по нескольким измерениям), вам придется полагаться на какую-то стратегию для создания и поддержания этих ключей самостоятельно. Как это сделать с помощью dbt? Давайте разберемся.

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

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

Другими словами, что если мы расскажем историю?

Когда вы запускаете задачу, содержащую более 1700 моделей, как определить, что является "хорошим" временем выполнения? Если весь процесс занимает 3 часа, это замечательно или ужасно? Хотя существует множество возможных ответов в зависимости от размера набора данных, сложности моделирования и исторических времен выполнения, суть обычно заключается в вопросе "достигли ли вы своих SLA"? Однако в мире облачных вычислений, где счета выставляются на основе использования, вопрос на самом деле звучит так: "достигли ли вы своих SLA и остались в рамках бюджета?"

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

Примечание редактора — с момента создания этого поста, владение пакетом pre-commit-dbt перешло к другой команде, и он был переименован в dbt-checkpoint. Настроен редирект, что означает, что приведенный ниже пример кода все еще будет работать. Также можно заменить repo: https://github.com/offbi/pre-commit-dbt на repo: https://github.com/dbt-checkpoint/dbt-checkpoint в вашем файле .pre-commit-config.yaml.

В dbt Labs у нас есть лучшие практики, которым мы предпочитаем следовать при разработке проектов dbt. Одна из них, например, заключается в том, что все модели должны иметь как минимум тесты unique и not_null на их первичный ключ. Но как мы можем применять такие правила?

Этот вопрос становится трудным для ответа в крупных проектах dbt. Разработчики могут не следовать одним и тем же соглашениям. Они могут не знать о прошлых решениях, и проверка pull-запросов в git может стать более сложной. Когда в проектах dbt сотни моделей, трудно понять, какие модели не имеют определенных тестов и не соблюдают ваши соглашения.

Если вам нужно было предоставить доступ к модели dbt с 2019 года по сегодняшний день, есть большая вероятность, что вы наткнулись на пост "Точные операторы grant, которые мы используем в проекте dbt" на Discourse. В нем объяснялись варианты для покрытия двух дополнительных возможностей:

1. запрос отношений через привилегию "select"
2. использование схемы, в которой находятся эти отношения, через привилегию "usage"

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

Если ваша команда активно работает с хранимыми процедурами, и вы когда-либо сталкивались со следующими или похожими проблемами:

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

Стоит рассмотреть, может ли альтернативный подход с dbt помочь.

Существует множество причин, по которым вы, как инженер по аналитике, можете захотеть зафиксировать полную историю версий данных:

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

Это часто ситуации с высокими ставками! Поэтому точность в отслеживании изменений в ваших данных имеет ключевое значение.

В общем, люди, работающие с данными, предпочитают более детализированные данные менее детализированным. Метки времени > даты, ежедневные данные > еженедельные данные и т.д.; наличие данных на более детализированном уровне всегда позволяет вам приблизиться. Однако, скорее всего, вы смотрите на свои данные на несколько отдаленном уровне — еженедельно, ежемесячно или даже ежегодно. Для этого вам понадобится удобная функция, которая поможет округлить поля даты или времени.

Функция DATE_TRUNC усечет дату или время до первой единицы заданной части даты. Многословно, многословно, многословно! Что это на самом деле значит? Если вы усечете 2021-12-13 до месяца, она вернет 2021-12-01 (первый день месяца).

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

«Сколько времени прошло с тех пор, как этот клиент последний раз делал у нас заказ?»

«Какое среднее количество дней до конверсии?»

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

Функция DATEDIFF возвращает разницу в указанных единицах (например, дни, недели, годы) между начальной и конечной датой/временем. Это простая и широко используемая функция, которую вы будете использовать чаще, чем ожидаете.

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

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

Какая ваша первая мысль? Ну, вы опытный инженер по аналитике и знаете, что хорошие люди из dbt Labs имеют решение для вас. И тут вас осеняет — ответ в снимках!

Мы все, вероятно, были в такой ситуации: Таблица 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, как она работает и почему мы её используем.

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

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