Как мы создали согласованные метрики запуска продукта с помощью семантического слоя dbt

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

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

Подготовка данных для метрик

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

1. Работать с инженерами, чтобы понять источники данных. В нашем случае это экспорт базы данных с сервера семантического слоя.
2. Загрузить данные в наш хранилище. Мы используем Fivetran и Snowflake.
3. Преобразовать данные в нормализованные таблицы с помощью dbt. Этот шаг классический. Основная задача dbt. Вы, вероятно, уже знаете, как это делается.

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

DAG семантического слоя в dbt Explorer

Давайте пройдемся по DAG слева направо: сначала у нас есть сырые таблицы с сервера семантического слоя, загруженные в наше хранилище, затем у нас есть модели стадий, где мы применяем бизнес-логику, и, наконец, чистая, нормализованная модель fct_semantic_layer_queries. В конце концов, мы построили семантическую модель под названием semantic_layer_queries на основе нашей нормализованной фактологической модели. Это типичный DAG для проекта dbt, который содержит семантические объекты. Теперь давайте увеличим масштаб секции DAG, содержащей наши объекты семантического слоя, и рассмотрим подробнее, как мы определили наши метрики продукта семантического слоя.

Как мы строим семантические модели и метрики

Что такое семантическая модель? Проще говоря, семантические модели содержат компоненты, необходимые для построения метрик. Семантические модели — это YAML-файлы, которые находятся в вашем проекте dbt. Они содержат метаданные о ваших моделях dbt в формате, который MetricFlow, конструктор запросов, управляющий семантическим слоем, может понять. DAG ниже в dbt Explorer показывает метрики, которые мы построили на основе semantic_layer_queries.

DAG семантического слоя в dbt Explorer

Давайте углубимся в семантические модели и метрики немного больше и объясним некоторые из решений по моделированию данных, которые мы приняли. Сначала нам нужно было решить, какую модель использовать в качестве основы для нашей семантической модели. Мы решили использовать fct_semantic_layer_queries в качестве нашей базовой модели, потому что определение семантической модели поверх нормализованной фактологической таблицы дает нам максимальную гибкость для соединения с другими таблицами. Это увеличило количество доступных измерений, что означает, что мы можем ответить на большее количество вопросов.

Вы можете задаться вопросом: почему бы просто не построить наши метрики на основе сырых таблиц и не позволить MetricFlow разобраться с остальным? Реальность такова, что почти всегда вам нужно будет выполнить некоторую форму моделирования данных, чтобы создать набор данных, на основе которого вы хотите строить свои метрики. Задача MetricFlow не в том, чтобы заниматься моделированием данных. Шаг трансформации выполняется с помощью dbt.

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

• Измерения: Мы включили все соответствующие измерения в нашу семантическую модель, которые могут понадобиться заинтересованным сторонам, такие как время создания запроса, статус запроса и булевы значения, показывающие, содержал ли запрос определенные элементы, такие как фильтр where или несколько метрик.
• Сущности: Мы добавили сущности в нашу семантическую модель, такие как идентификатор среды dbt cloud. Сущности функционируют как ключи соединения в семантических моделях, что означает, что любые другие семантические модели, которые имеют соединяемую сущность, могут быть использованы при выполнении запросов метрик.
• Меры: Далее мы добавили меры. Меры определяют агрегацию, которую вы хотите выполнить над своими данными. Я думаю о мерах как о примитиве метрики, мы будем использовать их для построения метрик и можем повторно использовать их, чтобы сохранить наш код DRY.

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

## Пример определения метрики 
metrics:
  - name: queries
    description: Общее количество выполненных запросов
    type: simple
    label: Semantic Layer Queries
    type_params:
      measure: queries

Наличие наших метрик в семантическом слое мощно по нескольким причинам. Во-первых, определения метрик и сгенерированный SQL централизованы и находятся в нашем проекте dbt, а не разбросаны по BI-инструментам или SQL-клиентам. Во-вторых, типы запросов, которые я могу выполнять, динамичны и гибки. Традиционно я бы материализовал куб или таблицу свертки, которая должна содержать все различные срезы измерений, которые могут заинтересовать моих пользователей. Теперь пользователи могут соединять таблицы и добавлять измерения к своим запросам метрик на лету во время выполнения запроса, экономя циклы нашей команды данных на обновление и добавление новых полей в таблицы свертки. В-третьих, мы можем предоставить эти метрики различным downstream BI-инструментам, чтобы заинтересованные стороны в продукте, финансах или GTM могли понять производительность продукта независимо от их технических навыков.

Теперь, когда мы выполнили работу по созданию конвейера для настройки наших метрик для запуска семантического слоя, мы готовы анализировать, как прошел запуск!

Наши команды по финансам, операциям и GTM смотрят на одни и те же метрики 😊

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

Основная работа по созданию нашего конвейера и определению метрик уже выполнена, что делает потребление на последнем этапе гораздо проще. Сначала мы настроили панель запуска в Hex как источник истины для метрик продукта семантического слоя. Этот инструмент используется кросс-функциональными партнерами, такими как маркетинг, продажи и исполнительная команда, чтобы легко проверять метрики продукта и использования, такие как общее количество запросов семантического слоя или еженедельные активные пользователи семантического слоя. Чтобы настроить наше подключение к Hex, мы просто вводим несколько деталей из нашей среды dbt Cloud, и затем мы можем работать с метриками напрямую в блокнотах Hex. Мы можем использовать интерфейс JDBC или использовать конструктор метрик GUI Hex для создания отчетов. Мы запускаем все наши WBR с этой панели, что позволяет нам выявлять тенденции в потреблении и быстро реагировать на изменения в нашем бизнесе.

Конструктор запросов семантического слоя в Hex

Со стороны финансов и операций данные о использовании продукта имеют решающее значение для принятия обоснованных решений о ценообразовании. Все наши модели ценообразования создаются в электронных таблицах, поэтому мы используем интеграцию с Google Sheets, чтобы предоставить этим командам доступ к согласованным наборам данных без необходимости загружать CSV-файлы с панели Hex. Это позволяет команде по ценообразованию добавлять срезы измерений, такие как уровень и размер компании, к данным в режиме самообслуживания без необходимости запрашивать ресурсы команды данных для генерации этих инсайтов. Это позволяет нашей финансовой команде итеративно строить финансовые модели и быть более самостоятельными в извлечении данных, вместо того чтобы полагаться на ресурсы команды данных.

Конструктор запросов семантического слоя в Google Sheets

Как бывший дата-сайентист и инженер данных, я лично считаю, что это огромное улучшение по сравнению с подходом, который я бы использовал без семантического слоя. Мой старый подход заключался бы в материализации одной большой таблицы со всеми числовыми и категориальными столбцами, которые мне нужны для анализа. Затем я бы написал кучу SQL в Hex или различных блокнотах, чтобы создать отчеты для заинтересованных сторон. Неизбежно я подписываюсь на большее количество циклов разработки, чтобы обновить конвейер всякий раз, когда нужно добавить новое измерение или данные нужно агрегировать немного по-другому. С точки зрения управления командой данных, использование центрального семантического слоя экономит циклы аналитиков данных, так как пользователи могут легче самообслуживаться. В каждой компании, в которой я когда-либо работал, аналитики данных всегда пользуются высоким спросом, с большим количеством запросов, чем они могут разумно выполнить. Это означает, что всякий раз, когда заинтересованная сторона может самообслуживаться своими данными без нашего участия, это огромная победа.

Результат: Согласованные управляемые метрики

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

Результат — доступ к согласованным и управляемым метрикам в инструменте, который наши заинтересованные стороны уже используют для выполнения своей работы. Мы можем поддерживать согласованность всей организации и предоставлять им доступ к точным данным, которые им нужны, чтобы внести свой вклад в успех продукта семантического слоя. Спасибо за чтение! Если вы думаете об использовании семантического слоя или у вас есть вопросы, мы всегда рады продолжить разговор в сообществе dbt в Slack. Оставьте нам сообщение в #dbt-cloud-semantic-layer. Мы будем рады вас услышать!