На недавней конференции по BI было выступление представителя компании Диасофт насчет внедрений хранилищ данных и аналитических систем в банках. Он упоминал, что в качестве аналитического инструментария использовались разные продукты (Cognos, BusinessObjects, Microstrategy). Также он говорил, что размеры ХД доходят до сотни гигабайт, а структура ХД, насколько я помню, была больше похожа на снежинку, чем на звезду...

В этой связи вопрос: не знаком ли кто-либо с примерами внедрений Microstrategy на таких объемах данных? Принимая во внимание что это не MOLAP-сервер, а продукт класса ROLAP/Query & Reporting, удается ли проводить с помощью Microstrategy интерактивный многомерный анализ, с такой же высокой скоростью отклика как например в Cognos PowerPlay или в MS AS, или просто в Банках не нужен анализ, а нужна стандартная отчетность, время генерации которой не так принципиально?

Александр,

Пока что речь идет о отчетности (но не стандартной) в последствии запланирован и многомерный анализ .

Я знаю несколько примеров внедрения продуктов класса Query & Reporting в банках, и в основном везде одна и та же ситуация: сначала решим задачу создания системы отчетности (этот этап тянется годами...), а потом перейдем к анализу :)
Как думаете все таки, можно ли использовать Microstrategy для многомерного анализа больших объемов данных, или придется использовать для задач анализа MOLAP-сервер другого производителя (например Cognos или Microsoft)?

To subquery:

Работали мы с Cognos и работаем.

Вот почему мне так приятно пользоваться услугами Вашего банка... :)

Из Вашего сообщения складывается впечатление, что, в отличие от Microstrategy он может легко "крутить" объемы в сотни гигабайт в одном кубе. Это миф. Проблем выше крыши.

Мой опыт говорит о том, что Cognos может легко крутить огромные массивы данных. А проблемы обычно решаются с помощью экспертов по Cognos. Что касается сотен гигабайт - то это зачастую размер распухших реляционных ХД. В Cognos не закачиваются все поля всех таблиц. Обычно я оцениваю размер исходных данных по двум параметрам - количество записей и количество категорий. Если не секрет, сколько записей в самых больших таблицах фактов Вашего ХД? И сколько у Вас категорий?

Один мягкий знак в русских наименованиях чего стоит. И не обойдешь никак!

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

Друго "впечатление", которое как-то складывается из Вашего сообщения, о том, что Вы предлагаете собирать в куб и крутить весь объем хранилища

Нет, этого я не предлагаю. Я обычно создаю кубы именно на основе витрин данных, для каждой предметной области отдельно, а затем просто настраиваю навигацию между витринами с помощью DrillThrough, а также вывожу ключевые показатели из нескольких витрин в панель управления руководителя (продукт Cognos Visualizer).

Объем витрины - на порядок меньше хранилища получается.

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

To АлександрФ:

Я думаю, что можно справиться средствами Microstrategy для многомерного анализа больших объемов . Использовать другого производителя я считаю не целесообразно с экономической точки зрения.

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

Самое интересное что я действительно убедился что большие объемы (Гигабайты) можно обрабатывать и время отклика системы от секунд до нескольких минут . Естественно это достигается прежде всего следующими факторами:

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

To subquery:

Работали с продуктами PowerPlay, Impromptu, . Мягкий знак не воспринимается в заголовках и фильтрах. Причем очень странно, "воспринимаенимость" зависит от количества букв в слове.

Как я понимаю, эта проблема встретилась в Impromptu... Это известный баг :) Но в моих проектах такой проблемы не возникает, поскольку есть способы обхода этой проблемы (либо использовать при фильтрации не знак равенства, а функцию "contains", либо пользователю при задании фильтра показывать название, типа "Московская область", а реально в фильтр будет вставляться код/числовой id, есть и другие способы).

Продукт Impromptu вне основных рынков (Америка, Западная Европа) не является у Cognos флагманским (как PowerPlay), а выполняет вспомогательные задачи. Основной его плюс - как у системы отчетности - превосходное соотношение цена/качество, так как минимальная цена поставки полного объема Windows-функциональности - в несколько раз ниже чем у BusinessObjects, Actuate, и думаю он также в несколько раз дешевле чем Microstrategy, Brio, Crystal... Но вот несколько месяцев назад у Cognos вышел ReportNet, и это уже более сильный продукт для создания традиционных отчетов, произвольных запросов и доставки данных массовым пользователям.

Количество записей - более 3 млн. количество категорий - около ста с "меньшей" стороны.

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

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

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

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

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

Но говорим, насколько я понимаю, о другом. Насколько эффективно использовать продукты от Cognos. Правильно я понимаю?

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

Похоже, что Вы заняли максималистскую позицию. Скорость - превыше всего! Да. Скорость. Но в успехе проекта это, увы, не главное.

Я имел в виду, что у Cognos выше скорость, а по другим параметрам - примерное равенство. Я считаю что скорость - это очень важный фактор, ведь время - это деньги!

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

При внедрении других продуктов тоже требуется обучить своих специалистов и периодически обращаться за консультациями к экспертам.

в настоящее время даже выбирая автомобиль, покупатель, на самом деле, может выбитать не скорость или проходимость, а перстиж или ближайшую станцию ТО. А колесами они крутят - одинаково ... не более 60 в городской зоне. Я понятно выражаюсь?

Вы провели удачную параллель. Только вот дело в том, что скорость ROLAP-продукта не всегда будет дотягивать до 60 - иногда она будет как у черепахи, особенно на самых интересных запросах с хитрыми агрегациями...

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

Это понятно. Может тогда не тратить деньги на компьютеры, а все считать на калькуляторе? :) Реально многие банки тратят большие деньги на аналитические системы, и я лишь предлагаю немного времени потратить на сравнительный анализ и выбор оптимального решения, чтобы и не переплачивать, и получить эффективный инструмент.

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

To Subquery:

Новогодние праздники потихоньку подходят к концу, так что можно продолжить нашу дискуссию :)

Изложенные Вами способы - не корректны для заголовков :-) в которых это тоже не работет... Да и методы не совсем пригодные в некоторых случаях.

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

Кому нужна Россия, чтобы с мягким знаком "копаться"? Никто и не будет!

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

Надо же! Надо бы с ним поговорить... в чем же он тогда "эксперт"?

Он эксперт по проектированию хранилищ данных (изначально предпочитает решения "без кубов" :) Если хотите - могу Вас с ним познакомить. Хотя думаю что Вы хорошо знакомы...

...Они не дороги, и производительны. Про экспертов Cognos, к сожалению, такого не скажешь. А стандартные SQL сервера - знают многие.

А вот дворников в России еще больше, чем специалистов по SQL :)
Число экспертов по Cognos не такое маленькое, стоимость услуг - разная (московские специалисты подороже, региональные - подешевле). И найти эксперта по Cognos очень просто - достаточно отправить запрос через сайт http://cognos.narod.ru/AskCognosGuru.html .

Но "последний", на "последнем" (в смысле неграмотный на MSTR) иногда может сделать то, что продается и используется (см. выше)

Существует обратная сторона медали:
Поскольку Microstrategy создает отчеты на основе прямых запросов к реляционной БД, то есть большой риск, что неопытный специалист завалит сложным запросом сервер РСУБД... При использовании Cognos такого риска нет, так как запросы идут к многомерному кубу.

выяснить, почему это два "умных" ;-) человека, смотря на одно и тоже, видят разное. Парадокс, не правда ли? Вероятно, смотрят с разных точек.

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

Я делаю проекты и общаюсь с заказчиком. Считаю, что с MSTR меньше проблем.

Если не секрет, Вы являетесь сотрудником Альфабанка, или Вы принимаете участие в проекте для Альфабанка, представляя другую компанию, и для удобства пользуетесь их почтовым сервером (alfabank.ru)?

Вы - вероятно, тоже ведете проекты, но с какими-то очень подготовленными заказчиками :-) Которые готовы платить за скорость, и исследовать данные преред принятием решения. Думаю, что у них даже методика исследования данных есть! Иначе как же они будут исследовать?

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

В свете состоявшегося приезда вицепризедента (европейского) MSTR в Россию (о котором немного наслышан), могу доложить, что Россия им интересна и они готовы, не смотря на ее место в мировом сообществе ;-), с пониманием относиться к запросам представителей "грубого и сильного народа" (который, почему-то всегда все обижают).

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

To Jimmy:

Самое большое измерение - 120000 записей
Самая большая таблица фактов - 11.5 млн записей (11500000) пока(!)
Ожидется рост до 35 млн
Отчеты - MicroStrategy 7i
Время отклика 1-10 мин.
Нормально?

Как эксперт по СУБД и SQL - Вы безусловно заслуживаете уважения. Но вот только будет не очень хорошо, если кто-нибудь из конечных пользователей Вашей компании через некоторое время узнает, что технология многомерного OLAP позволяет снизить отклик до 0.1 - 5 секунд. Тогда этот пользователь очень расстроится, что его своевременно не поставили об этом в известность... (это я привожу типичный пример реакции конечных пользователей разного ранга - от аналитиков до руководителей высокого уровня, после того, как они в первый раз видят демонстрацию многомерного анализа в Cognos PowerPlay).

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

Юрий, такой риск есть, скорее, при использовании Cognos Impromptu (который, всё-таки делает запросы не к многомерному кубу, а к реляционной СУБД).

Impromptu к реляционной СУБД обращается по минимуму, на разовой основе (обычно ночью), когда куб генерируется или обновляется, и далее работа идет только внутри куба. А в Microstrategy приходится те же самые записи обрабатывать при каждом новом запросе каждого пользователя (кэширование помогает, но общая картина от этого не сильно меняется).

Поделитесь, пожалуйста, как с этим обстоят дела в продуктах PowerPlay и Impromptu.

Что касается Impromptu (если например нам не хватает фунуциональности кубов), то в нем, как и в MSTR, можно указать ряд ограничений для каждой группы пользователей:
1) На сортировку по неиндексированным полям
2) На использование Outer Joins
3) На использование Select Distinct
4) На кортезианское произведение (выбор полей из несвязанных таблиц)
5) Максимальное количество символов для больших текстовых полей
6) Количество таблиц, из которых выбираются поля для отчета
7) Количество строк, которые возвращает запрос
8) Длительность выполнения запроса в минутах
9) Редактирование SQL-запроса, созданного визуальными средствами
и др.

в своё время возникали проблемы, когда пользователи пытались 10 тысяч листовых категорий затащить в отчёт PowerPlay

Иногда (к счастью не очень часто) встречаются задачи, для которых в кубе нет агрегированных значений, и приходится выполнять большое число вычислительных операций налету. В таком случае, в зависимости от архитектуры решения, можно нагружать либо центральный сервер, либо клиентские машины пользователей. Эта ситуация актуальна не только для PowerPlay, но и для MS AS, Oracle Express и т.п. В OLAP-клиенте Cognos PowerPlay есть опция, которая позволяет не делать запрос к кубу автоматически (а делать это только по требованию пользователя). То есть сначала мы перетаскиваем в область строк 10 тысяч листьев, потом определяем, что будет в колонках, накладываем нужные фильтры, настраиваем например параметры ранжирования, и только после этого запускаем обращение к кубу.
Мне встречались задачи, когда в измерении было порядка 1 миллиона листьев. В таких случаях я делал разбиение куба на партиции на основе этого измерения, и все работало быстро.

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

Это радует :) Хотя все же 1 день курса обучения у квалифицированного эксперта/преподавателя зачастую более ценен, чем 1 год самообучения ...

To Jimmy:

Знаете, демонстрация - вещь особая.
Я на демонтсрации MicroStrategy могу показать не меньшую производительность, а то и большую :0))

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

если в оперативной системе какой-то монстрообразный отчет формируется несколько часов, то 10 мин, предлагаемые нами

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

если бы не количество показателей, около 3000 в нашем проекте

А вот это интересно... Слабо себе представляю 3000 показателей. Каждый из них вычисляется по отдельному алгоритму и имеет разную природу?

железо" у пользователей системы не самое крутое, т.е. на уровне PIII800/PIV1000, 128-256М. Проблема? Отнюдь.

Я тоже считаю, что такая конфигурация - вполне приемлема.

Просто используем тонкого клиента (читай MSIE) - и получаем функционал, сравнимый с толстым клиентом, который требует "железо" существенно мощнее, чем описано выше.

Для тонкого клиента можно и более слабые компы использовать. А для толстого клиента Cognos PowerPlaу тоже не требуется мощное железо, поскольку операция визуализации небольшого числа заранее просчитанных агрегатов достаточно проста.

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

А как насчет "железа" для многомерного OLAP (Cognos) с временем отклика 0.5 - 1 сек?
Ну и ЛВС - не 1G случайно?
И какой размер (Gb) будет иметь многомерная витрина (куб?), которая в РСУБД занимает около 10G (пока), с параметрами, указанными в моем предыдущем посте?

Существуют стереотипы, возникшие в результате использования таких продуктов как Oracle Express, что OLAP-куб по размеру больше, чем источник данных...
Для OLAP-сервера Cognos PowerPlay требования к железу минимальны, поскольку высоко качество OLAP-движка. Как то я для смеха на 486 компе с процессором DX2-80 и с 16 мегабайтами оперативки сгенерировал многомерный куб, и крутился он вполне быстро...
Приведу примеры из практики:
1) Схема - "созвездие";
Измерений - 14 (некоторые с иерархиями);
Показателей - 16;
Самое большое измерение - 800 тысяч записей;
Самая большая таблица фактов - 16 млн записей;
Размер куба - 900 мегабайт.
2) Схема - "созвездие";
Измерений - 10 (некоторые с несбалансированными иерархиями);
Показателей - 12;
Самое большое измерение - 40 тысяч записей;
Самая большая таблица фактов - 90 млн записей;
Размер куба - 1.1 Гигабайта (1100 мегабайт).
В обоих случаях ЛВС - 100-мегабитная, клиентские компьютеры - Pentium 2-3, 128-256 мегабайт оперативной памяти. OLAP-сервер - Pentium 3, 256-512 мегабайт оперативной памяти.
И в обоих случаях большинство запросов выполнялось со скоростью многомерного OLAP (0.1 -5 секунд на запрос). Был правда в первом примере один сложный показатель, не опирающийся на агрегаты, и при его отображении в некоторых отчетах требовалось время на разогрев 5-6 минут. Но после первого запроса следующие, благодаря кэшированию, доходили до среднеОЛАПовской скорости.

To Torin:

MSTR действительно интересный продукт, но в целом присуствующие не должны сравнивать его с Cognos.

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

Если расматривать проблему превентивности отчет или анализ, считаю, что нет смысла в первую очередь ставить на анализ - ни один нормальный менеджер не сможет целый день в темпе вальса требовать driilUp-drillDown с поворотом по оси и накладыванием срезов.

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

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

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

В этом смысле MSTR тоже не промах - имеет на борту кроме прочего MDX connector, который "притворяется" MS Olap сервером. !

В случае использования MSTR + MS AS, имеет место некоторый зоопарк, при котором сильные стороны MSTR по созданию SQL-запросов визуальными средствами не смогут быть использованы для проектирования кубов в MS AS. Поэтому аналогичную связку Impromptu + PowerPlay я считаю более удачной архитектурой.

Cognos, конечно, интригует со своим Report.NET, Но доступной версии для тест драйва нет

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

Рекомендую при выборе аналитического продукта не забывать о следующих подводных камнях, с которыми Вы рискуете столкнуться, и учитывая которые многие компании выбрали для себя PowerPlay и другие продукты Cognos:
1) Далеко не все продукты поддерживают несбалансированные иерархии (это важно для поддержки Вашей номенклатуры товаров, классификация которой наверняка является несбалансированной иерархией);
2) Ваши учетные системы наверняка не хранят складские остатки на каждый день. Вычислять их в хранилище данных - малореально при Вашем количестве складов/филиалов, номенклатурных позиций и партионном учете, а вычислять их налету в продукте класса Query & Reporting - просто нереально, так как это будет слишком медленно;
3) Многие интересные показатели более удобно вычислять на основе многомерных запросов, а не на основе SQL-запросов, хотя бывают и обратные случаи...;
4) На стоимость проекта влияет не только стоимость лицензий на продукты, но и стоимость железа (например, центральный сервер) и стоимость разработки хранилища данных, которое требуется для продуктов класса Query & Reporting;
5) При получении отчетов на основе прямых SQL-запросов Вы привязываетесь к хранилищу данных (нужно иметь постоянный канал связи), и нельзя например проводить анализ/строить отчеты на локальном ноутбуке (компактный многомерный куб можно держать на ноутбуке, но хранилище данных - малореально).

To Birkhoff:

Что за внезапный наезд вбок? :) Вроде сравнивали MSTR и Cognos?
Такой стереотип может сложиться скорее у тех, кто с Express не работал.
Вообще, что за дурацкая постановка вопроса: "что больше, источник или куб"?

Это не наезд :) Вопрос был в том, насколько мощным должно быть железо для создания и работы с OLAP-кубами. Ответ на этот вопрос зависит от того, какой OLAP-продукт использовать. В интернете практически каждый из посетителей этого форума читал, что многомерный куб во много раз больше, чем источник, и я думаю, что автор этого заявления был знаком только с Oracle Express... Если источник данных имеет размер 10 гигабайт, и OLAP-куб будет терабайтным, то для куба потребуется очень дорогое железо. Я же привел примеры из жизни, которые показывают, что кубики у Cognos компактные и легко будут жить на слабеньком и недорогом офисном компьютере.
Если Вы считаете, что Express силен своей компактностью и низкой требовательностью к железу - тоже приведите примеры из жизни.

To Jimmy:

Так! А уважаемый г-н Jurii сам, своими руками, пробовал работать с MSTR?
И какой версии?
И какие задачи решал?

Безусловно мой опыт и знания в области Microstrategy - ограниченные. Мне немного показывали этот продукт несколько месяцев назад в компании, которая продвигает несколько BI-продуктов, рассказывали о некоторых слабостях MSTR, которые я по этическим соображениям не упоминаю. Я общался с несколькими экспертами по MSTR на тему того, появился ли реально в ее последней версии многомерный OLAP или нет, и общее мнение было таково, что MSTR - это все же ROLAP. Также я слежу за дискуссиями на этом форуме.
Имея практический опыт работы с BusinessObjects, Actuate, Brio (которые во многом похожи на MSTR), и используя скудные знания о MSTR, я могу делать выводы в отношении MSTR. Если Вы считаете, что я в чем-то заблуждаюсь - приводите аргументы. В подобных дискуссиях и рождается истина.

Возвращаясь к задаче, которая актуальна для г-на Torinа: Вы считаете, что MSTR может позволить легко крутить в разных разрезах 5 миллионов записей?

To Jimmy:

Вы считаете, что MSTR может позволить легко крутить в разных разрезах 5 миллионов записей?

Может.

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

To Jimmy & Андрей Прохоров:

ЗЫ
Кстати, анекдот хороший:
Это просто перл, достойный восхищения - "конкурента не знаю и знать не хочу, но конкурнет хуже, готов доказывать кому угодно".

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

Обычно, если человек задает вопрос, он хочет в чем-то разобраться.
У Вас я вижу горячее желание доказать чье-то превосходство.

Я как раз и начал дискуссию с целью разобраться. Если бы представители компании Диасофт ответили, что Cognos они используют как инструмент для OLAP-анализа, а BusinessObjects и Microstrategy - для репортинга, то и обсуждать было бы нечего. Но когда в дискуссии появились мнения, что ROLAP-продукты мало чем отличаются от OLAP-серверов - то дискуссия сразу стала активной и интересной.

To Jimmy:

Да, о самом главном, о Cognos - не используют его представители Diasoft!
Не из-за того, что он плохой или хороший, дорогой или дешевый - просто не используют, т.к. MSTR покрывает все наши потребности

Diasoft не использует Cognos, но на конференциях Cognos упоминает... Интересная маркетинговая политика :)

To Андрей Прохоров:

Вам была приведена ссылка на материалы о том, как мало ROLAP продукт MicroStrategy отличается от OLAP-сервера.
Ваши контраргументы в студию!

Я посмотрел Вашу ссылочку... Там сказано, что кубики Microstrategy генерируются налету:
"Fast cube generation with no pre-calculation of data
Automated cube expiration and refresh"

Это похоже на подход BusinessObjects, где Микрокубы генерируются тоже налету.
Соответственно, думаю Вы согласитесь, что fast generation - это понятие относительное (если сервер РСУБД сильно загружен, а объем данных - приличный, то fast может составить не мгновения или секунды, а минуты или часы).
Я уж не говорю о тех случаях, когда у компании используется не выделенное хранилище данных, а файл-серверная БД (типа dbf-версия 1С), или например каждый день в кубы надо подкачивать текстовые данные (новый лог-файл, порция данных с кассовых аппаратов и т.п.), или учетная система крутится на серьезной промышленной СУБД, но поставщик учетной системы запрещает создавать в ней лишние индексы... В этих случаях на мой взгляд Интеллектуальные кубы MSTR будут сильно уступать возможностям полноценного OLAP-сервера.
Ну а если делать отдельное хранилище данных - это трудоемкий и недешевый процесс, у каторого есть свои плюсы, но есть и ряд минусов...

To Андрей Прохоров:

Рекомендую перечитать мою реплику из этой дискуссии:

"Impromptu к реляционной СУБД обращается по минимуму, на разовой основе (обычно ночью), когда куб генерируется или обновляется, и далее работа идет только внутри куба. А в Microstrategy приходится те же самые записи обрабатывать при каждом новом запросе каждого пользователя (кэширование помогает, но общая картина от этого не сильно меняется)".

Если говорить о приличных объемах данных (миллионы, десятки миллионов записей за несколько лет), то в куб Cognos PowerPlay закачивается один раз историческая информация, а потом новые данные подкачиваются инкрементально. На первичную закачку требуются часы, а на подкачку - минуты или секунды. Обычно подкачка кубов производится по расписанию в ночное время, но если днем надо подкачать в куб свежие данные - это очень мало нагрузит сервер РСУБД.
Таким образом Cognos нагружает сервер РСУБД в то время суток, когда пользователи спят. А MSTR нагружает сервер РСУБД в часы пик... Время - деньги, но в дневные часы время стоит дорого, а ночью - дешево.

Понятна разница между подходами Cognos и MSTR?

To Андрей Прохоров:

Вы увлекшись началом фразы о MicroStrategy OLAP Services, так и не соизволили разобраться в ее завершении.
"...Automated cube expiration and refresh"
Это означает, что кубы можно генерить именно НОЧЬЮ, а потом пользоваться ими ДНЕМ.

Интересно было бы посмотреть, как подобный refresh работает на практике (например если сделать в РСУБД таблицы с агрегированными значениями, и их обновлять - то это солидная нагрузка на сервер)...
Наверное Вы хорошо знакомы с этой функциональностью, поскольку представляете главного российского партнера Microstrategy. Я бы хотел уточнить, есть ли ограничения на количество записей, которые реально закачать в эти кубики, и можно ли подкачивать в них записи инкрементально? Например в ситуации, когда данные правятся задним числом, наиболее удобный подход у Cognos - это создать куб на конец предыдущего закрытого периода и каждый раз подкачивать все записи, у которых дата в интервале от закрытого периода до текущей даты.

Другой вопрос - как MSTR хранит эти кубики - в реляционных таблицах?

Когда я общался с г-ном Лисянским на тему кубов, он дал мне понять, что кубов реально в Microstrategy нет...

Также прошу разъяснить почему время РСУБД витрины данных стоит дороже времени MOLAP-сервера в одно и тоже время суток?

Под стоимостью времени я имею в виду время, которое пользователи (руководители, аналитики и др.) тратят впустую в ожидании выполнения отчета или запроса. MOLAP-сервер занимается тем, что извлекает по многомерным индексам заранее просчитанные числа из OLAP-куба, и поэтому это делатеся либо мгновенно, либо за несколько секунд. Можно даже положить куб как файл на машину, где работает сервер РСУБД, и пользователи будут обращаться к кубу в режиме файл-сервер, не замечая никакого замедления (будет работать их персональный OLAP-сервер, который входит в лицензию PowerPlay User). А вот сервер РСУБД должен будет выполнить более серьезный объем работы, и поэтому будет заставлять ждать конечных пользователей, пока отработает тот или иной запрос.

To Jimmy:

Работать напрямую с OLTP системой для анализа данных, это не "разница между подходами Cognos и MSTR", а, по меньшей мере, непрофессионализм (не хотелось употреблять термин "идиотизм") разработчика.

Я думаю вопрос создания отдельного ХД зависит от того, насколько сильно загружают аналитические запросы реляционную БД. Используя Cognos, такая нагрузка в дневное время сводится к нулю, поэтому ХД не требуется. При использовании продуктов типа BusinessObjects, Actuate, видимо Microstrategy (если Андрей меня не убедит в обратном насчет кубов MSTR), аналитические запросы перекладывают большую нагрузку на сервер РСУБД, поэтому без отдельного ХД не обойтись.

To Константин Лисянский:

Когда я общался с г-ном Лисянским на тему кубов, он дал мне понять, что кубов реально в Microstrategy нет...
Юрий, можно URL, если это было в этом или другом форуме?

Насколько я помню, мы обсуждали этот вопрос как лично, так и на форуме. Привожу ссылку:
http://www.olap.ru/contacts/forum/display_message.asp?mid=16025

Там в верхней части постинга:

"
Юрий: >Спасибо за ссылку на сайт - узнал для себя кое-что новое. Я думал, что Microstrategy - это решение "Без кубов" :) Правда я пока не успел разобраться, что это за Olap Services - аналог микрокубов BusinessObjects, или полнофункциональный MOLAP-сервер...

Константин Лисянский: Полноценный ROLAP-сервер.
Про микрокубы BusinessObjects - отдельная история. Наверное, заметили там же сравнение и с ними."

To Андрей Прохоров:

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

Грязь я ни на кого не лью. Просто ограждаю посетителей форума от недопонимания... Хотя как то я обсуждал подобный вопрос на англоязычном форуме (уровень которого повыше, чем на этом форуме), и мне один из участников дискуссии сказал примерно следующее:
"Да, в таких продуктах как BusinessObjects, Actuate, Microstrategy и т.п. нет интеграции ROLAP и MOLAP, как у Cognos, но в то же время их все равно покупают и на них делают проекты :) "

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

А вот насчет кубиков Microstrategy все еще ясности нет. Надеюсь кто-нибудь из экспертов по MSTR прольет свет на этот вопрос...

To Jimmy:

А можно попросить заодно и от рассуждений о превосходстве Cognos над всеми прочими продуктами нас оградить, а?

Превосходство - понятие относительное. В области многомерного OLAP я пока не прочувствовал, насколько гибкие, мощные и компактные кубы в MSTR. Что касается репортинга - то поскольку у меня нет детальных знаний функциональности MSTR, а судя по рекламе - репортинг там хороший, то я не сравниваю его с Cognos Impromptu или ReportNet.
Главный приоритет дискуссий на форуме - чтобы пользователям было хорошо, и им эти дискуссии полезны.

To Константин Лисянский:

И это называется "дал понять, что нет кубов"? Где это конкретно сказано про реальное отсутствие кубов?
Я не помню, чтобы я в личном общении давал понять о реальном отсутствии кубов.

Вы говорили, что MSTR - это "Полноценный ROLAP-сервер". Как известно, ROLAP хранит данные в реляционных структурах, а не в многомерных кубах, разве не так?
Я конечно понимаю, что и в Excel можно делать кубики, и в BusinessObjects, и в MSTR вроде есть какие-то кубики... Но в нашей дискуссии речь идет о кубах MOLAP-серверов (таких как Cognos PowerPlay, MS AS, Oracle Express и др.), которые можно проектировать, оптимизировать, разбивать на партиции, обновлять инкрементально, закачивать в них большие объемы данных...

По поводу аргументов - складывается впечатление, что единственное преимущество Cognos - это скорость. Может, и другие преимущества есть?

Я начинал эту дискуссию не для того чтобы говорить о преимуществах Cognos, а чтобы прояснить, могут ли продукты класса Query & Reporting использоваться для многомерного интерактивного анализа, или к ним для решения этой задачи стоит докупать MOLAP-сервер.
Скорость - это самое очевидное и приятное преимущество, поскольку это экономит время на получение отчетов и оставляет больше времени на принятие управленческих решений. Есть и другие преимущества, но не уверен, что их надо обсуждать в этой дискуссии (если хотите - открывайте новую дискуссию типа "Cognos vs Microstrategy" - в чем-то она будет напоминать дискуссию MS AS vs Microstrategy, хотя понятно, что по причине наличия более широкой функциональности Cognos - более сильный соперник, чем Microsoft).

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

Если рассматривать задачи Вашей компании (часть задач, о которых Вы мне рассказывали), то поскольку речь идет о большой номенклатуре товаров (и/или о большом числе клиентов), то анализировать эти данные будет не один продвинутый аналитик, а как минимум несколько пользователей, каждый из которых отвечает за свою товарную группу (я делаю этот вывод исходя из собственногй практики создания аналитических систем для розничных компаний). Вопросы у этих людей будут непредвиденные, но алгоритмы ответов на них будут все же в основном одними и теми же (отличаться будут исходные параметры, типа периодов времени, групп товаров и т.п.). В такой ситуации на практике хорошо зарекомендовало себя создание одного или нескольких многомерных кубов в PowerPlay. Функциональности OLAP-клиента PowerPlay обычно достаточно, чтобы массовые пользователи получили ответы на большинство своих вопросов. При этом, когда они будут делать отчеты в PowerPlay, будут производиться вычисления над агрегированными данными, и на мой взгляд нецелесообразно получать такие отчеты с помощью сложных SQL-запросов.
Что касается небольшого количества сложных вопросов, то для их решения действительно кубов может не хватить. Я считаю, что в этих случаях будет помогать либо Интеллектуальный Конструктор Выражений Cognos Impromptu, либо репортинговая функциональность ReportNet. Для того чтобы дискуссия не была абстрактной, предлагаю Вам огласить конкретные примеры сложных непредвиденных вопросов.

P.S. Я являюсь экспертом по продуктам Cognos, Вы - по Microstrategy. А как известно, с помощью хорошо знакомого инструментария решать сложные задачи легче, чем решать те же задачи с помощью более подходящего но менее знакомого инструментария...

Александр,

Вы сами то в это верите? Скажите, Вы использовали когда-нибудь эту функциональность в своих проектах, и если да, то кто обеспечивал Вам эту самую дельту, которую Cognos так быстро может загрузить

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

но если он реализован, то куда грузить эту дельту в куб ли, в реляционное ХД без разницы везде, будет быстро :)

Согласитесь, что создавать отчеты на основе куба зачастую быстрее за счет заранее просчитанных агрегатов... Хотя против ХД я ничего не имею.

Кстати, меня давно интересовал вопрос, можно ли с помощью MOLAP решать задачи SCD? Кто знает, может есть опыт?

Я тестировал возможности OLAP-сервера PowerPlay в этой области, там заложена функциональность по работе с SCD. Вроде все работает нормально...