Когда маркетологам нужно получить новый отчет или изменить существующий, они вынуждены обращаться к аналитикам и ждать, пока те подготовят данные. Аналитики строят отчеты с помощью SQL. Со временем таких SQL запросов становится все больше, а логика в них все сложнее. В результате маркетологи теряют время и упускают возможности, а аналитикам приходится заниматься рутиной вместо интересных задач. Как трансформация и моделирование данных могут существенно облегчить жизнь и тем, и другим читайте под катом.
Что такое трансформация и моделирование данных?
Чтобы ответить на этот вопрос, разберемся с основными терминами, которые вы встретите в этой статье.
Модель данных это описание объектов и их свойств; связей между объектами и ссылок на источники данных. Связь между объектами реализуется через специальные свойства ключи.
Схема данных это шаблон модели, который разработан под конкретную бизнес-нишу. Схема позволяет создавать модель не с чистого листа, а учитывая наш предыдущий опыт.
Схема данных описывает некую предметную область, например, электронную коммерцию. В ней есть заказы, пользователи, сессии. У SaaS-бизнесов могут быть дополнительные сущности, например, подписка или тарифный план. У телеком компаний и банков подтвержденные заявки и т.д.
Как выглядит модель данных пример для Ecommerce:
Трансформация данных это процесс преобразования данных из одной структуры в другую.
Моделирование данных это трансформация данных в структуру, соответствующую требованиям модели.
Какую проблему решает моделирование данных?
Если представить основные этапы работы с данными в виде графика...
...можно увидеть, что на между этапами Preparation Reporting (Подготовка данных Создание отчетов) и возникает больше всего проблем.
Когда маркетологу нужно: получить данные для отчета в новой структуре; добавить колонку в готовый отчет; изменить логику объединения данных в готовом отчете он вынужден обращаться к аналитику и ждать.
Когда аналитику нужно: приджойнить в готовый отчет дополнительные данные; обновить логику расчета определенной метрики; заменить источник данных на источник с другой структурой он тратит значительное время на понимание и рутинное изменение надцати SQL-запросов.
Чтобы понять, как именно моделирование данных решает эти проблемы, рассмотрим подробнее процесс подготовки данных. Его можно разбить на три этапа:
1. Моделирование. На этом этапе аналитик задается вопросами: Как собранные данные соотносятся с бизнес-сущностями?, Какие способы объединения данных допустимы?.
Моделирование достаточно универсальная задача. Например, когда маркетолог спрашивает у аналитика: А мы вообще сможем объединить данные из источников X и Y?. Это задача моделирования.
2. Виртуализация. На этом этапе решается вопрос: Какая структура и вариант объединения данных нужны для конкретного отчета?. Структура может быть получена с помощью разных вариантов объединения, но какой нам нужен в данном случае? Нам нужны источники последней сессии или всех? Одну и ту же структуру мы можем получить разными способами. Для виртуализации аналитик должен ответить на эти вопросы и создать такой SQL-запрос, который эти данные вернет.
Задача виртуализации данных, когда нам нужно получить их в каком-то новом срезе, используется регулярно. Потому что каждый раз, когда нам нужно что-то поменять в отчете, мы сталкиваемся именно с этой задачей.
3. Трансформация. На этом этапе аналитик решает, в какой структуре необходимо подготовить данные для их объединения в отчете. Готовит данные: занимается дедупликацией, отсеиванием всплесков, нормализацией. То есть это все манипуляции с входным потоком для того, чтобы потом эти данные можно было использовать.
Задача трансформации достаточно нетривиальна. Потому что у каждого бизнеса есть уникальные требования. Она в целом менее универсальная и используется как минимум на этапе запуска. То есть мы сделали какой-то отчет и один раз как минимум определили правила трансформации.
Маркетологи зависят от аналитиков, потому что у них нет готового продукта, который решал бы задачу виртуализации. Из-за этого для каждого нового отчета, когда нужно добавить колонку, аналитик трансформирует данные снова и снова. Чтобы этого избежать, нужно решение, которое позволит трансформировать данные и хранить их в структуре, пригодной для многократного использования. Таким решением может выступать связка dbt + Google BigQuery.
Какое преимущество дает бизнесу моделирование данных?
Понятно, что маркетологи в большинстве своем далеки от темы трансформации и моделирования данных. Но без этого невозможно переиспользовать данные, подключенные к продукту, в котором вы создаете отчеты.
Как сейчас выглядит построение отчетов? Маркетолог рассказал аналитику, что нужно сделать. Тот написал SQL-запросы и построил на их результатах дашборд. Нашли расхождения, добавили условия в запросы, сделали пару итераций, получили обратную связь и таким образом довели отчет до ума. Но все решения были в контексте отчета. Это значит, что когда понадобится другой отчет с другими источниками, новыми колонками, несколькими срезами данных операцию проверки сходимости данных, валидацию нужно будет проходить заново.
С трансформацией и моделированием данных эта задача решается до того, как строится отчет. Когда мы еще не знаем, какие нам понадобятся отчеты. Но ответ на вопрос, что такое сессия, пользователь, расходы, мы сформулировали на уровне модели. То есть трансформация это преобразование данных в структуру, которая соответствует требованиям модели. Она позволяет строить отчеты, не тратя время на очередную обработку данных. При этом вы будете уверены, что отчеты построены на сходимых данных.
Способы трансформации данных для моделирования
Есть встроенный механизм регулярных запросов, которые выполняются в Google BigQuery, Scheduled Queries и AppScript. Их легко можно освоить, потому что это привычный SQL, но проводить отладку в Scheduled Queries практически нереально. Особенно, если это какой-то сложный запрос или каскад запросов.
Есть специализированные инструменты для управления SQL-запросами, например, dbt и Dataform.
dbt (data build tool) это фреймворк с открытым исходным кодом для выполнения, тестирования и документирования SQL-запросов, который позволяет привнести
элемент программной инженерии в процесс анализа данных. Он помогает оптимизировать работу с SQL-запросами: использовать макросы и шаблоны JINJA, чтобы не повторять в сотый раз одни и те же фрагменты кода.
Главная проблема, которую решают специализированные инструменты это уменьшение времени, необходимого на поддержку и обновление. Это достигается за счет удобства отладки.
Сравнение способов трансформации данных:
Если вы хотите получать больше пользы от своих данных, рекомендуем уже сейчас осваивать dbt или Dataform. Они помогут значительно упростить и ускорить создание отчетов для вашей компании.
