Выбор стратегии для модуля BI
Компания, в которой я работаю, производит систему управления контентом (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 настроен для работы с данными без схемы
Я определенно не лучший кандидат, чтобы найти наиболее подходящий вариант интеграции на рынке (в основном из-за отсутствия знаний в области BI), однако решение должно быть принято быстро.
Кто-нибудь был в подобной ситуации и мог бы посоветовать, какой путь выбрать, или, что еще лучше, посоветовать возможные плюсы / минусы варианта № 2? Самая большая проблема здесь в том, что я не знаю, чего не знаю;)
3 ответа
Я провел некоторое время, играя с QlikView и Wabit, и, должен сказать, я очень разочарован.
Я ожидал, что вся индустрия BI на самом деле содержит в себе какую-то науку, но из того, что я обнаружил, это всего лишь модное слово. Эта статья MSDN была на самом деле откровением. Весь бизнес BI состоит в том, чтобы брать данные из хорошо нормализованных схем (они называют их OLTP), помещать их в менее нормализованные схемы (OLAP, типа снежинки или звезды) и создавать индексы для каждого аспекта, который вы хотите (промышленный жаргон для это куб данных). Остальное - просто скрипты для получения симпатичных графиков.
Хорошо, я знаю, что я упрощаю вещи здесь. Я знаю, что мог пропустить много разных аспектов (хорошие отчеты? Экспорт в Excel? Прогнозы?), Но с точки зрения компьютерных наук я просто не вижу здесь ничего, кроме индекса базы данных.
Мне сказали, что некоторые инструменты BI поддерживают сжатие. Lucene тоже это поддерживает. Мне сказали, что некоторые инструменты BI способны хранить все индексы в памяти. Для этого есть кеш Lucene.
Говоря о двух кандидатах (Wabit и QlikView) - первый просто незрелый (у меня есть десятки исключений при попытке выйти за пределы того, что было предложено в их демонстрации), тогда как другой работает только под Windows (не очень хорошо, но Я мог бы жить с этим), и интеграция, вероятно, потребовала бы от меня написания некоторого VBScript (хм!). Мне пришлось потратить пару часов на форумах QlikView только для того, чтобы заставить работать простой элемент управления диапазоном дат, и мне это не удалось, потому что в Personal Edition у меня не было загружаемых демонстрационных проектов, доступных на их сайте. Не поймите меня неправильно, они оба являются хорошими инструментами для того, для чего они были созданы, но я просто не вижу смысла в интеграции с ними, поскольку я бы не многого выиграл.
Чтобы решить (спорную) незрелость Solr, я определю абстрактный API, чтобы я мог переместить все данные в базу данных, которая поддерживает полнотекстовые запросы, если что-то пойдет не так. И если хуже становится хуже, я всегда могу писать вещи поверх Solr/Lucene, если мне это нужно.
Если вы действительно находитесь в сценарии, в котором вы не уверены, чего не знаете, я думаю, что лучше всего изучить инструмент с открытым исходным кодом и оценить его полезность, прежде чем углубляться в собственную реализацию. Вполне может быть, что использование решения с открытым исходным кодом поможет вам еще больше кристаллизовать ваше собственное понимание и необходимые функции.
Ранее я работал с открытым исходным кодом под названием Pentaho. Я серьезно почувствовал, что понял намного больше, научившись использовать функции Пентахо для моей цели. Конечно, как и в случае работы с большинством решений с открытым исходным кодом, Пентахо поначалу казался немного пугающим, но мне удалось справиться с этим за месяц. Мы также работали с инструментом Kettle ETL и кубами Мондриана, который, я думаю, основывается на большинстве серьезных инструментов BI в наши дни.
Ранее все эти компоненты были независимыми, но я полагаю, что "Пентахо" взял на себя ответственность за все эти проекты.
Но как только вы будете уверены, что вам нужно, а что нет, я бы предложил создать собственный базовый инструмент отчетности поверх реализации mondrian. Настройка сложного инструмента с открытым исходным кодом действительно может быть большой проблемой. Кроме того, есть лицензии, которые следует опасаться. Я верю, что Pentaho - GPL, хотя вы можете проверить это.
Сначала вы должны уточнить, что ваши отчеты должны показать. Какая функция отчетности вам нужна? Какие выходные форматы вы хотите? Вы хотите показать его в браузере (HTML) или в формате PDF или с помощью интерактивного средства просмотра (Java/Flash). Где находятся данные (база данных, Java и т. Д.)? Вам нужны специальные отчеты или только некоторые жестко закодированные отчеты? Это только некоторые вопросы.
Без ответов на этот вопрос трудно дать реальную рекомендацию, но моей общей рекомендацией будет i-net Clear Reports (раньше назывался i-net Crystal-Clear). Это инструмент Java. Это коммерческий инструмент, но его стоимость ниже, чем у SAP и Co.