Три идеи, создавшие хранилища данных
Проблема: оперативных данных недостаточно для принятия решений
В 1992 году Билл Инмон в книге «Хранилище данных» (Building the Data Warehouse) обратил внимание на фундаментальное ограничение корпоративных систем. Все управленческие решения принимались на основе оперативной информации — сегодняшних или, в лучшем случае, вчерашних данных. Транзакционные приложения решали сугубо операционные задачи: фиксировали текущие проводки, отгрузки, закупки. Исторические сведения, необходимые для сравнения с прошлыми периодами (например, динамика продаж по сегментам относительно аналогичного периода год назад), как правило, не сохранялись. Архивные отчёты оказывались неполными или утерянными, а о долговременном прогнозировании не шло и речи.
Идея 1: Хранилище данных Билла Инмона
Инмон предложил простое решение: все операционные данные, которые могут понадобиться для генерации отчётов, следует никогда не удалять, а накапливать в отдельной базе —
хранилище данных (Data Warehouse, ХД). В оперативной системе, непрерывно обслуживающей текущие транзакции, для истории просто нет места. Выделив специализированное хранилище, компания получает доступ к накопленной информации для анализа и прогнозирования. На 500 страницах книги приводились многочисленные примеры упущенных бизнес-решений из-за отсутствия ретроспективы.
В начале 1990-х идея казалась почти фантастической. Объёмы памяти того времени были ничтожны: внешний дисковый накопитель — дискета — вмещал 360 Кбайт, мегабайт оперативной памяти считался огромным («больше никогда никому не нужно не будет»). Объёмы, требовавшиеся для исторического хранилища, выходили далеко за доступные рамки, поэтому быстрого внедрения не произошло.
Идея 2: Сбалансированная система показателей Нортона и Каплана
Инмон предложил хранить данные, но не определил, какие именно. Ответ на этот вопрос дали Роберт Каплан и Дэвид Нортон, разработав
сбалансированную систему показателей (Balanced Scorecard, BSC). Они выделили четыре перспективы (измерения), по которым оценивается успех компании:
• финансы,
• клиенты,
• внутренние бизнес-процессы,
• обучение и развитие персонала.
Логика системы строится на чёткой причинно-следственной цепочке. Инвестиции в развитие персонала, повышение квалификации и освоение новых технологий (перспектива обучения и развития) ведут к улучшению внутренних процессов (они становятся быстрее и эффективнее). Это, в свою очередь, повышает удовлетворённость клиентов обслуживанием или продуктами. А высокая клиентская лояльность закономерно приносит компании деньги, отражаясь в сильных финансовых показателях.
Для управления высшему менеджменту достаточно 12–15 ключевых стратегических показателей. Однако каждый из них агрегируется из нескольких сотен
метрик нижнего уровня. Именно эти детальные операционные метрики и необходимо накапливать в хранилище. Тогда, зная исходные данные, можно будет без потерь восстановить любые стратегические показатели и через год, и через пять лет. Цели по каждой перспективе обычно визуализируют на стратегической карте, где отображается, как достижение целей на одном уровне влияет на показатели другого.
Идея 3: Многомерная база данных и OLAP Эдгара Кодда
Третья проблема заключалась в скорости построения сложных отчётов. Эдгар Кодд, автор реляционной модели данных, указал, что классические реляционные базы оптимизированы для быстрого доступа к одной записи, группе записей или их отдельным атрибутам. Когда же требуется собрать информацию из множества разных таблиц и свести её в один отчёт, реляционная модель порождает
чудовищную неэффективность из-за ресурсоёмких операций соединения (inner join и других объединений). Такой запрос физически не может быть выполнен быстро при традиционной организации данных.
Кодд предложил принципиально иной способ —
многомерную модель данных, которая легла в основу технологии
OLAP (Online Analytical Processing — оперативная аналитическая обработка). Данные представляются в виде многомерного куба, где измерениями выступают, например, продукт, регион и время, а в ячейках находятся суммовые значения (объём продаж).
Над кубом выполняют несколько операций, каждая из которых мгновенно даёт нужный аналитический срез:
• Слайс (Slice) — сечение куба координатной плоскостью по одному измерению. Например, срез по измерению «Продукт» на позиции «плитка» покажет продажи плитки по всем регионам и всем периодам времени.
• Дайс (Dice) — вырезание подкуба, ограниченного несколькими значениями разных измерений (продажи выбранных материалов в конкретном регионе за определённый интервал).
• Вращение (Pivot) — поворот осей куба; позволяет поменять местами строки и столбцы в итоговом отчёте.
• Детализация (Drill-down) — переход от агрегированных данных к более подробным: можно «рассверлить» куб и рассмотреть продажи не по кварталам, а по месяцам, не по категориям кирпича, а по отдельным сортам или размерам, не по областям, а по городам.
Всего Кодд описал 12 принципов OLAP, которые определяют, какой должна быть полноценная аналитическая система.
Синтез трёх идей: появление архитектуры BI
Инмон, Нортон с Капланом и Кодд работали в абсолютно разных направлениях, не зная друг о друге и не пересекаясь. Тем не менее их независимые концепции идеально дополнили одна другую:
• Инмон дал принцип накопления исторических данных,
• Нортон и Каплан определили, какие именно метрики следует сохранять для стратегической отчётности,
• Кодд предложил эффективную модель хранения и обработки, позволяющую быстро получать любые аналитические разрезы.
Сочетание хранилища данных, сбалансированной системы показателей и многомерного OLAP-инструментария сформировало типовую архитектуру современных
BI-решений (Business Intelligence). Сегодня эта архитектура лежит в основе корпоративных систем поддержки принятия решений.
Краткие итоги
Формирование целостного подхода к построению аналитических систем прошло через последовательное решение трёх принципиальных проблем. Первая — неспособность учётных приложений обеспечить ретроспективный анализ: они фиксируют текущее состояние, но историю не сохраняют. Осознание этого ограничения привело к концепции отдельного хранилища данных, где накапливаются все операционные сведения, потенциально востребованные для отчётности и прогнозирования.
Простого накопления, однако, недостаточно — нужно понимать, какие именно данные критичны для управления. Здесь на помощь приходит методология сбалансированных показателей, выстраивающая причинно-следственную цепь от обучения персонала и оптимизации процессов к клиентской лояльности и финансовым результатам. Она даёт не просто набор метрик, а систему координат, в которой стратегические цели раскладываются на измеримые показатели, опирающиеся на детальные операционные счётчики. Благодаря этому хранилище наполняется не хаотично, а целенаправленно — под поддержку стратегии.
Третьим узким местом становится производительность. Классические реляционные базы данных отлично справляются с записью единичных транзакций, но крайне медленно строят аналитические отчёты, требующие объединения множества таблиц и агрегации больших объёмов. Многомерная модель, реализованная в OLAP-системах, решает эту задачу за счёт предварительной организации данных в кубы и специализированных операций — среза, вращения, детализации. Это переводит работу аналитика из режима длительного ожидания сложного запроса в интерактивное исследование.
На практике интеграция трёх компонентов — хранилища как источника консолидированной истории, стратегической модели показателей как смыслового фильтра и многомерного инструмента быстрого анализа — образует классическую BI-платформу. Такой подход позволяет связать разрозненные транзакционные системы, унифицировать справочники, выстроить сквозную отчётность от операционного уровня до стратегического и, главное, обеспечить единую версию правды для принятия обоснованных решений. Без любого из трёх элементов аналитический контур остаётся фрагментарным: данные либо есть, но не структурированы под стратегию, либо не могут быть оперативно обработаны.
В 1992 году Билл Инмон в книге «Хранилище данных» указал на фундаментальную проблему: менеджеры принимают решения на основе текущих оперативных данных, исторические сведения не сохраняются. Транзакционные системы обслуживают сегодняшние проводки, отгрузки, закупки, а сравнить продажи с прошлым годом или сегментировать изменения практически невозможно. Инмон предложил сохранять все операционные данные, потенциально нужные для отчётов, в отдельной базе — хранилище данных (Data Warehouse). В начале 90-х идея казалась фантастической из-за мизерных объёмов памяти (дискета 360 Кбайт, мегабайт ОЗУ — предел), поэтому быстрого внедрения не произошло.
Второй шаг сделали Нортон и Каплан, создав сбалансированную систему показателей (Balanced Scorecard, BSC). Они выделили четыре перспективы: финансы, клиенты, внутренние процессы, обучение и развитие. Логика BSC: инвестиции в развитие персонала улучшают процессы, что повышает удовлетворённость клиентов, а это ведёт к сильным финансовым результатам. Стратегических показателей — 12–15, но каждый агрегируется из сотен операционных метрик. Именно эти низовые метрики необходимо накапливать в хранилище, чтобы можно было восстановить стратегическую картину за любой период.
Третья проблема — скорость отчётов. Эдгар Кодд, создатель реляционной модели, показал, что реляционные базы хороши для единичных транзакций, но соединения таблиц для сводных отчётов крайне неэффективны. Он предложил многомерную модель — OLAP (Online Analytical Processing — оперативная аналитическая обработка). Данные организуются в куб с измерениями (продукт, регион, время). Основные операции:
• Slice — срез по одному измерению (продажи плитки за все периоды),
• Dice — подкуб с несколькими условиями,
• Pivot — поворот осей,
• Drill-down — переход к детализированным данным (поквартально → помесячно, по категориям → по сортам).
Кодд сформулировал 12 принципов OLAP. Три независимые концепции — хранилище, BSC и OLAP — сошлись и стали типовой архитектурой современных BI-систем: хранилище накапливает историю, BSC определяет, что именно хранить, OLAP обеспечивает быстрый многомерный анализ.
1. Традиционные транзакционные системы фиксируют только текущие операции и не приспособлены для хранения исторических данных.
2. Билл Инмон предложил концепцию хранилища данных — отдельной базы, в которой накапливаются операционные сведения для отчётности и анализа.
3. В начале 1990-х идея не получила немедленного развития из-за технических ограничений: требуемые объёмы памяти считались недостижимыми.
4. Нортон и Каплан разработали сбалансированную систему показателей (Balanced Scorecard), выделив четыре перспективы: финансы, клиенты, процессы, развитие.
5. Логика BSC выстраивает причинную цепочку: развитие персонала → эффективные процессы → удовлетворённость клиентов → финансовый успех.
6. Стратегические показатели верхнего уровня агрегируются из множества операционных метрик, которые и должны сохраняться в хранилище.
7. Эдгар Кодд показал, что реляционная модель неэффективна для сложных аналитических запросов из-за ресурсоёмких операций соединения.
8. В качестве решения Кодд предложил многомерную модель данных, реализованную в технологии OLAP (оперативная аналитическая обработка).
9. Данные в OLAP организуются в виде куба с измерениями (продукт, регион, время), что позволяет быстро выполнять срезы и агрегации.
10. Основные операции OLAP — срез (slice), дайс (dice), вращение (pivot) и детализация (drill-down) — обеспечивают гибкий интерактивный анализ.
11. Три независимые концепции — хранилище данных, сбалансированные показатели и OLAP — объединились в типовую архитектуру BI-решений.
12. Современные BI-системы строятся на сочетании накопления истории, стратегической модели метрик и многомерной аналитики для поддержки принятия решений.
1. Почему для анализа тенденций и прогнозирования недостаточно данных из оперативных транзакционных систем?
2. В чём заключается основная идея хранилища данных (Data Warehouse), предложенная Биллом Инмоном?
3. Какие технические ограничения сдерживали быстрое принятие концепции хранилищ данных в начале 1990-х годов?
4. Назовите четыре перспективы (измерения) сбалансированной системы показателей и их логическую взаимосвязь.
5. Как связаны между собой стратегические показатели верхнего уровня и операционные метрики в подходе Нортона и Каплана?
6. В чём, по мнению Эдгара Кодда, заключается главный недостаток реляционных баз данных при построении аналитических отчётов?
7. Дайте определение технологии OLAP и объясните, чем многомерная модель данных отличается от реляционной применительно к аналитическим задачам.
8. Опишите смысл операции «срез» (slice) в многомерном кубе и приведите пример её использования.
9. Каким образом операция детализации (drill-down) позволяет повысить глубину анализа в OLAP?
10. Какую роль играет сбалансированная система показателей в определении наполнения хранилища данных?
11. Почему, несмотря на независимое появление, идеи Инмона, Нортона–Каплана и Кодда считаются взаимодополняющими в архитектуре BI?
12. Каким образом многомерная организация данных решает проблему скорости выполнения сложных отчётов по сравнению с реляционной моделью?
