2Владимир:

Интересно мнение пользователей и Microstrategy. Я пригляделся и вижу, что возможны частные оптимизации путем модернизации DWH и заведения хитрого измерения «Абоненты звонившие 1 раз за день (месяц)». Насколько я понимаю в ROLAP’ах такие задачи можно решать только так. Интересен опыт.

Такой отчёт строится исключительно визуальными средствами за 3 минуты. В отчёте 3 объекта - фильтр на метрику "Количество заказов", фильтр на промежуток времени и метрика Distinct Count Клиентов.
SQL генерируется очень простой. Я взял построил отчёт на примере проекта из Microstrategy Tutorial.


авторReport: New Report
Data Rows: 1
Data Columns: 1
Cache Used: No

Execution Start Time: 05/10/2004 21:58:48
Execution Finish Time: 05/10/2004 21:58:52

Total Duration: 0:00:03.56
SQL Duration: 0:00:03.56
Analytical Duration: 0:00:00.00
Other Processing Duration: 0:00:00.00

Number of Rows Returned: 1
Number of Columns Returned: 1
Number of Temp Tables: 2

Total Number of Passes: 7
Number of SQL Passes: 7
Number of Analytical Passes: 0

DB User: Data
DB Instance: Tutorial Data

Tables Accessed:
LU_ORDER
ORDER_FACT


SQL Statements:

Pass0 - Duration: 0:00:00.00
create table ZZTH600IFA0MQ000 (
CUSTOMER_ID SHORT)


Pass1 - Duration: 0:00:01.76
insert into ZZTH600IFA0MQ000
select a12.[CUSTOMER_ID] AS CUSTOMER_ID
from [ORDER_FACT] a11,
[LU_ORDER] a12
where a11.[ORDER_ID] = a12.[ORDER_ID]
and a11.[ORDER_DATE] in (#2001-01-08 00:00:00#, #2001-01-09 00:00:00#, #2001-01-10 00:00:00#, #2001-01-11 00:00:00#, #2001-01-12 00:00:00#, #2001-01-13 00:00:00#, #2001-01-14 00:00:00#, #2001-01-15 00:00:00#, #2001-01-16 00:00:00#, #2001-01-17 00:00:00#, #2001-01-18 00:00:00#, #2001-01-19 00:00:00#, #2001-01-20 00:00:00#, #2001-01-21 00:00:00#)
group by a12.[CUSTOMER_ID]
having count(a11.[ORDER_ID]) = 1.0

Pass2 - Duration: 0:00:00.02
create table ZZTH600IFA0OT001 (
WJXBFS1 SHORT)


Pass3 - Duration: 0:00:01.76
insert into ZZTH600IFA0OT001
select distinct a12.[CUSTOMER_ID] AS WJXBFS1
from [ORDER_FACT] a11,
[LU_ORDER] a12,
[ZZTH600IFA0MQ000] pa1
where a11.[ORDER_ID] = a12.[ORDER_ID] and
a12.[CUSTOMER_ID] = pa1.[CUSTOMER_ID]
and a11.[ORDER_DATE] in (#2001-01-08 00:00:00#, #2001-01-09 00:00:00#, #2001-01-10 00:00:00#, #2001-01-11 00:00:00#, #2001-01-12 00:00:00#, #2001-01-13 00:00:00#, #2001-01-14 00:00:00#, #2001-01-15 00:00:00#, #2001-01-16 00:00:00#, #2001-01-17 00:00:00#, #2001-01-18 00:00:00#, #2001-01-19 00:00:00#, #2001-01-20 00:00:00#, #2001-01-21 00:00:00#)

Pass4 - Duration: 0:00:00.02
select count(*) AS WJXBFS1
from [ZZTH600IFA0OT001] pa2

Pass5 - Duration: 0:00:00.00
drop table ZZTH600IFA0MQ000

Pass6 - Duration: 0:00:00.00
drop table ZZTH600IFA0OT001


Оптимизацию возможно осуществить средствами СУБД.
Здесь пример на MS Access. Если использовать более продвинутую СУБД, то можно сгенерировать 1 запрос с использованием Derived Table. Будет быстрее. Ну, и, понятное дело - индексы должны быть в порядке.

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

И неужели Вы CDR закачиваете в MS AS? 100 млн. - что-то маловато для 5 млн. абонентов.



С уважением,
Константин Лисянский
http://lissianski.narod.ru

2Владимир:

А всё-таки ответа на мой вопрос о бизнес-смысле такого простого запроса не последовало. Я по-прежнему думаю, что запрос должен быть сложнее для принятия решения.

Про having count и больше ночи я не верю. Поинтересуйтесь у Jimmy какие запросы с таблицами фактов на десятки миллионов записей у него Sybase ASE под Microstrategy ворочает. И это сервер с самым тупым оптимизатором из всех, что я встречал.


2Jurii:
При наложении фильтра по измерению Дата этот общий итог уменьшается (становится равен числу звонков за выбранный период).
Теперь в OLAP-клиенте перетаскиваем в область строк измерение с абонентами и раскрываем его до листьев.

То есть, все пять миллионов строк потенциально (предположим, что период мал, все звонили, и не более одного раза)?
Сколько тянуть, интересно будем? А сколько это всё будет на экран выводиться? Мне кажется, такой запрос должен на сервере выполняться.
Иначе клиент уйдёт в даун. Я уже получал такое на Cognos PowerPlay на более скромных объёмах. Пользователи писали кипятком после перетаскивания измерения клиентов в 20 тысяч листьев в отчёт, когда комп зависал минут на двадцать. При отсутствии возможности остановить этот беспредел - картина удручающая.
На кривые руки просьба не намекать, я уже понял, что я безнадёжен и всё такое :)


С уважением,
Константин Лисянский
http://lissianski.narod.ru

2Jurii:

ОК. Пусть даже и так, но я же не зря спросил Владимира о том, какая задача решается. Просто посчитать количество таких клиентов можно, но что дальше? Я имею в виду, какие решения можно принимать на основе этого числа?
Допустим, Вы даже получите список таких абонентов (скажем, 1 миллион человек). Дальше что будете с ним делать (напомню, он у Вас в веб-браузере в виде 100 тысяч страниц по 10 строк на страницу)?


С уважением,
Константин Лисянский
http://lissianski.narod.ru

2Jurii:

1) Это может быть один из ключевых показателей в системе сбалансированных показателей, каждый месяц это число вычисляется, и его вручную соответствующий менеджер вводит в продукт Cognos Metrics Manager :)

Воистину :))

2) Этих абонентов можно рассматривать как малоактивных, или как неопытных - их список можно выгрузить из PowerPlay Web в формат CSV, после этого специальная программа разошлет им SMS-сообщения с предложением куда-либо позвонить, и потом можно будет отслеживать, уменьшится ли число этих малоактивных абонентов с приходом следующего периода

Чтобы работать с такими списками нужна система хранения немного попродвинутее, чем текстовые файлы в формате CSV.
А как дальше сравнивать как на этих абонентов подействовала Ваша рассылка SMS? Скажем, надо для этого списка посмотреть сколько раз за период каждый из абонентов позвонил более 1 раза, менее одного раза, 1 раз.
То есть надо ответить на такой запрос: для списка абонентов, которые за период Х сделали всего один звонок, показать тех, которые после посылки им SMS за период Y после рассылки сделали более одного звонка.
Это звучит уже более интересно. Однако, можно навернуть ещё дальше - можно сегментировать этих абонентов по причине отсутствия звонков (например, есть абоненты, которые любят в отпуск отдыхать в недоступных цивилизации местах, где сотовый телефон не работает, для таких нужно посмотреть, может быть это их нормальное поведение для данного периода времени). Представим теперь, что надо собрать такой отчёт. Фишка в том, что это работа с множествами. У меня возникает сомнение в том, что это задача для OLAP. Применение SQL не вызывает никаких сомнений, а вот OLAP - не знаю.

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

Да, да согласен. Можно, но г-н Иванов не делится постановкой задачи. Может её в бизнес-виде и не существует? И опять-таки, вышеперечисленные задачи, по моему мнению лучше решать стандартным SQL, а не притягивать за уши OLAP.


С уважением,
Константин Лисянский
http://lissianski.narod.ru