ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / The future for MOLAP
25 сообщений из 43, страница 1 из 2
  1  все
The future for MOLAP
    #39379787
SkyTod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SkyTod
Гость
Вот смотрю, что MS уже практически не развивают MOLAP . Сам сейчас перехожу на ROLAP, ибо держать 100+ измерений на на МОЛАПе - самоубийство.

Я так понимаю, что MS хочет всех перевести на Tabular.

Вообще чем пользуются местные олаперы или что планируют пробовать/изучать в 2017+?
...
Рейтинг: 0 / 0
05.01.2017, 19:04
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39379839
T87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
T87
Участник
SkyTodВот смотрю, что MS уже практически не развивают MOLAP . Сам сейчас перехожу на ROLAP, ибо держать 100+ измерений на на МОЛАПе - самоубийство.

Я так понимаю, что MS хочет всех перевести на Tabular.

Вообще чем пользуются местные олаперы или что планируют пробовать/изучать в 2017+?
Делать кубы в 100+ измерений - вот это самоубийство
...
Рейтинг: 0 / 0
05.01.2017, 20:51
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39379868
Фотография vikkiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vikkiv
Участник
T87,

ну почему, если это измерения не одного куба а нескольких для какой-то SSAS:DB - то ничего особенного, обычное дело в крупной корпоративной среде (с контролем версий и множеством разных команд разработчиков под разные департаменты, релизы вообще ещё то развлечение), неудобство в том что измерения в памяти хранятся - и с ростом их ширины/глубины требования к памяти растут , к тому-же множество клиентов типа Excel можно сказать гениальны по способностям конструировать MDX запросы {но конечно лучше чем ничего/без них}, так что crossjoin-ы получаются ого какие, и только потом non empty на оси - т.к. на стороне ETL это не всегда решаемо (а Degenerate очень затратно) - приходится потом делать автоматизацию подмены источника и Process Update на полупустые измерения из nonempty очищеных таблиц делать..
...
Рейтинг: 0 / 0
05.01.2017, 22:37
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39379905
SkyTod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SkyTod
Гость
T87Делать кубы в 100+ измерений - вот это самоубийство
Что предлагаете? Плодить кубы на каждую бизнес задачу? Я загнусь их поддерживать.

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

ROLAP решает эту проблему тем, что не надо вычислять группы мер. Сделал легкий процесс базы и вуаля. С MOLAP сложнее: пришлось покупать SSD, ибо он не справляется с вычислением измерений, групп мер, изменения xmla и еще получения данных (всякие большие MDX).

Кстати, только после года использования я понял, что MDX - зло. Сначала я его очень любил, но когда начал чуть ли не везде его использовать (чего там - рантайм же), а тысячи пользователи материть, что все тупит, то я понял одну хорошую практику:
1. Считай все в DWH.
2. Если надо MDX, то не используй всякие сетовые функции (Sum, NonEmpty, Filter, Existing и тому подобные).

Поэтому и возник вопрос, есть ли смысл учить DAX? Или Tabular на практике тоже не очень?
...
Рейтинг: 0 / 0
06.01.2017, 01:13
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39379912
Фотография Alex_496
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_496
Участник
SkyTod,

1.
100+ измерений -> может какие-то можно объединить в одно измерение

2.
Посмотрите Profiler-ом какие запросы ROLAP пуляет и как эти запросы будут отрабатываться на 0,5-1 млрд. записей

3.
так по пробуйте Tabular на больших объемах и потом расскажите как у Вас получилось
...
Рейтинг: 0 / 0
06.01.2017, 01:51
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39379953
T87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
T87
Участник
SkyTodT87Делать кубы в 100+ измерений - вот это самоубийство
Что предлагаете? Плодить кубы на каждую бизнес задачу? Я загнусь их поддерживать.

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

ROLAP решает эту проблему тем, что не надо вычислять группы мер. Сделал легкий процесс базы и вуаля. С MOLAP сложнее: пришлось покупать SSD, ибо он не справляется с вычислением измерений, групп мер, изменения xmla и еще получения данных (всякие большие MDX).

Кстати, только после года использования я понял, что MDX - зло. Сначала я его очень любил, но когда начал чуть ли не везде его использовать (чего там - рантайм же), а тысячи пользователи материть, что все тупит, то я понял одну хорошую практику:
1. Считай все в DWH.
2. Если надо MDX, то не используй всякие сетовые функции (Sum, NonEmpty, Filter, Existing и тому подобные).

Поэтому и возник вопрос, есть ли смысл учить DAX? Или Tabular на практике тоже не очень?
Ну не видя конкретныхзадач, предлагать что-то конкретное глупо. Навскидку: Объединение измерений по смыслу (я например не могу представить 100+ дименшенов для продаж), делать Junk для мелких дименшенов.
По поводу MDX - во многом согласен, по возможности все выносить на DWH.
По tabular 2016 ничего не могу сказать, но 2014 на мой взгляд очень не дотягивал до multidim.
...
Рейтинг: 0 / 0
06.01.2017, 09:53
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380102
SkyTod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SkyTod
Гость
Alex_4961.
100+ измерений -> может какие-то можно объединить в одно измерениеТо есть увеличить количество атрибутов? Шило на мыло, как по мне.
Alex_4962.
Посмотрите Profiler-ом какие запросы ROLAP пуляет и как эти запросы будут отрабатываться на 0,5-1 млрд. записейЭто да. Как, кстати, в этом плане в HOLAP? Hadoop кто использовал для таких задач? Или затратно? Все-таки 2017 год.
Alex_4963.
так по пробуйте Tabular на больших объемах и потом расскажите как у Вас получилосьВы даже отняли у меня желание попробовать. :)
T87Ну не видя конкретныхзадач, предлагать что-то конкретное глупо. Навскидку: Объединение измерений по смыслу (я например не могу представить 100+ дименшенов для продаж), делать Junk для мелких дименшенов.Я приводил примеры выше, они не всегда связаны с продажей напрямую. Например, надо посмотреть сколько клиентов начали заказывать определенное SKU после того, как получили смс с текстом (а фильтр текста - это отдельное измерение). Таких примеров тысячи.
...
Рейтинг: 0 / 0
06.01.2017, 15:38
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380113
T87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
T87
Участник
SkyTod,

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

Если бы Вы показали свою матрицу шины, то можно было бы боллее предметно поговорить, а так разговор сферическом коне в вакууме
...
Рейтинг: 0 / 0
06.01.2017, 16:18
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380166
RioMare
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RioMare
Участник
Делать кубы в 100+ измерений - вот это самоубийство
Всецело поддерживаю !
А разные заказчики хотят, увидеть все что угодно: смс в разрезе текста, звонки в разрезе двух номеров, цены в разрезе определенных промежутков…

Я конечно могу заблуждаться, но (M/R/H)OLAP немного для других вещей - считать фиксированные значения для различных уровней измерений ( или как комбинации измерений ) в разрезе времени . Для этого MDX и нужен.
А вот для того, чтобы оценить "сколько клиентов начали заказывать определенное SKU после того, как получили смс с текстом"
подойдёт скорее вот это.
...
Рейтинг: 0 / 0
06.01.2017, 18:59
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380178
SkyTod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SkyTod
Гость
T87Если бы Вы показали свою матрицу шины, то можно было бы боллее предметно поговорить, а так разговор сферическом коне в вакуумеЕсли действительно так интересно, то могу расписать, но это займет много времени. И скорее всего мы придем к тому, что их объединять нет смысла.
RioMareЯ конечно могу заблуждаться, но (M/R/H)OLAP немного для других вещей - считать фиксированные значения для различных уровней измерений ( или как комбинации измерений ) в разрезе времени . Для этого MDX и нужен.
А вот для того, чтобы оценить "сколько клиентов начали заказывать определенное SKU после того, как получили смс с текстом"
подойдёт скорее вот это. Мне DataMining не прижился, а тупому пользователю нужно зайти в ексельку и увидеть отчет в том разрезе, что он хочет. И я все чаще вынужден наоборот: выносить атрибуты в отдельное измерение, чем играться в SlowChanging Dimensions и DataMining. И пусть это будет MDX, но все равно измерение надо добавлять.
...
Рейтинг: 0 / 0
06.01.2017, 19:57
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380571
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
Имхо, olap (не зависимо какая буква стоит впереди) умер как технология.
Приход дешёвой памяти сильно изменил рынок.
А текущие бизнес потребности (всё большие скорости принятия решений, машинное обучение и тд и тп) окончательно расставили точки над Ё.
Будущее за MPP системами (куда включаю и NewSQL в том числе).
У MDX-а могло быть будущее если бы MS стали развивать его в сторону параллельности, но походу "не успех" APS(PDW) не дал им шанса,
собственно в сиквеле (который толкают вперёд) мы до сих пор не видим кластера.
Что касается Tabular... в том виде (архитектурно) как есть сейчас это "уже умерло" хоть и не знает об этом.SkyTodHadoop кто использовал для таких задач?для каких "таких"? Экосистема "хадупа" довольно широка. Посмотрите на чём сидит Амазон, например.
...
Рейтинг: 0 / 0
08.01.2017, 19:59
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380589
Voyager_lan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Voyager_lan
Участник
[quot T87]SkyTodпропущено...

По tabular 2016 ничего не могу сказать, но 2014 на мой взгляд очень не дотягивал до multidim.

Не всё сразу. Tabular допилят рано-вовремя-не очень поздно :) Допилят и DirectQuery под него.
Понятно, что сложные проекты с Tabular сейчас не взлетят, т.к. функциональность не дотягивает до miltidim... Всему свое время, прогнозы пока рано делать, что уже, а что еще не умерло :)
И еще, как тут уже сказали, не все задачи подряд нужно одним "молотком" забивать...
...
Рейтинг: 0 / 0
08.01.2017, 22:09
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380620
SkyTod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SkyTod
Гость
ДедушкаИмхо, olap (не зависимо какая буква стоит впереди) умер как технология.Это как? Концепция же остается: возможность затем просматривать кубы без знания языков запросов. Какие здесь альтернативы?
...
Рейтинг: 0 / 0
09.01.2017, 02:36
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380662
Фотография Alex_496
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_496
Участник
Дедушка,

ну да,
сервер HP BL660c Gen9 E5-4627v4 (40 cores, 1024GB RAM) = $44К
и +
дисковый массив на 7Tb без резервирования = $23К


32 планки по 16Гб, модель HP 672633-B21 = $8,6К
...
Рейтинг: 0 / 0
09.01.2017, 09:29
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380705
RioMare
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RioMare
Участник
SkyTod,
если хочется именно OLAP/MDX :
Как я понимаю ваша задача обычная marketing automation -
Измерение Nr.1 :
[Marketing_campaing].[ID] где [ID] - это кому куда слали СМС с текстом/promo-code/ & etc.
ну и факты соответственно
[dateID].[marketing_campain_id].[customer_id].[итд_итп].[слали_СМС]

ну и потом как-то так -
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
with set 
	customers as [customer]..[чего-то-там].Children
	markeing_campaign as [Marketing_campaing].[ID].[&С новым годом]
	campaign_outcome as NonEmpty(customers,markeing_campaign,[measures].[слали_СМС]
        sales_outcome as NonEmpty(campaign_outcome,customers,[measures].[продажи_Chardon_MOЁT]
select 
	...
from [куб]


Зачем там 100 измерений ?
...
Рейтинг: 0 / 0
09.01.2017, 10:34
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380786
Фотография StarikNavy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StarikNavy
Участник
SkyTod,

емнип, MS как изначально позиционировали Tabular "маленький объем/простота для вхождения в мир настоящего BI" так и оставили его в этом углу
...
Рейтинг: 0 / 0
09.01.2017, 12:16
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380797
Фотография vikkiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vikkiv
Участник
StarikNavySkyTod,

емнип, MS как изначально позиционировали Tabular "маленький объем/простота для вхождения в мир настоящего BI" так и оставили его в этом углу..походу при этом забросив развитие настоящего БИ (облачные попытки с миграцией на Azure/PDW пока сложно назвать особо выдающимися)
...
Рейтинг: 0 / 0
09.01.2017, 12:25
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380919
RioMare
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RioMare
Участник
SkyTod,

а если из области общей эрудиции :)

IMHO MS решили пойти по пути "заработаем $1 на миллионе клиентов, чем $1,000,000 на одном" и поэтому развивают продукты, которые можно продать миллиону, а остальные поддерживают в работоспособном состоянии.
Поэтому SQL Server развивают, а Analysis Services - нет. ( поскольку он нужен одному, а не миллиону ) и через пару релизов в каком-нибудь SQL2020 его больше вообще поставлять не будут.
А OLAP не умерла, просто стала узкоспециализированной - для объёмов, которые in-memory движки просто не тянут ( пока ).
...
Рейтинг: 0 / 0
09.01.2017, 15:49
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380943
Фотография Alex_496
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_496
Участник
IMHO,

MS вляпались в Agile, поэтому количество багов, порой самых грубо очевидных, в службах MS SQL 2016 стало больше, а коммуникация с MS в рамках премьер-поддержки => то ещё развлечение, столько времени отъедает на переписку.
...
Рейтинг: 0 / 0
09.01.2017, 16:22
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380982
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
RioMareА OLAP не умерла, просто стала узкоспециализированной - для объёмов, которые in-memory движки просто не тянут ( пока ).ну я не рискну предположить какой объём данных не сможет вытянуть аналитика на Spark (например),
shared nothing тож не просто так (не нужно всё тянуть в память на одном серваке) пример кластер Exasol ну и тд.
Технология обработки данных на одном сервере (а в случае с MDX ещё и в один поток) не жилец (исключительно имхо).
...
Рейтинг: 0 / 0
09.01.2017, 17:31
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39380985
Фотография Alex_496
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_496
Участник
Дедушка,

а может, команде-разработчиков SSAS Multidim не дали развивать проект? История об этом умалчивает, например, почему ушел Моша, причины нам не известны.
Задачи типа задействования FE в несколько потоков - вряд ли концептуально не разрешимая.
...
Рейтинг: 0 / 0
09.01.2017, 17:39
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39381005
SkyTod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SkyTod
Гость
RioMareSkyTod,
если хочется именно OLAP/MDX :
Как я понимаю ваша задача обычная marketing automation -
Измерение Nr.1 :
[Marketing_campaing].[ID] где [ID] - это кому куда слали СМС с текстом/promo-code/ & etc.
ну и факты соответственно
[dateID].[marketing_campain_id].[customer_id].[итд_итп].[слали_СМС]

ну и потом как-то так -
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
with set 
	customers as [customer]..[чего-то-там].Children
	markeing_campaign as [Marketing_campaing].[ID].[&С новым годом]
	campaign_outcome as NonEmpty(customers,markeing_campaign,[measures].[слали_СМС]
        sales_outcome as NonEmpty(campaign_outcome,customers,[measures].[продажи_Chardon_MOЁT]
select 
	...
from [куб]


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

И это только одно измерение. У нас есть еще аналитика нескольких CRM, сайта, телефонии, которые могут иметь от 0 до 20 новых измерений, которых уже невозможно объединить с существующими (например, номера входящих и исходящих вызовов, канал вызова, оператор). Также иногда приходится дублировать два измерения (например, клиентов для задач, где один клиент привел другого клиента) и тд.
...
Рейтинг: 0 / 0
09.01.2017, 18:04
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39381038
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
ДедушкаТехнология обработки данных на одном сервере (а в случае с MDX ещё и в один поток) не жилец (исключительно имхо).

Там же только формульный движок однопоточный, просто пишем меньше вычислений в кубе, и все будет нормально.
Также при желании можно самому поднять ферму из olap-серверов после балансировщика. Конечно, это не идеальное решение, но это вполне работает на довольно больших объемах и с большим количеством пользователей.
...
Рейтинг: 0 / 0
09.01.2017, 19:11
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39381040
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
Хотя, и мне тоже не нравится нулевое развитие AS за последние годы )
...
Рейтинг: 0 / 0
09.01.2017, 19:12
| Ответить | Цитировать | Написать  
The future for MOLAP
    #39381047
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
SkyTodИ это только одно измерение. У нас есть еще аналитика нескольких CRM, сайта, телефонии, которые могут иметь от 0 до 20 новых измерений, которых уже невозможно объединить с существующими (например, номера входящих и исходящих вызовов, канал вызова, оператор). Также иногда приходится дублировать два измерения (например, клиентов для задач, где один клиент привел другого клиента) и тд.

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

Номера входящих и номера исходящих при желании объединяются в одно измерние "номера телефонов". Аналогично с клиентами. Канал вызова, оператор - не должны вызвать никаких проблем, т.к. должны иметь крайне малую мощность.
...
Рейтинг: 0 / 0
09.01.2017, 19:20
| Ответить | Цитировать | Написать  
25 сообщений из 43, страница 1 из 2
  1  все
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / The future for MOLAP
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=49&msg=39379912&tid=1858390]:
 0ms
get settings:
 11ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 69ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 67ms
get tp. blocked users:
 2ms
others: 237ms
total:  419ms
созд. / загр.: 419ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]