В вычислительной технике хранилище данных ( DW или DWH ), также известное как корпоративное хранилище данных ( EDW ), представляет собой систему, используемую для отчетности и анализа данных , и является основным компонентом бизнес-аналитики . [1] Хранилища данных представляют собой центральные репозитории данных, интегрированных из разрозненных источников. Они хранят текущие и исторические данные, организованные таким образом, чтобы было легко создавать отчеты, запрашивать и получать информацию из данных. [2] В отличие от баз данных, они предназначены для использования аналитиками и менеджерами для принятия организационных решений. [3]
Данные, хранящиеся в хранилище, загружаются из операционных систем (таких как маркетинг или продажи). Данные могут проходить через операционное хранилище данных и могут потребовать очистки данных для дополнительных операций, чтобы гарантировать качество данных, прежде чем они будут использованы в хранилище данных для отчетности.
Двумя основными подходами к построению системы хранилища данных являются извлечение, преобразование, загрузка (ETL) и извлечение, загрузка, преобразование (ELT).
Среда для хранилищ и витрин данных включает в себя следующее:
Операционные базы данных оптимизированы для сохранения целостности данных и скорости записи бизнес-транзакций за счет использования нормализации базы данных и модели «сущность-связь» . Проектировщики операционных систем обычно следуют 12 правилам нормализации базы данных Кодда для обеспечения целостности данных. Полностью нормализованные проекты баз данных (то есть удовлетворяющие всем правилам Кодда) часто приводят к тому, что информация из бизнес-транзакции хранится в десятках или сотнях таблиц. Реляционные базы данных эффективны в управлении связями между этими таблицами. Базы данных имеют очень высокую производительность вставки/обновления, поскольку каждая транзакция затрагивает только небольшой объем данных в этих таблицах. Для повышения производительности старые данные периодически очищаются.
Хранилища данных оптимизированы для аналитических шаблонов доступа, которые обычно включают выбор определенных полей, а не всех полей, как это принято в операционных базах данных. Из-за этих различий в доступе операционные базы данных (в широком смысле, OLTP) выигрывают от использования системы управления базами данных, ориентированной на строки (СУБД), тогда как аналитические базы данных (в широком смысле, OLAP) выигрывают от использования СУБД, ориентированной на столбцы . Операционные системы поддерживают снимок бизнеса, в то время как хранилища поддерживают исторические данные через процессы ETL, которые периодически переносят данные из операционных систем в хранилище.
Онлайн-аналитическая обработка (OLAP) характеризуется низкой скоростью транзакций и сложными запросами, включающими агрегации. Время отклика является эффективным показателем производительности систем OLAP. Приложения OLAP широко используются для интеллектуального анализа данных . Базы данных OLAP хранят агрегированные исторические данные в многомерных схемах (обычно звездообразных схемах ). Системы OLAP обычно имеют задержку данных в несколько часов, в то время как задержка витрин данных ближе к одному дню. Подход OLAP используется для анализа многомерных данных из нескольких источников и точек зрения. Три основные операции в OLAP — это свертывание (консолидация), детализация и нарезка.
Онлайн-обработка транзакций (OLTP) характеризуется большим количеством коротких онлайн-транзакций (INSERT, UPDATE, DELETE). Системы OLTP делают упор на быструю обработку запросов и поддержание целостности данных в средах с множественным доступом. Для систем OLTP производительность — это количество транзакций в секунду. Базы данных OLTP содержат подробные и актуальные данные. Схемой, используемой для хранения транзакционных баз данных, является модель сущностей (обычно 3NF ). [4] Нормализация является нормой для методов моделирования данных в этой системе.
Предиктивная аналитика занимается поиском и количественной оценкой скрытых закономерностей в данных с использованием сложных математических моделей и прогнозированием будущих результатов. Напротив, OLAP фокусируется на анализе исторических данных и является реактивной. Предиктивные системы также используются для управления взаимоотношениями с клиентами (CRM).
Витрина данных — это простое хранилище данных, ориентированное на одну тему или функциональную область. Поэтому оно черпает данные из ограниченного числа источников, таких как продажи, финансы или маркетинг. Витрины данных часто создаются и контролируются одним отделом в организации. Источниками могут быть внутренние операционные системы, центральное хранилище данных или внешние данные. [5] Как и в случае со хранилищами, хранимые данные обычно не нормализуются.
Типы витрин данных включают зависимые , независимые и гибридные витрины данных. [ необходимо разъяснение ]
Типичное хранилище данных на основе извлечения, преобразования, загрузки (ETL) использует уровни подготовки , интеграции данных и доступа для размещения своих ключевых функций. Уровень подготовки или база данных подготовки хранит необработанные данные, извлеченные из каждой из разнородных систем исходных данных. Уровень интеграции интегрирует разнородные наборы данных путем преобразования данных из уровня подготовки, часто сохраняя эти преобразованные данные в базе данных оперативного хранилища данных (ODS). Затем интегрированные данные перемещаются в еще одну базу данных, часто называемую базой данных хранилища данных, где данные организованы в иерархические группы, часто называемые измерениями, а также в факты и агрегированные факты. Комбинацию фактов и измерений иногда называют схемой звезды . Уровень доступа помогает пользователям извлекать данные. [6]
Основной источник данных очищается , преобразуется, каталогизируется и предоставляется для использования менеджерами и другими бизнес-профессионалами для добычи данных , онлайн-аналитической обработки , маркетинговых исследований и поддержки принятия решений . [7] Однако средства для извлечения и анализа данных, для извлечения, преобразования и загрузки данных, а также для управления словарем данных также считаются важными компонентами системы хранения данных. Многие ссылки на хранилище данных используют этот более широкий контекст. Таким образом, расширенное определение хранилища данных включает инструменты бизнес-аналитики , инструменты для извлечения, преобразования и загрузки данных в репозиторий, а также инструменты для управления и извлечения метаданных .
Хранилище данных на основе ELT избавляется от отдельного инструмента ETL для преобразования данных. Вместо этого оно поддерживает промежуточную область внутри самого хранилища данных. При таком подходе данные извлекаются из гетерогенных исходных систем и затем напрямую загружаются в хранилище данных, прежде чем произойдет какое-либо преобразование. Затем все необходимые преобразования обрабатываются внутри самого хранилища данных. Наконец, обработанные данные загружаются в целевые таблицы в том же хранилище данных.
Хранилище данных поддерживает копию информации из исходных систем транзакций. Эта архитектурная сложность обеспечивает возможность:
Концепция хранилищ данных восходит к концу 1980-х годов [8] , когда исследователи IBM Барри Девлин и Пол Мерфи разработали «хранилище бизнес-данных». По сути, концепция хранилищ данных была призвана предоставить архитектурную модель для потока данных из операционных систем в среды поддержки принятия решений . Концепция пыталась решить различные проблемы, связанные с этим потоком, в основном связанные с высокими затратами. При отсутствии архитектуры хранилищ данных требовалось огромное количество избыточности для поддержки нескольких сред поддержки принятия решений. В крупных корпорациях было типично, что несколько сред поддержки принятия решений работали независимо. Хотя каждая среда обслуживала разных пользователей, им часто требовалась большая часть одних и тех же хранимых данных. Процесс сбора, очистки и интеграции данных из различных источников, как правило, из давно существующих операционных систем (обычно называемых унаследованными системами ), как правило, частично реплицировался для каждой среды. Более того, операционные системы часто пересматривались по мере появления новых требований к поддержке принятия решений. Часто новые требования требовали сбора, очистки и интеграции новых данных из « киосков данных », которые были специально разработаны для быстрого доступа пользователей.
Кроме того, с публикацией книги The IRM Imperative (Wiley & Sons, 1991) Джеймса М. Керра, идея управления и присвоения долларовой стоимости ресурсам данных организации, а затем представления этой стоимости в качестве актива в балансе стала популярной. В книге Керр описал способ заполнения предметных баз данных данными, полученными из систем, управляемых транзакциями, для создания области хранения, где сводные данные могли бы быть дополнительно использованы для информирования руководителей о принятии решений. Эта концепция способствовала дальнейшему размышлению о том, как хранилище данных может быть разработано и управляемо на практике в рамках любого предприятия.
Ключевые события первых лет развития хранилищ данных:
Факт — это значение или измерение в управляемой системе.
Необработанные факты — это те, которые сообщает субъект, предоставляющий отчет. Например, в системе мобильной телефонной связи, если базовая приемопередающая станция (BTS) получает 1000 запросов на выделение канала трафика, выделяет 820 и отклоняет остальные, она может сообщить системе управления три факта:
tch_req_total = 1000tch_req_success = 820tch_req_fail = 180Необработанные факты агрегируются на более высоких уровнях в различных измерениях для извлечения информации, более релевантной для сервиса или бизнеса. Это называется агрегированными фактами или резюме.
Например, если в городе три BTS, то приведенные выше факты можно объединить на уровне города в сетевом измерении. Например:
tch_req_success_city = tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3avg_tch_req_success_city = (tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3) / 3Два наиболее важных подхода к хранению данных в хранилище — размерный и нормализованный. Размерный подход использует схему «звезда» , предложенную Ральфом Кимбаллом . Нормализованный подход, также называемый третьей нормальной формой (3NF), представляет собой нормализованную модель сущностей-отношений, предложенную Биллом Инмоном. [22]
В размерном подходе данные о транзакциях разделяются на «факты», которые обычно являются числовыми данными о транзакциях, и « измерения », которые являются справочной информацией, дающей контекст фактам. Например, транзакция продажи может быть разбита на факты, такие как количество заказанных продуктов и общая цена, уплаченная за продукты, и на измерения, такие как дата заказа, имя клиента, номер продукта, место доставки заказа и место выставления счета, а также продавец, ответственный за получение заказа.
Этот размерный подход упрощает понимание данных и ускоряет их извлечение. [16] Размерные структуры просты для понимания бизнес-пользователями, поскольку структура разделена на измерения/факты и контекст/измерения. Факты связаны с бизнес-процессами организации и операционной системой, а измерения являются контекстом о них (Kimball, Ralph 2008). Еще одним преимуществом является то, что размерная модель не включает в себя реляционную базу данных каждый раз. Таким образом, этот тип метода моделирования очень полезен для запросов конечных пользователей в хранилище данных.
Модель фактов и измерений можно также понимать как куб данных , [23] где измерения — это категориальные координаты в многомерном кубе, факт — это значение, соответствующее координатам.
Основными недостатками размерного подхода являются:
В нормализованном подходе данные в хранилище хранятся в соответствии с, в некоторой степени, правилами нормализации базы данных . Нормализованные реляционные таблицы базы данных группируются в предметные области (например, клиенты, продукты и финансы). При использовании на крупных предприятиях результатом являются десятки таблиц, связанных сетью соединений. (Kimball, Ralph 2008).
Главное преимущество этого подхода заключается в том, что добавлять информацию в базу данных просто. К недостаткам можно отнести то, что из-за большого количества таблиц пользователям может быть сложно объединять данные из разных источников в осмысленную информацию и получать доступ к информации без точного понимания источников данных и структуры данных хранилища данных.
Как нормализованные, так и размерные модели могут быть представлены в диаграммах сущности-связи, поскольку обе содержат соединенные реляционные таблицы. Разница между ними заключается в степени нормализации. Эти подходы не являются взаимоисключающими, и существуют другие подходы. Размерные подходы могут включать нормализацию данных в определенной степени (Kimball, Ralph 2008).
В Information-Driven Business [ 24] Роберт Хиллард сравнивает два подхода, основанных на информационных потребностях бизнес-задачи. Он приходит к выводу, что нормализованные модели содержат гораздо больше информации, чем их размерные эквиваленты (даже когда в обеих моделях используются одни и те же поля), но за счет удобства использования. Методика измеряет количество информации с точки зрения информационной энтропии и удобства использования с точки зрения меры преобразования данных Small Worlds. [25]
В подходе снизу вверх витрины данных сначала создаются для предоставления возможностей отчетности и анализа для определенных бизнес-процессов . Затем эти витрины данных могут быть интегрированы для создания комплексного хранилища данных. Архитектура шины хранилища данных в первую очередь представляет собой реализацию «шины», набора согласованных измерений и согласованных фактов, которые являются измерениями, которые совместно используются (определенным образом) между фактами в двух или более витринах данных. [26]
Подход сверху вниз разработан с использованием нормализованной модели корпоративных данных . «Атомарные» данные , то есть данные с наивысшим уровнем детализации, хранятся в хранилище данных. Из хранилища данных создаются витрины размерных данных, содержащие данные, необходимые для конкретных бизнес-процессов или конкретных отделов. [27]
Хранилища данных часто напоминают архитектуру концентратора и спиц . Устаревшие системы, питающие хранилище, часто включают управление взаимоотношениями с клиентами и планирование ресурсов предприятия , генерируя большие объемы данных. Для консолидации этих различных моделей данных и облегчения процесса извлечения , преобразования и загрузки хранилища данных часто используют операционное хранилище данных , информация из которого анализируется в фактическое хранилище данных. Чтобы уменьшить избыточность данных, более крупные системы часто хранят данные в нормализованном виде. Затем на основе хранилища данных можно построить витрины данных для конкретных отчетов.
Гибридная (также называемая ансамблевой) база данных хранилища данных хранится в третьей нормальной форме для устранения избыточности данных . Однако обычная реляционная база данных неэффективна для отчетов бизнес-аналитики, где преобладает многомерное моделирование. Небольшие витрины данных могут закупать данные из консолидированного хранилища и использовать отфильтрованные, конкретные данные для требуемых таблиц фактов и измерений. Хранилище данных предоставляет единый источник информации, из которого витрины данных могут считывать, предоставляя широкий спектр деловой информации. Гибридная архитектура позволяет заменить хранилище данных на основной репозиторий управления данными , где может находиться операционная (не статическая) информация.
Компоненты моделирования хранилища данных следуют архитектуре концентратора и спиц. Этот стиль моделирования представляет собой гибридную конструкцию, состоящую из лучших практик как из третьей нормальной формы, так и из схемы «звезда» . Модель хранилища данных не является истинной третьей нормальной формой и нарушает некоторые из ее правил, но это архитектура сверху вниз с дизайном снизу вверх. Модель хранилища данных предназначена исключительно для хранилища данных. Она не предназначена для доступа конечного пользователя, что при ее создании все еще требует использования витрины данных или области выпуска на основе схемы «звезда» для бизнес-целей.
Существуют основные характеристики, определяющие данные в хранилище данных, в том числе предметная ориентация, интеграция данных, изменчивость во времени, энергонезависимость данных и гранулярность данных.
В отличие от операционных систем, данные в хранилище данных вращаются вокруг субъектов предприятия. Ориентация на субъект — это не нормализация базы данных . Ориентация на субъект может быть действительно полезна для принятия решений. Сбор требуемых объектов называется предметно-ориентированным.
Данные, найденные в хранилище данных, интегрированы. Поскольку они поступают из нескольких операционных систем, все несоответствия должны быть устранены. Последовательности включают соглашения об именах, измерение переменных, структуры кодирования, физические атрибуты данных и т. д.
В то время как операционные системы отражают текущие значения, поскольку они поддерживают ежедневные операции, данные хранилища данных представляют собой длительный временной горизонт (до 10 лет), что означает, что они хранят в основном исторические данные. Они в основном предназначены для добычи данных и прогнозирования. (Например, если пользователь ищет модель покупок определенного клиента, пользователю необходимо просмотреть данные о текущих и прошлых покупках.) [28]
Данные в хранилище данных доступны только для чтения, что означает, что их нельзя обновлять, создавать или удалять (если только нет нормативного или законодательного обязательства делать это). [29]
В процессе хранилища данных данные могут быть агрегированы в витринах данных на разных уровнях абстракции. Пользователь может начать просматривать общее количество единиц продажи продукта во всем регионе. Затем пользователь смотрит на штаты в этом регионе. Наконец, он может изучить отдельные магазины в определенном штате. Поэтому, как правило, анализ начинается с более высокого уровня и переходит к более низким уровням детализации. [28]
При виртуализации данных используемые данные остаются в своих исходных местах, и устанавливается доступ в режиме реального времени, позволяющий проводить аналитику по нескольким источникам, создавая виртуальное хранилище данных. Это может помочь в решении некоторых технических трудностей, таких как проблемы совместимости при объединении данных с различных платформ, снижая риск ошибок, вызванных неверными данными, и гарантируя, что используются самые новые данные. Кроме того, избегание создания новой базы данных, содержащей персональную информацию, может облегчить соблюдение правил конфиденциальности. Однако при виртуализации данных подключение ко всем необходимым источникам данных должно быть рабочим, поскольку локальной копии данных нет, что является одним из главных недостатков подхода. [30]
Различные методы, используемые для построения/организации хранилища данных, указанного организацией, многочисленны. Используемое оборудование, созданное программное обеспечение и ресурсы данных, специально требуемые для правильной работы хранилища данных, являются основными компонентами архитектуры хранилища данных. Все хранилища данных имеют несколько фаз, в которых требования организации изменяются и настраиваются. [31]
Эти термины относятся к уровню сложности хранилища данных:
Мы можем разделить ИТ-системы на транзакционные (OLTP) и аналитические (OLAP). В целом, мы можем предположить, что OLTP-системы предоставляют исходные данные для хранилищ данных, тогда как OLAP-системы помогают их анализировать.