DWH

Data Warehouse (DWH) — это единое корпоративное хранилище архивных данных из разных источников. Цель Data Warehouse — обеспечить компанию возможностью принимать верные решения в ключе управления бизнесом на основе целостной информационной картины.

В DWH данные из всех СУБД предприятия аккумулируют и очищают, формируя их единый источник. Благодаря этому Data Warehouse содержит самую точную информацию обо всех аспектах деятельности предприятия за годы работы.

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

Однако возникает вопрос: зачем использовать для аналитики отдельное хранилище, а не анализировать данные в каждой СУБД по отдельности, ведь DWH — это тоже база данных?

Отличия DWH от транзакционной БД

Дело в том, что Data Warehouse и транзакционные БД — это разные типы баз данных. Хранилище предназначено для анализа данных, которые поступают в него с определённой периодичностью — например, ежечасно или ежедневно. Оно разворачивается поверх СУБД и способно быстро обрабатывать большие массивы данных, собранные за несколько лет. DWH фактически — инструмент для комплексного анализа данных из множества источников: по товарам, сделкам, персоналу, логистике и т. д.

СУБД в основном предназначены не для аналитики, а для повседневной работы. Информация в них обновляется в реальном времени. В основе CRM, ERP, 1C и многих других систем и программ лежит именно функциональность БД. Актуальные сведения поступают сначала в основные БД, а уже оттуда значимые данные пересылаются в DWH. Таким образом удаётся получить целостную информационную картину.

Архитектура Data Warehouse

Одна из моделей проектирования Data Warehouse — «слоеный пирог», построенный по архитектуре LSA, Layered Scalable Architecture.

Она реализует логическое деление структур с данными на несколько функциональных уровней:

Стейджинг (Primary Data Layer) — уровень, на котором подгружаются данные из внешних источников. Например, из таблиц, ERP-системы или биллинговой системы.
Ядро хранилища (Core Data Layer) — центральный уровень, который подгоняет данные к единым структурам и ключам. На этом слое обеспечивается целостность и качество данных.
Аналитические витрины (Data Mart Layer) — слой, который преобразует данные к структурам, удобным для анализа и использования в BI-дашбордах и других аналитических системах.
Сервисный слой (Service Layer) — уровень, на котором обеспечивается управление предыдущими слоями, мониторинг и диагностика ошибок.

Модели

Существует две модели, описывающие то, как должны быть устроены хранилища данных. Их идейные вдохновители — Билл Инмон, «отец хранилищ данных», и Ральф Кимбалл, идейный лидер в области хранилищ многомерных данных.

По модели Инмона (Inmon) данные из источников должны поступать в хранилище сразу после процесса ETL.

Преимущества/недостатки подхода Инмона

Преимущества подхода Инмона

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

Недостатки подхода Инмона

Сложность увеличивается со временем по мере добавления нескольких таблиц в модель данных.
Требуются разработчики, обладающие навыками моделирования и проектирования хранилищ данных, которые могут быть дорогими и недоступными на рынке труда.
Первичная разработка и ввод в эксплуатацию занимают много времени.
Требуется дополнительная операция ETL, поскольку витрины данных создаются после создания хранилища данных.
Этот подход требует от экспертов эффективного управления хранилищем данных.

По модели Кимбалла (Kimball) после процесса ETL данные загружаются в витрины данных, а объединение витрин создает концептуальное (а не фактическое) хранилище данных.

Преимущества/недостатки подхода Кимбалла

Преимущества подхода Кимбалла

Kimball dimensional modeling позволяет быстро реализовывать хранилища данных поскольку не требуется нормализация данных, что позволяет быстро выполнять начальные фазы процесса проектирования хранилища данных.
Преимущество звездообразной схемы состоит в том, что большинство операторов данных могут легко понять ее из-за ее денормализованной структуры, которая упрощает запросы и анализ.
Площадь системы хранилища данных тривиальна, поскольку она ориентирована на отдельные области бизнеса и процессы, а не на все предприятие. Таким образом, хранилище занимает меньше места в базе данных, что упрощает управление системой.
Это позволяет быстро извлекать данные из хранилища данных, поскольку данные разделяются на таблицы фактов и измерения. Например, таблица фактов и измерений для страховой отрасли будет включать транзакции по полисам и транзакции по претензиям.
Для управления хранилищем данных достаточно небольшой группы проектировщиков и разработчиков, поскольку системы источников данных стабильны, а хранилище данных ориентировано на процессы. Кроме того, оптимизация запросов проста, предсказуема и управляема.
Согласованная структура измерений для data quality framework. Подход Кимбалла также называют подходом к образу жизни, измеряющим бизнес, потому что он позволяет инструментам business intelligence глубже проникать в несколько звездообразных схем и дает надежную информацию.

Недостатки подхода Кимбалла

Данные не полностью интегрированы до создания отчетности, идея «единого источника правды» потеряна.
При обновлении данных в архитектуре Kimball DWH могут возникать не точные данные. Это связано с тем, что при использовании техник денормализации хранилища данных избыточные данные добавляются в таблицы базы данных.
В архитектуре Kimball DWH проблемы с производительностью могут возникать из-за добавления столбцов в таблицу фактов, поскольку эти таблицы содержат довольно подробные сведения. Добавление новых столбцов может расширить размерность таблицы фактов, что повлияет на ее производительность (т.е. увеличится детализация хранилища данных). Кроме того, модель многомерного хранилища данных становится трудно изменить при любых изменениях потребностей бизнеса.
Поскольку модель Кимбалла ориентирована на бизнес-процессы, вместо того, чтобы сосредоточиться на предприятии в целом, она не может удовлетворить все требования к отчетности бизнес-аналитики.
Процесс включения больших объемов устаревших данных в хранилище данных сложен.

От выбора двух подходов будет зависеть исходный результат. Представим хранилище в виде картотеки — библиотечного шкафа с карточками, в котором хранятся данные.

По Инмону мы сначала берем 10 карточек, выписываем из них самое важное на листочек и кладем в шкаф. Подобный подход используют в страховании. Сначала формируют общую картинку о всех застрахованных, собирают данные о доходе, возрасте, хронических болезнях, распространении определенных болезней в регионе, демографии, авариях на дорогах и пр. Все аспекты взаимосвязаны, поэтому сначала собираются все возможные данные, а после фильтруются и ложатся в основу модели.
По Кимбаллу мы начинаем с нескольких ящиков (витрин данных), а потом решаем, что сложить в общий шкаф. Такой подход используют, например, в маркетинге: чтобы анализировать рекламные кампании не нужно знать абсолютно все, к метрикам нужно подходить выборочно.

При создании DWH также следует учитывать и специфику данных, взаимосвязи внутри групп данных, связи между ними, типы преобразования данных, частоту обновления, взаимосвязь между объектами хранилища, процессы передачи, резервного копирования, восстановления.

Источник:

PreviousETL NextDWH vs Data Lake vs Data Mart

Last updated 12 months ago