На примере магазина объясняем разницу между операционной базой и аналитическим хранилищем: текущие операции, история, объединение источников и обновление.
Оформить покупку и сравнить продажи — разные задачи
Представим условный магазин. Покупатель оплачивает товар, сотрудник уточняет статус доставки, руководитель сравнивает продажи за несколько лет. Всем нужны данные, но ожидания различаются: покупка должна оформиться сейчас, а для сравнения потребуется история и единые правила подсчёта.
Отсюда возникает различие между операционной базой и аналитическим хранилищем. При этом хранилище тоже может быть построено на базе данных. Это не противопоставление двух несовместимых технологий, а разговор о назначении системы и характере работы с информацией.
База, с которой работает приложение
В обзоре AWS база данных описывается как организованное хранение информации, доступной для управления и использования. В операционной системе магазина она поддерживает повседневные действия: появление заказа, изменение его статуса, регистрацию оплаты.
Представим, что сотрудник ищет один конкретный заказ. Ему не нужен анализ всех продаж за пять лет. Он хочет увидеть актуальный статус и выполнить разрешённое действие. Проектируя такую систему, команда учитывает именно этот рабочий сценарий.
Хранилище собирает картину для анализа
Аналитическое хранилище помогает объединять информацию из разных источников для отчётности и анализа. Такое назначение описано в материале AWS о хранилищах. В нашем условном магазине туда могут поступать сведения о заказах, расходах на рекламу и возвратах.
Руководитель получает возможность сравнить периоды и подразделения по согласованным правилам. Для этого недостаточно просто скопировать файлы в одну папку: нужно понять, как связаны записи, какие периоды охвачены и что означают показатели.
Зачем сохранять историю определений
Представим, что магазин объединил две категории товаров в одну. В текущем каталоге уже новые названия, но руководителю нужно объяснить изменение продаж относительно прошлого года. Команде придётся решить, сравнивать ли данные по старым категориям или пересчитать историю по новой структуре.
Оба варианта могут быть полезны для разных вопросов. Важна прозрачность: читатель отчёта должен понимать, что именно сравнивается. Само слово «хранилище» не гарантирует сохранение любой истории — нужные сведения и правила их изменения необходимо предусмотреть при проектировании.
Почему свежесть данных нужно обсуждать отдельно
В нашем магазине статус заказа в приложении изменился только что, а аналитический отчёт обновляется по расписанию. В течение некоторого времени значения могут различаться без ошибки. Пользователю отчёта нужно знать, на какой момент собраны сведения и когда ожидать следующее обновление.
Частоту выбирают под задачу. Для анализа сезонности не всегда требуется та же оперативность, что для обработки покупки. Если же руководителю нужно быстро замечать изменения, требования будут другими. Нельзя автоматически считать любую базу мгновенной, а любое хранилище обновляемым только ночью.
Когда отдельное хранилище стоит обсуждать
Поводом для обсуждения может стать ситуация, когда отчёты регулярно собирают из нескольких систем, определения показателей расходятся, а работа с историей требует ручных исправлений. Это повод исследовать архитектуру, но ещё не доказательство, что компании немедленно нужен новый дорогой продукт.
Для небольшого проекта существующая система иногда покрывает потребности. Сначала полезно перечислить потребителей, источники, нужную историю и допустимое время обновления. Затем оценить, где возникают ограничения и кто будет сопровождать решение. Вопрос «какое хранилище купить» имеет смысл после такого описания, а не вместо него.
Следующий шаг
Если эти задачи связаны с вашей работой или планами, посмотрите Архитектор данных. Сопоставьте содержание программы с тем, что хотите научиться делать самостоятельно. До выбора обучения полезно записать конкретную задачу, свой текущий опыт и вопросы к преподавателю. Название инструмента само по себе ещё не определяет подходящую программу.
