2015-09-10 3 views
-3

У меня есть БД, который содержит некоторые данные. Эти данные преобразуются в требуемом формате перед сохранением в этой БД. Также эта БД запрашивается производственными приложениями.Архитектура анализа данных

Обратите внимание, что нет базы данных необработанных данных, все данные обрабатываются для дальнейшего использования в наших приложениях, прежде чем мы вставим их в этот noSQL. Теперь мне нужно реализовать некоторые отчеты на основе этих данных.

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

Chart

Конечно, это простой пример, чтобы понять, что мне нужно и пытаться достичь, реальных отчетов будет быть более сложным.

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

Там я вижу некоторые проблемы и трудности, потому что тяжелые отчеты будут влиять на пропускную способность БД и поскольку такая же БД также используется приложениями, она замедляет их. Если уже есть какие-то принципы построения систем, подобные этому, я был бы признателен, если вы упомянете об этом в комментариях/ответах.

Поскольку я не смог найти какие-либо руководящие принципы, я буду описывать шахтные мысли, как реализовать аналитик:

  • Присылай рассчитывает как «событие» думал некоторые обмен сообщений платформ (RabitQM) в другое приложение, которое будет хранить эту информацию для разделения БД и использует его позже в отчетах. Я вижу следующие плюсы и минусы в этом подходе:
    • Плюсы: влияние производительности на панели приборной панели отсутствует.
    • Недостатки: дублирование данных
+0

Пожалуйста, будьте точнее о «добытых данных». Добыча данных - это огромное поле, и некоторые люди используют это модное слово для простых агрегатов или веб-соскабливания. Не играйте в бинговое бинго здесь, это не коммерческий шаг продаж. –

ответ

-1

Итак, вы БД в настоящее время используются транзакционным приложением, и вы собираетесь построить аналитическое приложение на данные из этой БД, но озабоченность по поводу влияние производительности, добавленное в транзакционное приложение.

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

Подсистема приложения представляет собой систему OLTP, Аналитическая подсистема представляет собой систему OLAP. Процесс преобразования данных из OLTP DB в OLAP DB называется ETL. Ваша идея репликации данных через очередь сообщений в другой БД является одним из возможных пользовательских методов ETL.

Обычно в OLAP-системе вы используете звездную схему или OLAP-куб для хранения предварительно агрегированных данных, чтобы приложение отчетов могло запрашивать данные из БД с лучшей производительностью. Большинство инструментов отчетности (инструменты BI), такие как Tableau, Cognos, SSRS, могут считывать данные из звездной схемы. Даже если вы не собираетесь использовать какой-либо из этих инструментов, просто хотите создать пользовательский интерфейс отчета с помощью специального кода, также будет полезно использовать схему звездочек.

Теперь отчетность и приложение используют разные БД, между этими двумя будут временные задержки. Если использовать очередь обмена сообщениями для преобразования данных в аналитическую БД в реальном времени, то временная задержка будет минимальной. Однако при добавлении новых данных в БД OLAP существует стоимость, если вы предварительно агрегируете данные, чтобы повысить производительность запросов. Вот почему многие системы отчетности обычно не сообщают о данных в реальном времени, если временная задержка приемлема для бизнеса.

Смежные вопросы