Как построить семантический слой по частям: пошаговое руководство для занятых инженеров-аналитиков

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

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

Мы здесь, чтобы обсудить другой способ: построение семантического слоя по частям. Наша цель — убедиться, что вы получаете больше рычагов и скорости на каждом этапе вашего пути. Если вы хотите начать строить, но у вас ограниченные ресурсы (как у большинства занятых инженеров-аналитиков), это особенно для вас.

Система существительного: решение, что происходит где

Когда вы используете семантический слой dbt, вы хотите минимизировать моделирование, которое существует вне dbt. Полностью устраните его, если можете. Почему?

• Это дублирующее, фрагментарное и запутанное, как обсуждалось выше.
• Это менее мощное.
• Вы не можете тестировать его.
• В зависимости от инструмента, часто вы не можете контролировать версии.

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

к сведению

🏎️ Семантический слой — это движок денормализации. dbt преобразует ваши данные в чистые, нормализованные хранилища. Семантический слой dbt — это движок денормализации, который динамически соединяет и формирует эти строительные блоки в максимальное количество форм динамически.

Это позволяет создать более гибкий слой потребления, что означает, что инструменты нижнего уровня (такие как AI или панели управления) могут располагаться как можно ближе к артефактам и API, созданным семантическим слоем, и сосредоточиться на том, что делает их уникальными, вместо того чтобы быть обремененными базовыми задачами динамического моделирования и агрегации. Любые конструкты, специфичные для инструмента, обычно должны работать как можно ближе к прозрачным проходам, в основном служа для отображения метрик и измерений из семантического слоя в вашем инструменте нижнего уровня. Конечно, могут быть исключения, но в качестве общего руководящего принципа это дает вам максимальную способность к динамической денормализации, и, следовательно, ценность, от вашего кода семантического слоя.

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

План: к итеративной скорости

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

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

2. Каталогизируйте модели и их столбцы, которые обслуживают продукт данных, как в dbt, так и в инструменте BI, включая сводки, таблицы метрик и хранилища, которые их поддерживают. Обратите особое внимание на агрегации, так как они будут составлять метрики. Вы можете обратиться к этому примеру Google Sheet для одного из способов отслеживания этого.

3. Растопите замороженные сводки в вашем проекте dbt, а также вариации, смоделированные в вашем инструменте BI, в код семантического слоя. Мы углубимся в этот процесс, и мы рекомендуем вам прочитать больше об этой тактической терминологии (замороженные, сводка и т.д.) по ссылке — она будет использоваться на протяжении всей этой статьи!

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

Эльза быстро итератирует.

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

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

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

Миграция части: пошаговое руководство

1. Определите цель

1. Определите относительно нормализованное хранилище, которое обеспечивает сводки в dbt. Если вы делаете сводки в вашем инструменте BI, начните с этого. Но мы рекомендуем начинать с замороженных таблиц в dbt сначала и постепенно проходить через поток DAG, включая логику в вашем инструменте BI в последнюю очередь. Это потому, что мы хотим итеративно разбивать эти замороженные концепции таким образом, чтобы мы получали выгоду от более ранних частей цепочки, которые уже были мигрированы. Думайте о "движении слева направо в большом DAG", который охватывает все ваши инструменты.
   • ✅ orders, customers — это базовые концепции, поддерживающие ваш бизнес, поэтому они должны быть моделями хранилищ, материализованными через dbt.
   • ❌ active_accounts_per_week — это построено на основе вышеуказанного, и то, что мы хотим генерировать динамически в семантическом слое dbt.
   • Другими словами: customers и orders — это нормализованные строительные блоки, active_accounts_per_week — это сводка, и мы всегда хотим мигрировать их в семантический слой.
     Замороженная сводка, построенная на нормализованных хранилищах.

2. Каталогизируйте входные данные

1. Определите нормализованные столбцы и игнорируйте любые столбцы агрегации на данный момент. Например, order_id, ordered_at, customer_id, order_total — это поля, которые мы хотим поместить в нашу семантическую модель, оконная функция, которая суммирует customer_cac статически в модели dbt, не является полем, которое мы хотим в нашей семантической модели, потому что мы хотим динамически закодировать это вычисление как метрику в семантическом слое.
   1. Если вы обнаружите на следующем шаге, что не можете выразить определенное вычисление в семантическом слое, используйте dbt для его моделирования**.** Это красота интеграции вашего кода семантического слоя в вашу кодовую базу dbt, это легко управлять перемещением линии между слоями преобразования и семантическим, потому что вы управляете единой кодовой и инструментальной базой.

3. Напишите код семантического слоя

1. Начните с семантической модели, проходя по столбцам и помещая все идентифицированные столбцы из Шага 2 в 3 семантических категории:
   1. Сущности — это основа ваших семантических концепций или объектов, вы можете думать о них как о ключах или идентификаторах, которые формируют зерно.
   2. Измерения — это способы группировки и классификации этих объектов или концепций, такие как время и категории.
   3. Меры — это числовые значения, которые вы хотите агрегировать, такие как общая сумма заказа или количество раз, когда пользователь кликнул на рекламу.
2. Создайте метрики для столбцов агрегации, которые мы не закодировали в семантической модели.
3. Теперь, определите сводку, которую вы хотите растопить. Обратитесь к предыдущему примеру, чтобы помочь различить эти типы моделей.
4. Повторите эти шаги для любых других концепций, которые вам нужно создать для этой сводки, например, active_accounts_per_week может потребовать как customers, так и orders.
5. Создайте метрики для столбцов агрегации, присутствующих в сводке. Если ваша сводка ссылается на несколько моделей, поместите метрики в YAML-файл, который наиболее тесно связан с зерном или ключевой агрегацией таблицы. Например, active_accounts_per_week агрегируется на недельном временном зерне, но ключевая метрика считает учетные записи клиентов, поэтому мы хотели бы поместить эту метрику в файл customers.yml или sem_customers.yml (в зависимости от системы именования, которую вы предпочитаете). Если она также содержит метрику, агрегирующую общие заказы за данную неделю, мы поместим эту метрику в orders.yml или sem_orders.yml.
6. Создайте сохраненные запросы с экспортами, настроенные для материализации ваших новых артефактов на основе семантического слоя в хранилище параллельно с замороженной сводкой. Это позволит нам переключить инструменты потребления и провести аудит результатов.

4. Подключите внешние инструменты параллельно

1. Теперь, переключите ваш внешний аналитический инструмент на указание на экспорты семантического слоя вместо сводки. Помните, мы хотим переключить указатели только для сводки, которую мы мигрировали, все остальное должно оставаться указывающим на замороженные сводки. Мы мигрируем итеративно по частям!
   1. Если у ваших инструментов нижнего уровня есть интеграция с семантическим слоем, вы захотите настроить это также. Это позволит не только декларативное кэширование общих шаблонов запросов с экспортами, но и легкие, полностью динамические запросы на лету.
2. Как только вы воспроизвели предыдущее состояние вещей, с семантическим слоем, предоставляющим данные вместо замороженных сводок, теперь вы готовы переместить преобразования, происходящие в вашем инструменте BI, в семантический слой, следуя тому же процессу.
3. Наконец, чтобы почувствовать новую скорость и мощь, которую вы разблокировали, попросите заинтересованную сторону о измерении или метрике, которая находится в их списке желаний для продукта данных, с которым вы работаете. Затем насладитесь славой, удивив их, когда вы отправите это через час!

подсказка

💁🏻‍♀️ Если ваш инструмент BI позволяет это, убедитесь, что вы выполняете шаги, связанные с BI, в среде разработки. Если у него нет таких возможностей, придерживайтесь дублирования продукта данных, который вы перестраиваете, и выполняйте это там, чтобы вы могли заменить его позже после тщательного тестирования.

Глубокое воздействие

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

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