История моделей данных — это не строгое следование хронологии, а путь нарастания сложности для решения всё более трудных задач. Чтобы понять, почему появились сложные модели, нужно начать с самой простой и интуитивно понятной из них. Это проведет нас от базовых структур к комплексным, позволит осознанно выбирать инструмент, понимая все предпосылки и компромиссы.
«Широкие» таблицы
Путь поиска баланса между простотой, производительностью и гибкостью начинался с «широких» (их также называют «плоских») таблиц, где вся информация хранится в единой структуре. Это была эпоха простоты: достаточно одного запроса — и все двести атрибутов пользователя оказывались у вас в руках. Процесс извлечения данных был быстрым и интуитивно понятным, поскольку обходился без сложных соединений и подзапросов.
Однако у этой простоты обнаружилась обратная сторона — избыточность. Представьте, что данные о сотрудниках и их работодателях хранятся в одной таблице. Если компания меняет название, то необходимо обновлять каждую запись, которая связана с изменяемой информацией. Это не только расточительно с точки зрения хранения, но и чревато аномалиями в данных. Также при увеличении количества данных в «широких плоских» таблицах возрастает и риск нарушения консистентности информации.
Поэтому появилась необходимость избавиться от таких ключевых проблем «широких» таблиц, как:
Дублирование данных: Одна и та же информация (например, название компании, город, банкротство) повторяется для каждой записи всех сотрудников.
Аномалии модификации: Любое изменение, добавление или удаление данных требует массовых операций, что влечет за собой риск для целостности информации и ресурснозатратно.
Сложность масштабирования: С ростом объёма данных таблица становится неуправляемой, производительность запросов падает, что подводит к тому, что дальнейшее расширение и поддержание целостности становятся невозможными.
Это приводит нас к следующему этапу эволюции.
«Звезда» и «Снежинка»
Ответом на проблемы широких таблиц стали нормализованные модели, такие как «Звезда» и её более строгая версия — «Снежинка». Логика «звезды» тесно связана с нашей лингвистической основой. Любое предложение, например, «Иванов купил в магазине № 5 колбасу», состоит из сущностей – Иванов, магазин, колбаса, и действия, которое их связывает – купил. В модели «звезда» таблица фактов (например, «Чек») — это и есть глагол, центральное событие, которое произошло. А окружающие ее таблицы измерений («Покупатели», «Магазины», «Товары») — это существительные, множества объектов, которые вовлечены в действие. «Снежинка» — это та же «Звезда», но таблицы измерений дополнительно нормализованы. Например, измерение «Товар» может быть разложено на отдельные таблицы «Категория товара», «Производитель» и «Бренд», образуя структуру, которая визуально напоминает снежинку.
Рассмотрим как пример «человек работает в компании» эволюционирует от «плоской» таблице к «звезде».
Благодаря подобной декомпозиции появляется понятие нормализации – управление избыточностью с помощью свода правил - нормальных форм. Всего выделяют 11 нормальных форм. Основными считаются с 1НФ по 6НФ, также существуют промежуточные и альтернативные формы, которые устраняют конкретные виды избыточности. Например, НФБК (нормальная форма Бойса-Кодда) является усиленной версией 3НФ, а ДКНФ (доменно-ключевая нормальная форма) считается «идеальной», но труднодостижимой на практике. Ниже представлена таблица, которая отражает характеристики всех форм нормализации.
Нормальные формы можно представить в виде шкалы. На одном ее конце находится нулевая нормальная форма — «широкая» таблица, из которой дёшево извлекать данные, но дорого хранить из-за дублирования. На другом конце — шестая нормальная форма, где каждый атрибут вынесен в отдельную таблицу, что позволяет экономить место на диске, однако для сборки данных потребуется огромное количество операций соединения. Поэтому выбор уровня нормализации — это всегда компромисс между ресурсами хранения и вычислительной мощностью.
Несмотря на преимущества, «Звезда» и «Снежинка» столкнулись с трудностями. Они плохо приспособлены к частым изменениям в структуре источников данных. Добавление нового атрибута часто требовало перестройки всей модели, что делало процесс медленным и дорогим. Кроме того, эти модели не были идеальны для хранения полной истории изменений данных из операционных систем. Попытки сохранить историю изменений — например, каждый переезд клиента — приводили к «раздуванию» таблиц измерений. Количество записей увеличивалось, актуальная информация терялась, а производительность падала. Это явление, иронично названное «взрывом звезды», наглядно демонстрировало, что классические модели достигли предела своих возможностей в мире, где данные должны не только храниться, но и рассказывать свою полную историю.
Data Vault
Ответом на эти проблемы стала модель Data Vault. Её философия заключается в гибкости и поглощении изменений из разных внешних источников.
Базовые компоненты модели Data Vault:
Хабы (Hubs): Содержат только уникальные бизнес-ключи сущностей. Отвечают на вопросы «кто?» и «что?» в модели.
Связи (Links): Описывают взаимодействия между хабами, выполняя роль «глаголов» (например, «клиент совершил заказ»). Представляют собой транзакции, факты продаж или любые иные события.
Спутники (Satellites): Хранят все описательные атрибуты, их историю изменений и метаданные – время и источник поступления данных.
Покажем, как эта модель справлялась с историчностью и изменчивостью источников, когда их количество росло, структура менялась, а данные поступали из противоречащих друг другу систем
Компании захотели хранить не только актуальное состояние данных, но и всю их историчность, чтобы отслеживать изменения объектов во времени. Чтобы реализовать эти процессы, используются механизмы Slowly Changing Dimensions (SCD) – медленно меняющихся измерений.
Пока существуют 7 типов SCD:
SCD 0: данные никогда не меняются после загрузки;
SCD 1: актуальные данные перезаписываются, история не сохраняется;
SCD 2: для каждого изменения создается новая запись с метками актуальности:
флаг актуальности;
дата начала;
флаг актуальности + дата начала;
дата начала + дата окончания;
флаг актуальности + дата начала + дата окончания
SCD 3: в строку добавляются отдельные колонки для хранения предыдущего значения атрибута;
SCD 4: история выносится в отдельную таблицу
SCD 5, 6, 7: являются гибридными комбинациями базовых (вышеперечисленных) типов.
Не существует «самого правильного» типа SCD. Выбор зависит от бизнес-требований к истории, объема данных и вычислительных ресурсов. Реализуем историчность с помощью SCD2. В нашем примере для таблицы satelite_company, которая хранит атрибуты компании - ее наименовании и местоположении, добавим дополнительные столбцы "Дата начала" и "Дата окончания" актуальности записей. Это позволит нам сохранить всю историю изменений названий и городов компаний.
Однако при изменении одного из атрибутов, например, местоположения, создается новая запись с тем же наименованием. Таким образом, в таблице satellite_company появляется дублирующее значение: переезжая, компания повторяет данные о ее названии. Более того, если не проанализировать всю историю изменений, невозможно сразу определить, что именно менялось - наименование компании или ее местоположение. Каждая новая версия строки отражает изменение любого из ее атрибутов, без указания, какой именно был обновлен. Если предположить, что Наименование будет меняться крайне редко, а из одного города в другой можно переезжать довольно часто, то было бы логично разделить таблицу satellite_company на две новых таблицы: satellite_name_company - для хранения наименования компании и satellite_city_company - для хранения месторасположения компании.
То есть для эффективного сохранения данных с разным периодом изменения лучше сделать отдельные спутники.
Кроме того, эпоха микросервисной архитектуры привела к взрывному росту количества источников данных: вместо одного монолитного источника аналитикам пришлось работать с десятками разнородных систем, каждая из которых имела свою базу данных. Предположим, что для таблицы satellite_person данные поступают из разных отделов: ФИ и Дата Рождения из HR-отдела, а паспортные данные из системы безопасности. Такая ситуация может привести к конфликтам загрузки и падению производительности. Поэтому второй принцип, которого стоит придерживаться – разделение по источникам.
Ключевое преимущество Data Vault заключается в том, что новые источники данных или изменения в атрибутах интегрируются путем добавления новых сущностей, без необходимости изменять существующую структуру. Это делает данную модель идеальным решением для сред с высокой изменчивостью источников и строгими требованиями к аудиту и отслеживанию данных.
Якорная модель (Anchor Modeling)
Следующим шагом в этой эволюции стала якорная модель (Anchor Modeling), которую можно рассматривать как Data Vault, доведенный до шестой нормальной формы. Состоит из:
Якоря (Anchors): Представляют собой фундаментальные бизнес-сущности и содержат только их уникальные идентификаторы, являясь структурным скелетом модели.
Атрибуты (Attributes): Хранят все описательные данные и их историю изменений в виде отдельных таблиц, каждая из которых напрямую связана с якорем.
Связки (Ties): Фиксируют отношения и события между несколькими якорями, определяя их взаимосвязи в конкретный момент времени.
В этой модели каждый атрибут хранится в отдельной таблице, поэтому она может эволюционировать без перестройки существующей структуры. Все это обеспечивает беспрецедентную гибкость, масштабируемость и полноту аудита. Но за преимущества данной модели придется заплатить невероятной сложностью запросов и общей поддержки системы.
Как выбрать модель данных для вашего проекта?
Чтобы сделать осознанный выбор, задайте несколько вопросов, например:
Каковы цели и требования к данным?
· Скорость разработки и простота: Широкая таблица или «звезда»
· Полный аудит и трассируемость: Data Vault или Якорная модель
· Воспроизводимость и историчность: Data Vault
Какова природа и объем данных?
· Стабильные, предсказуемые данные: «Звезда» или «снежинка»
· Быстрорастущие, неструктурированные потоки: Data Vault
· Очень большие объемы, требующие экономии места: Якорная модель
Насколько сложна архитектура источников?
· Один-два стабильных источника: «Звезда»
· Десятки микросервисов с частыми изменениями: Data Vault
· Экосистема с постоянно меняющейся структурой: Якорная модель
Какие ресурсы и экспертиза есть в команде?
· Небольшая команда, нужна простота: Широкая таблица
· Опыт в классическом BI: «Звезда»
· Экспертиза в интеграции данных и готовность к сложности: Data Vault
· Специализированная команда для долгосрочных сложных проектов: Якорная модель
В статье представлены базовые примеры для ознакомления с темой, однако на практике выбор модели является нетривиальной задачей. Он требует комплексного анализа всей системы, учитывающего всю совокупность входных условий и их взаимосвязи.
Практические примеры выбора модели
Давайте рассмотрим, как эти принципы работают на практике:
Пример 1: Крупный банк
Контекст: Десятки источников (кредиты, карты, вклады), жёсткие требования регуляторов, необходимость знать, кто и когда изменил каждое поле.
Проблема: изменчивость источников, нужен полный аудит.
Выбор: Data Vault. Модель позволяет гибко добавлять новые сущности, сохраняя всю историю изменений для отчётности перед регуляторами. Якорная модель была бы избыточна и слишком сложна для поддержки.
Пример 2: Быстрорастущий стартап
Контекст: Небольшая команда, продукт постоянно меняется, метрики для проверки гипотез вводятся и отменяются каждую неделю.
Проблема: Скорость разработки и простота важнее идеальной структуры.
Выбор: «Широкая» таблица (витрина данных). Это позволит быстро доставлять данные менеджерам для анализа. Нормализация и сложные модели только замедлили бы итерационный процесс.
Пример 3: Научно-исследовательский проект (геномика)
Контекст: Десятки лабораторий по всему миру, тысячи приборов, генерирующих терабайты данных. Проект рассчитан на 20 лет. Критически важна воспроизводимость экспериментов.
Проблема: Необходимость хранить эволюцию самой модели данных и всех параметров.
Выбор: Якорная модель. Она гарантирует, что через 10 лет можно будет точно воссоздать условия старого эксперимента, так как каждый атрибут и его история сохраняются независимо. Сложность запросов — приемлемая цена за научную достоверность.
Пример 4: Классический ритейл
Контекст: Стабильные процессы, два основных источника (склад, продажи), команда с опытом классического подхода к моделированию. Цель — стандартные отчёты по продажам и запасам.
Проблема: Предсказуемость и производительность отчётов.
Выбор: «Звезда». Это проверенная модель, которая обеспечивает высокую скорость выполнения запросов для предсказуемых бизнес-вопросов и проста для понимания бизнес-пользователями.
Таким образом, не существует «лучшей» модели данных. Эволюция моделей — это история о поиске оптимального инструмента для управления самым ценным ресурсом — данными. Правильный выбор определяется конкретным контекстом, а не модой на технологии. От стартапа, где важна скорость, до научного проекта, где критична точность, — каждая модель находит своё идеальное применение.