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

Question

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

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

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

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

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

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

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

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

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

Минусы:

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

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

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

Answer 1

Я провел некоторое время, играя с обоими Qlikview а также Вабит, и, должен сказать, я совершенно разочарован.

У меня было ожидание, что у всей биографии на самом деле есть некоторая наука, но из того, что я обнаружил, это просто модное слово. Эта статья MSDN на самом деле был открытым глазами. Весь бизнес BI состоит из получения данных из хорошо нормализованных схем (они называют это Ольтп), поместив его в менее нормализованные схемы (Олап, снежинка- или же Звездный тип) и создание индексов для каждого аспекта, который вы хотите Data Cube) Остальное - это просто сценарий, чтобы получить красивые графики.

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

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

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

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

Answer 2

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

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

Answer 3

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

Без ответов на этот вопрос трудно дать реальную рекомендацию, но моя общая рекомендация была бы I-NET ясные отчеты (Раньше назывался I-сетевой кристалл). Это инструмент Java. Это коммерческий инструмент, но стоимость ниже, как SAP и CO.