2 backfire:

Что вы подрозумеваете под "неуместно делаемым хранилищем"?

На конференции по Business Intelligence задавался примерно следующий вопрос - нужно ли городить проект по созданию хранилища данных, если источник данных - единая учетная система с количеством записей в таболице фактов не более миллиона? Мой ответ на этот вопрос - что не нужно (если аналитический инструментарий не нагружает реляционный сервер, на котором крутится учетная система (например - Cognos PowerPlay).

Кстати, какому термину Cognos соотв. ваше жаргонное "виртуальная вьюшка".

Поскольку первая русификация продуктов Cognos была создана мною, я считаю, что у меня есть моральное право переводить термины Cognos с английского на русский. Виртуальная вьюшка - это перевод термина Impromptu Query Definition (вьюшка, хранимая не в реляционной базе данных, а в файле).

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

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

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

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

Жаль, что этот доклад был сразу после моего выступления - я не смог его послушать, приходилось на стенде Cognos отвечать на вопросы по моему выступлению...

Но этот доклад достаточно грубо прервал ведущий.

Это было понятно еще до начала конференции - после доклада по регламенту был фуршет, и ведущий понимал, что посетители конференции будут недовольны, если их будут морить голодом :)

Аналитическая системе за 5 дней. Гы :)
Даже требования за такое время собрать и задокументировать невозможно. Не то что построить что-то (спроектировать, утвердить, разработать, протестировать, сдать в опытную эксплуатацию, сделать доработки, передать в производственную эксплуатацию).

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

2 Профессор Нах:

2 Jurii
Судя по реакции зала, зажечь докладом про внедрение аналитической системы за 5 дней не удалось :)

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

Там все делается визульно при помощи мышки и вьюшек :)
Юрий, не обижайтесь :)

Зачем же обижаться, это чистая правда, и это меня радует :)

2 олапист:

то есть правильно ли я понимаю что в молели кубов PowerPlay вообще отсутствуют такие понятия как схема звезда, таблица фактов, таблица измерения, а есть ER-модель, с информацией о связях между колонками, и работа и источником данных ведется путем одного большого select-а (ну или виртуального select'a если источников несколько) который join-ит все таблицы?
информация об уникальных ключах в этой модели тоже отсутствует?
а как же при этом powerplay сможет оптимизировать запросы при процессинге?

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

также не понятно как работает incremental update. опять только лишь предположения: либо в источниках данных должны находится только данные для "доливки", либо pp сам вычисляет различия между текущим кубом и данными из источников?

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

2 backfire:

Я думаю, что тему следует закрыть, ибо ушли от темы в "никуда".
А как думают другие?

Я думаю, что эта тема будет открыта вечно - поскольку на нашем форуме есть ГУРУ и по Cognos, и по MS AS :)

2 Alexander Stoulov:

Константин, Профессор Нах, Юрий
Покритикуйте, пожалуйста, доклад по проекту в Юнилевер. Проведу работу над ошибками

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

2 Шургин Сергей:

ЗЫ. Думаю, если бы использовали CRN, ничего бы не изменилось в докладе (как и в проекте).

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

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

Год назад сотрудники Cognos агитировали партнерстововать на стенде MicroStrategy ...

По моим сведениям Cognos и MSTR стали партнерами, или по крайней мере очень близки к этому. Хотя лично я не понимаю, в чем суть партнерства (или может я путаю MSTR с Терадатой :) Надо будет уточнить у моих знакомых из Cognos.

2 Alexander Stoulov:

Соответсвенно разные слайды готовили разные люди.

Хороший подход. В Вашей компании хорошо поставлен менеджмент...

Смейтесь, смейтесь. Мне кажется что наше название хорошо ассоциируется с идеологией ХД, тем более, что оно соответсвует действительности. Справочник номенклатуры содержит и Lipton, и Timotey, и услуги, и сырье и много еще чего. От Вас, Юрий, как, наверно, единственного человека в этом форуме с базовым маркетинговым образованием, я ждал похвалы за отличное название. :)

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

Ну это уже черный PR.

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

Кстати, Юрий, а может многое объясняет Ваш конфликт интересов, о котором уже говорили. :))

По правде говоря, как минимум в последние 28 лет у меня не было каких-либо конфликтов интересов :)

2 Maxim Lvov:

Юрий, аналитические системы замечательно быстро работают и на Business Objects.

ОК, я с этим соглашусь, если мы согласимся с тем - что Excel - мощное и быстро работающее аналитическое средство.
У BO нет OLAP-сервера, поэтому он по определению медленно работает на серьезных объемах данных и/или при консолидации данных из разных источников. В то же время можно сделать ХД, оптимизированное под аналитические запросы, и BO заработает быстро. Но проблема в том, что под все возможные запросы ХД оптимизировать заранее невозможно...

2 Maxim Lvov:

В проекте Юнилевера оно использовалось поверх хранилища данных, похтому необходимости в OLAP-сервере не было.

Время покажет, была ли необходимость ставить OLAP-сервер поверх ХД или нет... Надо будет проверить, насколько изменится вкус чая Липтон через пол-года :)

Но проблема в том, что под все возможные запросы ХД оптимизировать заранее невозможно...
Так же как и проблемы добавления измерений в кубы Cognos и любые другие многомерные кубы...

Оптимизация ХД и оптимизация кубов - это разные вещи. Возможных запросов обычно бывает очень много, и надо сделать очень много таблиц с агрегатами. А количество аналитических разрезов и показателей в кубе - не так много. На мой взгляд, использование OLAP-кубов - это автоматизация процесса создания таблиц с агрегатами в реляционном ХД. OLAP-куб с 30 измерениями - это как 10 тысяч таблиц с агрегатами в ХД. Трудоемкость администрирования, поддержки и обновления куба - на порядки ниже, чем поддержка множества таблиц.

2 Maxim & Андрей:

Каждая из архиетктур имеет свои преимущества и недостатки. Однако, соглашусь с Профессором Нах, что данные хранилища используются в 80% случаев, и даже больше, для создания консолидированной регулярной отчетности. А здесь уже применяются совсем другие средства, в частности нежели OLAP-кубы Cognos PP.
Если у человека в руках молоток, то каждая проблема кажется гвоздем. Немногие могут выбрать инструмент адекватный задаче.

Согласен, для каждой задачи - свой инструментарий. Когда я приезжаю на какой-нибудь завод, то там обычно есть 2 столовые - одна для рабочих, другая для руководителей. Я предпочитаю обедать во второй, хотя там не так многолюдно ;) Так что для кого-то в качестве инструментария нужен молоток, а для кого-то - аналитическая система...

2 Шургин Сергей:

С Новым Годом

И Вам того же ;) Также поздравляю с наступающим НГ всех посетителей нашего форума.

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

Вы немного ошиблись - родился я в ноябре. Хотя плюс-минус несколько месяцев - это не так много :)

Вам знакомы понятия параллельных многопоточных вычислений? Или в экономических ВУЗах (экономических факультетах технических ВУЗов) про это не упоминают?

С понятиями я конечно знаком, но с многопоточными вычислениями - не особо глубоко, в нащем ВУЗе этого не проходили.

Было бы очень интересно узнать, что в вашем понимании есть система аналитическая?

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

И вообще, Юрий, просыпайтесь. Ваш многомерный поезд уходит в прошлое. Технологии РСУБД и производительность машин решают вопросы, с которыми 30 лет (?) могла справиться только многомерная физическая модель данных.

Прошу не трогать МПС ;) Железо с моей точки зрения - это не выход. Даже Костя Лисянский, приведя информацию о возможностях оптимизации запросов в MSTR + Терадата не отрицает, что на больших базах среднее время отклика на аналитический запрос составляет минуты, а не секунды.

Эх,... не могу вам показать форму отчета. А надо б было вас заставить повторить это в PP.

Покажите, в чем проблема?

Уточните, конечно

Уточню. Сейчас на вскидку могу сказать, что в презенташке Когноса на слайде партнеров упоминалась компания S & T (которые продвигают MSTR).

А вообще, хочу спросить, управление чем у нас по-вашему поставлено хорошо?

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

А куб оптимизировать можно заранее? Уверяю вас, ХД более гибкая штука. У разработчика меньше огораничений, интерфейсы открыты, опять же многопоточность.

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