Comments 17
Утверждение про то, что нужно анализировать «сырые» данные, очень спорное. По мере расширения перечня задач, которые решает система, я, например, пришел к тому, что в конечные отчеты вообще не должны попадать непредрассчитанные и не сохраненные в БД агрегации. Кроме того, в случае изменения исходных данных и их перерасчета, предыдущую версию данных пользовательского отчета во многих случаях лучше сохранить. Соображений в пользу этого несколько. Основные: 1) не оставить пользователя без отчета, когда идет обновление «сырых» данных; 2) давать возможность получить предварительный отчет по неполным данным, а потом узнать какая составляющая изменилась.
Сколько уходит времени у пользователя вашей системы, чтобы создать новый отчёт, который до этого никому кроме него и не нужен был? У нас это время меньше минуты (на манипуляции с интерфейсом).
Смотря, что понимать под новым отчетом.
1. Если новый перечень объектов/агрегация (даты, подразделения, продукты...) — то они все они предсказуемы и предрасчитаны (даты — месяца, кварталы, годы; подразделения — более крупные подразделения и т.д.)
2. Если совсем новый показатель — то печалька: пользователь его сам не создаст. Но это не страшно при "вытягивающей" системе работы, если данных, которых пользователи не заказывали, в БД не появляется.
Давайте снова рассмотрим пример «сколько денег потратили холостые гетеросексуалы из Калифорнии возрастом до 25 лет за каждый месяц прошлого года».

У нас менеджер для этого
— Указывает метрику IncomeLog
— Указывает размерности: gender search, country, state, payment month, marital status, age
— Указывает фильтры по размерностям.

То есть мы указываем доступные метрики и размерности. А как их комбинировать — дело пользователя.

Если я правильно понял ваш пример — у вас нет свободы комбинирования размерностей. Только те, что посчитаны заранее.
Да, Вы правильно поняли.
Но, хотелось бы ещё отметить три разноплановых момента:
1. Ваша свобода комбинирования размерностей ограничивается производительностью системы. Ну и структурой данных, если пользователи не создают сами индексы/кубы и т.д. для своих задач.
2. Необходимо помнить, что описанный Вами отчет — промежуточный материал в работе аналитика над его задачами. Конечный отчет, который ляжет на стол менеджеру, будет содержать именно сгруппированные данные, которые этот аналитик будет досчитывать в Excel-е.
3. Система, которую я описал, идеальная абстракция. На практике приходится быть гибче, и поддерживать промежуточные варианты обращения к данным. Диалектика, так сказать, в ответ на Ваш тезис)
Да. Вопросы производительности часто являются указанием насколько сырые данные надо хранить и анализировать.

Да. Окончательная визуализация в Excel — тоже необходима. Но и без красивых графиков в фронтенде тоже никуда 8)

PS Не представляю себе проектирования без диалектики.
Спасибо, очень интересная статья и полезные советы! Как раз думаем о внедрение чего то для BI. А можно немного подробностей?

Вы используйте pentaho business analytics я так понимаю?
Я так понимаю OLAP кубы тоже используются? Если да, то не совсем понятно что используется в качестве OLAP сервера? Используется ли mondrian.pentaho.com/?

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

Какие северные мощности выделенные под проект?
Данные для анализа (OLAP-кубы) располагаются и обрабатываются в Vectorwise.

Составление нового отчёта в комментарии выше

Серверные мощности критичны для базы данных. Сейчас конфигурация сервера БД такая
Диск 2Тb
Процессор 12 Cores (+12 Hyper-threading но толку от них почти нет)
192Gb RAM

Ну и плюс несколько более слабых серверов для «прочего».
Благодарю за ответ!

> Данные для анализа (OLAP-кубы) располагаются и обрабатываются в Vectorwise.
Верно ли я понимаю что у вас получается ROLAP, где pentaho business analytics (подозреваю что как раз через mondrian) преобразует MDX в SQL? Если не секрет, почему выбрали именно это решение? Рассматривали ли какие то MOLAP решения?

> 192Gb RAM
о да! охотно верю что менеджер получают отчеты в течение минут :)

В статье вы фактически описывали получения ответов на четко поставленные вопросы. А в сторону Data mining смотреть планируйте? Вроде как в продуктах pentaho какие то элементы DM заявлены.
Прочитал про ROLAP и MOLAP. На сколько я понял из описания, мы действительно используем ROLAP подход.

Думаю, что ваша гипотеза про использование Mondrian для преобразования MDX в SQL верна. Я не залезал в Pentaho глубоко.

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

Да, DM запланирован. Практически же кроме «интуиции оператора» пока никакого DM нет.
Расскажите, что используете для визуализации Pentaho. Стандартный JPivot слишком устарел и выглядит откровенно плохо. Наблюдаю за Saiku — вроде как официальная замена, но тоже вроде еще в разработке. Есть еще разработка FlexMonster — красивая, но платная… Подскажете еще что-то?
Я думаю вопрос был не мне. Но он мне тоже интересен и актуален :)
Из того что знаю я более менее живым выглядит только openi. Но не пробовал его. Был еще какой то jrubik, но он явно мертв.

За FlexMonster спасибо — не видел его раньше. Выглядит милым. Хотя не радует что Flash. С планшета уже толком не посмотришь.
У нас используется родной Pentaho Reporting (EE). Спасибо за ссылки на альтернативу.
Причина использования — почти единственный визуализатор с платной поддержкой. И как мне тут подсказывают англоязычные коллеги «with Pentaho each consultancy seems to have their own front end».
UFO landed and left these words here
Согласно вики на каждую женщину приходится 1.01 мужчины. Так что вам показалось.

PS Да, название на графике немного смущает. Там правильнее написать — доля людей указавших интересы в конкретной категории по отношению к числу людей указавших категорию вообще. Так что у наблюдаемого вами эффекта правильная трактовка — женщины склонны указывать интересы из большего числа категорий, чем мужчины.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
2006
Location
Россия
Website
badoo.com
Employees
501–1,000 employees
Registered

Habr blog