Разбираем хабы, линки и сателлиты на условной службе проката. Показываем, какую задачу решает Data Vault и почему это ещё не готовый отчёт.
У одного бизнеса появляется несколько описаний
Представим условную службу проката велосипедов. Клиенты записаны в системе бронирования, велосипеды — в учёте имущества, поездки — в приложении. Позже появляется ещё один канал продаж. Команда хочет соединить сведения и сохранить, что приходило из каждого источника. Если каждый раз перестраивать одну огромную таблицу, любое новое описание приходится согласовывать со всеми прежними полями.
Data Vault — подход к организации хранилища, который разделяет ключи объектов, отношения между ними и описательные сведения с историей. В обзоре Google Cloud эти части называются хабами, линками и сателлитами. Здесь разберём смысл модели, без выбора облака и без инструкции по её технической реализации.
Хаб отвечает за узнаваемый объект
Хаб собирает бизнес-ключи одного понятия. Бизнес-ключ — признак, по которому предмет узнают в исходном процессе: например, номер велосипеда в учёте имущества. Для нашего проката отдельными понятиями будут клиент и велосипед. Название модели не означает, что вся анкета клиента обязательно должна оказаться в одной центральной таблице.
Условной команде сначала стоит договориться, какой номер означает один и тот же велосипед. Если приложение и склад используют разные номера, модель не угадает соответствие за людей. Даже одинаковая последовательность цифр может обозначать разные объекты в двух системах. Правило сопоставления нужно объяснить до того, как обсуждать устройство таблиц.
Линк хранит отношение, сателлит добавляет описание
В объяснении Databricks линки связывают основные понятия, а сателлиты содержат описательные сведения о них и их отношениях. В нашей истории можно отдельно выразить, какой клиент арендовал какой велосипед. Это отношение не равно ни анкете клиента, ни карточке имущества. Подробность записи об аренде тоже требуется определить заранее.
Описание клиента, например город, может со временем меняться. Для учебного разбора представим сателлит, который сохраняет поступившие версии такого описания. Тогда обновление адреса не требует превращать старую поездку в поездку нового клиента. Точный состав служебных дат и правила определения актуальной версии зависят от проекта; одной картинки из трёх блоков для этого недостаточно.
Новый источник не должен стирать прежнюю картину
Допустим, приложение передало город клиента иначе, чем форма бронирования. Нашей команде важно сначала сохранить происхождение двух утверждений, а затем решить, какое использовать в конкретном отчёте. Если молча заменить одно значение другим, спор исчезнет из таблицы, но причина расхождения останется неизвестной. Разделение описаний позволяет обсуждать этот случай явно.
В условном процессе предложим записать четыре вопроса: какой объект описывается, откуда пришло утверждение, когда его получили и для какого рабочего решения оно подходит. Это порядок обсуждения, а не обещание, что любой проект Data Vault автоматически устраняет ошибки. Неверно выбранный ключ или потерянный источник остаются ошибками независимо от названия модели.
Для читателя отчёта обычно нужен следующий слой
Data Vault не следует воспринимать как готовую удобную таблицу для всех аналитиков. Databricks описывает построение отчётных витрин поверх такой модели. Витрина — подготовленный набор под конкретные вопросы. В нашем прокате руководителю нужен итог по дням и пунктам выдачи, а не перечень всех технических связей и версий описаний.
Выбор модели стоит обсуждать с учётом числа источников, изменений и требований к истории. Для маленькой разовой выгрузки такая организация может оказаться избыточной; это предлагаемая проверка соразмерности, а не универсальный запрет. О более широком устройстве систем можно прочитать в материалах про архитектора данных и озеро и хранилище. Программа «Архитектор данных» поможет сопоставить темы обучения со своей задачей.
