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

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

Другими словами, что если мы расскажем историю?

"Когда бизнес-вопросы приходят, они приходят не поодиночке, а батальонами." - известный специалист по данным Уильям Шекспир

Это, возможно, более совместный способ описания отношений между инженером аналитики и заинтересованными сторонами, чем "если дать мышке печенье".

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

Как это выглядит на практике? Давайте рассмотрим пример:

Сколько заказов поступило на прошлой неделе?

С простым вопросом формальные принципы моделирования могут быть не важны. У вас есть исходные данные и запрашиваемая информация. Назовите это как-то подходяще и двигайтесь дальше. Все так просто.

Но это не так просто.

Сколько из размещенных заказов было выполнено в течение трех дней?

Сколько товаров было в каждом заказе?

Сколько из заказов были от возвращающихся клиентов?

Бизнес-любопытство - это квинтэссенция гидры (просто посмотрите на dbt DAG), и инженер аналитики должен знать, что одна голова - это не конец.

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

Ведущее решение

Итак, какие соглашения мы должны использовать в наших проектах?

История и гравитация привели многие команды к размерному моделированию, построению бизнес-молекул из атомных fct и dim. Этот подход пользуется заслуженной популярностью "если не сломано, не чини" и занимает значительную долю практик команд данных.

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

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

Но что, если эта дополнительная выгода - это ясность?

Введение в нарративное моделирование

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

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

Из этих принципов возникли три основных соглашения: таблицы событий, таблицы деталей и схемы сущностей.

Таблицы событий

Во-первых, основа хорошего нарратива - это сюжет: что произошло? В нашем примере, Сколько заказов поступило на прошлой неделе?

Чтобы ответить на этот вопрос, нам все еще нужна одна строка на каждый размещенный заказ с временными метками, чтобы мы могли фильтровать по конкретным периодам времени (например, на прошлой неделе). Но как мы должны это назвать?

Каждый принцип нарративного моделирования включает слово "интуитивный". С учетом этого, давайте назовем эту таблицу order_placed.

В нарративном моделировании мы бы назвали order_placed таблицей событий. Таблицы событий имеют соглашение о наименовании subject_verb.

Если это похоже на fct_ таблицы, так и есть! Однако преимущество order_placed над fct_orders проявляется, когда вам нужно дополнительное событие на уровне заказа. Например, Сколько заказов было выполнено на прошлой неделе?

• В размерном моделировании вы уже использовали fct_orders, поэтому, вероятно, вам нужно будет переименовать эту модель. Это может привести к соглашениям о наименовании, таким как fct_order_placement и fct_order_fulfillment, которые могут казаться отчетом о двух отдельных сущностях, а не о двух вещах, которые могут произойти с заказами.
• В нарративном моделировании нет ограничений, так как мы создаем order_fulfilled рядом с order_placed, оставляя место для order_cancelled и всех других шагов в потоке заказа.

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

Таблицы деталей

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

В примере с заказами таблица order_details может содержать такие поля, как:

• customer_id
• items_ordered
• payment_method

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

• items_fulfilled
• days_to_fulfillment

Можно представить, что заинтересованная сторона хочет знать все пять этих данных, но контекст для них исходит из нескольких событий в потоке заказа. Таблица _details позволяет нам собрать широкий банк знаний о данной сущности (в данном случае, о заказе) в одном месте. Если обновление данных достаточно производительно, это может быть даже место для отображения истинных снимков полей, таких как status или current_location.

Итак, у нас есть все, что произошло с нашим заказом, и все, что мы хотели бы о нем знать. Теперь давайте соберем все это вместе... буквально.

Схемы сущностей

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

• order_cancelled
• order_details
• order_fulfilled
• order_placed

Сохранение связанной информации в группе кажется достаточным для удобства использования. Однако я видел достаточно аналитических баз данных, где база данных и схема имеют одно и то же имя (например, DATA_MARTS.DATA_MARTS.*), чтобы увидеть возможность создания базы данных, которая описывает бизнес, как только вы ее открываете.

На протяжении нашего примера order была сущностью, о которой мы хотим знать много. Любое предприятие, которое создает бизнес-вопросы, будет иметь десятки, если не сотни сущностей, которые интересуют людей. Даже в нашем примере мы коснулись других сущностей, таких как item и customer.

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

• analytics база данных
  • customer схема
    • customer_details
    • customer_created
  • item схема
    • item_details
    • item_fulfilled
  • order схема
    • order_cancelled
    • order_details
    • order_fulfilled
    • order_placed

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

Если вместо этого база данных имела схемы для parts_order и customer_order, тот же новый сотрудник заходит в базу данных, видит эти схемы и думает: "О, есть два типа... Я, вероятно, должен спросить, какой." Это различие может быть гораздо труднее заметить в одной аналитической схеме.

Интуитивно и образовательной.

Давайте визуализируем

Одним из самых мощных способов для заинтересованных сторон концептуализировать поток данных через проект dbt является визуализация DAG в документации dbt. Если мы считаем своей целью захват бизнес-знаний и ведение разговоров о том, как мы получаем эти знания, давайте рассмотрим, как два варианта проявляются в их DAG:

Размерное моделирование

В этом подходе у нас есть стандартные fct и dim таблицы и чистый поток DAG. Давайте рассмотрим некоторые возможные недостатки:

• Поскольку я создал этот поток, я знаю, что fct_shipments к dim_order_items к fct_orders представляет собой поток знаний. Пакет был отправлен с товарами внутри, что означает, что сами товары теперь отправлены, и если все товары в данном заказе отправлены, то весь заказ выполнен. Однако, чтобы новый человек узнал это в этом подходе, ему нужно войти в модели и посмотреть SQL, чтобы понять, почему они являются зависимостями.
• Мы назвали таблицу fct_orders, потому что заказы - это события. Поскольку мы можем представить себе заинтересованную сторону, желающую идентифицировать отмененные заказы, мы используем подход int / fct, но теперь намерение fct кажется немного неясным. Оно захватывает событие, размещение заказа, в момент, когда мы не знаем, что он будет отменен. Мы могли бы потенциально создать dim_orders и fct_order_placements, если мы хотим захватить оба, но это предполагает, что дизайн fct / dim является скорее выбором, который разные разработчики в вашем коде могут подходить по-разному.

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

Нарративное моделирование

Как это сравнивается с вышеизложенным?

• Теперь мы явно указываем на наши зависимости. Мы говорим зрителю, что мы делаем вывод, что товары были отправлены из отправленных пакетов, затем используем эти товары, чтобы определить, когда заказ был полностью выполнен.
• Шаги размещения и выполнения заказа теперь явные, переходящие в таблицу order_details, где мы также можем рассчитать days_to_fulfillment.
• DAG выглядит немного более сложным, с дополнительными узлами и более широкой базой конечных моделей справа по сравнению с эффектом сужения размерного моделирования. Этот потенциальный недостаток может нуждаться в контекстуализации:
  • Во-первых, мы более явно указываем на бизнес-вопросы, на которые мы отвечаем, поэтому каждый из этапов order, который мог бы ранее быть спрятан в CTE fct_orders, теперь является узлом сам по себе.
  • Во-вторых, помните гидру? В идеале бизнес-вопросы порождают бизнес-ответы, которые порождают новые бизнес-вопросы. Если база знаний должна расширяться, разумно, что DAG может также. Ключ, однако, заключается в проверке того, что каждая модель отвечает на вопрос, который кто-то задает.

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

Преимущества на практике

Заинтересованные стороны находят участие в моделировании данных более простым

• Им не нужно изучать особенности структуры fct/dim (например, идея о том, что только некоторые бизнес-данные называются фактами).
• Отдельные модели оформлены как события или сущности в бизнесе, что позволяет заинтересованной стороне сравнивать логику модели с их предметными знаниями.

Нематериальные бизнес-шаги легче моделировать

• Пробелы в знаниях фиксируются точно. Например, если лучший способ, которым вы знаете, что отправление было получено клиентом, это то, что водитель грузовика отсканировал его из системы, вы можете смоделировать shipment_scanned_out как явную модель, за которой следует неявная модель shipment_received, ссылающаяся на нее. Это сохраняет в коде текущую точку зрения компании, что действие сканирования - это лучшая доступная информация.
• Определенные бизнес-решения напрямую управляют преобразованиями данных. Если вся посылка стоит $50.00 за доставку и в ней несколько товаров, стоимость доставки может быть распределена по каждому товару в зависимости от веса или стоимости продукта. В любом случае, команды могут зафиксировать это распределение как item_apportioned_shipping_cost.

Пользователи могут связывать бизнес-концепции с исходными данными

• Хотя структура схемы выше сосредоточена на бизнес-сущностях, все еще существуют многочисленные случаи использования стейджинговых и промежуточных таблиц.
• После очистки исходных данных с помощью стейджинговых таблиц используйте тот же подход "что произошло" для более технических событий, создавая трехузловую зависимость от stg_snowplow_events до int_page_click_captured до user_refreshed_cart, таким образом отвечая на вопрос "где мы получаем информацию о поведении пользователей в Интернете?" в быстром посещении DAG в документации dbt.

Должна ли ваша команда использовать это?

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

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

Нарративное моделирование может не подойти для...

• ...компаний, где расходы на хранение, даже в облачных хранилищах, должны быть тщательно отслежены. В конце концов, модели fct/dim возникли из необходимости оптимизации хранения данных.
• ...компаний с BI-инструментами, которые сильно зависят от таблиц с несколькими сущностями. Это все еще может работать с нарративным моделированием, однако, если есть дополнительный слой стандартных наборов данных, моделируемых из общих компонентов ваших нарративных моделей (чтобы данные оставались в шаге в разных контекстах).

Бесконечная история

Существует классический фильм под названием "Desk Set", в котором Кэтрин Хепберн управляет справочным столом крупной телесети, а Спенсер Трейси приходит установить исследовательский компьютер в ее отделе. В гладиаторских поединках остроумия фильм исследует концепцию знаний и, в частности, насколько они должны быть человеческими. В какой-то момент Ричард Самнер, персонаж Трейси, проводит Бани Уотсон, персонажа Хепберн, через громоздкую задачу "поезд покинул станцию", и я все время думаю о ее ответе (сокращенном ниже).

Ричард Самнер: Итак, поезд отправился из Гранд Централ с семнадцатью пассажирами на борту и экипажем из девяти человек. На 125-й улице четверо вышли, а девять вошли. В Уайт Плейнс трое вышли, а один вошел. В Чаппакуа девять вышли, а четверо вошли. И на каждой следующей остановке никто не выходил, никто не входил, пока поезд не достиг предпоследней остановки, где пятеро вышли, а один вошел. Затем он достиг терминала.

Ричард Самнер: Сколько людей вышло в Чаппакуа?

Бани Уотсон: Девять.

Ричард Самнер: Эм, не могли бы вы сказать мне, как вы пришли к этому выводу?

Бани Уотсон: Страшно, не правда ли? Вы заметили, что в Чаппакуа также девять букв?

Ричард Самнер: Вы привыкли ассоциировать слова с количеством букв в них?

Бани Уотсон: Я ассоциирую многие вещи с многими вещами.

Ричард Самнер: Понятно. Хм.

Бани Уотсон: Разве вы не собираетесь спросить меня, сколько людей вышло в Уайт Плейнс? Трое.

Ричард Самнер: Но в Уайт Плейнс десять букв.

Бани Уотсон: Нет. Одиннадцать.

Ричард Самнер: [пауза] Но только трое вышли там.

Бани Уотсон: Видите ли, я была в Уайт Плейнс всего три раза в своей жизни.

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

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

Итак, перед лицом батальонов бизнес-вопросов мы можем стать хозяевами самих себя.

Примечания

Footnotes

1. Однако, с точки зрения исходных данных коммерции, можно представить, что товары добавляются в заказ как отдельные события сначала, прежде чем происходит окончательное событие размещения заказа. Конечная точка API для размещения заказа может не нуждаться в знании того, что находится в корзине, а только в том, кто и когда. В этом случае выбор за дилером, присоединять ли товары для order_placed или order_details. ↩

2. Спросите меня, откуда я это знаю! ↩