Зачем нужно хранилище данных

С чего всё начинается

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

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

OLTP против OLAP

Рабочие системы — это OLTP (Online Transaction Processing): много мелких быстрых операций (создать заказ, списать товар). Их задача — быстро и надёжно проводить транзакции прямо сейчас.

Аналитика — это OLAP (Online Analytical Processing): тяжёлые запросы по большим объёмам за длительные периоды («выручка по месяцам за 5 лет»). Если запускать такие запросы прямо на рабочих системах, они будут тормозить заказы клиентов. Поэтому аналитику выносят в отдельное хранилище.

Зачем именно отдельное хранилище

• Интеграция — собрать разрозненные источники в единую согласованную картину;
• Историчность — рабочие системы часто хранят только «текущее состояние», а хранилище помнит, как было раньше;
• «Одна версия правды» — все отделы считают показатели одинаково, из одного места;
• Производительность — тяжёлая аналитика не мешает операционным системам.

Процесс переноса данных из источников в хранилище называют ETL (Extract — извлечь, Transform — преобразовать, Load — загрузить) или ELT, когда преобразования делают уже внутри хранилища.

Две классические школы

Исторически сложились два подхода к построению DWH:

• Билл Инмон — «сверху вниз»: сначала единое нормализованное корпоративное хранилище (CIF), из него — витрины;
• Ральф Кимбалл — «снизу вверх»: сразу строим витрины со «звёздами» (dimensional modeling) и связываем их общими измерениями.

У обоих есть сильные стороны и ограничения по гибкости и масштабу. Именно из попытки взять лучшее и убрать слабые места родился Data Vault. Дальше разберём по очереди: подход Кимбалла, подход Инмона, затем Data Vault 1.0 и 2.0 — каждому посвящён свой урок.

💡 Запомни: OLTP — про операции «сейчас», OLAP/DWH — про анализ за годы. Хранилище интегрирует источники, хранит историю и даёт «одну версию правды».

OLTP и OLAP: разберём подробнее

Чтобы прочувствовать разницу, сравним их по характеру работы:

Свойство	OLTP (рабочие системы)	OLAP (хранилище/аналитика)
Типичная операция	создать заказ, провести платёж	«выручка по регионам за 3 года»
Объём за запрос	несколько строк	миллионы строк
Частота записи	постоянно, много мелких	пакетами (раз в час/сутки)
Что важно	скорость и надёжность транзакции	широкие выборки и история
Модель данных	нормализованная (без дублей)	удобная для анализа
Хранит историю?	обычно нет (только «сейчас»)	да, за годы

Пример: авиакомпания

Представь авиакомпанию, у которой есть три отдельные системы:

• Бронирование — билеты, пассажиры, брони (своя база);
• Расписание и операции — рейсы, самолёты, аэропорты, статусы;
• Программа лояльности — мили, уровни, начисления (часто вообще отдельный продукт).

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

Витрины данных (Data Marts)

Когда хранилище большое, для конкретных команд делают витрины — небольшие тематические срезы под отдел (финансы, маркетинг, операции). Опасность — когда витрины делают «кто во что горазд», вне единого хранилища: получаются «острова данных» (data silos / spreadmarts), где у каждого отдела свои несовпадающие цифры. Цель архитектуры (и Data Vault в частности) — чтобы все витрины росли из одного согласованного источника, а не противоречили друг другу.

💡 OLTP оптимизированы под быстрые транзакции и редко хранят историю; OLAP/DWH — под широкую аналитику за годы. Витрины удобны, но должны строиться из единого хранилища, иначе появляются противоречивые «острова данных».