Из архивов Slack: Когда бэкенд-разработчики приносят радость аналитикам

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

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

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

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

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

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

Скриншот разговора, который начал тему

Когда все части становятся на свои места

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

Признаки того, что данные приносят радость

Все таблицы имеют первичный ключ.

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

Поля, основанные на времени, передаются как временные метки, а не даты.

Поля, основанные на времени, такие как когда создан аккаунт или размещен заказ, должны передаваться как временные метки. Этот формат обеспечивает наибольшую гибкость и детализацию для аналитиков и конечных бизнес-пользователей. Временные метки могут быть преобразованы в точные даты, поля типа дата не могут быть преобразованы в точные временные метки. Дополнительные очки: когда таблицы бэкенд-приложений имеют точные поля created_at и updated_at, это победа для всех.

Существуют согласованные соглашения об именах для таблиц и полей.

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

Мягкое удаление — это круто.

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

Данные передаются в правильном типе.

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

“Я посмотрел на список выше и не увидел, чтобы 'правильная типизация данных' была явно указана. Я видел так много случаев, когда строки должны быть int или decimal или date или чем-то еще.” - комментарий в теме Slack от Джоша Эндрюса

Признаки того, что операции приносят радость

Коммуникация и сотрудничество перед релизами — это норма.

Аналитики могут выявить изменения в релизах, которые могут сломать их модели до релиза, благодаря регулярной коммуникации с бэкенд-разработчиками. Рассмотрите возможность мониторинга или проверки PR для бэкенд-работы, чтобы понять магию под капотом! Кроме того, сотрудничество между бэкенд- и аналитическими командами может побудить бэкенд-разработчиков установить менталитет, при котором они часто думают о том, как их работа повлияет на последующую аналитику.

Не забывайте о документации.

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

Идеальное сочетание

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

Хотите узнать больше о том, что делает моделирование данных радостью? Обязательно присоединяйтесь к сообществу dbt в Slack!