Обсудить
бизнес-задачи
бизнес-задачи
Сравнение Anchor Modeling и Dimensional Modeling
блог о bi, №1 в рунете
Крайне важно правильно выбрать методологию моделирования данных для хранилища еще на этапе проектирования, это поможет обеспечить необходимый уровень гибкости и масштабируемости, а также позволит синхронизоваться с поставленными бизнес-задачами.
В этой статье мы рассмотрим сильные и слабые стороны двух популярных методологий – Anchor Modeling и Dimensional Modeling, а также сравним их производительность на типовых запросах.
Dimensional Modeling или Размерное моделирование – это метод моделирования данных, при котором «факты» и «измерения» являются ключевыми компонентами для организации и описания сущностей в хранилище данных.
Типичными примерами моделей в данном случае являются «Звезда» и «Снежинка». Обе модели подразумевают связь таблицы фактов с таблицами измерений. В «Снежинке» также измерения могут быть связаны с другими измерениями, что повышает уровень нормализации (до 3 Нормальной Формы (3NF)).
- Факты – описывают события бизнес-логики (продажа, покупка, отправка письма);
- Измерения – их характеристики (магазин, товар, отправитель), добавляющие контекст к хранимым событиям в таблицах фактов;
Типичными примерами моделей в данном случае являются «Звезда» и «Снежинка». Обе модели подразумевают связь таблицы фактов с таблицами измерений. В «Снежинке» также измерения могут быть связаны с другими измерениями, что повышает уровень нормализации (до 3 Нормальной Формы (3NF)).
Рис. 1 – пример ER-диаграммы для Dimensional Modeling.
В центре расположена таблица факта «Чек» (событие продажи), которая связана с таблицами измерений.
В центре расположена таблица факта «Чек» (событие продажи), которая связана с таблицами измерений.
Anchor Modeling или Якорное моделирование – метод моделирования, позволяющий эффективно работать с большими объемами данных, которые меняются по структуре и содержанию. В основе метода лежит высокая степень нормализации (до 6 Нормальной Формы (6NF)).
Основными понятиями модели являются:
Каждая из вышеописанных концепций будет представлена отдельной таблицей в хранилище для каждой сущности – если у якоря 10 различных атрибутов, значит в хранилище должны существовать 10 отдельных независимых таблиц для них.
Основными понятиями модели являются:
- Якорь (Anchor) – представляет собой сущность или событие, содержит суррогатные ключи и (опционально) время добавления записи.
- Атрибут (Attribute) – используется для моделирования свойств и характеристик якорей, содержит суррогатный ключ якоря, значение атрибута и время добавления записи для поддержания историчности данных.
- Связь – моделирует отношения между якорями, содержит суррогатные ключи и время добавления записи. У связей не может быть атрибутов.
Каждая из вышеописанных концепций будет представлена отдельной таблицей в хранилище для каждой сущности – если у якоря 10 различных атрибутов, значит в хранилище должны существовать 10 отдельных независимых таблиц для них.
Рис. 2 – ER-диаграмма фрагмента для Anchor Modeling
Сине-зеленым цветом отмечены якоря, зеленым – связи (линки), оранжевым – атрибуты якорей.
Сине-зеленым цветом отмечены якоря, зеленым – связи (линки), оранжевым – атрибуты якорей.
Атрибуты и связи делятся на статичные и с историей. Последние применяются, когда необходимо сохранять все произошедшие с сущностью изменения. Существует несколько подходов в реализации поддержания историчности, мы применили один из базовых – сохранение для каждой записи даты последнего обновления (поле last_update_date) и флаг актуальности данных для выборки всех последних обновлений (поле is_actual)
Сравним плюсы и минусы каждой модели.
Сравним плюсы и минусы каждой модели.
Anchor Modeling
Плюсы модели
- Гибкость моделирования, высокая масштабируемость (благодаря крайне высокой степени нормализации данных);
- Экономия места в связи с отсутствием null значений (если для данного атрибута у якоря отсутствует значение, соответствующей записи просто нет в таблице) и дублирования;
- Более высокая устойчивость к ошибкам в разработке (в том числе смежных источников), так как данные хранятся независимо друг от друга;
- Простота поддержки историчности данных, в том числе старых атрибутов, линков и якорей, которые уже не используются в работе: достаточно удалить join этой сущности из запросов, ведь таблица хранится независимо от других;
Минусы модели
- Большое количество таблиц и join’ов, сложность в оптимальной настройке запросов;
- Высокий порог входа для специалистов, сложность в понимании концепции и управления;
- Высокая нагрузка на базу данных даже для типовых запросов (будет рассмотрено ниже);
- Большое количество таблиц требует автоматизации процесса их создания и обновления (возможно с применением Python);
Dimensional Modeling
Плюсы модели
- Простая архитектура, низкий порог входа для специалистов;
- Высокая производительность в извлечении данных (будет рассмотрено ниже);
Минусы модели
- Низкая масштабируемость, затруднен процесс изменения структуры данных;
- Дублирование данных и null значения, что приводит к увеличению объема хранилища и сложности обновления данных;
Сравнительный анализ производительности Anchor Modeling и Dimensional Modeling
Для проведения анализа были выбраны следующие типовые запросы:
Стоит отметить, что в Якорном моделировании вся работа с таблицами происходит через представления, поскольку для анализа все таблицы нужно денормализовать в удобный вид
Запросы производились в тестовой среде с общим количеством записей в таблице факта «Чеки» ~2.5 миллиона. Для 2-го и 3-го запросов дополнительно использовались измерения Товары (26.3 тыс. строк), Магазины (32 строки), Группы товаров (983 строки).
Результаты работы запросов:
- Вывод всей таблицы факта «Чеки»
- Вывод отчёта за 3 месяца по магазинам для план/факт анализа
- Вывод отчета ABC анализа
Стоит отметить, что в Якорном моделировании вся работа с таблицами происходит через представления, поскольку для анализа все таблицы нужно денормализовать в удобный вид
Запросы производились в тестовой среде с общим количеством записей в таблице факта «Чеки» ~2.5 миллиона. Для 2-го и 3-го запросов дополнительно использовались измерения Товары (26.3 тыс. строк), Магазины (32 строки), Группы товаров (983 строки).
Результаты работы запросов:
Таблица 1 – сравнение времени выполнения
Таблица 2 – сравнение используемой памяти
Таблица 3 – сравнение чтения в байтах
Таблица 4 – сравнение чтения в мегабайтах
По всем параметрам в производительности в виду специфики схемы уступает Якорное моделирование.
Обе модели проходили тестирование в рамках схемы базы данных, обязательным требованием которой является поддержание историчности всех полей: измениться может как наименование товара, так и дата выдачи чека. Таким образом, в случае Якорного моделирования даже для вывода одного факта необходимо было предварительно сделать выборку актуальных данных (последнее обновление) из порядка 40 таблиц, только после чего можно было приступать к выводу основной таблицы фактов. Это создало высокую нагрузку и ухудшило производительность запросов по сравнению с Размерным моделированием.
Обе модели проходили тестирование в рамках схемы базы данных, обязательным требованием которой является поддержание историчности всех полей: измениться может как наименование товара, так и дата выдачи чека. Таким образом, в случае Якорного моделирования даже для вывода одного факта необходимо было предварительно сделать выборку актуальных данных (последнее обновление) из порядка 40 таблиц, только после чего можно было приступать к выводу основной таблицы фактов. Это создало высокую нагрузку и ухудшило производительность запросов по сравнению с Размерным моделированием.
Вывод
• Если требуется подробная информация о бизнес-процессах и гибкость моделирования, якорное моделирование — лучший выбор.
• Если необходима быстрая аналитика и простота реализации, модель на основе измерений — более подходящее решение.
• Если необходима быстрая аналитика и простота реализации, модель на основе измерений — более подходящее решение.
Таким образом, выбор между якорным моделированием и моделированием на основе измерений зависит от конкретных потребностей проекта и характеристик данных. Необходимо тщательно проанализировать оба варианта перед принятием решения о внедрении.