To andyk:

На форуме я не буду слишком подробно писать про свои проекты, если есть интерес - пишите мне на адрес cognos@narod.ru

Поделитесь, пожалуйста, информацией по поводу опыта крупных проектов по OLAP в российской рознице.

Мне приходилось делать 3 крупных проекта для сетей супермаркетов/гипермаркетов, максимальный объем записей - до 100 миллионов, максимальный справочник товаров - до 230 тысяч (хотя в других отраслях были объемы и побольше). В ближайшее время начну еще один проект для еще более крупной розничной сети, в кубы придется закачивать порядка 200 миллионов строк чеков в год. Хотя такие тесты я еще не проводил, руководство этой компании выбирая Cognos руководствовалось успешным опытом моих предыдущих проектов, и тем, что Cognos хорошо масштабируется - размер куба предсказуем и растет пропорционально закачиваемым данным, с постоянной скоростью, без взрывов. Стоит также отметить, что Cognos приводит как рекомендуемый ориентир 1 миллиард записей в таблице фактов (строки чеков) и 2 миллиона категорий (товары), так что запас прочности есть.

Аргументы в пользу Cognos очевидны:
1) Возможность закачки в кубы больших объемов данных без потери производительности и без необходимости предварительной агрегации на уровне РСУБД;
2) Скромные требования к железу (в качестве сервера можно использовать обычный комп класса Pentium 3-4 с оперативкой 256-512 мегабайт);
3) Возможность масштабирования в будущем (работа под Unix, распределение нагрузки между серверами);
4) Работа с популярными СУБД через прямые драйверы без необходимости использования ODBC;
5) Проектирование аналитических моделей (как серверной так и клиентской части) без необходимости программирования

To Birkhoff:

Он спросил, какие есть аргументы в пользу Когноса

Вместо того чтобы прикалываться, приведите свои аргументы в пользу Oracle :)

To Birkhoff:

Внедрял, например, в телекоме, где объемы данных явно не меньше.
Все проблемы решаются :)

Не всегда большие объемы реляционных данных закачивают в OLAP-кубы. Однако для розницы нужен очень детальный уровень, поскольку хочется иметь детализацию по времени не только до дня, но и до часов/минут суток, в разбивке по товарам, кассам/кассирам...

Какой Вы подход использовали в телекомовских проектах? Предварительно агрегировали данные на уровне РСУБД, или сразу закачивали в кубы данные с высокой детализацией? Можете ли вы привести пример количества записей, которые вы закачали в куб Oracle Express?

To Birkhoff:

Мы уже сто раз с вами обсуждали, что количество записей для MOLAP важная характеристика, но далеко не определяющая.

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

Детализация до транзакций часто делается комбинированием OLAP и ROLAP подхода, в MOLAP системе обычно хранятся все-таки предагрегированные данные.

Как я понимаю, автор дискуссии хотел чтобы данные с которыми непосредственно работают конечные пользователи хранились только в MOLAP.
В тоже время я ничего не имею против связки РСУБД и MOLAP - в двух моих розничных проектах в качестве реляционного ХД использовалась БД Oracle, и на ее основе проектировалась MOLAP-система Cognos.

To Guess:

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

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

Если же анализ сводится к стандартным отчетам - то на фига козе баян

Стандартные отчеты есть во всех торговых системах, но про них в этом форуме речь не идет, их нельзя назвать нормальными инструментами для анализа данных.

И кто бы ты нибыл ТЕРАДАТА или Oracle или COGNos - все едино.
Не готовы наши торговые предприятия к таким вложениям бабок для анализа.

Вы упомянули 3 разных продукта. Первые два действительно недешевые, но Cognos то чем Вам не нравится? Один из крупных системных интеграторов, специализирующийся на автоматизации розничных компаний (как больших, так и маленьких) прошел у меня обучение по продуктам Cognos и сейчас они предлагают своим клиентам Cognos PowerPlay в связке с их торговой системой за очень приемлемые деньги...

Чтобы потянуть такие объемы - нужны действительно сервера.
И на этом фоне стоимость софта становится небольшой.

В качестве сервера нужен компьютер стоимостью не более 1000$, это не так дорого, хотя на спор я могу создать аналитическую систему на еще более дешевом и слабом компьютере :) Хотя понятно что это справедливо только для MOLAP-продуктов типа Cognos PowerPlay.

Так что , тот кто заявляет здесь что он внедрял - не прав и я не стал бы ему верить.

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

To backfire:

Как то не вяжутся вместе ваши утвержедения о рекомендованом ориетире,
возможности закачки больших объемов и скромных требований к железу.

Я как-то упомянал, что создавал OLAP-кубы в PowerPlay на морально устаревших компьютерах типа 486 моделей с оперативкой менее 32 мегабайт. Это говорит о том, что OLAP-движок Cognos написан оптимально. Если взять мои крупные проекты, я не закачиваю в кубы за один проход сразу все записи, поскольку реляционный сервер просто не может выполнить SQL-запрос, формирующий таблицу фактов. Я закачиваю данные порциями, например за один раз - двухмесячный массив, потом инкрементально подкачиваю еще один массив, потом - еще один и т.д. Когда куб готов - ежедневное обновление куба требует подкачать небольшие объемы новых данных. Так что все вполне вяжется...

А как же Хранилище данных, вы собираетесь строить аналитичекую систему поверх зоопарка оперативных систем?

В двух из трех моих розничных проектов (не считая проекты для сетей АЗС, где тоже в принципе розница) еще до внедрения Cognos уже имелись хранилища данных, в которые стекаются данные из магазинов. В третьем проекте использовалась корпоративная система на основе СУБД Progress, в нее реплицировались данные из локальных баз магазинов, но поскольку эта СУБД имеет свою специфику - оптимальным вариантом было выгружать из нее данные в текстовые файлы и на основе этих файлов создавать кубы в PowerPlay.

5) Проектирование аналитических моделей (как серверной так и клиентской части) без необходимости программирования
Точнее было сказать без возможности программирования, что имеет следствием - проще создать ситему мышкой заново (без гарантии недопущения ошибок) чем внести мало-мальски значимые контролированые изменения в уже созданную систему.

Cognos позволяет балансировать нагрузку между РСУБД (создавая виртуальные вьюшки - SQL-запросы - в Impromptu визуальными средствами) и OLAP-сервером, где MDX тоже создается визуальными средствами, либо с помощью объектно-ориентированных конструкторов выражений. В редких случаях пользователи Cognos занимаются программированием (редактируют SQL-запросы Impromptu, пишут новые функции, используют встроенный Visual Basic).
В MS AS не такие удобные визуальные средства для проектирования кубов, а SQL-запросы по определению пишутся только вручную.

To Гликоген:

Я бы хотел дистанцироваться от Юрия, т.к. более технический специалист, и знаю наряду с сильными сторонами и слабости Cognos :)

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

Он не упоминал (видимо, потому что не работал с) Cognos DecisionStream - это визуальный ETL Builder/Engine, но в котором есть и SQL, и свой скриптовый язык.

DecisionStream я не внедрял, и соответственно не упоминаю о нем. Пока что обхожусь на практике функциональностью Impromptu.

To drive:

Если серьезно, то после такой активной рекламы в возможности Cognos верится все меньше и меньше.

Цель этого ПиАра (рекламой это назвать нельзя, поскольку за плечами людей говорящих про Cognos - реальные успешные проекты) состоит в том чтобы массовые пользователи узнали, что Excel - это не единственный аналитический инструмент, и чтобы процесс выбора аналитического продукта был более объективным. Далее кто-то заказывает демонстрацию продуктов Cognos и референс-визиты (обычно это представители компаний, которым интересна тема аналитических систем и корпоративной отчетности), а кто-то просто сидит и ни во что не верит (например представители компаний продвигающих другие BI-продукты или технические специалисты, которые не понимают, что если они расскажут про Cognos своему руководству - руководство их отблагодарит, а не заменит их ручной труд по созданию аналитических моделей на визуальные средства Cognos :) ...

Тут тебе и сервер за 1000$ и одновременно работа с детальными данными в 200-300 млн. строк. Что-то с трудом в это верится.

Под сервером за 1000$ имеется в виду компьютер, на котором будут создаваться OLAP-кубы и к которому будут коннектиться пользователи. А на каком компьютере лежат 200-300 миллионов записей - это другой вопрос, возможно он будет посерьезнее.
Я полагаю что кубы MS AS и Oracle Express требуют более дорогого железа, но для OLAP-движка Cognos можно использовать и дешевое, и проверено это на практике.

Кстати, вопрос к знатокам Cognos. А сколько одновременно с ним может активно работать пользователей, и как количество пользователей сказывается на производительности?

У компании Cognos есть проекты где в аналитической системе работают более 10 тысяч пользователей. Недавно проводились тесты продукта ReportNet, и там проверялась его работоспособность при работе 190 тысяч пользователей. Понятно что у Cognos есть и MOLAP, и ROLAP, и HOLAP, и принципы масштабирования в этих случаях разные. Но если брать самый простой и дешевый подход с MOLAP-кубами и доступом к кубам как к файлам - то количество пользователей никак не влияет на производительность (немного надо учитывать загрузку сети, но это можно и игнорировать).

To akoo:

Но его использование не может быть оптимальным для всех OLAP-задач - это однозначно

Теоретически наверное это так, осталось лишь доказать это утверждение, найти те задачи, где Cognos не оптимален :) Хотя например в качестве калькулятора оптимально использовать не PowerPlay, а Calc.exe ...

Он не оптимален ни для ПБОЮЛ, ни для Walmart. Если бы Вы высказывались не как сейлз, а как эксперт, то какая целевая область у Cognos на Ваш взгляд?

С этим я никак не соглашусь. Даже ПБОЮЛ может себе позволись заплатить 1000$ за OLAP-сервер, включающий 1 рабочее место OLAP-клиента (это минимальная конфигурация Cognos). Не всегда это будет нужно, но если ПБОЮЛ грамотный - то PowerPlay позволит ему делать сложные модели по консолидации данных из разных источников, например к своим данным подкачивать цены конкурентов. Walmart - это тоже реально для Cognos: мы ведь понимаем, что Cognos будет аналитической надстройкой над реляционным ХД, и при этом Cognos позволяет балансировать нагрузку между сервером РСУБД и OLAP-сервером. Если хочется чтобы проект выглядел солидно - у Cognos есть и дорогие конфигурации :)
Как Вы видите, стоимость минимальной конфигурации Cognos доступна всем (чего не скажешь например про Oracle OLAP, Essbase и т.п.). По сравнению с MS AS - у Cognos дешевле стоимость внедрения/быстрее можно обучить пользователей создавать кубы/отчеты.
Если брать более массовые ситуации, когда компания уже не ПБОЮЛ но еще не Walmart, то это объем данных от миллиона до 100 миллионов записей. С миллионом худо-бедно справится и ROLAP, и MOLAP-продукты, но будет проявляться фактор наличия встроенной функциональности - то есть ROLAP будет неудобен для поддержки несбалансированной иерархии справочника товаров, а продукты типа Essbase, Oracle и MS AS будет трудоемко внедрять (надо писать ручками SQL-запросы, кубы не очень визуально проектируются и т.п.). Если брать объемы порядка 100 миллионов -то ROLAP не обеспечит высокую скорость отклика, а некоторые MOLAP-продукты типа Essbase и Oracle OLAP не позволят делать кубы с детальными данными...

Какие у него преимущества конкретно перед Essbase для задачи, описанной мною в начале? P.S. ХД = Oracle

Преимущества такие:
1) Cognos в отличие от Essbase позволит закачивать в кубы детальные данные и кубы не будут взрываться
2) Кубы Cognos легче будет проектировать (визуальные средства у Cognos сильнее)
3) OLAP-клиент Cognos PowerPlay даже по мнению представителей компании Ланит значительно лучше (более гибкие для создания сложных отчетов, более красивый и наглядный интерфейс), чем стандартные OLAP-клиенты для Essbase.
4) Не уверен что в России есть внедрения Essbase в рознице
5) Не уверен, что из Essbase можно подключаться к Oracle по прямому драйверу
6) Ну и наконец - цены немного разные, как на лицензии, так и на внедрение, Cognos дешевле

Что касается слабостей Cognos перед Essbase - то теоретически они могут проявиться если будут создаваться модели анализа продаж со сложной внутренней логикой. В таком случае может потребоваться подключать второй OLAP-сервер Cognos - Cognos Planning (во многом он похож на Essbase).
однако в моих предыдущих проектах по рознице не было задач, которые не решались в PowerPlay.

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

To drive:

Ясно, что если начать серьезно иcследовать системы, то пожалуй не у одной из MOLAP-систем не будет серьезных преимуществ над другими системами, ни в производительности, ни в функциональных возможностях.

Может оказаться много мелких преимуществ (например не у всех есть иерархические показатели, не у всех хорошо поддерживаются в кубе показатели типа Дистинкт каунт, что очень актуально для розницы, не все продукты позволяют закачивать в кубы детальные данные, не для всех продуктов есть нормальные OLAP-клиенты...). Например господа Goodleo, Torin и др. часто упоминают много мелких неудобств при работе с MS AS, ни одно из них в отдельности не является поводом для перехода на другой OLAP-сервер. Однако если их вместе собрать - то набегает большой снежный ком :)

Так как ХД = Oracle, то внедрять Oracl'овые OLAP-системы будет легче, да и по стоимости, вполне возможно выйдет дешевле.

Это спорный вопрос. Слишком уж слабая Completeness of Vision (мало функциональности) у аналитических продуктов Oracle...

но в том то и дело, что Jurii так все расписал, что создалось впечатление, что сервер может быть любым, скорость от этого не зависит.

Я не теоретик - а практик, и примеры привожу из практики.

Глядите, что он пишет:
В качестве сервера нужен компьютер стоимостью не более 1000$
И глядите, что как он ответил на мой "бесмысленный" вопрос:
количество пользователей никак не влияет на производительность (немного надо учитывать загрузку сети, но это можно и игнорировать.

Я уточнил, что используется подход когда пользователи работают с кубом как с файлом. Подумайте, что будет, если файл формата Excel лежит на компьютере, и его по сети открывают на чтение 1000 пользователей? Ведь все будет работать быстро, это не вызывает сомнений. К кубам PowerPlay доступ производится только на чтение, пользователи которые параллельно работают с одним и тем же кубом друг друга не замечают и создают независимые отчеты.