Хранилище данных

Что такое хранилище данных

Хранилище данных (Data Warehouse) — это не база данных и не их совокупность. Это сложный программно-аппаратный комплекс или архитектура, которая включает программные и аппаратные компоненты и служит исключительно для работы с данными.

Повышая качество мастер-данных (Master Data), мы обеспечиваем единое информационное пространство организации, устраняем противоречия в данных разных приложений и поддерживаем корректные текущие операции. Цель хранилища данных иная. Она не в том, чтобы улучшать существующие данные, а в том, чтобы из огромного массива разнокачественных данных отобрать достоверные, актуальные, согласованные и целостные сведения исключительно для принятия управленческих решений. Иными словами — для использования в корпоративной отчётности.

Вместо бумажных отчётов и сложных запросов к таблицам применяется многомерный куб. Его основу составляет модель OLAP (Online Analytical Processing), в частности соответствующая правилам Кодда. Преимущество OLAP-модели в том, что объём и сложность отчёта практически не влияют на производительность: отчёт из 20 чисел и отчёт из 20 000 чисел строится мгновенно. Это обеспечено технической реализацией многомерного куба, однако отдельные данные внутри куба изменить почти невозможно.

Классическая модель Кимболла

Модель хранилища данных, предложенная Кимболлом (Kimball), описывает последовательную обработку данных.

• Источники данных (Operational Source Systems) — операционные системы слева на схеме. Из них извлекаются данные, на основе которых строятся показатели, вплоть до показателей системы сбалансированных показателей (BSC).
• Область подготовки данных (Data Staging Area) — промежуточная область, где данные очищаются. Выполняются операции: очистка (cleanse), комбинирование (combine), стандартизация (standardize), то есть приведение к единому формату, проверка на непротиворечивость, содержательный контроль (возможно, с участием людей). Заведомо ложные данные не допускаются к дальнейшей обработке.
• Витрины данных (Data Marts) или промежуточная реляционная база — после очистки данные загружаются в многомерные кубы (OLAP-кубы), именуемые Data Mart №1, Data Mart №2 и так далее, либо сначала попадают в реляционную базу, где хранятся постоянно и откуда по запросам поступают в кубы.
• Справа находятся инструменты доступа и анализа данных, работающие с этими кубами.

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

Эволюция модели: новые компоненты

Позднее модель усложнилась, сохранив основную идею. Появились:
• Большие данные (Big Data) как источники.
• Постоянная область детальных данных — центральное хранилище (Central Warehouse), куда данные поступают после очистки и хранятся постоянно.
• Зависимые хранилища данных (Dependent Data Stores) — витрины, которые могут быть как многомерными кубами, так и небольшими хранилищами со своими кубами.
• Внизу схемы отдельно выделены мастер-данные.

Это более разветвлённая, но концептуально близкая к исходной идея.

Ограничения и появление Data Lake

Архитектура централизованного хранилища довольно негибкая. Трудно заранее определить, какие именно данные понадобятся руководителям через год или три для принятия стратегических решений. Состав данных и измерений плохо поддаётся быстрым изменениям.

Альтернативный подход предлагает не прогнозировать нужный набор данных, а дать бизнес-пользователям возможность самостоятельно загружать любые данные без обязательной очистки. Такую загрузку называют Ingest (заглатывание). Данные помещаются не в Warehouse, а в озеро данных (Data Lake), где могут находиться и хорошие, и плохие, и полезные, и бесполезные сведения. Пользователи могут агрегировать и исследовать их любыми способами — с помощью кубов, статистических методов, визуализации. Принимаемые решения остаются на их ответственности.

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

Аналитические платформы и Data Discovery

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

Это не означает, что хранилище данных полностью теряет актуальность. Во многих компаниях можно обойтись аналитической платформой, и решения, принимаемые бизнес-пользователями, будут вполне качественными. Одним из лидеров этого направления (по отчёту Gartner за 2015 год) была компания Tableau, реализующая подобный подход к обработке данных.

Выводы

• Идея централизованного стратегического управления исключительно на основе сбалансированной системы показателей не является бесспорной.
• Корпоративные BI-системы (Business Intelligence) на базе хранилищ данных распространены не очень широко и не всегда популярны, несмотря на усилия вендоров.
• Полная архитектура хранилища данных реализуется редко.
• Конкурентом централизованного хранилища становится децентрализованная обработка данных на платформе Data Discovery.

Краткие итоги

Исходной точкой анализа служит фундаментальное разделение между операционной обработкой данных и аналитической поддержкой решений. Если мастер-данные и транзакционные системы обслуживают текущую деятельность, то хранилище данных целенаправленно собирает проверенные сведения для формирования корпоративной отчётности и стратегических показателей. Центральным звеном здесь выступает многомерная OLAP-модель, обеспечивающая одинаково высокую скорость построения отчётов любого объёма, но жёстко фиксирующая структуру данных.

Классическая архитектура Кимболла закладывает эталонный конвейер: извлечение из операционных источников, очистка и стандартизация в промежуточной области (Staging), загрузка в витрины данных (Data Marts) или центральное хранилище (Central Warehouse) с последующей аналитикой через многомерные кубы. Принципиальной характеристикой является накопительный характер — данные не удаляются, и это экономически оправдано. Однако у такого подхода обнаруживается серьёзное ограничение: он требует заранее спроектированных измерений и показателей, что входит в противоречие с реальной управленческой практикой, где потребности в данных могут быстро меняться и не поддаются точному прогнозированию.

Реакцией на эту негибкость становится концепция Data Lake и аналитических платформ класса Data Discovery. В ней акцент смещается с корпоративного контроля на свободу бизнес-пользователя: любые данные (вплоть до «мусорных») загружаются в озеро данных без предварительной очистки, а весь цикл отбора, смешивания и моделирования передаётся в руки принимающего решения специалиста. Такой подход не исключает классическое хранилище, но демонстрирует, что во многих ситуациях допустима децентрализованная аналитика без жёсткого единого семантического слоя.

Практический смысл этого противостояния — в осознанном выборе между управляемостью и гибкостью. Там, где критичны согласованность показателей и юридическая достоверность отчётности, сохраняет ценность строгая архитектура с очисткой и единой версией правды. Там же, где важнее скорость получения инсайтов, возможность проверять гипотезы на разнородных данных и адаптироваться к изменчивым условиям, платформы Data Discovery оказываются более адекватным инструментом. Понимание обеих моделей позволяет выстроить гибридные решения, в которых озеро данных питает как формализованные витрины, так и среду самостоятельной аналитики.