Analytics craft

Примечание редактора — с момента создания этого поста, владение пакетом 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 помочь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение​

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

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

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

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

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

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

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

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

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

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

Аналитика — это сложно. Делать аналитику правильно — еще сложнее.

Существует огромное количество факторов, которые нужно учитывать: отсутствуют ли данные? Как сделать это инсайт доступным? Почему моя база данных заблокирована? Мы вообще задаем правильные вопросы?

Усугубляет ситуацию то, что аналитика иногда может казаться одиноким занятием.

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

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

Большинство организаций тратят хотя бы часть своего времени на вклад в проект с открытым исходным кодом. Однако 100% из них в той или иной степени зависят от результатов работы сообществ с открытым исходным кодом.

Если вы недавно общались со мной, следите за мной в Twitter или принимали мой заказ в Wendy’s, вы, вероятно, знаете, как сильно я ненавижу традиционные дашборды. Мой отец, психотерапевт, работает со мной, чтобы добраться до корней моего воспитания, которые привели к этому глубоко укоренившемуся чувству.

💾 Эта статья для всех, кто когда-либо сомневался в здравомыслии даты, не представленной в формате ISO 8601

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

• Почему существует несколько моделей с почти одинаковыми, но слегка различающимися именами?

• В какой модели находятся нужные мне поля?

• Какая модель является предшественником или последователем какой?