Почему компании перестали доверять разрозненным базам

У любой крупной организации данные разбросаны по десяткам систем. Бухгалтерия ведёт свою базу, отдел продаж — свою, склад — третью, а где-то сбоку лежат отчёты информационных агентств и макроэкономические сводки. Каждая система по-своему права, но стоит задать вопрос вроде «как менялась прибыль по регионам за пять лет» — и начинается мучение: данные не стыкуются, форматы разные, история половины показателей потеряна. Именно из этой боли выросла идея информационного хранилища.

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

Определение 1

Информационное хранилище — интегрированная предметно-ориентированная база данных, предназначенная для создания, хранения, пополнения и обслуживания архивов.

Данные как главный актив

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

Три шага, без которых ничего не заработает

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

Разведка. Сначала анализируют всё, что уже есть в источниках: что за данные там лежат, каков их смысл, как они устроены. По сути, проводят инвентаризацию семантики и содержания.
Проектирование. Затем рисуют схему будущей базы — с оглядкой сразу на две вещи: какие данные реально доступны в организации и какие запросы будут генерировать аналитические приложения.
Загрузка. И только потом извлекают нужное, преобразуют под утверждённый проект и заливают внутрь. Этот триумвират — извлечение, преобразование, загрузка — и есть знаменитый процесс ETL.

Как это выглядит изнутри

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

Конечный пользователь к сырым таблицам напрямую не лезет. Он берёт инструмент себе по вкусу — средство визуализации, генератор отчётов, пакет статистической обработки — и через него, опираясь на репозиторий, разбирает содержимое хранилища. На выходе рождается то, ради чего всё затевалось: готовый отчёт, обнаруженная скрытая закономерность, прогноз.

Замечание 1

Любопытно, что с точки зрения теории выбор инструмента на структуру хранилища не влияет вовсе. Хоть меняй аналитические программы каждый месяц — сама конструкция и правила её поддержки остаются прежними. А вот физически воплотить эту концепцию можно очень по-разному. И здесь начинается самое интересное.

Три архитектуры на выбор

Виртуальное хранилище: иллюзия вместо стен

Самый лёгкий путь — не строить хранилище, а сымитировать его. Виртуальный вариант просто предоставляет интерфейсы к регистрирующей системе так, будто вы работаете с настоящим хранилищем. Делают это либо через набор «представлений» (view) в базе, либо через инструменты класса Desktop OLAP — Business Objects, Brio Enterprise и им подобные.

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

Замечание 2

Отсутствие истории — часто недооценённая беда виртуального подхода. Регистрирующая система хранит текущее состояние, а не то, что было год назад. Для аналитики, которая живёт сравнениями во времени, это почти приговор.

Двухуровневая схема: хранилища в миниатюре

Второй путь отказывается от центрального хранилища и делает ставку на витрины данных (data mart). Каждая витрина берёт информацию из регистрирующих систем и замыкается на одной предметной области — продажи, финансы, логистика. По принципам построения это те же хранилища, только уменьшенные.

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

Трёхуровневая архитектура: полноценное корпоративное решение

Когда организация дозревает до серьёзного масштаба, в ход идёт трёхуровневая схема. Она раскладывается на понятные этажи.

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

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