Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 The future for MOLAP  [new]
SkyTod
Member

Откуда:
Сообщений: 30
Вот смотрю, что MS уже практически не развивают MOLAP. Сам сейчас перехожу на ROLAP, ибо держать 100+ измерений на на МОЛАПе - самоубийство.

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

Вообще чем пользуются местные олаперы или что планируют пробовать/изучать в 2017+?
5 янв 17, 19:04    [20075545]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
T87
Member

Откуда:
Сообщений: 66
SkyTod
Вот смотрю, что MS уже практически не развивают MOLAP. Сам сейчас перехожу на ROLAP, ибо держать 100+ измерений на на МОЛАПе - самоубийство.

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

Вообще чем пользуются местные олаперы или что планируют пробовать/изучать в 2017+?

Делать кубы в 100+ измерений - вот это самоубийство
5 янв 17, 20:51    [20075796]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
vikkiv
Member

Откуда: London / Zurich
Сообщений: 1133
T87,

ну почему, если это измерения не одного куба а нескольких для какой-то SSAS:DB - то ничего особенного, обычное дело в крупной корпоративной среде (с контролем версий и множеством разных команд разработчиков под разные департаменты, релизы вообще ещё то развлечение), неудобство в том что измерения в памяти хранятся - и с ростом их ширины/глубины требования к памяти растут , к тому-же множество клиентов типа Excel можно сказать гениальны по способностям конструировать MDX запросы {но конечно лучше чем ничего/без них}, так что crossjoin-ы получаются ого какие, и только потом non empty на оси - т.к. на стороне ETL это не всегда решаемо (а Degenerate очень затратно) - приходится потом делать автоматизацию подмены источника и Process Update на полупустые измерения из nonempty очищеных таблиц делать..
5 янв 17, 22:37    [20076130]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
SkyTod
Member

Откуда:
Сообщений: 30
T87
Делать кубы в 100+ измерений - вот это самоубийство

Что предлагаете? Плодить кубы на каждую бизнес задачу? Я загнусь их поддерживать.

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

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

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

Поэтому и возник вопрос, есть ли смысл учить DAX? Или Tabular на практике тоже не очень?
6 янв 17, 01:13    [20076594]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Alex_496
Member

Откуда: Moscow http://dvbi.ru
Сообщений: 3459
SkyTod,

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

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

3.
так по пробуйте Tabular на больших объемах и потом расскажите как у Вас получилось
6 янв 17, 01:51    [20076634]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
T87
Member

Откуда:
Сообщений: 66
SkyTod
T87
Делать кубы в 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.
6 янв 17, 09:53    [20076899]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
SkyTod
Member

Откуда:
Сообщений: 30
Alex_496
1.
100+ измерений -> может какие-то можно объединить в одно измерение
То есть увеличить количество атрибутов? Шило на мыло, как по мне.
Alex_496
2.
Посмотрите Profiler-ом какие запросы ROLAP пуляет и как эти запросы будут отрабатываться на 0,5-1 млрд. записей
Это да. Как, кстати, в этом плане в HOLAP? Hadoop кто использовал для таких задач? Или затратно? Все-таки 2017 год.
Alex_496
3.
так по пробуйте Tabular на больших объемах и потом расскажите как у Вас получилось
Вы даже отняли у меня желание попробовать. :)
T87
Ну не видя конкретныхзадач, предлагать что-то конкретное глупо. Навскидку: Объединение измерений по смыслу (я например не могу представить 100+ дименшенов для продаж), делать Junk для мелких дименшенов.
Я приводил примеры выше, они не всегда связаны с продажей напрямую. Например, надо посмотреть сколько клиентов начали заказывать определенное SKU после того, как получили смс с текстом (а фильтр текста - это отдельное измерение). Таких примеров тысячи.
6 янв 17, 15:38    [20077651]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
T87
Member

Откуда:
Сообщений: 66
SkyTod,

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

Если бы Вы показали свою матрицу шины, то можно было бы боллее предметно поговорить, а так разговор сферическом коне в вакууме
6 янв 17, 16:18    [20077730]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
RioMare
Member

Откуда: EU
Сообщений: 269
Делать кубы в 100+ измерений - вот это самоубийство

Всецело поддерживаю !
А разные заказчики хотят, увидеть все что угодно: смс в разрезе текста, звонки в разрезе двух номеров, цены в разрезе определенных промежутков…

Я конечно могу заблуждаться, но (M/R/H)OLAP немного для других вещей - считать фиксированные значения для различных уровней измерений ( или как комбинации измерений ) в разрезе времени. Для этого MDX и нужен.
А вот для того, чтобы оценить "сколько клиентов начали заказывать определенное SKU после того, как получили смс с текстом"
подойдёт скорее вот это.
6 янв 17, 18:59    [20078068]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
SkyTod
Member

Откуда:
Сообщений: 30
T87
Если бы Вы показали свою матрицу шины, то можно было бы боллее предметно поговорить, а так разговор сферическом коне в вакууме
Если действительно так интересно, то могу расписать, но это займет много времени. И скорее всего мы придем к тому, что их объединять нет смысла.
RioMare
Я конечно могу заблуждаться, но (M/R/H)OLAP немного для других вещей - считать фиксированные значения для различных уровней измерений ( или как комбинации измерений ) в разрезе времени. Для этого MDX и нужен.
А вот для того, чтобы оценить "сколько клиентов начали заказывать определенное SKU после того, как получили смс с текстом"
подойдёт скорее вот это.
Мне DataMining не прижился, а тупому пользователю нужно зайти в ексельку и увидеть отчет в том разрезе, что он хочет. И я все чаще вынужден наоборот: выносить атрибуты в отдельное измерение, чем играться в SlowChanging Dimensions и DataMining. И пусть это будет MDX, но все равно измерение надо добавлять.
6 янв 17, 19:57    [20078175]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 4537
Имхо, olap (не зависимо какая буква стоит впереди) умер как технология.
Приход дешёвой памяти сильно изменил рынок.
А текущие бизнес потребности (всё большие скорости принятия решений, машинное обучение и тд и тп) окончательно расставили точки над Ё.
Будущее за MPP системами (куда включаю и NewSQL в том числе).
У MDX-а могло быть будущее если бы MS стали развивать его в сторону параллельности, но походу "не успех" APS(PDW) не дал им шанса,
собственно в сиквеле (который толкают вперёд) мы до сих пор не видим кластера.
Что касается Tabular... в том виде (архитектурно) как есть сейчас это "уже умерло" хоть и не знает об этом.
SkyTod
Hadoop кто использовал для таких задач?
для каких "таких"? Экосистема "хадупа" довольно широка. Посмотрите на чём сидит Амазон, например.
8 янв 17, 19:59    [20082715]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Voyager_lan
Member

Откуда:
Сообщений: 1437
[quot T87]
SkyTod
пропущено...

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


Не всё сразу. Tabular допилят рано-вовремя-не очень поздно :) Допилят и DirectQuery под него.
Понятно, что сложные проекты с Tabular сейчас не взлетят, т.к. функциональность не дотягивает до miltidim... Всему свое время, прогнозы пока рано делать, что уже, а что еще не умерло :)
И еще, как тут уже сказали, не все задачи подряд нужно одним "молотком" забивать...
8 янв 17, 22:09    [20083068]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
SkyTod
Member

Откуда:
Сообщений: 30
Дедушка
Имхо, olap (не зависимо какая буква стоит впереди) умер как технология.
Это как? Концепция же остается: возможность затем просматривать кубы без знания языков запросов. Какие здесь альтернативы?
9 янв 17, 02:36    [20083446]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Alex_496
Member

Откуда: Moscow http://dvbi.ru
Сообщений: 3459
Дедушка,

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


32 планки по 16Гб, модель HP 672633-B21 = $8,6К
9 янв 17, 09:29    [20083663]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
RioMare
Member

Откуда: EU
Сообщений: 269
SkyTod,
если хочется именно OLAP/MDX :
Как я понимаю ваша задача обычная marketing automation -
Измерение Nr.1 :
[Marketing_campaing].[ID] где [ID] - это кому куда слали СМС с текстом/promo-code/ & etc.
ну и факты соответственно
[dateID].[marketing_campain_id].[customer_id].[итд_итп].[слали_СМС]

ну и потом как-то так -
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 измерений ?
9 янв 17, 10:34    [20083837]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 1596
SkyTod,

емнип, MS как изначально позиционировали Tabular "маленький объем/простота для вхождения в мир настоящего BI" так и оставили его в этом углу
9 янв 17, 12:16    [20084324]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
vikkiv
Member

Откуда: London / Zurich
Сообщений: 1133
StarikNavy
SkyTod,

емнип, MS как изначально позиционировали Tabular "маленький объем/простота для вхождения в мир настоящего BI" так и оставили его в этом углу
..походу при этом забросив развитие настоящего БИ (облачные попытки с миграцией на Azure/PDW пока сложно назвать особо выдающимися)
9 янв 17, 12:25    [20084370]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
RioMare
Member

Откуда: EU
Сообщений: 269
SkyTod,

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

IMHO MS решили пойти по пути "заработаем $1 на миллионе клиентов, чем $1,000,000 на одном" и поэтому развивают продукты, которые можно продать миллиону, а остальные поддерживают в работоспособном состоянии.
Поэтому SQL Server развивают, а Analysis Services - нет. ( поскольку он нужен одному, а не миллиону ) и через пару релизов в каком-нибудь SQL2020 его больше вообще поставлять не будут.
А OLAP не умерла, просто стала узкоспециализированной - для объёмов, которые in-memory движки просто не тянут ( пока ).
9 янв 17, 15:49    [20085176]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Alex_496
Member

Откуда: Moscow http://dvbi.ru
Сообщений: 3459
IMHO,

MS вляпались в Agile, поэтому количество багов, порой самых грубо очевидных, в службах MS SQL 2016 стало больше, а коммуникация с MS в рамках премьер-поддержки => то ещё развлечение, столько времени отъедает на переписку.
9 янв 17, 16:22    [20085355]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 4537
RioMare
А OLAP не умерла, просто стала узкоспециализированной - для объёмов, которые in-memory движки просто не тянут ( пока ).
ну я не рискну предположить какой объём данных не сможет вытянуть аналитика на Spark (например),
shared nothing тож не просто так (не нужно всё тянуть в память на одном серваке) пример кластер Exasol ну и тд.
Технология обработки данных на одном сервере (а в случае с MDX ещё и в один поток) не жилец (исключительно имхо).
9 янв 17, 17:31    [20085666]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Alex_496
Member

Откуда: Moscow http://dvbi.ru
Сообщений: 3459
Дедушка,

а может, команде-разработчиков SSAS Multidim не дали развивать проект? История об этом умалчивает, например, почему ушел Моша, причины нам не известны.
Задачи типа задействования FE в несколько потоков - вряд ли концептуально не разрешимая.
9 янв 17, 17:39    [20085698]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
SkyTod
Member

Откуда:
Сообщений: 30
RioMare
SkyTod,
если хочется именно OLAP/MDX :
Как я понимаю ваша задача обычная marketing automation -
Измерение Nr.1 :
[Marketing_campaing].[ID] где [ID] - это кому куда слали СМС с текстом/promo-code/ & etc.
ну и факты соответственно
[dateID].[marketing_campain_id].[customer_id].[итд_итп].[слали_СМС]

ну и потом как-то так -
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 новых измерений, которых уже невозможно объединить с существующими (например, номера входящих и исходящих вызовов, канал вызова, оператор). Также иногда приходится дублировать два измерения (например, клиентов для задач, где один клиент привел другого клиента) и тд.
9 янв 17, 18:04    [20085787]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30963
Блог
Дедушка
Технология обработки данных на одном сервере (а в случае с MDX ещё и в один поток) не жилец (исключительно имхо).


Там же только формульный движок однопоточный, просто пишем меньше вычислений в кубе, и все будет нормально.
Также при желании можно самому поднять ферму из olap-серверов после балансировщика. Конечно, это не идеальное решение, но это вполне работает на довольно больших объемах и с большим количеством пользователей.
9 янв 17, 19:11    [20086011]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30963
Блог
Хотя, и мне тоже не нравится нулевое развитие AS за последние годы )
9 янв 17, 19:12    [20086016]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30963
Блог
SkyTod
И это только одно измерение. У нас есть еще аналитика нескольких CRM, сайта, телефонии, которые могут иметь от 0 до 20 новых измерений, которых уже невозможно объединить с существующими (например, номера входящих и исходящих вызовов, канал вызова, оператор). Также иногда приходится дублировать два измерения (например, клиентов для задач, где один клиент привел другого клиента) и тд.


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

Номера входящих и номера исходящих при желании объединяются в одно измерние "номера телефонов". Аналогично с клиентами. Канал вызова, оператор - не должны вызвать никаких проблем, т.к. должны иметь крайне малую мощность.
9 янв 17, 19:20    [20086048]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
RioMare
Member

Откуда: EU
Сообщений: 269
Дедушка,
Наверное не ясно выразился - развивать OLAP как stand-alone продукт уже вряд ли кто-то будет. Будут поддерживать свою реализацию OLAPa для своих же продуктов, как IBM/Cognos TM1 ( Jurii может меня поправить :) ) или SAS/OLAP Server.
Те, кому это не нужно - забьют и будут делать свою in-memory analytics.

@SkyTod, вот такое будущее for MOLAP - future of no future
9 янв 17, 19:20    [20086049]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
SkyTod
Member

Откуда:
Сообщений: 30
Критик
OLAP - это в первую очередь аналитическая отчетность, в кубах вы можете показывать только сгруппированные данные. Кого они не устраивают - добро пожаловать в детальную sql-витрину, пусть пишут adhoc-запросы.
Это круто, если у вас так. Учить людей SQL я не хочу, самому каждую неделю запускать некий код по требованию - тоже не хочу, пусть сами в кубе крутят. Зачем мне это? Раз сделал в кубе и забыл.
10 янв 17, 18:29    [20090729]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
T87
Member

Откуда:
Сообщений: 66
SkyTod
Критик
OLAP - это в первую очередь аналитическая отчетность, в кубах вы можете показывать только сгруппированные данные. Кого они не устраивают - добро пожаловать в детальную sql-витрину, пусть пишут adhoc-запросы.
Это круто, если у вас так. Учить людей SQL я не хочу, самому каждую неделю запускать некий код по требованию - тоже не хочу, пусть сами в кубе крутят. Зачем мне это? Раз сделал в кубе и забыл.

Мне еще ни один юзер не смог внятно объянить нафига ему простыня данных. В основном это просто привычка. Юзеров надо обучать работать с аналитикой, хотя согласен, не всегда они идут на контакт.
P.s.: Посмотрите tabular 2016 с directquery.
10 янв 17, 20:44    [20091154]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Alex_496
Member

Откуда: Moscow http://dvbi.ru
Сообщений: 3459
T87
SkyTod
пропущено...
Это круто, если у вас так. Учить людей SQL я не хочу, самому каждую неделю запускать некий код по требованию - тоже не хочу, пусть сами в кубе крутят. Зачем мне это? Раз сделал в кубе и забыл.

Мне еще ни один юзер не смог внятно объянить нафига ему простыня данных. В основном это просто привычка. Юзеров надо обучать работать с аналитикой, хотя согласен, не всегда они идут на контакт.
P.s.: Посмотрите tabular 2016 с directquery.


ну например,
1.
простыня данных для того, чтобы её проВПР-ить с другими Excel-наколенными-данными, которых нет в вашем кубе, а потом собрать снова в сводную таблицу

2.
передать простыню данных внешним пользователям/контрагентам для сверки, встречной проверки
10 янв 17, 20:54    [20091185]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
T87
Member

Откуда:
Сообщений: 66
Alex_496
T87
пропущено...

Мне еще ни один юзер не смог внятно объянить нафига ему простыня данных. В основном это просто привычка. Юзеров надо обучать работать с аналитикой, хотя согласен, не всегда они идут на контакт.
P.s.: Посмотрите tabular 2016 с directquery.


ну например,
1.
простыня данных для того, чтобы её проВПР-ить с другими Excel-наколенными-данными, которых нет в вашем кубе, а потом собрать снова в сводную таблицу

2.
передать простыню данных внешним пользователям/контрагентам для сверки, встречной проверки

1. А DWH то нафига ели там данных не хватает? Заливать всё туда и строить сражу нужную отчетность, а не ВПРииь
2. Для этого не нужен adhoc. Как писал выше Критик - делайте витрины, ну или на крайняк еженочные автоматические генерации простыней
10 янв 17, 21:03    [20091214]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
soulsurfer
Member

Откуда:
Сообщений: 317
T87
1. А DWH то нафига ели там данных не хватает? Заливать всё туда и строить сражу нужную отчетность, а не ВПРииь

А это сходу сценарий могу рассказать: данные в DWH считаются чистыми и выверенными, а те, с которыми надо ВПРить - грязными и пихать в DWH архитектор не разрешает.

Вот аналитики и хотят простыни ВПРить. :)
11 янв 17, 11:32    [20092787]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3259
soulsurfer
T87
1. А DWH то нафига ели там данных не хватает? Заливать всё туда и строить сражу нужную отчетность, а не ВПРииь

А это сходу сценарий могу рассказать: данные в DWH считаются чистыми и выверенными, а те, с которыми надо ВПРить - грязными и пихать в DWH архитектор не разрешает.

Вот аналитики и хотят простыни ВПРить. :)

так а зачем тут олап? пусть из витрины+отчета данные берут.
11 янв 17, 13:50    [20093610]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
soulsurfer
Member

Откуда:
Сообщений: 317
Ivan Durak
soulsurfer
пропущено...

А это сходу сценарий могу рассказать: данные в DWH считаются чистыми и выверенными, а те, с которыми надо ВПРить - грязными и пихать в DWH архитектор не разрешает.

Вот аналитики и хотят простыни ВПРить. :)

так а зачем тут олап? пусть из витрины+отчета данные берут.

Действительно причем тут олап, если выше спрашивают про DWH?
11 янв 17, 13:55    [20093644]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3259
soulsurfer
Ivan Durak
пропущено...

так а зачем тут олап? пусть из витрины+отчета данные берут.

Действительно причем тут олап, если выше спрашивают про DWH?

началось-то все с
автор
пусть сами в кубе крутят. Зачем мне это? Раз сделал в кубе и забыл.
11 янв 17, 14:19    [20093785]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Leoris
Member

Откуда:
Сообщений: 47
soulsurfer,
а что мешает создать рядом базу данных / схему для аналитиков, куда они могут лить свои грязные данные и объединять с витринами?
11 янв 17, 14:22    [20093806]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
soulsurfer
Member

Откуда:
Сообщений: 317
Leoris
soulsurfer,
а что мешает создать рядом базу данных / схему для аналитиков, куда они могут лить свои грязные данные и объединять с витринами?

Как правило, отсутствие времени. Аналитикам нужен результат сейчас, а не через несколько недель имплементации загрузки в некую БД, устранение проблем с авторизациями, доступами и т.д.
11 янв 17, 14:36    [20093892]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3259
soulsurfer
Leoris
soulsurfer,
а что мешает создать рядом базу данных / схему для аналитиков, куда они могут лить свои грязные данные и объединять с витринами?

Как правило, отсутствие времени. Аналитикам нужен результат сейчас, а не через несколько недель имплементации загрузки в некую БД, устранение проблем с авторизациями, доступами и т.д.

там где я работал, и где были весь толковые и сообразительные аналитики. Они сами себе могли создавать в своих схемах свои витрины грязные, делать с ними все что угодно, парралельно создав задачу на разработку эжтой витрины для продакшена.
Главное условие - аналитики должны быть продвинутые, дружить с sql и бд.
11 янв 17, 14:52    [20094000]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Alex_496
Member

Откуда: Moscow http://dvbi.ru
Сообщений: 3459
T87
Alex_496
пропущено...


ну например,
1.
простыня данных для того, чтобы её проВПР-ить с другими Excel-наколенными-данными, которых нет в вашем кубе, а потом собрать снова в сводную таблицу

2.
передать простыню данных внешним пользователям/контрагентам для сверки, встречной проверки

1. А DWH то нафига ели там данных не хватает? Заливать всё туда и строить сражу нужную отчетность, а не ВПРииь
2. Для этого не нужен adhoc. Как писал выше Критик - делайте витрины, ну или на крайняк еженочные автоматические генерации простыней


Положим, есть N-спецов по DWH-строению. Им сформирован пул задач на 12 мес. вперед.
А тут с парашютом приземлился новый ТОП-манагер, который запрягает своих опричников и к вам ломятся еще туча зачач подтянуть данные из неведомых CRM, да чтобы срочно, еще вчера. Так вот, по п.1 продвинутые юзвери хоть как-то решают задачу и не дергают вас
11 янв 17, 15:24    [20094141]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
soulsurfer
Member

Откуда:
Сообщений: 317
Ivan Durak
soulsurfer
пропущено...

Как правило, отсутствие времени. Аналитикам нужен результат сейчас, а не через несколько недель имплементации загрузки в некую БД, устранение проблем с авторизациями, доступами и т.д.

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


Рассказать вам про "ошибку выживших"?
11 янв 17, 17:15    [20094833]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30963
Блог
soulsurfer
Leoris
soulsurfer,
а что мешает создать рядом базу данных / схему для аналитиков, куда они могут лить свои грязные данные и объединять с витринами?

Как правило, отсутствие времени. Аналитикам нужен результат сейчас, а не через несколько недель имплементации загрузки в некую БД, устранение проблем с авторизациями, доступами и т.д.


что-то?
у нас они сами этим занимаются - в качестве песочницы выделена отдельная БД, причем оговорено, что нами она не поддерживается
11 янв 17, 20:30    [20095505]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
RioMare
Member

Откуда: EU
Сообщений: 269
soulsurfer
Аналитикам нужен результат сейчас, а не через несколько недель имплементации загрузки в некую БД, устранение проблем с авторизациями, доступами и т.д.

Вот именно поэтому всякие in-memory engine ( и подобные ) активно развиваются - не нужно никаких промежуточных БД, ни песочниц, ни витрин и тд. Берите данные напрямую из DWH и работайте насколько позволяют знания и возможности железа.
А МOLAPы остануться как ускорители для заранее оговорённых отчётов и рано или поздно вытеснят column-based MPP DB, поскольку не надо будет заморачиваться с измерениями-фактами ( моё IMHO ).
12 янв 17, 09:52    [20096888]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
kaldorey
Member

Откуда:
Сообщений: 557
soulsurfer
А это сходу сценарий могу рассказать: данные в DWH считаются чистыми и выверенными, а те, с которыми надо ВПРить - грязными и пихать в DWH архитектор не разрешает.

Вот аналитики и хотят простыни ВПРить. :)


Для этого есть лямбда архитектура. Если такое уж понадобилось, то самое время ее реализовать
12 янв 17, 18:52    [20099861]     Ответить | Цитировать Сообщить модератору
 Re: The future for MOLAP  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3259
RioMare
soulsurfer
Аналитикам нужен результат сейчас, а не через несколько недель имплементации загрузки в некую БД, устранение проблем с авторизациями, доступами и т.д.

Вот именно поэтому всякие in-memory engine ( и подобные ) активно развиваются - не нужно никаких промежуточных БД, ни песочниц, ни витрин и тд. Берите данные напрямую из DWH и работайте насколько позволяют знания и возможности железа.
А МOLAPы остануться как ускорители для заранее оговорённых отчётов и рано или поздно вытеснят column-based MPP DB, поскольку не надо будет заморачиваться с измерениями-фактами ( моё IMHO ).

+1.
Да и вдобавок у продвинутых репортинг систем встренные свои системы olap (или псевдоолап) есть ну или как минимум кеширование. Зачем в системе два олапа, если у нас к примеру есть и SSAS и Microstrategy со своим кубом.
30 янв 17, 13:49    [20161655]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / OLAP и DWH Ответить