Хранилища данных (DWH)
В конце прошлого века компьютерные системы стали неотъемлемой частью бизнеса. Например, софт помогал автоматизировать производственные процессы или этапы продаж; доступ к электронной истории банковских операций и бухучету позволил начать работу над автоматизацией аналитических отчетов.
Но алгоритмы программ и принципы их работы с информацией сильно отличались. Получить единую картину из разрозненных элементов было фактически нереально. Да и понятия о консолидированных данных на тот момент еще не существовало. Хотя бизнесу они были очень нужны. Кроме того, эту информацию надо было также где-то хранить и обрабатывать.
Для решения этих вопросов было разработано хранилище данных (Data Warehouse – DWH). DWH устроено по такому же принципу, как и базы данных, описанные выше. Единственное отличие – это возможность хранить в нем не одну базу данных, а множество. Хранилище можно назвать домом всех баз данных.
Правильно выстроенное хранилище позволяет учитывать разные бизнес-процессы компании и держать все данные в одном месте.
Информацию вносят в хранилище, изменения в нем отображаются мгновенно. Благодаря этому можно получать объемные и разносторонние аналитические отчеты.
Сегодня также огромную популярность набирают ELT-процессы, которые мы рассмотрим подробнее в следующей части. Суть в том, что данные сначала загружаются в хранилище, а затем трансформируются в нем. Подобное изменение стало доступно из-за широкого распространения облачных баз данных и усовершенствования технических мощностей.
Рис. 12. Схема ELT-процесса
Почему аналитические хранилища настолько привлекательны для бизнеса? И нужны ли они вам? Давайте разбираться.
Аналитики на практике используют три основных типа DWH:
Корпоративное хранилище данных (Enterprise Data Warehouse) – центральное хранилище организации. В нем находятся классифицированные, систематизированные данные, отображающие разнообразные бизнес-процессы (учет и хранение остатков товаров, информацию о закупках, взаимодействие с сотрудниками, графики отпусков, больничных листов и так далее). Внутри таких хранилищ информация распределена по категориям. Такие системы отлично подходят для выработки долгосрочных решений, например для оптимизации логистики на предприятии.
Хранилище оперативных данных (Operational Data Store) – это хранилище, дающее доступ к обновленной информации в режиме реального времени. Оно оптимально для осуществления повседневных операций, то есть в нем находятся данные, которые регулярно обновляются и влияют на работу компании.
Аналитическое хранилище данных — главный инструмент аналитика. Поскольку его работа требует регулярного обращения к базам данных для построения отчетов, иногда нагрузка на сервер бывает крайне высокой. Поэтому создают отдельное хранилище исключительно для задач аналитики.
Рис. 13. Типы аналитических хранилищ
Перед разработкой хранилища следует ответить на ряд вопросов:
• Что вы планируете в нем хранить?
• Для какой цели оно строится: регулярная отчетность, бизнес-анализ действий покупателей или внутренних процессов организации?
• На какой объем данных оно рассчитано?
• Как часто данные будут обновляться?
• Кто будет иметь доступ к хранилищу?
На основании ответов создается внутренний документ с описанием требований к хранилищу, его логической и физической структуре.
В моей практике был такой пример: иностранная фирма Vembla разрабатывала приложение – аналог «Самоката» (сервис доставки продуктов на дом). Основное преимущество фирмы Vembla – доставка заказа за 15 минут. Прежде компания использовала информацию со старой версии сайта, загруженной в медленное хранилище для резервных копий. Но этого было явно мало, и они хотели построить аналитическое хранилище. Самое главное – руководители четко понимали, что хотели бы там видеть.
Что мы сделали?
На тот момент у компании уже были свои облачные хранилища для разработчиков, поэтому мы выбрали простой и действенный путь:
• расширили существующее хранилище, потому что развертывание нового и перемещение в него данных в данном случае нерационально;
• дополнили его инструментами для создания полноценного аналитического хранилища;
• создали возможность для сбора в одном месте информации о скорости доставки, о возражениях клиентов, данных из рекламных кампаний, из Apple Store, Facebook*, отзывов и так далее.
Как упоминалось выше, базы данных, где мы храним разные потоки информации, затем анализируем их и можем построить отчетность, называются аналитическим хранилищем.
Рассмотрим работу с аналитическим хранилищем на примере гипермаркета «Лента» (рис. 14). Возьмем два отдела: аналитический и отдел закупок. Руководитель второго планирует определенное количество поставок товара, и ему необходимо спрогнозировать, как изменится объем сбыта, если снизить цену в магазине на эту позицию на 10, 15 и 20 % соответственно. Маркетинговому аналитику необходимо прикинуть и рассчитать такие модели. У него есть аналитическое хранилище, которое помогает ответить на вопросы руководителя отдела закупок. Аналитик обращается к опыту проведения похожих акций, смотрит прежние результаты и создает запрос на отслеживание изменения спроса с начала распродажи. Далее аналитик строит модель-прогноз и передает его результаты в отдел закупок. И уже на основании цифр руководитель принимает решение.
Рис. 14. Алгоритм работы с аналитическим хранилищем
Что происходит, если аналитического хранилища нет? Тогда этот же пример выглядит совсем иначе.
Информацию о работе магазина взять негде. Руководитель собирает менеджеров на совещание. Там высказывают несколько гипотез. Наиболее вероятные (и не всегда правильные) теории проверяют на практике путем перебора вариантов. И в итоге зачастую виновными в падении доходов оказываются линейные сотрудники.
Единство хранения информации обеспечивает:
Быстрое получение данных. Чем крупнее организация, тем больше возникает проблем с доступом к информации. За разные фрагменты данных могут отвечать разные отделы. Информация хранится сразу в нескольких местах. И если собирать ее по частям, этот процесс может затянуться.
При использовании DWH все хранится в одном месте и данные можно получить незамедлительно, написав запрос к хранилищу.
Сохранность данных. В корпоративном хранилище «забыть» что-то невозможно. Информация изначально записывается в удобном виде. Для DWH норма – хранить данные за 10 и более лет.
Надежность работы других систем. Аналитик работает напрямую с аналитическим хранилищем, других баз данных он не касается.
Еще одно преимущество аналитических хранилищ – работа с консолидированными данными, поступающими из нескольких источников.
Информация проверяется еще на этапе ввода. Таким образом, руководители и аналитики получают достоверную картину происходящего за большой период.
Вернемся к предыдущему примеру с падением продаж в магазине.
Зачем здесь нужно аналитическое хранилище данных? Ведь всю информацию можно взять из обычных баз. Но так поступать опасно. Во-первых, согласование доступов потребует времени. Во-вторых, затормозит работу отделов. И в-третьих, информацию понадобится привести в единый вид, а уже потом изучать.
Ключевой момент: нельзя использовать данные, которые находятся в продакшене (в «боевых» базах данных, вовлеченных в текущие рабочие процессы), для целей аналитики. Поскольку аналитический запрос может перегрузить их, основные операции для пользователей будут заблокированы, и это может обернуться потерей клиентов, а следовательно, и выручки.
Например, если ваш продукт – мобильное приложение, то в этих базах хранятся данные для его работы. Они в продакшене, то есть вовлечены в текущие рабочие процессы. Если перегрузить их аналитическими действиями, приложение сначала затупит, а потом «упадет»: пользователи не смогут ни войти, ни зарегистрироваться, ни покрутить ленту.
Приведу еще один пример использования аналитического хранилища. Ко мне обратилась компания – разработчик мобильного приложения, игры по типу Match-3 или «Три в ряд». Это игра, в которой нужно соединить несколько линий в одну, пройти определенные уровни. По ходу можно покупать доспехи, апгрейды для персонажа.
Компания хотела получить продуктовую аналитику и понять:
• насколько хорошо игроки проходят уровни,
• какой уровень для них сложный,
• когда клиенты уходят.
А также разобраться с эффективностью рекламы:
• какая доля пользователей открывает приложение,
• сколько игроков доходит до покупки.
Как можно решить эти задачи? Например, с помощью сервисов мобильной аналитики.
Но это похоже на жизнь в арендованной квартире: вы как бы пользуетесь сервисом, но по факту отдаете информацию на сторону.
И как только возникает сложная задача, сервис может с ней не справиться.
Что мы сделали?
Во-первых, подобрали решение для сбора информации – Firebase. С его помощью разметили все движения пользователя, затем включили экспорт данных в хранилище Google BigQuery.
Во-вторых, создали аналитическое хранилище и добавили в него экспорт информации из рекламных кабинетов (разработчики покупали рекламу в соцсетях). Мы собрали в одном месте данные о действиях пользователя и маркетинговых затратах.
В-третьих, решили вопрос отслеживания эффективности рекламы: как пользователь нашел приложение – сам или перешел по ссылке? Подобрали систему для такого отслеживания и подключили импорт в хранилище.
Все это помогло проанализировать информацию и понять, насколько эффективна реклама и не зря ли потрачены деньги.