Архитектура хранения данных в OLAP

~ 35 минут
Архитектура хранилищ данных отнесена в архитектуре систем предприятия в отдельный блок по ряду причин.
  • Она выполняет роль хранения и обработки данных для решения аналитических задач не только техническими, но и бизнес-пользователями.
  • Обрабатываемые массивы данных для аналитических задач существенно больше тех массивов данных, с которыми могут справиться транзакционные системы.
  • Характер задач обуславливает и другие принципы моделирования структур данных в хранилище.
Архитектура хранилищ данных, которые работают с транзакционными приложениями, отличается от других. Сегодня разберёмся, на что нужно обратить внимание при её проектировании.

Архитектура хранения данных

Сразу напомним два понятия, которые пригодятся вам в уроке.
✏️ Нормализация — метод уменьшения избыточности и несогласованности данных в таблице базы данных, он реализуется через приведение структуры данных к нормальным формам.
При повышении нормальной формы — приведении структуры к более строгим требованиям — количество таблиц увеличивается, а не уменьшается.
✏️ Денормализация — метод проектирования схем баз данных, при котором намеренно увеличивается избыточность данных.
Часто используется в OLAP-архитектурах, поскольку увеличивает скорость выполнения запроса. Денормализация уменьшает количество таблиц.
Когда-то давно, лет 40–50 назад, компьютеры работали существенно медленнее, чем сейчас. И выполнять анализ непосредственно в рабочей базе данных было долго и дорого в плане затрат вычислительных ресурсов. Ещё это мешало выполнять операционные задачи баз данных, а для этого они и предназначались. Уже в те времена стало очевидным, что правильнее проектировать отдельный класс архитектур для обработки данных по принципам OLAP.
Поэтому разработчики придумали отдельные хранилища, в которые загружали данные для анализа. Эти системы хранили в предварительно агрегированные данные в виде OLAP-кубов. OLAP-кубы — это лишь один из вариантов для архитектуры структур данных современных хранилищ.
✏️ В проектировании хранилищ особо важна архитектура проектирования структур данных и их слоёв. Эти структуры несут основную операционную нагрузку в хранилище.
OLAP-архитектура используется для задач аналитики данных, а значит, должна иметь совершенно другие подходы к проектированию структуры сущностей, разработан ряд стандартных моделей для архитектуры OLAP, которые вы рассмотрите в этом уроке.
Подходов к проектированию слоя данных в хранилище много. Самые популярные — созданные ещё в 1990-е модели Билла Инмона и Ральфа Кимбалла. И хотя за это время появились новые архитектуры, например DataValut, Anchor и другие, они до сих пор актуальны.
В мире OLTP превалируют модели данных, которые спроектированы с учётом нормализации структур данных. Самый широко используемый случай — это третья нормальная форма.

Модель Инмона

Для этой модели характерен подход сверху вниз. Хранилище данных строится как централизованный корпоративный репозиторий с нормализованной структурой (3NF). Оно является единым источником правды, а для анализа данных создаются специализированные витрины данных (Data Marts).
Чтобы минимизировать избыточность используется высокая степень нормализации. А фокус этой модели — на долгосрочной устойчивости и масштабируемости.
В модели Инмона слой представления данных, который используется для аналитики, часто проектируется с использованием архитектуры, схожей с архитектурой «Снежинка».
Модель Инмона хорошо подходит для предприятий с медленно изменяющейся структурой процессов и данных. Но стоит учитывать долгий процесс внедрения и сложности в начальном проектировании.

Модель Кимбалла

Эта модель, напротив, использует подход снизу вверх. Хранилище данных проектируется как совокупность витрин данных , которые объединяются для формирования интегрированной структуры. Данные обычно хранятся в денормализованной форме (звёздная схема).
Слой представления фактически является хранилищем данных. Спроектировать и запустить модель Кимбалла проще. Она хорошо подходит для оптимизации аналитических запросов. Конечные пользователи получают данные в упрощённом виде.
Такой восходящий подход — от низших слоёв к высшим, где более высокие слои укрупняют сущности, — хорошо адаптируется к бизнес-логике. Однако при использовании в крупных организациях могут возникнуть сложности, связанные с масштабированием и избыточностью данных.
Когда проектируют «от витрин», важно быстро получить слой, которым могут пользоваться конечные пользователи, сделать широкие таблицы, основанные на модели измерений. Например, когда компании нужна управленческая отчётность по какому-то аспекту деятельности компании, проектируют целевую широкую витрину исходя из требований бизнеса.

Модель Data Vault

Эта модель и её развитие — Anchor, или якорная модель, — разработаны для гибкости при изменении структуры данных и интеграции новых источников. Они, в отличие от моделей Инмона и Кимбалла, ориентированы на быстрое изменение структур.Они, в отличие от моделей Инмона и Кимбалла, ориентированы на быстрое изменение структур.
Data Vault сочетает элементы 3NF и «Звезды». В результате получается гибкое и масштабируемое решение.
Основные компоненты модели:
  • Hub — бизнес-ключи сущностей.
  • Satellite — хранят атрибуты сущностей.
  • Link — определяют отношения между Hub.
Эта модель хорошо подходит для крупных проектов, в которых проектирование и модернизация схемы данных выполняются в Agile-стиле.
Вот как соотносятся числа сущностей в разных архитектурах данных:
Для хранения данных нужны таблицы измерений и фактов. Они работают вместе, но выполняют разные функции — сейчас разберёмся.

Как выбрать модель?

Выбор делается до фактического старта работ по реализации хранилища. В качестве критериев выбора архитектуры хранилищ вы можете учитывать несколько факторов.
  • Связность данных между IT-системами или организационными единицами предприятия. Выбор модели данных зависит от того, нужно ли развязать эти связи.
  • Срочность внедрения хранилища (некоторые архитектуры сложны в проектировании, и это может влиять на выбор архитектуры).
  • Характер пользовательских задач. То, как пользователи будут использовать данные хранилища витрины, напрямую влияет на архитектуру.
  • Ограниченность ресурсов. Этот фактор влияет на возможность избыточности данных.

Таблицы фактов и таблицы измерений

Давайте разберёмся со структурами данных, которыми оперирует модель Кимбалла, это так называемое размерное проектирование, основанное на схемах «Звезда» и «Снежинка» для организации данных интуитивно понятным способом и более рациональным для написания запросов и создания отчётов.
Схема «Звезда» представляет собой простую структуру данных, в которой одна центральная таблица фактов окружена таблицами измерений. Таблица фактов содержит ключевые числовые показатели, такие как доход или количество продаж, а таблицы измерений описывают контекст этих показателей, например дату, продукт или клиента. Эта схема популярна в аналитике, потому что она понятна и удобна для написания запросов. Но её основной недостаток заключается в возможном дублировании данных в измерениях, что увеличивает объём хранения.
Схема «Снежинка» — более сложный вариант. Здесь таблицы измерений нормализованы, то есть разделены на более мелкие таблицы. Например, вместо одной таблицы «Продукт» может быть несколько связанных таблиц, таких как «Продукт» и «Категория продукта». Это уменьшает дублирование данных и экономит место в базе данных. Но сложность запросов возрастает из-за необходимости соединять большее количество таблиц. Это тоже может сказаться на производительности.
✏️ Схема «Звезда» предпочтительна для простоты и быстроты анализа, тогда как схема «Снежинка» больше подходит для оптимизации хранения данных и повышения их целостности.

Таблица фактов

Отражает бизнес-процесс — запись в таблице представляет бизнес-событие. Так что при моделировании нужно выделить бизнес-процессы — они определят таблицы фактов.
Спроектировать таблицы фактов можно для продаж, кликстрима на сайте, производственного заказа и других бизнес-процессов.

Таблица измерений

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

Срезы

Срезы — ещё один способ представления данных в OLAP-системах, применяемый к многомерным кубам. Срезом называют выборку данных из OLAP-куба, основанную на одном или нескольких измерениях.

OLAP: требования к производительности

Когда говорят о скорости, обычно формируются ожидания о времени выполнения процесса. Это также применимо к выполнению запросов в OLAP.
OLAP-запросы — аналитические запросы, которые включают агрегацию больших объёмов данных и выборку большого количества связанных данных. В некоторых моделях (например, в модели Кимбалла) предусматривается денормализация данных и их представление в витринах, с которыми работают конечные пользователи. Данные в витринах часто представлены в виде широких таблиц.
Использование широких таблиц в аналитических хранилищах может существенно ускорить выполнение аналитических запросов — запросы в этом случае работают с одной таблицей базы данных.
Для оценки качества работы базы данных с запросами пользователей рекомендуется использовать метрику, измеряющую время выполнения запросов. Это ключевой показатель эффективности базы данных и корректности проектирования модели.
Итак, четыре фактора, влияющие на производительность OLAP:
  • Инфраструктура — достаточное количество ресурсов для размещения данных и выполнения вычислений над ними.
  • Модель данных хранилища влияет на способ написания запросов на выборку данных — значит, и на скорость работы запросов.
  • Индексация. В OLAP-хранилищах также существуют вспомогательные структуры — индексы. Их использование может ускорить выборку данных.
  • Мониторинг медленных запросов и их проактивная оптимизация помогут существенно ускорить работу хранилища и найти ошибки в проектировании.
Для OLAP лучше всего подходят колоночные базы данных. В их особенностях сейчас и разберёмся.

Сценарии использования

Хранилища данных предназначены для решения аналитических задач, к которым относятся задачи BI-аналитики данных с дальнейшим представлением результатов аналитики в виде отчётов и ML. В таких задачах процессы машинного обучения нуждаются в массивах исторических данных для построения более точных моделей.
Многие задачи из сфер BI и ML нужно хранилище данных.

BI-аналитика

В сфере BI это могут быть управленческая отчётность, разработка новых стратегий в продажах, маркетинге, анализ эффективности рекламных кампаний или анализ удовлетворённости клиентов компании.
Пример
Представьте сеть кафе с десятками филиалов по всей стране. Руководству нужно понимать, как работают отдельные точки, какие блюда продаются лучше всего, где накапливаются излишки продуктов, а где, наоборот, всё распродаётся слишком быстро. Раньше анализ был хаотичным: данные собирали вручную из разных систем, отчёты запаздывали, а проблемы часто обнаруживали слишком поздно.
Решением стало внедрение хранилища данных. Теперь все данные из касс, системы учёта продуктов, CRM и таблиц с графиками сотрудников собираются в одном месте. Благодаря этому аналитики создают дашборды, где руководители видят ежедневные отчёты по продажам, выручке, остаткам продуктов и загруженности персонала. Например, выявили, что один из филиалов списывает слишком много продуктов. Разобрались: поставки происходили реже, чем нужно, и продукты просто портились. Исправили график заказов, и убытки сразу снизились.
Ещё один важный инсайт, полученный благодаря хранилищу, — анализ популярности блюд по регионам. В южных филиалах хорошо продаются прохладительные напитки, а на севере — горячие супы. Это помогло адаптировать меню под вкусы клиентов и увеличить продажи. Хранилище данных превратило разрозненные цифры в понятную картину, которая помогает принимать решения быстро и с пользой для бизнеса.

ML-процессы

В сфере ML хранилище данных может выступать источником данных для прогнозных и рекомендательных систем или источником данных для Feature Store (Хранилище признаков).
Пример
Интернет-магазин электроники столкнулся с типичной проблемой: клиенты просматривают товары на сайте, но часто уходят без покупки. Чтобы исправить это, компания решила использовать персонализированные рекомендации.
Все данные о поведении клиентов собираются в хранилище: какие товары они искали, что добавляли в корзину, какие страницы чаще всего просматривали. Например, если кто-то искал ноутбук, то логично предложить ему ещё и аксессуары: сумку, мышь, подставку. На основе этих данных разработали модель машинного обучения, которая подсказывает каждому клиенту те товары, которые ему интересны.
Результаты впечатляют. Теперь, заходя на сайт, покупатели сразу видят рекомендации, которые совпадают с их интересами. Если клиент выбирал смартфон, ему предлагают чехлы, защитные стёкла и зарядные устройства. Благодаря этому средний чек вырос, а повторные покупки увеличились — людям начали напоминать о том, что пора обновить картридж для принтера или продлить гарантию на технику.
Персонализация сделала процесс покупки более удобным, а хранилище данных обеспечило всю необходимую информацию для создания таких точных рекомендаций.

Колоночные базы данных

Колоночные, или столбчатые, базы данных сегодня набирают всё большую популярность по сравнению с базами данных, где информация хранится построчно. Такой способ организации хранилищ удобен для обработки больших наборов данных, особенно в аналитических целях и в контексте хранилищ данных.
Ключевые преимущества столбчатых баз данных:
  1. Сжатие данных: данные одного типа в столбцах эффективно сжимаются, экономя место и ускоряя обработку.
  2. Быстрые запросы: считываются только нужные столбцы, что значительно ускоряет аналитические запросы.
  3. Кеширование: данные удобно размещаются в кэше процессора, уменьшая задержки.
  4. Параллельная обработка: столбцы обрабатываются векторизованно и параллельно, увеличивая скорость вычислений.
  5. Эффективная аналитика: данные оптимизированы для сложных агрегаций и отчётов.
  6. Работа с разреженными данными: снижает хранение пустых значений, экономя ресурсы.
  7. Индексация по отдельным столбцам.
  8. Масштабируемость: легко добавлять новые узлы без потери производительности.
  9. Реальное время: позволяют обновлять данные и проводить аналитику одновременно.
Как мы уже сказали, колоночно ориентированные хранилища в OLAP позволяют значительно ускорить выполнение аналитических запросов. При этом важно учитывать:
  • Особенности внутреннего представления и хранения данных.
  • Влияние этого способа хранения данных на запись и чтение данных.
  • Способы ускорения поиска данных для OLAP-задач.
  • Особенности распределённых хранилищ.

Архитектура колоночных хранилищ

Данные в колоночных базах хранятся по колонкам. На уровне физического хранения таблица сохраняется в виде последовательности колонок: сначала первая колонка и её значения, затем вторая и так далее. Данные хранятся «вертикально» — если представить данные в виде таблицы, то сначала выделяется и сохраняется на диск одна колонка и сохраняется на диск, затем соседняя выделяется и сохраняется непосредственно за предыдущей.
Этот способ хранения позволяет быстро выполнять аналитические функции (например, агрегацию в большом объёме данных). Для расчёта агрегатов задействуются только нужные для расчётов колонки. Для OLAP такой подход увеличивает скорость выполнения запросов и снижает требования к ресурсам.
Функции агрегации часто сопровождаются функциями поиска — фильтрации данных. Фильтрация нужна, чтобы расчёт агрегата выполнялся только для определённого подмножества данных в соответствии с бизнес-логикой.
Операции поиска в базе данных связаны с чтением данных из дискового хранилища. В OLAP и колоночных хранилищах данные разбиваются на разделы — партиции — или шарды. При выполнении выборки данных — как с агрегацией, так и без — необходимо указывать, из какой партиции или шарда нужно выбрать данные. Это существенно ускоряет выборку данных и их фильтрацию по критериям.

Принципы разделения таблиц на партиции

  • В запросе на выборку данных — SELECT — не должно участвовать много разделов. Если проектирование партиций приводит к тому, что запрос затрагивает большое количество разделов, то преимущества разделения данных на партиции минимальны.
  • Количество разделов в таблице должно измеряться десятками или сотнями — не тысячами.
  • Операция INSERT должна вставлять данные в один или несколько разделов — лучше в один.

Виды архитектур для колоночных баз данных

Для реализации распределённых архитектур колоночных баз данных используются:
  • MPP — Massive Parallel Processing. Архитектура таких баз данных предполагает параллельное выполнение SQL-запросов на множестве самостоятельных узлов. Каждый узел в такой системе представляет собой отдельный инстанс базы данных, работающий автономно. Некоторые колоночные СУБД используют архитектуры: Greenplum, Vertica, Clickhouse.
  • MapReduce — архитектуры на базе этой модели распределённых вычислений используют другие принципы обработки данных. Суть метода заключается в двух операциях: Map и Reduce. Процесс вычисления начинается с разделения данных, над которыми будут проводиться вычисления, между несколькими машинами в распределённой среде. Затем на каждой машине выполняются вычисления и результаты объединяются с помощью операции Reduce. На базе этой технологии построено множество вычислительных фреймворков — например, Apache Hadoop.
  • Apache Spark. Этот фреймворк часто называют развитием MapReduce, но Spark не является СУБД. Это платформа для распределённых вычислений, предназначенная для работы с большими объёмами данных в хранилищах.

Облачные колоночные хранилища

Облачные провайдеры сервисов предоставляют как управляемый сервис аналитические колоночные хранилища данных, способные и предназначенные для обработки OLAP-нагрузки.
На российском рынке основной предлагаемой базой данных является СУБД ClickHouse, изначально разработанная Яндексом. Аналоги на международном рынке: Amazon Redshift, Google BigQuery, Azure Synapse Analytics.
Вот три преимущества облачных колоночных хранилищ:
  • Возможность расширения мощности и дискового пространства по запросу.
  • Обеспечение высокой доступности провайдером.
  • Облегчённая интеграция с другими сервисами провайдера, которые дополняют функции СУБД. Например, использование DataLens в качестве BI-системы в комбинации с Clickhouse.

Задание 1

Компания продаёт товары через онлайн-платформу и использует хранилище данных для аналитики. Архитектура данных включает таблицу фактов, которая фиксирует каждую продажу, и несколько таблиц измерений с дополнительными данными — информацию о клиенте, категории товара и географическом местоположении.
Во время выполнения аналитического запроса вы заметили, что отчёт формируется медленно из-за большого объёма данных. Какое из следующих решений может ускорить запрос?

Задание 2

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

Задание 3

Вам нужно выполнить агрегацию данных по сумме продаж за месяц. Как колонковая база данных оптимизирует этот запрос? Выберите одно самое важное преимущество.

Итоги

  • В проектировании хранилищ особо важна архитектура проектирования структур данных и их слоёв. Эти структуры несут основную операционную нагрузку в хранилище. Подходов к проектированию слоя данных в хранилище много. Популярные — модели Билла Инмона, Ральфа Кимбалла, DataValut, Anchor.
  • Для хранения данных нужны таблицы измерений и фактов. Они работают вместе, но выполняют разные функции. Первые отражают бизнес-процессы — запись в таблице представляет бизнес-событие. Вторые предоставляют контекстную информацию, дополняют данные в таблицах фактов и уточняют бизнес-процессы. Также используют срезы — ещё один способ представления данных в OLAP-системах. Это выборка данных из OLAP-куба, основанная на одном или нескольких измерениях.
  • Для OLAP лучше всего подходят колоночные базы данных — данные в них хранятся по колонкам. Колоночные базы позволяют значительно ускорить выполнение аналитических запросов, потому что задействуются только нужные колонки. Операции поиска в базе связаны с чтением данных из дискового хранилища. В OLAP и колоночных хранилищах данные разбиваются на разделы — партиции — или шарды.
  • Для реализации распределённых архитектур колоночных баз данных используются: MPP — Massive Parallel Processing, MapReduce и Apache Spark. Можно использовать облачные колоночные хранилища: ClickHouse, Amazon Redshift, Google BigQuery, Azure Synapse Analytics. С ними можно расширить мощность и дисковое пространство, а ещё интегрировать хранилище с другими сервисами провайдера.