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

После того как ваше будет построено, подавляющее большинство ваших данных будет поступать из других 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.

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

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

Почему люди используют 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 имеют решение для вас. И тут вас осеняет — ответ в снимках!