Comments 18
Утверждение про то, что нужно анализировать «сырые» данные, очень спорное. По мере расширения перечня задач, которые решает система, я, например, пришел к тому, что в конечные отчеты вообще не должны попадать непредрассчитанные и не сохраненные в БД агрегации. Кроме того, в случае изменения исходных данных и их перерасчета, предыдущую версию данных пользовательского отчета во многих случаях лучше сохранить. Соображений в пользу этого несколько. Основные: 1) не оставить пользователя без отчета, когда идет обновление «сырых» данных; 2) давать возможность получить предварительный отчет по неполным данным, а потом узнать какая составляющая изменилась.
Сколько уходит времени у пользователя вашей системы, чтобы создать новый отчёт, который до этого никому кроме него и не нужен был? У нас это время меньше минуты (на манипуляции с интерфейсом).
Смотря, что понимать под новым отчетом.
1. Если новый перечень объектов/агрегация (даты, подразделения, продукты...) — то они все они предсказуемы и предрасчитаны (даты — месяца, кварталы, годы; подразделения — более крупные подразделения и т.д.)
2. Если совсем новый показатель — то печалька: пользователь его сам не создаст. Но это не страшно при "вытягивающей" системе работы, если данных, которых пользователи не заказывали, в БД не появляется.
1. Если новый перечень объектов/агрегация (даты, подразделения, продукты...) — то они все они предсказуемы и предрасчитаны (даты — месяца, кварталы, годы; подразделения — более крупные подразделения и т.д.)
2. Если совсем новый показатель — то печалька: пользователь его сам не создаст. Но это не страшно при "вытягивающей" системе работы, если данных, которых пользователи не заказывали, в БД не появляется.
Давайте снова рассмотрим пример «сколько денег потратили холостые гетеросексуалы из Калифорнии возрастом до 25 лет за каждый месяц прошлого года».
У нас менеджер для этого
— Указывает метрику IncomeLog
— Указывает размерности: gender search, country, state, payment month, marital status, age
— Указывает фильтры по размерностям.
То есть мы указываем доступные метрики и размерности. А как их комбинировать — дело пользователя.
Если я правильно понял ваш пример — у вас нет свободы комбинирования размерностей. Только те, что посчитаны заранее.
У нас менеджер для этого
— Указывает метрику IncomeLog
— Указывает размерности: gender search, country, state, payment month, marital status, age
— Указывает фильтры по размерностям.
То есть мы указываем доступные метрики и размерности. А как их комбинировать — дело пользователя.
Если я правильно понял ваш пример — у вас нет свободы комбинирования размерностей. Только те, что посчитаны заранее.
Да, Вы правильно поняли.
Но, хотелось бы ещё отметить три разноплановых момента:
1. Ваша свобода комбинирования размерностей ограничивается производительностью системы. Ну и структурой данных, если пользователи не создают сами индексы/кубы и т.д. для своих задач.
2. Необходимо помнить, что описанный Вами отчет — промежуточный материал в работе аналитика над его задачами. Конечный отчет, который ляжет на стол менеджеру, будет содержать именно сгруппированные данные, которые этот аналитик будет досчитывать в Excel-е.
3. Система, которую я описал, идеальная абстракция. На практике приходится быть гибче, и поддерживать промежуточные варианты обращения к данным. Диалектика, так сказать, в ответ на Ваш тезис)
Но, хотелось бы ещё отметить три разноплановых момента:
1. Ваша свобода комбинирования размерностей ограничивается производительностью системы. Ну и структурой данных, если пользователи не создают сами индексы/кубы и т.д. для своих задач.
2. Необходимо помнить, что описанный Вами отчет — промежуточный материал в работе аналитика над его задачами. Конечный отчет, который ляжет на стол менеджеру, будет содержать именно сгруппированные данные, которые этот аналитик будет досчитывать в Excel-е.
3. Система, которую я описал, идеальная абстракция. На практике приходится быть гибче, и поддерживать промежуточные варианты обращения к данным. Диалектика, так сказать, в ответ на Ваш тезис)
Спасибо, очень интересная статья и полезные советы! Как раз думаем о внедрение чего то для BI. А можно немного подробностей?
Вы используйте pentaho business analytics я так понимаю?
Я так понимаю OLAP кубы тоже используются? Если да, то не совсем понятно что используется в качестве OLAP сервера? Используется ли mondrian.pentaho.com/?
Так же очень интересно, насколько эта связка позволяет вам быстро создавать новые отчеты? Грубо говоря, менеджер захотел новый отчет — какие ваши дальнейшие действия и как быстро он получит желанные данные?
Какие северные мощности выделенные под проект?
Вы используйте pentaho business analytics я так понимаю?
Я так понимаю OLAP кубы тоже используются? Если да, то не совсем понятно что используется в качестве OLAP сервера? Используется ли mondrian.pentaho.com/?
Так же очень интересно, насколько эта связка позволяет вам быстро создавать новые отчеты? Грубо говоря, менеджер захотел новый отчет — какие ваши дальнейшие действия и как быстро он получит желанные данные?
Какие северные мощности выделенные под проект?
Данные для анализа (OLAP-кубы) располагаются и обрабатываются в Vectorwise.
Составление нового отчёта в комментарии выше
Серверные мощности критичны для базы данных. Сейчас конфигурация сервера БД такая
Диск 2Тb
Процессор 12 Cores (+12 Hyper-threading но толку от них почти нет)
192Gb RAM
Ну и плюс несколько более слабых серверов для «прочего».
Составление нового отчёта в комментарии выше
Серверные мощности критичны для базы данных. Сейчас конфигурация сервера БД такая
Диск 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 заявлены.
> Данные для анализа (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 нет.
Думаю, что ваша гипотеза про использование Mondrian для преобразования MDX в SQL верна. Я не залезал в Pentaho глубоко.
Выбор ПО и технологий для построения системы прошёл без моего участия, потому я не осведомлён какие конкуренты рассматривались в том выборе. Если вас действительно интересуют детали, предлагаю увести переписку по этому вопросу в приват.
Да, DM запланирован. Практически же кроме «интуиции оператора» пока никакого DM нет.
Расскажите, что используете для визуализации Pentaho. Стандартный JPivot слишком устарел и выглядит откровенно плохо. Наблюдаю за Saiku — вроде как официальная замена, но тоже вроде еще в разработке. Есть еще разработка FlexMonster — красивая, но платная… Подскажете еще что-то?
Я думаю вопрос был не мне. Но он мне тоже интересен и актуален :)
Из того что знаю я более менее живым выглядит только openi. Но не пробовал его. Был еще какой то jrubik, но он явно мертв.
За FlexMonster спасибо — не видел его раньше. Выглядит милым. Хотя не радует что Flash. С планшета уже толком не посмотришь.
Из того что знаю я более менее живым выглядит только openi. Но не пробовал его. Был еще какой то jrubik, но он явно мертв.
За FlexMonster спасибо — не видел его раньше. Выглядит милым. Хотя не радует что Flash. С планшета уже толком не посмотришь.
У нас используется родной Pentaho Reporting (EE). Спасибо за ссылки на альтернативу.
UFO just landed and posted this here
Согласно вики на каждую женщину приходится 1.01 мужчины. Так что вам показалось.
PS Да, название на графике немного смущает. Там правильнее написать — доля людей указавших интересы в конкретной категории по отношению к числу людей указавших категорию вообще. Так что у наблюдаемого вами эффекта правильная трактовка — женщины склонны указывать интересы из большего числа категорий, чем мужчины.
PS Да, название на графике немного смущает. Там правильнее написать — доля людей указавших интересы в конкретной категории по отношению к числу людей указавших категорию вообще. Так что у наблюдаемого вами эффекта правильная трактовка — женщины склонны указывать интересы из большего числа категорий, чем мужчины.
Да, все-таки есть разделение - данные для аналитиков (тут конечно лучше иметь доступ к "сырым" данным) и данные для топ-менеджеров/руководителей - им вполне достаточно иметь доступ к агрегированным данным (отчеты/дашборды, даже по рассылке).
Мне например в компании удобнее получать XLS файл со сводкой информации раз в неделю, чем заходить в систему BI.
Sign up to leave a comment.
Как создать систему бизнес-аналитики и не наломать дров