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

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

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

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

В области аналитической инженерии неизбежно столкновение с моментами, когда в ваших данных появляются загадочные или бесполезные пустые значения. 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, а не как строка.”

“primary key для этой table на самом деле 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, которые вы запускаете в производственной среде, являются центром управления вашим проектом. Они формируют структуру, определяющую стандарты качества и свежести данных вашей команды.

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

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

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

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

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

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

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

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

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

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

Причина проста: пакеты, как неотъемлемая часть dbt, следуют нашему принципу создания аналитическими инженерами и для них. Их легко установить, они доступны, и в конце концов, это просто SQL (с добавлением git и jinja). Вы можете либо поделиться своим пакетом с сообществом, либо использовать его среди своих команд в вашей организации.

Поэтому я бросаю вам вызов: после прочтения этой статьи проверьте свои навыки, подумайте о коде, который вы снова и снова используете, и создайте пакет. Пакеты могут быть настолько сложными, насколько вы хотите; это просто SQL, скрытый в смеси переиспользуемых макросов и обширных тестовых фреймворков. Давайте начнем ваше путешествие.

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

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

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

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

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

Airflow и dbt часто рассматриваются как взаимоисключающие:

Вы либо строите SQL-трансформации, используя SQL-операторы базы данных Airflow (например, SnowflakeOperator), либо разрабатываете их в проекте dbt.

Вы либо оркестрируете модели dbt в Airflow, либо развертываете их, используя dbt Cloud.

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

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

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