2 Kaniovski:

Необходимо иметь возможность строить кубы на основе разных реляционных БД (Oracle и MSSQL).

Microstrategy не умеет строить кубы, это ее самый существенный недостаток, со всеми вытекающими последствиями.

Так что если Вам реально надо строить кубы - выбирайте решение среди OLAP-продуктов (кроме MS AS это Cognos PowerPlay/Cognos 8 BI, Oracle Express/10G, Hyperion Essbase).

2 Гликоген:

C другой стороны, если нравится - можно брать, по заявкам они имеют все то же, что и Cognos/Hyperion/BO

Хорошее сравнение - ROLAP с ROLAP+MOLAP... Конечно если посмотреть что все эти системы - нероссийские, позволяют делать отчеты, выгружать данные в Excel, то можно сделать вывод, что они одинаковые. Но так тупо сейчас уже мало кто выбирает систему :)

Самое слабое место Microstrategy - это, как пишут в интернете, то что г-н Сакович уволился с должности менеджера по продажам компании S & T :)

2 MSTR_Fan:

P.S. Jurii, а Вы только на удобные вопросы отвечаете теперь? ;-)

Если Вы имеете в виду что я не ответил на интересные вопросы в дискуссии "OLAP на хранилищах от разных СУБД", то я обязательно отвечу в ближайшие дни. Вопрос там довольно серьезный требует точного ответа, а на это пока времени нет...
На этом форуме я пока не встречал неудобных вопросов ;)

2 MSTR_admin:

то что г-н Сакович уволился с должности менеджера по продажам компании S & T :)
:) г-н Сакович наверно упадет со стула, когда узнает, что был менеджером по продажам

Я это не с потолка взял :) В Яндексе легко найти ссылки, например вот эту:
http://www.it-vip.ru/Person.asp?ID=3401&Display=1&First_Letter=%D1

А чтобы г-ну Саковичу было не больно падать, прошу г-на Гликогена подстелить мягкий коврик для своего коллеги :)

Юра не надо путать свою профессию с профессией специалистов :)

Я по должности - руководитель проектов, не привык что-либо путать.

Microstrategy не умеет строить кубы, это ее самый существенный недостаток, со всеми вытекающими последствиями.
почитайте обзоры - MicroStrategy уже 2,5 года является HOLAP-системой, со всеми вытекающими (мало того, что куб можно построить - вы не ограничены размером куба и в любой момент можете провести анализ за его пределы, вплоть до транзакционной информации в хранилище)

Есть мнение, что Microstrategy - это все-таки прямые SQL-запросы к реляционным хранилищам данных, то есть это не OLAP-продукт. Вы с этим не согласны? Если не согласны, приведите аргументы. То что система относится к классу HOLAP, не говорит, что у нее есть OLAP-серверная функциональность (например BO умеет делать микрокубы, но это не OLAP, это разогретый кэш). Простой тест, позволяющий определить, является ли Microstrategy OLAP-сервером, это взять текстовый файл формата CSV размером 1 гигабайт, сделать из него куб в Microstrategy, и потом подкачать инкрементально в этот куб другой текстовый файл. И после этого отчеты поверх этого OLAP-куба (типа показать динамику продаж групп товаров по месяцам) должны выполняться быстро на обычном компьютере, за доли секунды, или максимум за секунды, но не за минуты. Справится ли с этим тестом Microstrategy, или "OLAP" там устроен по-другому?

2 Kaniovski:

Из официальных источников (с официального сайта) я вычитал что MicroStrategy может не только работать с огромными массивами реляционных данных, но и создавать собственные кубы.

С огромными массивами реляционных данных работает не MSTR, а движок реляционной СУБД (Oracle, Терадата), куда MSTR передает свои SQL-запросы. То что MSTR может создавать кубы - это вопрос, на который пока никто толком не пролил свет. Что это за кубы? Реляционный кэш, микрокубы, или действительно многомерная БД?

2 MSTR_Fan:

Специализация - качественные OLAP-решения на больших реляционных хранилищах данных, то есть если "сырых" данных меньше, скажем, 30 Гб, и не требуется сложный анализ на детальном уровне - MS AS или Cognos PP гораздо более оправданное решение

30 Гб - это странная оценка... Я считаю что ее надо как минимум на порядок поднять, до терабайта (так как терабайт - это не много для Cognos). То что выше терабайта - это отдельная тема. Там уже не на последнем месте крутизна сервера РСУБД. И я полагаю, что если у нас есть ХД в котором 100 терабайт данных, на его основе можно делать OLAP-кубы для разных групп пользователей, и пользователям это будет удобнее чем делать прямые запросы и ждать часами пока сгенерируются отчеты.

По этой причине MSTR очень силен в аналитике розничных продаж

А есть ли в России примеры успешных внедрений MSTR в крупной рознице, или это все только реклама?

Куб = многомерный кэш
Если будете утверждать, что Куб обязательно должен быть MDBMS - приведите источник из классиков, а не "квадраты Гартнера" :)

Кэш или не кэш, не важно как называть. Важно например, можно ли обновлять этот кэш инкрементально? То есть подкачав к миллиону записей еще одну запись оперативно пересчитать все агрегированные значения? Я так понимаю что в MSTR это не делается, и при появлении одного нового документа надо будет заново обработать документы за всю историю чтобы актуализировать данные в отчетах... И вопрос то стоит шире - например OLAP-сервер должен позволять проводить вычисления, которые опираются на агрегаты...

2 Виктор Сакович и Гликоген:

Долго озирался вокруг, но, поскольку господина Гликогена не увидел, со стула решил не падать
Ответственно заявляю, что с Саковичем никогда не работал! :)

А Ваши IP-адреса говорят о том, что вы работаете в одной и той же компании-партнере Cognos :) С IP-адресом не поспоришь...

2 MSTR_admin:

менеджер по продажам == консультант по продажам
горе тех.специалисту, попавшему в вашу команду :)

Бывают консультанты по внедрению, технические консультанты, но консультанты по продажам - это то же самое что и менеджеры по продажам.

Есть мнение, что Microstrategy - это все-таки прямые SQL-запросы к реляционным хранилищам данных, то есть это не OLAP-продукт.
Это ваше мнение? тогда опустим сий бесполезный спор

Это мнение коллективное, его в свое время насколько я помню высказывал Константин Лисянский.

способен ли современный протокол передачи данных отобразить детальную информацию по 1Gb данных за время <5 секунд?
или всё таки признаем, что сказки про 5 секунд - пыль в глаза

Я не говорю что надо за 5 секунд визуализировать весь гигабайт данных, я говорил про аналитический запрос - например вывести продажи групп товаров по месяцам. С Cognos PowerPlay архитектура понятна - все агрегаты там просчитаны заранее, и они визуализируются в пределах 5 секунд. А вот MSTR будет налету обрабатывать миллионы записей SQL-запросом...

2 MSTR_*:

Да уж, много вас под серыми никами развелось на форуме :) Интересно, делали ли вы хоть один серьезный проект на MSTR, или поскольку вы продавцы/маркетологи - вам такими мелочами заниматься не положено? :)

2 MSTR_Fan:

30 Гб - это странная оценка... Я считаю что ее надо как минимум на порядок поднять, до терабайта (так как терабайт - это не много для Cognos
Я написал эту оценку потому что хорошо представляю себе возможности этих технологий. Мы здесь говорим о серьезной аналитической системе, а в такой, будь это куб или таблицы в РХД, данные хранятся на транзакционном уровне, и MOLAP, с ростом объёмов, хорош только для менеджерских агрегированных отчетов, с этим даже никто не спорит. Неужели Вы считает, что кто-либо из читающих поверит в то что кому-то в здравом уме придет в голову мысль заливать целиком многомиллиардную таблицу с CDR или чеками?

Серьезная аналитическая система должна иметь единый семантический слой, который ссылается и на реляционные таблицы, и на OLAP-кубы. Записи CDR по закону надо хранить в определенном объеме определенное время, и если потребуется - по индексу для одного телефонного номера можно посмотреть все записи без использования OLAP. Но вот например проанализировать розничные продажи без OLAP-просто нереально. OLAP-сервер позволяет например создать формулу, которая учтет каждый чек, на основе формулы можно сделать интересный аналитический разрез, и при этом не обязательно закачивать все чеки в куб (хотя пожалуй если речь идет о чеках - их стоит держать в кубе по всем магазинам за всю историю, вот все CDR можно не закачивать).

Я вообще не в курсе, а Метро, Ашан, Мигрос, Оби - они разве уже свой бизнес в России свернули? Или их размер Вас не устраивает? :-)

Согласен, это серьезная розница. Но я сомневаюсь, что например в Ашане успешно внедрена MSTR. Недавно было объявлено что Ашан выбрал BO в качестве системы репортинга, и в этом пресс-релизе был намек на то, что анализ данных в Ашане делается с помощью MS AS...

2 just_me:

И MSTR и BO поддерживают агрегат таблицы.
При этом переводят обработку запроса пользователя (переписав запрос к другим таблицам), если запрашиваемые данные находятся вне агрегат таблиц (в Вашей терминологии кубов).

Таблицы с агрегатами и OLAP-кубы - это совершенно разные вещи. Таблицы надо проектировать, поддерживать, писать и переписывать процедуры их обновления... А кубы - это более высокий уровень, где оперируют бизнес-терминами пользователей. Один куб содержит столько агрегатов, сколько не поместится и в тысяче таблиц. Спроектировать и поддерживать OLAP-куб на порядки удобнее и эффективнее, чем таблицы с агрегатами. Да и с точки зрения компактность/производительность, OLAP-куб лучше, чем таблицы...

Кэширование в MSTR и локальные микрокубы - это уже другая тема.

То есть Вы подтверждаете, что OLAP-кубы в MSTR отсутствуют, и их заменяют таблицы с агрегатами, которые создает разработчик хранилища данных?

2 MSTR_admin:

p.s.: иногда лучше жевать ... чем заниматься рукофлудием, Юра

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

2 MSTR_Fan:

Ясно что Вы и близко не видели серьезных розничных или телко моделей, таких как IBM RDW, Teradata RetailDecisions, Nokia NDW

Эти модели с научной точки зрения интересны, но на практике мало применимы. Даже те кто ездит на экскурсии за границу смотреть внедрения этих моделей, приезжает оттуда не в восторге...

Недавно было объявлено что Ашан выбрал BO в качестве системы репортинга, и в этом пресс-релизе был намек на то, что анализ данных в Ашане делается с помощью MS AS...
Впечатляющие познания. "я сомневаюсь","был намек".

Вы не читали этот пресс-релиз на сайте компании Терн?

Мне очень странно такое Ваше неприятие MSTR. Вас разве сильно обидели? Право слово, ну подвинули Вас в нескольких тендерах, ну разве это повод так врать в публичном месте?

Я не имею ничего против MSTR. Просто меня удивляет, что есть много фанатов MSTR, которые не рассказывают о реальных проектах, обходятся общими словами, засоряют форум... И в интернете про MSTR ничего кроме рекламы не увидишь - ни одного описанного проекта в России...

Кроме того, я уверен что все высказывавшиеся в этом топике люди работают в команиях, партнерах Вашего любимого вендора, а кое-кто даже внедрял его ;-)

А Вы интересно где работаете? :)

Советую завязывать с грязью в сторону MSTR и BO, а то окончательно прослывете клоуном, да и Cognos не лучшую репутацию сделаете.

Хороший аргумент в защиту MSTR и BO :)

Благодаря г-ну Kaniovski наконец то мы узнали больше про MSTR...

Вчера я упоминал, что MSTR - это не OLAP-сервер, не умеет строить кубы.
Сначала г-н MSTR_admin ответил:

в рекламных проспектах когноса - конечно не умеет
почитайте обзоры - MicroStrategy уже 2,5 года является HOLAP-системой, со всеми вытекающими (мало того, что куб можно построить - вы не ограничены размером куба и в любой момент можете провести анализ за его пределы, вплоть до транзакционной информации в хранилище)

потом г-н just me добавил:

И MSTR и BO поддерживают агрегат таблицы.
При этом переводят обработку запроса пользователя (переписав запрос к другим таблицам), если запрашиваемые данные находятся вне агрегат таблиц (в Вашей терминологии кубов).

потом появился наивный уточняющий вопрос от г-на Прохорова:

А что Вы подразумеваете под OLAP сервером?
Вопрос не праздный, т.к. четкого определения этого термина нет, и почти каждый участник форума подразумевает под ним что-то свое. Укажите, какие именно OLAP возможности Вас интересуют.

и в конце Виктор Сакович признался, что:

Изначально MSTR - это ROLAP продукт, но года три назад там появилась и некоторая MOLAP функциональность, то есть теперь это вроде как HOLAP

Особенно мне нравится некоторая и вроде как :)

Не понимаю, почему специалисты по MSTR так уходят от ответов про OLAP в MSTR... Это какая-то мафия со своими тайнами получается. И почему-то вместо аргументированной цивилизованной дискуссии эти мафиози всегда переводят разговор на Cognos (вместо того чтобы рассказать про процесс создания кубов в MSTR, про длительность этого процесса и про время отклика на запросы пользователей к кубам, несут полный бред типа Тем более на этом форуме практически на каждый топик прибегает Jurii и начинает впаривать Cognos. ).

2 Kaniovski:

Могу ли я узнать подробности о том, как Вас ввели в заблуждение и кто это сделал? (с каким Юрием Вы лично общались на тему Cognos и сформировали искаженное мнение о Cognos)?

2 Kaniovski:

Меня не вводили в заблуждение по поводу Cognos и я действительно прослушал вводную лекцию об этом продукте в компании http://www.bipartner.ru

Интересно... После Ваших слов ознакомился с Cognos несколько дней назад, спасибо Юрию. Могу некоторые мысли озвучить. После беседы с Юрием его специалистами я подумал, что Вас обманули. А сейчас Вы говорите что Вас никто не обманывал... Ну ладно, будем считать что Вы второпях неправильно сформулировали свой постинг.

2 Виктор Сакович:

Для того, чтобы понять, какой продукт лучше подойдёт, логичнее плясать от того, какая функциональность Вам нужна, а не от того, как это там устроено. Устроено всё совсем не MS AS, я уже писал.

Да, это верно. Хотя если в MSTR совсем нет базовой функциональности многомерного OLAP, которая есть в MS AS, это не есть хорошо, так как многомерный OLAP ничем не заменишь...

Я, честно говоря, не понимаю, что Вы, Yurii делаете в этом топике.

Автор топика сразу сказал, что ему надо строить кубы. Я сообщил что MSTR не умеет строить кубы. Что же в этом нелогичного? Форум для того и создан чтобы отвечать на вопросы и повышать уровень информированности посетителей форума.

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

Я знаю только один тендер, где наша компания проиграла MSTR. Причина была в том, что MSTR была ранее внедрена в одном из региональных подразделений этой компании, и компания решила идти по обкатанной дорожке. Однако поскольку объемы данных в регионе и в центральном офисе этой компании отличаются как минимум на порядок, я считаю что для Cognos еще не все потеряно :)

вместо этого ищете какую-то мафию, или выясняете, есть ли внутри MSTR (или BO) что-то вроде Cognos PP

Что ее искать, и так все очевидно - несколько человек под серыми никами (или может это один и тот же специалист по MSTR) не обогащают форум своим опытом, а постоянно переходят на личности :) Надеюсь что Вы до такого не опускаетесь и постите всегда под своим ником...
Я не ищу Cognos PP внутри MSTR - я лишь хочу понять, что из OLAP есть в MSTR.

Но это вовсе не означает, что эти продукты не являются OLAP-продуктами

Если MSTR не умеет делать OLAP-кубы и не может быстро генерировать аналитические отчеты, то хоть называй ее OLAPом, хоть не называй - все равно понятно что посноценной аналитической системы на ее основе не создашь. Хотя для стандартных отчетов она может и подойдет.

В конце концов ReportNet удивительно напоминает MicroStrategy, но Вы нигде не говорите, что он не является OLAP продуктом

Я периодически говорю, что у Cognos есть функциональность Query & Reporting (в продукте Impromptu/ReportNet/Cognos 8 BI), и говорю что это функциональность, аналогичная BO и MSTR. Так как BO и MSTR я не считаю OLAP-продуктами, то и ReportNet тоже не считаю. Самой ценной функциональностью Cognos для пользователей я считаю OLAP-сервер PowerPlay.

2 Виктор Сакович:

Причина была в том, что MSTR была ранее внедрена в одном из региональных подразделений этой компании, и компания решила идти по обкатанной дорожке. Однако поскольку объемы данных в регионе и в центральном офисе этой компании отличаются как минимум на порядок, я считаю что для Cognos еще не все потеряно
Это несомненно так.

К чему относится Ваша фраза "Это несомненно так"? К обкатанной дорожке, или к тому что сейчас у заказчика MSTR конкретно тормозит, нет возможности анализировать детальные данные по продажам, на полках из-за этого часто отсутствуют лекарства и в итоге страдают (хорошо если не умирают) покупатели? Здоровье нации - дело серьезное, поэтому львиная доля фармацевтических компаний используют OLAP-продукты, а не медленный репортинг).

А ещё Вы не смогли продемонстрировать решение большинства задач, которые были предложены клиентом, частично потому, что Cognos PP не предназначен для решения таких задач, частично, может быть, из-за Вашей некомпетентности в продукте Cognos PP.

Мы вовремя не узнали, что региональное подразделение этой компании использует MSTR, и поэтому не смогли избежать необъективности в этом тендере. Часть задач была легкими, а другая часть - заточена на сильные стороны MSTR. Так как Cognos имеет ту функциональность, которая нужна миллионам менеджеров и руководителей, в нем не была учтена эта экзотическая функциональность :) Эти задачи можно было решить в модуле, аналогичном MSTR - в Impromptu, но мы знали, что в крупных розничных сетях из-за большого объема данных, кроме OLAP ничего реально работать не может. Поэтому мы показали PowerPlay, продемонстрировали те задачи, которые реально актуальны для розницы (из нашего отраслевого решения для розницы), прямо на глазах представителей заказчика выяснили, в каких аптеках в такое-то время суток лучше всего продается виагра :) Покрутили кубики, показали средний отклик на запрос в пределах 5 секунд. Но по формальным признакам мы не дотянули до победы :)

Вы пришли с магическими квадратами Гарднера и заунывной песней о том, что MicroStrategy не умеет делать инкрементальное обновление кубов

Это была не песня, а многолетний опыт внедрения аналитических систем в крупной рознице. Без инкрементального обновления OLAP-кубов аналитическая система работать не будет. Поскольку пресс-релиза об успешном внедрении MSTR у этого заказчика опубликовано не было, то боюсь что мой опыт меня не обманывает, и MSTR не позволяет заказчику анализировать данные (уж не говоря о таких темах как визуализация данных на картах и планограммах).

На мой взгляд, Вы зря уж так сильно ополчились на MSTR. Всё таки Вашим основным конкурентом на ближайшее время будет MS AS 2005. Я считаю, что Microsoft сделал очень хороший продукт, реализовав практически всю функциональность, которую можно иметь в MOLAP технологиях.

Я не ополчился на MSTR. Просто хочется расставить все точки над "i", развеять тайну, окутывающую MSTR. Хочется подтвердить мои гипотезы о сильных и слабых сторонах MSTR. Однако специалисты по MSTR - это похоже одни сейлзы и маркетологи, не имеющие опыта внедрения MSTR и ссылающиеся только на мифические проекты, сделанные на Западе. И с такими специалистами тяжело разговаривать на техническом языке.
Точно так же я хочу разобраться в сильных и слабых сторонах BO и MS AS.
А насчет конкуренции - это как-то несерьезно. Не могут MS AS, MSTR, BO и т.п. конкурировать с Cognos, поскольку у них есть лишь половинчатая функциональность (либо OLAP, либо репортинг), а у Cognos - полная функциональность (OLAP и репортинг интегрированы).