Выбор стратегии для модуля BI

Question

Компания, в которой я работаю, производит систему управления контентом (CMS) с различными различными надстройками для публикации, электронной коммерции, онлайн-печати и т. Д. Сейчас мы находимся в процессе добавления «модуля отчетности», и мне нужно исследовать какую стратегию следует придерживаться. «Модуль отчетности» иначе известен как Business Intelligence или BI.

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

Грубо говоря, у нас есть два варианта.

Вариант 1 заключается в написании решения на основе Apache Solr (в частности, с использованием https://issues.apache.org/jira/browse/SOLR-236). Плюсы этого подхода:

• бесплатно / с открытым исходным кодом / хорошее качество
• мы используем Solr / Lucene в других местах, поэтому хорошо знаем домен
• полная гибкость в отношении того, что индексируется, поскольку мы можем принимать входящие данные (в формате XML), проталкивать их через XSLT и передавать их в Solr
• общая гибкость того, как показывать результаты поиска. Как и в предыдущем шаге, мы могли бы иметь собственный шаблон поиска XSLT и отображать результаты в любом формате, который нам необходим
• наши разработчики веб-интерфейса опытны в XSLT, поэтому адаптация этого механизма для другого клиента должна быть относительно простой
• Solr предлагает поиск в реальном времени / полнотекстовый / граненый поиск, который нам абсолютно необходим. Быстрый прототип (основанный на записях Solr, 1M) смог обеспечить результаты поиска за 55 мс. Наш расчетный максимум записей составляет около 1 млрд. Строк (это не так уж много для типичного приложения BI), и если хуже становится хуже, мы всегда можем посмотреть на SolrCloud и т. Д.
• есть компании, которые делают очень похожие вещи, используя Solr (например, Honeycomb Lexicon)

Минусы этого подхода:

• SOLR-236 может быть или не быть стабильным, более того, пока не ясно, когда / если он будет выпущен как часть официального релиза
• возможно, нам придется написать кое-что, чтобы заставить работать некоторые специфичные для BI функции. Это звучит немного похоже на изобретение колеса
• самая большая проблема в том, что мы не знаем, что нам может понадобиться в будущем (например, интеграция с каким-либо программным обеспечением BI, экспорт в Excel и т. Д.)

Вариант 2 заключается в интеграции с некоторым бесплатным или коммерческим программным обеспечением BI. До сих пор я смотрел на Wabit и взглянул на QlikView , возможно, другие. Плюсы этого подхода:

• не нужно изобретать велосипед, программное обеспечение (надеюсь) испытано и проверено
• сэкономит нам время, которое мы могли бы потратить на решение проблем, на которых мы специализируемся

Минусы:

• , поскольку мы являемся магазином Java, а наше решение является кроссплатформенным, нам пришлось бы исключить множество вариантов, имеющихся на рынке
• Я не уверен, насколько гибким может быть программное обеспечение BI. Чтобы просмотреть некоторые предложения BI, потребуется ли у них гибкое индексирование, поиск в реальном времени / полнотекстовый поиск, полностью настраиваемые результаты и т. Д.
• Мне сказали, что предложения BI с открытым исходным кодом недостаточно развиты, тогда как коммерческие BI (SAP, другие) стоят состояния, их лицензии начинаются с десятков тысяч фунтов / долларов. Хотя я не против коммерческого выбора как такового, он добавит к общей цене, которая может легко стать слишком большой
• не уверен, насколько хорошо BI настроен для работы с данными без схемы

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

Кто-нибудь был в подобной ситуации и мог бы посоветовать, какой путь выбрать, или, что еще лучше, посоветовать возможные плюсы / минусы варианта № 2?Самая большая проблема здесь в том, что я не знаю, чего не знаю;)

Answer 1

Я провел некоторое время, играя с QlikView и Wabit , и, должен сказать, я очень разочарован.

Я ожидал, чтоНа самом деле вся индустрия БИ имеет под собой какую-то науку, но из того, что я обнаружил, это всего лишь модное слово. Эта статья MSDN была действительно откровением.Весь бизнес BI состоит в том, чтобы брать данные из хорошо нормализованных схем (они называют это OLTP ), помещать их в менее нормализованные схемы ( OLAP , снежинка- или звездного типа ) и создание индексов для каждого аспекта, который вы хотите (промышленный жаргон для этого - куб данных ).Остальное - всего лишь несколько сценариев для получения красивых графиков.

Хорошо, я знаю, что здесь все упрощается.Я знаю, что мог пропустить много разных аспектов (хорошие отчеты? Экспорт в Excel? Прогнозы?), Но с точки зрения компьютерной науки я просто не вижу здесь ничего, кроме индекса базы данных.

Мне сказали, чтонекоторые инструменты BI поддерживают сжатие.Lucene тоже это поддерживает.Мне сказали, что некоторые инструменты BI способны хранить все индексы в памяти.Для этого есть кеш Lucene.

Говоря о двух кандидатах (Wabit и QlikView) - первый просто незрелый (у меня есть десятки исключений при попытке выйти за пределы того, что было предложено в их демонстрации).) тогда как другой работает только под Windows (не очень хорошо, но я мог бы с этим жить), и интеграция, вероятно, потребовала бы от меня написания некоторого VBScript (хм!).Мне пришлось потратить пару часов на форумах QlikView только для того, чтобы заставить работать простой элемент управления диапазоном дат, и мне это не удалось, потому что у меня не было поддерживаемых загружаемых демонстрационных проектов, доступных на их сайте.Не поймите меня неправильно, они оба являются хорошими инструментами для того, для чего они были созданы, но я просто не вижу смысла в интеграции с ними, потому что я бы не многого выиграл.

ДляАдресная (спорная) незрелость Solr Я определю абстрактный API, чтобы я мог переместить все данные в базу данных, которая поддерживает полнотекстовые запросы, если что-то пойдет не так.И если хуже становится хуже, я всегда могу писать вещи поверх Solr / Lucene, если мне нужно.

Answer 2

Сначала вы должны уточнить, что должны показывать ваши отчеты.Какая функция отчетности вам нужна?Какие выходные форматы вы хотите?Вы хотите показать его в браузере (HTML) или в формате PDF или с помощью интерактивного средства просмотра (Java / Flash).Где находятся данные (база данных, Java и т. Д.)?Вам нужны специальные отчеты или только некоторые жестко закодированные отчеты?Это только некоторые вопросы.

Без ответов на этот вопрос трудно дать реальную рекомендацию, но моя общая рекомендация будет i-net Clear Reports (раньше назывался i-net Crystal-Clear).Это инструмент Java.Это коммерческий инструмент, но его стоимость ниже, чем у SAP и со *. 1007 *

Answer 3

Если вы действительно находитесь в сценарии, в котором вы не уверены, что не знаете я думаю, что лучше изучить инструмент с открытым исходным кодом и оценить его полезность, прежде чем углубляться в собственную реализацию , Вполне может быть, что использование решения с открытым исходным кодом поможет вам еще больше кристаллизовать ваше собственное понимание и необходимые функции.
Ранее я работал с открытым исходным кодом Pentaho . Я серьезно почувствовал, что понял намного больше, научившись использовать функции Пентахо для моей цели. Конечно, как и в случае работы с большинством решений с открытым исходным кодом, Пентахо поначалу казался немного пугающим, но мне удалось справиться с этим за месяц. Мы также работали с инструментами Kettle ETL и Mondrian кубами, которые, как я думаю, в наши дни основаны на большинстве серьезных инструментов BI. Ранее все эти компоненты были независимыми, но я полагаю, что «Пентахо» взял на себя ответственность за все эти проекты.

Но как только вы будете уверены в том, что вам нужно, а что нет, я бы предложил создать собственный базовый инструмент отчетности поверх реализации mondrian. Настройка сложного инструмента с открытым исходным кодом действительно может быть большой проблемой. Кроме того, есть лицензии, которые следует опасаться. Я считаю, что Pentaho - GPL, хотя вы можете проверить это.