Pentaho выглядит довольно солидно, предлагая полный набор инструментов BI с улучшенной интеграцией, как сообщается, в процессе. Но ... есть вероятность, что компании, желающие пойти по пути с открытым исходным кодом для своего решения BI, также, скорее всего, в конечном итоге будут использовать технологию баз данных с открытым исходным кодом ... и в , что означает, что "независимость от базы данных" может легко быть обоюдоострым мечом. Например, вы можете разработать куб в службах аналитики Microsoft, хорошо понимая, что все MDX / XMLA, которые ваш куб отправляет в базу данных, будут последовательно интерпретироваться, что будет препятствовать неприятным сюрпризам.
Сравните это со стеком Pentaho, который обычно заканчивается взаимодействием с Postgresql или Mysql. Я не могу ручаться за то, как Postgresql работает в области OLAP, но из опыта знаю, что Mysql - при всех его несомненных достоинствах - имеет «проблемы» с типами SQL, которые обычно возникают повсеместно в решении OLAP (Вы не можете продвинуться далеко в кубе без использования GROUP BY или COUNT DISTINCT). Таким образом, часть того, что вы сэкономите на стоимости лицензий, почти наверняка будет использована для решения вопросов, возникающих из-за того, что Пентахо не всегда знает, с какой базой данных он разговаривает - грабя Питера (по крайней мере, частично), чтобы заплатить Павлу, так сказать.