Хранилища данных в современном мире уже не считаются новой технологией. Между тем рынок управленческих систем – решений, построенных на базе хранилищ данных – развивается очень динамично.
Когда речь заходит о хранилищах данных, важно понимать говорим ли мы о центральном хранилище организации или о хранилище, поддерживающем функциональность определенной промышленной либо заказной управленческой системы. Третий вариант – попытка совмещения двух вариантов в одном, исходя из текущих потребностей бизнеса и возможностей организации.
Два варианта архитектуры
В высшей школе молодых IT-специалистов учат, что существуют две основные концепции проектирования хранилищ данных. Их авторы — Билл Инмон и Ральф Кимбел.
Архитектура “по Инмону” разделяет две области анализа и детальных данных. Такое хранилище декомпозируется на четкие предметные области, которые описывают конкретный объект учёта. С точки зрения моделирования это помогает хранить нормализованные данные в уникальной для каждой области структуре, необходимой для каждой конкретной бизнес-модели. При этом аналитическая отчетность — витрина данных — строится дополнительно: рядом в хранилище или же отдельно (в разных базах данных).
Архитектура “по Кимбелу”, в первую очередь, направлена на обработанные данные для аналитической отчетности (подготовлена платформа для построения витрин данных; схемы называют: “звезда”, “снежинка” или “созвездие”). Такое хранилище содержит несколько уровней агрегированных данных, но при этом область анализа и область детальных данных явным образом не разделяются. Хотя верхние уровни агрегации для оптимизации, как и в предыдущем варианте, могут выделяться. Таким образом, мы получаем комплекс витрин, связанных в единой системе.
Вариант “по Инмону” обеспечивает лучшую масштабируемость и большую гибкость в плане внедрения новых бизнес-задач. Вариант “по Кимбелу” дает возможность быстрее получить результат для анализа, адаптированный под конкретные текущие бизнес-требования.
Практика применения двух архитектур
Возвращаемся к практическому использованию архитектуры при создании решений для финансовых организаций. Построение «по Инмону» оказывается характерным для центрального хранилища. Построение «по Кимбелу» – для функционально-ориентированного.
В JetRuby Agency применяется, как архитектура “по Инмону”, так и “по Кимбелу”. Что называется — в зависимости от целесообразности. Обычно на этапе планирования архитектуры всего интернет-сервиса, происходит и планирование его хранилища данных под конкретные задачи, поставленные заказчиком. Исходя из задач и бизнес-логики, а также с учетом дальнейшей перспективы, создается хранилище с необходимой архитектурой.
Сегодня, благодаря использованию ElasticSearch, принципиальная разница между выбором той или иной архитектуры отсутствует. Однако если ваши базы данных станут очень тяжелыми, процесс их оптимизации окажется довольно сложным (в наибольшей степени это касается центральных хранилищ). В этой связи, следует рассмотреть функционально-ориентированное хранилище, которое в первую очередь ориентируется на бизнес.
Суть одного из выполненных нами проектов заключалась в раскрытии партнерских сетей и медиа-компаний, проводимых по всему миру. В результате мы успешно реализовали архитектуру “по Кимбелу” и типичное функционально-ориентированное хранилище.
Весь сервис состоял из нескольких логических частей:
- Сложная серверная архитектура — больше сотни серверов по всему миру, на которых жили боты, собирающие полезную информацию о целевых ресурсах.
- Две БД — с сырыми данными из баз ботов и организованным функционально-ориентированным хранилищем.
- Веб-интерфейс для отображения витрин данных.
Для реализации архитектуры “по Кимбелу” были подготовлены фоновые обработчики, которые агрегировали данные по временному признаку, а уже над ними производились вычисления с последующим выводом на витрину веб-интерфейса.
Кроме того, был создан базовый класс Item для агрегированных данных за час работы ботов и группа классов: Daily, Weekly и Monthly, которые наследовали от базового класса все его методы (являлись точными копиями в плане структур таблиц БД). А уже в зависимости от задачи они дополнялись кастомными методами (если это не требовалось, то весь класс мог состоять всего из одной строчки кода, в которой указывалось имя таблицы БД). Один день работы ботов выливался примерно в 10 ГБ данных в БД, что уже ставило под сомнение агрегацию “на лету” даже со средствами ElasticSearch.
Правильный выбор архитектуры сэкономил заказчику деньги, а разработчику и потребителю конечных результатов — время.
Будьте внимательны и терпеливы, тогда у вас все получится. В противном случае всегда можно обратиться к нам за помощью.
