To Volj:

которое могло бы за приемлемое время (не более десятка секунд) работать с кубом

За десять секунд хотите сгенерировать куб, или чтобы каждый отчет на основе куба генерировался за 10 секунд?

Динамическая работа - обязательна

Что Вы имеете в виду под динамической работой - чтобы данные в кубе хранились как ROLAP и отчеты создавались на основе SQL-запросов, а не на основе многомерных запросов?

To Volj:

Думаю Вам стоит потестировать OLAP-сервер Cognos PowerPlay (заказать ознакомительную версию можно через сайт http://cognos.narod.ru ). Несколько месяцев назад я проводил тестирование этого продукта - создал куб с 30 измерениями (в каждом - по 5 уровней иерархии), и этот куб крутился очень шустро (по 10 секунд ждать не приходилось).

To Volj:

А сколько записей было в табл фактов?

Записей было немного, всего 1000, но зато в каждом из 30 измерений было более 1000 членов/категорий/листьев. Мой опыт подсказывает, что на 250 тысячах записей все будет работать также быстро.

Сколько занимала первоначальная подготовка данных?

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

На каком сервере все крутилось? ,

Конфигурацию не помню, но сервер был более чем скромный. Cognos PowerPlay умеет работать даже на 486 компьютерах с 16 мегами оперативной памяти.

Просто Вы, как я заметил, являетесь специалистом по Cognos ( ;-) ), а я пока разберусь...

Да, у меня опыт в области Cognos - более 4 лет, это немало. Если хотите - могу поделиться :) Пишите запрос через сайт http://cognos.narod.ru ...

To Константин:

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

Вам приходилось на практике с этим сталкиваться? Я например знаю, что такая проблема есть у Oracle Express (и видимо есть у Oracle 9i OLAP) и Hyperion Essbase. OLAP-сервер MS AS по словам моего знакомого, работающего с большими БД, также имеет проблему лавинообразного роста размера куба. А вот Cognos сколько я ни тестировал - такой проблемы не встречал.

На мой взгляд, 30 измерений - достаточно много для одного куба.

Есть такая задача - анализ анкет. Например если в анкете 100 вопросов - то в кубе будет более 100 измерений... :)

Возможно, и инструменты попроще типа Cognos ... подойдут

Не забывайте, все гениальное - просто :) Попробуйте провести аналогичный моему тест на 30 измерениях в каждом из которых - 5 уровней иерархии, и Вы поймете, что Microstrategy - это все же не OLAP.

To GoodLeo:

1.Здесь каждый будет "рекламировать" то с чем работал.
3. И действительно зачем 30 (!!!!) измерений??? Тут помойму любой сервак повесится, особенно если они ещё будут типа Parent-Children

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

To Volj:

Подготовка данных - это формирование определенного OLAP-куба на основе таблицы фактов, а не их "набивка".

Ну теперь понятно. Это я называю генерацией или процессингом куба. Время необходимое для формирования куба зависит от кол-ва записей и от кол-ва категорий/листьев/членов. Я думаю для 250000 записей при 30 измерениях это будет несколько минут - но это нужно проверить экспериментально.

Вот, например, Jurii прорекламировал, что системе Cognos совершенно безразлично к-во записей в таблице фактов: что 1000, что 250000. Я, конечно, понимаю, что речь идет не о сотнях миллионов записей, но все же как, вы верно заметили, чудес не бывает :)

Я бы не сказал, что с моей стороны это была реклама - скорее я просто поделился опытом и высказал предположение. Я не спорю, чудес не бывает, но обработка 250000 записей - это не чудо, а вполне реальная задача. Мне приходилось закачивать в кубы десятки миллионов записей, в кубах было полтора десятка измерений. И я уверен, что если бы я сделал еще полтора десятка измерений - ничего бы не изменилось. Cognos PowerPlay умеет работать с пустотами в кубе, и соблюдает баланс между хранением в кубе агрегатов и формул, на основе которых производные показатели вычисляются налету.

Мне просто не хочется тратить время на набивку 250000 записей. Поэтому я предлагаю Вам потестировать ознакомительную версию PowerPlay на уже имеющихся у Вас данных.

To Volj:

Чудо - это одинаковое время обработки 1000 записей и 250000

Есть некоторое фиксированные время на "разгон" в процессе генерации куба (для 1000 и для 250000 оно одинаково). Далее записи читаются например со скоростью 10000 записей в секунду. Обычно этап чтения - самый длинный, но если например будет очень много категорий - то самым длинным будет формирование шапки куба... У Вас есть оценки, сколько элементов будет в каждом измерении?

Кстати, подскажите пропорционально чему замедляется работа при увеличении количества измерений: логарифмически, линейно, в квадрате или экспоненциально?

На мой взгляд можно говорить о линейном замедлении и только по той причине, что каждая запись будет содержать больше полей и процесс чтения будет дольше. Но я не могу сказать, что куб PowerPlay с 30 измерениями будет генериться в 15 раз дольше, чем куб с 2 измерениями. Как то давно я создавал тестовый куб с 50 измерениями для одной из структур МПС Белоруссии, и если бы число измерений влияло бы на скорость генерации куба существенно - я бы это заметил.

To Константин:

Кубы были довольно небольшими (150 МБайт), но вот, быстродейтсвие при этом было кастратофически низким. Причём попытки его поднять в виде партишионинга и других приёмов оказались не очень успешными.

Как Вы говорили насчет ХД - "Проектировать надо правильно"? ;) Это и для кубов актуально... В таких случаях надо обращаться за помощью к экспертам по Cognos через сайт http://cognos.narod.ru

Пришлось от него отказываться.

Как я понимаю, это произошло на Вашем текущем месте работы? Если да - то компания Cognos не приобрела ценного партнера. К счастью, свято место пусто не бывает, и при моем активном участии у Cognos появляются новые партнеры как в Москве, так и в регионах :)

Одноуровневые иерархии ответов с очень небольшим количеством листовых элементов. Совсем не впечатляет :). Это и на Excel можно анализировать

В Excel можно это анализировать, если объем данных небольшой.

Намекаете на то, что я ошибся форумом? То, что это не OLAP расскажите аналитикам olapreport.com, gartner

Да нет, не намекаю - просто знаю, что там где нет кубов - нет гарантии быстрого отклика на запрос пользователя. В то же время Microstrategy относится к классу Business Intelligence.
Задам ка я пожалуй этот вопрос Вашему коллеге, который будет выступать на этом мероприятии: http://www.osp.ru/BI
Заодно после просмотра 3-й части Матрицы - Революция, послушаю про Революцию в отчетности (доклад ЮРИЯ Ротманова, представителя Cognos :)

To Volj:

Есть некоторое фиксированные время на "разгон" в процессе генерации куба?
Чем в это время Cognos занимается?

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

Размер куба примерно 10E+50

Правильно ли я понимаю, что это означает, что например в 20 измерениях у Вас по 100 элементов, а еще в 10 измерениях - по 10 элементов? (100^20*10^10 = 10^50)

Имеется в виду размер базы, на основании которой рассчитывается куб, или размер куба с просчитанными аггрегатами?

Константин имел в виду размер куба с просчитанными агрегатами.

А как, вообще, Cognos переваривает обратную моей ситуацию: сотни миллионов записей в табл фактов и относительно небольшой (5-7 измерений) куб?

Приведу пример: В кубе по анализу продаж 10 измерений и 12 показателей. Закачиваются данные порциями по 5-6 миллионов записей - каждая порция - по 25 минут. Всего около 90 миллионов записей. Размер куба со всеми агрегатами - около гигабайта. Отчеты в любых разрезах на компьютерах Pentium-2 256 Mb оперативки - летают, по 10 секунд ждать не приходится.

To Volj:

А время аггрегирования какое? Или аггрегирование было учтено в "25 минут"?

Да, каждые 5-6 миллионов записей подкачивались за 25 минут (включая чтение и агрегирование).

А почему кстати вам не подходит ROLAP решение типа Business Objects или Oracle Discoverer?
Может, и подходит, я же не знаю :)

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

To Birkhoff:

Для пользователя это видится почти как настоящий OLAP.

Только вот время отклика будет похуже и по иерархиям не очень удобно будет перемещаться...

Тем более представьте мучения пользователя, которому для каждого конкретного отчета нужны 3-4-5 измерений, а у него на экране нависают все 30

Продвинутые OLAP-клиенты позволяют скрыть ненужные измерения, чтобы не нависали :)

Для поиска скрытых закономерностей в основном нужна голова или data mining. Технология визуализации данных имеет второстепенное значение

Голова всегда нужна :) А OLAP ценен не только визуализацией, но и наличием возможности быстро выбирать нужные оси координат отчета, быстро накладывать фильтры, и мгновенно получать отчет.

To Volj:

А про data mining мне бы очень хотелось узнать побольше. Есть ли продукт, в котором интегрирован OLAP и data mining?

У Cognos OLAP интегрирован с data mining. Рекомендую скачать с моего сайта небольшую презентацию по теме data mining:
http://cognos.narod.ru/Scenario1.ppt

Однако самое важное для data mining - это наличие факторов и целевых функций. Чтобы получить их (вычислить на основе данных из учетной системы), надо использовать продукты класса Query & Reporting и/или OLAP. У Cognos все это есть в интегрированном виде.

Стоит упомянуть OLAP-сервер MS Analysis Services, в котором есть data mining, о вот функциональности Query & Reporting там нет, по крайней мере пока (это означает, что Вам придется вычислять факторы не визуальными средствами, а с помощью SQL-запросов, которые Вы будете писать вручную).

To Константин:

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

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

Продвинутые OLAP-клиенты позволяют скрыть ненужные измерения, чтобы не нависали :)
Я думаю, что это умеют любые клиенты, а не только продвинутые.

Если я не ошибаюсь, Вы больше знакомы с OLAP-клиентом PowerPlay. Это продвинутый клиент. А во многих других клиентах нет многого из того, что есть в PowerPlay...

В этом плане у Microstrategy всё в порядке - 45 встроенных статистических функции.

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

Исключение членов из измерения делается просто и выброс в графу "прочие" - тоже с помощью механизма пользовательских группировок.

ROLAP-продукты это позволяют, но они на это не заточены! То есть сделать это не так удобно, как например создать вычисляемую строку прочие в OLAP-клиенте и скрыть остальные ненужные строки. Я уж не говорю про Парэто-фильтр "80 на 20" в OLAP-клиенте, когда пользователю не надо думать, кого запихивать в группу прочие...

У Microstrategy data mining отсутствует, хотя они и пишут, что он есть.
Из всех производителей OLAP, мне кажется, только у Microsoft есть что-то более-менее достойное

В том то и проблема, что мало у кого есть Query & Reporting, OLAP и data mining в ИНТЕГРИРОВАННОМ виде. Видимо поэтому Cognos, как аналитический продукт, во всех известных рейтингах стоит либо на первом месте, либо в тройке лидеров.
Конкуренцию Cognos теоретически могли бы составить Microsoft и Oracle, но у этих компаний другая стратегия - ориентироваться на разработчиков - чтобы в мире было много приложений на их платформах со средненьким качеством, а не одно - с высоким качеством (многочисленные разрозненные разработчики не могут инвестировать в разработку столько, сколько инвестирует крупный производитель BI-продуктов).

To Константин:

В особенности, у MS AS, где существует явная поддержка несбалансированных иерархий.

Этот вопрос в свое время детально обсуждался. У MS AS есть поддержка в явном виде структуры ID, Name, Parent_ID, но работает она реально на не очень ветвистых измерениях (до 5 тысяч листьев все OK, до 50 тысяч - еще можно, но более 50 тысяч - тормозит). Схлопывания пустых уровней иерархии у MS AS не было обнаружено. Таким образом, у Cognos работа с несбалансированными иерархиями иногда менее удобна, чем в MS AS, но зато - более универсальна (в случаях когда иерархия хранится не в трех полях, а по-другому, или на больших объемах данных).

А если сервер не использовать? Если куб только на клиенте, тогда как? Я уже подзабыл как это там будет.

Вы наверное спрашиваете про минимальную конфигурацию PowerPlay User? Если да - то ее функциональность и мощность мало отличается от более серьезных серверных конфигураций PowerPlay. Схлопывание уровней в PPU имеется.

PowerPlay, действительно удобен, не спорю. Только функциональности очень не хватает.

Как-то г-н GoodLeo перечислил свои требования к OLAP-клиентам, и PowerPlay наиболее полно соответствует этим требованиям. Если Вы не находите в OLAP-продукте PowerPlay той функциональности, которая есть в знакомых Вам продуктах класса Query & Reporting, то такая функциональность есть в продукте Cognos Impromptu, который обычно используется в связке с PowerPlay.

Очевидно, Вам стоит познакомиться с Microstrategy

С удовольствием это сделаю, как только подвернется такая возможность :)

Как у Cognos с правилом 70 на 30 дела обстоят? Или с 65 на 35?
Можно это так же легко сделать?

Это можно делать либо в Impromptu (по аналогии с BusinessObjects или Microstrategy), либо в PowerPlay, используя функцию "Кумулятивный Процент от базы".

Интегрировать всё могут себе позволить только очень крупные компании.
Интегрированные решения имеют компании IBM, Oracle, NCR, то есть крупнейшие игроки на рынке хранилищ данных.

Я думаю у нас разные понятия о термине интегрированность. Вы хотите сказать, что SQL-запросы, подготовленные в Oracle Discoverer можно использовать как таблицы фактов для Oracle Express? В том то и весь кайф, что результаты работы Cognos Impromptu могут быть сохранены в виде виртуальной вьюшки, и эта вьюшка служит таблицей фактов для проектирования кубов PowerPlay и источником данных для data mining в Scenario. А из куба PowerPlay ожно настроить drill through через эту вьюшку, причем визуальными средствами.

К вопросу о data mining - а какие у Cognos продукты класса data mining?
(подсказка: 4Thought не называть - нейронные сети, как ни странно, не относятся к data mining).

Сами по себе нейронные сети может и не относятся к Data Mining, но 4Thought - это продукт, позволяющий анализировать влияние факторов на целевые функции - на мой взгляд это чистый data mining. Ну и еще к data mining относится вышеупомянутый продукт Scenario.

Насчёт интегрированности решения Cognos - я бы всё-таки постеснялся.
Практический пример - Вы можете точно сказать в каких отчётах Impromptu и кубах PowerPlay участвуют данные из определённой таблицы базы данных?
Сколько Вам понадобится времени для ответа на этот вопрос?

На практике интеграция Cognos работает через виртуальные вьюшки. И поскольку продукты Cognos умеют работать напрямую с OLTP, структура которой меняется редко - отвечать на Ваш вопрос тоже приходится редко. А те продукты, которые требуют единое ХД (MS AS и все продукты ROLAP/Query & Reporting) - действительно нуждаются в быстрых ответах на Ваш вопрос, поскольку ХД изменяется/дорабатывается часто.

Как показывает практика, конкуренции с Microsoft не выдерживает ни одна маленькая компания (каковой является Cognos, да и Microstrategy и BusinessObjects). С Microsoft надо дружить, а не конкурировать, но всё равно сожрут :)

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

А что касается дружбы с Microsoft, то у Cognos это имеется (прямые драйверы к MS SQL, работа напрямую с Excel, Access, PowerPlay User - это в том числе OLAP-клиент для MS AS, Cognos поддерживает настройки безопасности Active Directory Server, использует MS Internet Explorer как Web-клиента и т.п.).