Прветствую,
несколько вопрос по пводу постройки кубов.

Имеется реально много записей -- порядка 50 миллионов в день.

Имеется 8 процессорная машинка с 64гб памяти от Sun.

Постройка кубов занимает порядка 12 часов.

Иногда случается наползание нового процесса на незаконченный
предыдущий.

Вопросы:

1) Насколько верно утверждение, что Cognos более 4 процессоров не берет
для обработки кубов?
2) Есть ли какие то приспособы от Cognos, которые позволяют проследить
на очень детальном уровне чем собственно Transformer занят и где
у него затык? То есть хотелось бы чот нибудь такое типа:
Занят обработкой такого то запроса,
Ушло столько то таких то и таких то ресурсов
Обработано столько то и столько то записей со средней скоростью
столько то аписей в секунду.

итд итп.

Отличного крайне мало.

Эти данные я вижу конечно и обрабатываю.
Теперь посчитайте сколько у вас занимает процессинг одной записи (порядка
пол-миллисекунды) и умножьте на 50 миллионов -- получите
около 7 часов. Теперь надо знать что у вас там за записи итд итп.
Меня интересует что происходит в:
1) монент считывания записи, что это занимает так много времени на запись
2) и как производятся расчеты после того как все это было считано.

Jurii2 Гликоген:

Юрий, прошу не вводить людей в заблуждение!
Impromptu с ReportNet не имеет ничего общего!

Я рассматриваю ReportNet как новую версию Impromptu. Решают они одинаковые задачи, функциональность у них одинаковая, за исключением того что Impromptu силен в среде Windows, а ReportNet - в Web-среде (Impromptu Web Reports лично мне не очень нравится, хотя внедрен он по всему миру во множестве компаний, сейчас с IWR мигрируют на RN).

автор2 pustota1 (он же abur, как я понимаю :) :
Да, это все обо мне ;-)

Не понял как определяется слово "закачать". Считать данные из
базы данных и обработать или только считать данные.

И считать, и обработать.

У нас считывание и обработка занимает до 12 часов. Кроме того, как я писал не совсем ясно умеет ли Когнос распаралеливать работу на больше чем 4 процессора. Сомневаюсь, что были сделаны ошибки которые замедляют процесс в 12 раз.

авторПосмотрите, сколько создается процессов при чтении данных - если 8 - то используются все 8 процессоров.
Вы уверены что зависимость жесткая? То есть нету 8 процессов нету
использования 8 процессоров. И Transformer может использовать любое
количество процессоров. Вопрос не праздный, потому как если это
так, то будем посмотреть что делать дальше с Cognos support.
авторА что касается ошибок - то это дело житейское, я уверен что 12 часов - это неоптимальный процессинг куба.
Согласен, что ошибки дело житейское. Согласен что очень
может быть, что мы имеем дело с неоптимальным процессингом куба.
Вопрос: Можно ли это как то промерить и увидить где узкое место?
Профайлинг такой совершить по процессу построения куба.


Данные записываются один раз в банк данных и больше не исправляются

Это радует.

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

авторМожно поподробнее насчет того как Вы создаете недельные кубы на основе кубов по каждому дню? Используете партицирование по оси времени?

Покамест нельзя, поскольку я сам начал разбираться. Не буду чепуху
городить. Что конретно имеется ввиду под партиционированием по оси времени?

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

авторКак-то я делал кубик в котором было несколько сот миллионов записей с возможностью увидеть детализацию до каждой записи. Тут важно правильное проектирование... Какая у вас предметная область? Много клиентов, и по каждому много транзакций? Судя по объемам, вы либо крупный телеком, либо, что более вероятно - интернет-портал типа www.yandex.ru ...

Более вероятно второе, а на самом деле первое ;-). Да, крупный телеком.
Да, много клиентов и у кажодого много транзакций. Транзакции в связи
с этим решением носят однако не финансовый характер, а скорее имеется ввиду
определенный обмен сообщениями в разных протоколах.

Я имею в виду не только агрегации с помощью средств РСУБД, но и использование функций агрегирования в модуле Impromptu/ReportNet.
Эту фразу ня не понял, можно в более разжеванном виде?

автор
Ну например есть у нас 1 миллиард транзакций по 10 миллионам физ. лиц за 20 дней. Мы можем использовать функцию агрегирования Impromptu - Total, или Count, или Average/Min/Max, и т.д., указать контекст For ФизЛицо, День, и на выходе получим массив данных не более 200 миллионов записей - это то что вернет SQL-запрос, сгенерированный Impromptu, а результат этого запроса подается на вход в Transformer.



Транзакции не однотипные. Представьте себе что у вас есть 10 миллионов
клеинтов за 20 дней, 1 миллиард транзакций, но у транзакций есть скажем
10 разных видов плюс не все 10 миллионов клиентов одинаковы, а скажем
соотнесены к 4 разным классам.

Jurii2 abur:

Вы уверены что зависимость жесткая? То есть нету 8 процессов нету
использования 8 процессоров. И Transformer может использовать любое
количество процессоров. Вопрос не праздный, потому как если это
так, то будем посмотреть что делать дальше с Cognos support.

[quot автор]
Сколько процессов у Вас запускается реально? 4? Я не могу утверждать насчет 8 процессоров, но я никогда не слышал, чтобы у Transformer было подобное ограничение на число параллельных процессов. И хочется понять, является ли у вас процесс чтения узким местом? Можете ли Вы мне прислать по почте Ваш 12-часовой лог-файл?
Сегодня ночью и посмотрим. ;-).
Неанонимизированный конечно нет, если же говорить об анонимизированном
то, скорее всего тоже нет, но поскольку я не знаю что конкретно нужно, то
и говорю что скорее всего. Какие данные Вам нужны конкретно для оценки
ситуации. Еще раз повоторюсь, что скорее всего нет.
Дело не в моей скрытности, дело в сушествующих
обязательствах и правилах.

Согласен что очень
может быть, что мы имеем дело с неоптимальным процессингом куба.
Вопрос: Можно ли это как то промерить и увидить где узкое место?

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

Рискну предположить, что это посторение куба. Чтение и открытие
источника все таки стандартные операции, если железо используется
правильно (это я проверю) не думаю что тут должны быть проблемы.
Предоставляет ли Cognos штатные средства для копания глбуже
в эту сторону и если да, то какие.

Покамест нельзя, поскольку я сам начал разбираться. Не буду чепуху
городить. Что конретно имеется ввиду под партиционированием по оси времени?

Если у нас есть 2 куба, то просто так их в 1 куб не объеденишь... Партицирование по оси времени - это создание физического куба для каждого периода времени (года, дня, недели, месяца, квартала, как душе угодно) и объединение всего этого в виртуальный куб. Это стандартная функциональность модуля Transformer.

Более вероятно второе, а на самом деле первое ;-). Да, крупный телеком.

автор
Если не секрет - российский телеком или зарубежный? Если российский - Вам грех не воспользоваться акцией тест-драйва за 2 часа, чтобы сократить время создания куба с 12 до 2 часов :).



Не секрет. Зарубежный.

Транзакции не однотипные. Представьте себе что у вас есть 10 миллионов
клеинтов за 20 дней, 1 миллиард транзакций, но у транзакций есть скажем
10 разных видов плюс не все 10 миллионов клиентов одинаковы, а скажем
соотнесены к 4 разным классам.

Я думаю что в кубе не обязательно иметь детализацию до каждого клиента (хотя мне приходилось моделировать куб, в котором содержались данные по примерно 250 миллионам физических лиц).
автор
Что Вам мешает, обрабатывая каждую реляционную запись закачивать в куб не все записи из таблицы фактов?
Мешают три вещи:
1) Законодательство
2) Заключенные S(ervice)L(evel)A(greements) с абонентами/другими операторами
1) Существующие стандарты относительно снимаемых с сети KPI.

Больше помех нету ;-).

Сергей.Позволю себе высказать предположение что для данной задачи у Вас железо слабовато. Н.р. МТС для аналогичной работы использует SAN сервер с 12-ю двухядерными процессорами т.е их на самом деле - 24.
Да я даже смелее скажу, конечно, тут 4 процессора лучше чем 2
и 8 лучше чем 4 итд. И не так чтобы уж очень денег было жалко.
Однако перед тем как идти что то покупать надо понять что нам
собственно надо и почему именно оно. Что будем делать если 24 процессорная
машинка со скрипом будет тянуть? 48 процессорную покупать?

Гликоген

Кстати, куб у вас в файловом виде хранится или в таблицах SQL?

В файловом

Jurii2 abur:

[quot автор]
Пришлите мне для начала 3 цифры - сколько времени уходит на открытие источника данных (когда РСУБД выполняет SQL-запрос), сколько времени читаются данные, и сколько времени после этого создается куб.
Понял. Подумаю.

Рискну предположить, что это посторение куба. Чтение и открытие
источника все таки стандартные операции, если железо используется
правильно (это я проверю) не думаю что тут должны быть проблемы.

автор
Железо тут ни при чем, так как если запрос сложный, или данные читаются из сложной вьюшки, то открытие источника и чтение будут длиться долго. Я думаю что при правильном проектировании аналитической модели Cognos мне бы удалось и на 2-х процессорном сервере сгенерировать кубик из 50 миллионов записей значительно быстрее чем за 12 часов. Очень рекомендую не предполагать, а конкретно проверить.
Спасибо. Будем проверять.

Предоставляет ли Cognos штатные средства для копания глбуже
в эту сторону и если да, то какие.

Чтобы копать глубже, надо анализировать лог-файл, следить за параметрами сервера через Task Manager и обладать опытом в области Cognos.

Не секрет. Зарубежный.
авторА в какой стране находится Ваш офис, если не секрет?

В одной из стран Европейского Союза.




Мешают три вещи:
1) Законодательство
2) Заключенные S(ervice)L(evel)A(greements) с абонентами/другими операторами
3) Существующие стандарты относительно снимаемых с сети KPI.
автор
Я думаю что эти вещи Вам никак не могут мешать закачивать в кубы Transformer заранее предагрегированные данные. Законодательство (как и 2 других фактора) лишь обязывает Вас иметь все детальные записи в РСУБД/ХД, но при этом не запрещает решать аналитические задачи.


Не совсем верно. Часть данных используется для дискуссий с другими операторами где SLA, например, регулярно обсуждаются. KPI используется
для дискуссий с теми же операторами и для дискуссий с абонентами и поставщиками.
Это не совсем то законадательство, которое вы, наверное, думаете
(уголовное итд.) Речь идет о так называемой добросовестности при
принятии решений в случае акционерного общества и добросовестной
конкуренции.
На основе этих 3 факторов и конкретных способов использования и было решено предоставлять drill down до записи включительно.