Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: Qlik продался Thoma Bravo  [new]
George Nordic
Member

Откуда: Moscow
Сообщений: 1023
Jurii
Клик, в свою очередь - это реляционная СУБД, и там простая модель с INNER JOIN, отсутствует MDX.
Qlik - это отнюдь не реляционная субд. QIX - это поколоночное хранение данных. Надеюсь, вы понимаете разницу между реляционной (быстрое добавление данных, потом индексирование, медленное извлечение данных по индексу) и поколоночным хранением данных (хранимые данные являются индексом, сжатие до 10 раз, долгая вставка строк, мгновенное извлечение). Данные способ хранения не требует MDX и предрассчитанных кубов - данные и так извлекаются и объединяются мгновенно.

С Уважением,
Георгий
10 июн 16, 10:20    [19279220]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2000
George Nordic
...Данные способ хранения не требует MDX и предрассчитанных кубов - данные и так извлекаются и объединяются мгновенно.


оч.. смешно.
какие при этом вычислительные мощности нужны?
на примере десятка сотен млн строк данных (с учетом что хранение уже вертикальное) общим объемом около 10GB
задача посчитать количество уникальных покупателей помесячно, в разбивке по среднему чеку с шагом задаваемым маркетологом (скажем сейчас 100р) желательно наложив еще с десяток условий на товары, их стоимость и проводимые акции...
10 июн 16, 10:42    [19279320]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
товарищъ
Member

Откуда: Минск
Сообщений: 630
ShIgor
... десятка сотен млн строк
это миллиард?
при сверх больших объемах данных (десятки и сотни TB) рекомендуют использовать ROLAP либо уже теперь DirectQuery на columndb. проблема не в извлечении, а в длительном процессенге кубов и занимаемом объеме.
вы привели всего один кейс, однако 80% запросов гораздо проще. а для этих 20% можно создать отдельные витрины-агрегаты на уровне ХД, ну или использовать тот MOLAP для узкой задачи
10 июн 16, 10:56    [19279411]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
George Nordic
Member

Откуда: Moscow
Сообщений: 1023
ShIgor
оч.. смешно.
какие при этом вычислительные мощности нужны?
на примере десятка сотен млн строк данных (с учетом что хранение уже вертикальное) общим объемом около 10GB
задача посчитать количество уникальных покупателей помесячно, в разбивке по среднему чеку с шагом задаваемым маркетологом (скажем сейчас 100р) желательно наложив еще с десяток условий на товары, их стоимость и проводимые акции...

Сотня млн строк отработает у меня на ноуте. Но тут вопрос по модели данных - если вы планируете работать с огромным массивом данных, то и модель должна быть простая, никаких снежинок, максимум - звезда. На тренинге мы в ноутбук грузим 10 млн строк и строим по ним простые отчеты. На боевом сервере - один крупный ритейлел грузил (и грузит) 10 млрд чеков, в памяти занимало 79Gb. Как раз для маркетинга и чековой аналитики. Характеристики сервера - ищите по Борису Михайлину - это был его проект, отличный специалист, кстати. Если Вас интересует чековая аналитика, вот как Вы описали, да на паре-тройке миллиардов, да вживую - когда маркетолог может любые произвольные фильтры / срезы условия накладывать - обращайтесь, расскажем поподробнее. Довольно частая задача.

С Уважением,
Георгий
10 июн 16, 11:49    [19279732]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
George Nordic
Member

Откуда: Moscow
Сообщений: 1023
ShIgor, вот еще хороший способ на поколонке ускорить расчет: предрассчитывать данные при загрузке. Сначала данные как есть загружаются в QVD-файл, а потом по нему идет ряд расчетов и происходит загрузка в другой QVD, в котором, кроме сырых данных, лежат агрегаты и флаги.

Давайте расскажу про флаги. Ими можно заменить тяжелые агры и count distinct обычными sum - во флаг при загрузке пишется или логический флаг (соответствует / нет запросу count distinct) или числовое значение (например, кол-во посетителей по дням в разрезе торговых точек).

Таким образом, мы можем при работе существенно снизить нагрузку на процессор. Давайте на вашем примере:
ShIgor
на примере десятка сотен млн строк данных (с учетом что хранение уже вертикальное) общим объемом около 10GB
задача посчитать количество уникальных покупателей помесячно, в разбивке по среднему чеку с шагом задаваемым маркетологом (скажем сейчас 100р) желательно наложив еще с десяток условий на товары, их стоимость и проводимые акции...

Сначала маркетолог накладывает фильтры - мин/макс сумма чека, дни недели, часы работы, регион, категория и т.п. В итоге по связанным данным в Qlik в поле "кол-во посетителей" останутся только те записи, которые ответствуют данным критериям (наложенным фильтрам, все остальные будут, по ассоциативной модели, из данной выборки исключены). И sum по данному полю даст искомый результат. Все гениальное просто. Подобный способ может в разы поднять быстродействие. Только приходится голову включать при разработке модели данных.

С Уважением,
Георгий
10 июн 16, 12:42    [19280042]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2000
George Nordic,

примеры 2009 года уже никому не интересны, причем сервер там не хилый. 128 гигов оперативки на тот момент - можно было без штанов остаться.
ну, а предложенное решение - упрощение задачи подходящее для поиска единственного порога (назовем его так), таких порогов может быть сотни и тысячи (кол-во периодов * на количество порогов), и каждый раз "шерстить" весь объем данных - слишком накладно, либо моделей будет ооочень много. а какова оперативность?
10 июн 16, 14:34    [19280776]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Jurii
Member

Откуда: Moscow http://cognos.narod.ru http://ai4you.gr8.com/
Сообщений: 3038
2 George Nordic:


Qlik - это отнюдь не реляционная субд. QIX - это поколоночное хранение данных. Надеюсь, вы понимаете разницу между реляционной (быстрое добавление данных, потом индексирование, медленное извлечение данных по индексу) и поколоночным хранением данных (хранимые данные являются индексом, сжатие до 10 раз, долгая вставка строк, мгновенное извлечение). Данные способ хранения не требует MDX и предрассчитанных кубов - данные и так извлекаются и объединяются мгновенно.


Реляционной СУБД я называю Клик за то, что там обычные таблицы с исходными данными и справочниками связываются обычными связями по совпадающим полям. Далее идет процессинг, сжатие данных, тут сомнений нет. С теоретической точки зрения будет интересно узнать больше о поколоночной архитектуре.
Данные соединяются быстро, но так как нет агрегатов - расчет идет не мгновенно. И вопрос с кубами/MDX не только в скорости - но и в удобстве (клик не позволяет пользователю/аналитику натаскивать в область отчета нужные данные - members, sets, tuples и т.п.).
Можно сделать вывод, что Клик работает обычно быстро, поскольку не дает пользователю возможности сделать что-то сложное в плане анализа данных (фильтры по индексированным полям и в MS SQL Server отрабатывают быстро.

Давайте расскажу про флаги. Ими можно заменить тяжелые агры и count distinct обычными sum - во флаг при загрузке пишется или логический флаг (соответствует / нет запросу count distinct) или числовое значение (например, кол-во посетителей по дням в разрезе торговых точек).

Все мы думали над тем, можно ли заменить count distinct на sum ;) Но эта задача не имеет универсального решения. Например, заранее не известно, с какой даты по какую пользователь запустит отчет, или какие критерии задаст для классификации клиентов на мелких и крупных. В Клике правда, насколько я знаю, очень проблематично делать отчет с даты по дату, поэтому может быть флаги используются более часто, чем в серьезных BI системах ;)
10 июн 16, 14:37    [19280795]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
George Nordic
Member

Откуда: Moscow
Сообщений: 1023
Jurii
Реляционной СУБД я называю Клик за то, что там обычные таблицы с исходными данными и справочниками связываются обычными связями по совпадающим полям.
А, понятно.
ShIgor
George Nordic, примеры 2009 года уже никому не интересны, причем сервер там не хилый. 128 гигов оперативки на тот момент - можно было без штанов остаться.
ну, а предложенное решение - упрощение задачи подходящее для поиска единственного порога (назовем его так), таких порогов может быть сотни и тысячи (кол-во периодов * на количество порогов), и каждый раз "шерстить" весь объем данных - слишком накладно, либо моделей будет ооочень много. а какова оперативность?
1. Ну так и задача была соответствующая - с сырыми чеками работали, агрегация их не устраивала. 2. Решал подобную, Hadoop + Mahout + Qlik. Все данные лежали в Hadoop, Mahout собирал статистику и строил агрегаты + флаги, в Qlik велась аналитика и что/если. Когда выборка по критериям была сформирована, в Hadoop шел уже прямой запрос, который вытаскивал детальные данные (гибридная модель, DataDiscovery). 350 млрд CDR в Hadoop лежало. Говорю, если есть задача - пишите, обсудим, как решать. Я слышал что Магнит, Детский Мир и Х5 подобные задачи решали, и я не думаю что у Вашей компании чеков больше.

С Уважением,
Георгий
10 июн 16, 16:07    [19281419]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Jurii
Member

Откуда: Moscow http://cognos.narod.ru http://ai4you.gr8.com/
Сообщений: 3038
2 George Nordic:

Реляционной СУБД я называю Клик за то, что там обычные таблицы с исходными данными и справочниками связываются обычными связями по совпадающим полям.
А, понятно.


Могу называть Клик не реляционной, а файл-серверной СУБД ;)
Если мы в Клик загружаем 10 миллиардов строк чеков и много справочников, включая справочник из 1000 магазинов, а потом хотим подключить еще один справочник с дополнительным свойством магазина (в нем 1000 записей) - что произойдет? Справочник добавится мгновенно, как в реляционной БД, и сразу можно в этом разрезе крутить ранее загруженные 10 миллиардов записей? или будет долгое обновление файлов Клика?

в Qlik велась аналитика и что/если

Можете подробнее рассказать, что такое в Клике анализ "что/если"? Это обычно делают в системах бюджетирования, в Клике этого быть не должно.
10 июн 16, 16:29    [19281550]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
vikkiv
Member

Откуда: London
Сообщений: 1359
Jurii
Можете подробнее рассказать, что такое в Клике анализ "что/если"? Это обычно делают в системах бюджетирования, в Клике этого быть не должно.
Если продукт дополняется дополнительной функциональностью то в чём проблема? в угрозе другим продуктам? Не опасение-ли это типа если Excel сможет писать с листов без дополнительных усилий в таблицы SQL (понятным способом недалёкому пользователю) - то работу в мгновение потеряют миллионы Delfi/Java/C++/C# формописателей и Web интерфейсников?
10 июн 16, 17:33    [19281905]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
vikkiv
Member

Откуда: London
Сообщений: 1359
в смысле на самом деле я конечно вовсе не фанат сторонних приблуд Кликов/Табло и прочего зоопарка.. больше придерживаюсь Core продуктов из пакетно-родного функционала DB систем.. т.к. слишком велик риск - выпустит основной производитель под которые эти прикладники затачивают продукцию - что-то своё полностью интегрированное (т.к. кто-то уже доказал/проверил что это достойный рынок) - и эта мелочь тут-же повалится с рынка.. а потраченного времени (на курсы и пр. освоение) уже не вернёшь.. Элементарный пример развитие PowerBI и его интеграция с Office365 и SharePoint (хотя первая поддержка пока убрана, а вторая ещё не внедрена).. хоть и немного другой сегмент рынка - но многие инициативы других продуктов уже серьёзно подрезал.
10 июн 16, 17:43    [19281954]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Jurii
Member

Откуда: Moscow http://cognos.narod.ru http://ai4you.gr8.com/
Сообщений: 3038
2 vikkiv:

Можете подробнее рассказать, что такое в Клике анализ "что/если"? Это обычно делают в системах бюджетирования, в Клике этого быть не должно.
Если продукт дополняется дополнительной функциональностью то в чём проблема? в угрозе другим продуктам? Не опасение-ли это типа если Excel сможет писать с листов без дополнительных усилий в таблицы SQL (понятным способом недалёкому пользователю) - то работу в мгновение потеряют миллионы Delfi/Java/C++/C# формописателей и Web интерфейсников?


Если функциональность бюджетирования в Клике реально появилась - то George об этом расскажет. Если этого функционала там нет - то читатели данной дискуссии не будут введены в заблуждение. В целом в Клике иногда ощущается больше маркетинга и рекламы, чем реального функционала. Помню в LinkedIn была дискуссия на тему - что Вам не хватает из функционала в Клике... Там столько всего написали, что сложилось впечатление, что Клик еще рано использовать для серьезных задач.
10 июн 16, 17:52    [19282029]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Кэптен
Member

Откуда: Kiev
Сообщений: 211
Во развели бодягу.
Клик никто и не использует для серьезных задач. У Гартнера это четко прописано - это доп. приблуда для основных серьезных БИ практически у всех опрошенных.
Про размеры обрабатываемых данных и количестве ОЗУ под них тоже подсчеты тут не раз делали, тот же Георгий. Про миллиарды строк в Клике - угу...потом правда оказывается, что этот миллиард в Хадупе :)
10 июн 16, 23:43    [19283142]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
SpellBuilder
Member

Откуда: р.Москва, д.МО
Сообщений: 1899
Кэптен
Во развели бодягу.
Клик никто и не использует для серьезных задач. У Гартнера это четко прописано - это доп. приблуда для основных серьезных БИ практически у всех опрошенных.
Про размеры обрабатываемых данных и количестве ОЗУ под них тоже подсчеты тут не раз делали, тот же Георгий. Про миллиарды строк в Клике - угу...потом правда оказывается, что этот миллиард в Хадупе :)

В крупных, зоопарк, каждое бизнес подразделение использует свое в силу старых подходов, сове родное.
Ну поставят хадуп и что, многие так и останутся на своих MSSAS, SAS, Oracle Discoverer, Oracle BI, Cognos BI. Смена платформы в бизнес подразделении сравни революции они напридумают десятки доводов повышающих риски и значительные потери и послушают их т.к. они отвечают за бизнес, а не Вас рассказывающих про звезды и колонки.
11 июн 16, 19:04    [19284453]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
transpose
Member

Откуда:
Сообщений: 185
Кэптен,

нормально миллиард влезает. Вот люди фантазируют чего-то, а всего делов-то: скачать бесплатную версию Qlikview и запустить ее на сервере с 128-256ГБ оперативки. И сами увидите что все работает.

То же и Jurii, пройдет еще четыре года и похоже так же в каждой теме будут вопросы, а что же такое Qlik и какая у него функциональность. Респект Георгию - повторенье мат ученья :-)

У меня закрадывается подозрение что некоторые персонажи здесь это куклы Георгия :-)
12 июн 16, 01:06    [19285282]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 217
Кэптен
У Гартнера это четко прописано - это доп. приблуда для основных серьезных БИ практически у всех опрошенных.

Поясните, пожалуйста, в чем видите разницу в задачах, которые решаются в Qlik'е, а какие - в "серьезных БИ"? Для интеграции больших объемов данных из разных источников Клик полагается на хранилища, как и любая корп система отчетности и анализа -- это факт. Где после этого возникает развилка между инструментами BI?
12 июн 16, 13:33    [19285749]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 217
transpose
То же и Jurii, пройдет еще четыре года и похоже так же в каждой теме будут вопросы, а что же такое Qlik и какая у него функциональность.

Юрий продает и внедряет Cognos много лет. Ему невыгодно признавать альтернативные инструменты. Так что тут дело не в непонятливости.

Все это не умаляет возможностей Cognos и возможностей Юрия по созданию на нем аналитических систем для реальных клиентов. Но всерьез воспринимать его аргументы не надо -- он не учит другие инструменты, не пытается всерьез понять контекст в котором они применимы, а просто как продавец борится с конкурентом.
12 июн 16, 14:17    [19285826]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
transpose
Member

Откуда:
Сообщений: 185
Roman Kolchin
transpose
То же и Jurii, пройдет еще четыре года и похоже так же в каждой теме будут вопросы, а что же такое Qlik и какая у него функциональность.

Все это не умаляет возможностей Cognos и возможностей Юрия по созданию на нем аналитических систем для реальных клиентов.

Тролль ограничивает свой успех размениваясь на выдумывание глупостей. Заодно сигнализирует всем, что по сути спросить ему нечего и это говорит о его аналитических способностях. Соответственно и польза его клиентам сомнительная, похоже он подсовывает им неоптимальное решение!
12 июн 16, 16:12    [19286025]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 217
transpose
Roman Kolchin
пропущено...

Все это не умаляет возможностей Cognos и возможностей Юрия по созданию на нем аналитических систем для реальных клиентов.

Тролль ограничивает свой успех размениваясь на выдумывание глупостей. Заодно сигнализирует всем, что по сути спросить ему нечего и это говорит о его аналитических способностях. Соответственно и польза его клиентам сомнительная, похоже он подсовывает им неоптимальное решение!

Я не шутил. Лично с Юрием не знаком, но наслышан о его деятельности. Он давно занимается Cognos'ом, продал и сделал много успешных проектов, клиенты довольны. Если пишет что-то конкретное про его любимый Default BI, то его можно и нужно слушать :)

Но по отношению к конкурирующим продуктам он конечно ведет себя мягко говоря некорректно.
12 июн 16, 16:31    [19286057]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Jurii
Member

Откуда: Moscow http://cognos.narod.ru http://ai4you.gr8.com/
Сообщений: 3038
2 Roman Kolchin:

Но по отношению к конкурирующим продуктам он конечно ведет себя мягко говоря некорректно.

Иногда мои посты звучат достаточно жестко. Но тем самым я надеюсь, что у разных BI решений найдутся специалисты (не стеснительные скромные инженеры, а уверенные в себе люди), которые смогут рассказать подробнее об их функционале, и всем нам будет интересно это прочитать. Пока что специалисты по Клику молчат - из этого можно сделать вывод, что имеющаяся у меня информация о Клике - правильная, и он с точки зрения гибкости достаточно слаб, как и BO, Oracle BI, MSTR, Прогноз и MS BI. Если кто-нибудь их специалистов продемонстрирует соответствие того или иного решения концепции BI Fingers - то у Default BI появится альтернатива (правда беда в том, что чистый BI мало кому интересен, а у TM1 Magic Edition альтернатива появиться не может ;)

У Гартнера это четко прописано - это доп. приблуда для основных серьезных БИ практически у всех опрошенных.
Поясните, пожалуйста, в чем видите разницу в задачах, которые решаются в Qlik'е, а какие - в "серьезных БИ"? Для интеграции больших объемов данных из разных источников Клик полагается на хранилища, как и любая корп система отчетности и анализа -- это факт. Где после этого возникает развилка между инструментами BI?


Клик не заточен на то, чтобы напрямую работать с данными из ХД, ему все данные нужно загрузить в свой черный ящик (буду рад если кто-то озвучит, что Клик научился работать с ХД, только отправляя туда SQL запросы). В Клике нет функционала для разработки сложных отчетов. Нет многомерной модели, нет семантического слоя метаданных, нет блока для моделирования/бюджетирования, и т.п.
13 июн 16, 12:58    [19287958]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 217
Jurii
Клик не заточен на то, чтобы напрямую работать с данными из ХД, ему все данные нужно загрузить в свой черный ящик

Клик кэширует данные для быстрого расчета в памяти. Тем самым требуется меньше материализованных вьюх на стороне ХД. Это правильно и очень удобно.

С помощью такой архитектуры Клик своим функционалом покрывает большую часть аналитики, которая не требует обновления данных в реальном времени. Но для отдельных случаев, когда в отчет требуется подтягивать 1-2 показателя онлайн, в клике есть такая возможность -- DIRECT QUERY.


Jurii
В Клике нет функционала для разработки сложных отчетов.

Вас обманули. В Клике можно разработать очень сложную визуализацию. Если мне не изменяет память, то графические элементы можно разместить аж на 50 слоях отчета -- прямо как в Фотошопе.


Jurii
Нет многомерной модели

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

OFFTOPIC: Или вы имели в виду "многомерную модель TM1"? Да, в Клике она другая, математически попроще. Давайте лучше сравним TM1 с Oracle Essbase. Essbase, с его Hybrid Storage -- движком, объединяющим чумовые возможности чистой многомерной математики (обкатана на серьезных финансовых и прогнозных приложениях более чем за 20 лет эксплуатации у десятков тысяч компаний) с эффективной агрегацией и формульным расчетом in-memory -- рвет TM1 по всем параметрам. Да-да, я не шучу. Если раньше в Essbase можно было для куба выбирать или движок Blocked Storage с "чумовой математикой" или Aggregate Storage (c чумовой агрегацией in-memory и более простыми расчетами), то сейчас весь функционал получаем в рамках одного куба.


Jurii
нет семантического слоя метаданных

У любой уважающей себя комплексной системы BI должен быть семантический слой!! В системах на базе Qlik этот слой должен быть в Хранилище данных -- там нужно придумать понятные названия таблиц и полей, сложить однотипные данные в одинаковые таблицы или объединить в единые вьюхи и вуа-ля у вас готов семантический слой. За счет того, что программистам ХД требуется меньше морочиться из-за разработки и поддержки материализованных вьюх, они могут посвятить больше времени интеграции данных. Это будет полезно не только для конкретных отчетов в текущий момент, но и для последующего развития хранилища.

Исходя из моего опыта, если интеграция и унификация данных не выполнена на уровне ХД, а еще лучше -- в системах источниках или хотя бы на уровне выгрузки данных из систем-источников, то делать ее в инструменте BI -- бесполезная трата времени.

А если у вас нет большого количества источников, и вы не хотите делать Хранилище данных, то семантический слой вам очевидным образом не обязателен.

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

Не верю, что вы всерьез перечисляете эти фишки в виде аргументов. Вас не научил опыт, что конкретные возможности инструмента имеют смысл только в рамках конкретного сценария использования у конкретного клиента???? Меня опыт научил именно такой "теории относительности" функционала -- кому-то важна голая производительность, кому-то скорость внедрения, кто-то хочет больше вовлечь бизнес, а у кого-то есть хорошая команда ИТ, а бизнес-пользователь слишком децентрализован и консервативен -- бросание ключевыми словами типа "MDX", "семантическая модель" или придумывание метафор типа "би пальцев" всю сложность контекста не охватывает. Прекращайте бросаться терминами, приводите конкретные примеры из вашего огромного опыта и вас начнут понимать "скромные инженеры", а уверенный безапелляционный тон и красивые слова оставьте для клиентов :)


Jurii
нет блока для моделирования/бюджетирования

Нету. Да что вы про бюджетирование повторяете каждый раз? Если нужно построить бюджетный процесс, пусть клиент выбирает адекватное решение из всех вариантов на рынке. Например, отличное решение для бюджетирования -- Oracle Hyperion Planning, Гартнер со мной согласен. Клик его отлично понимает в качестве источника данных, кстати.
13 июн 16, 15:47    [19288302]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Jurii
Member

Откуда: Moscow http://cognos.narod.ru http://ai4you.gr8.com/
Сообщений: 3038
2 Roman Kolchin:

Но для отдельных случаев, когда в отчет требуется подтягивать 1-2 показателя онлайн, в клике есть такая возможность -- DIRECT QUERY

Вот об этом было бы интересно узнать подробнее. Постараюсь найти этот функционал в Клике.

В Клике нет функционала для разработки сложных отчетов.
Вас обманули. В Клике можно разработать очень сложную визуализацию


Можно ли в Клике натаскивать строки в отчет, перетаскивая мемберы из одного или разных измерений? Или можно только перетащить в целом измерение? Можно ли те или иные строки раскрывать в другие мемберы из других измерений? Можно ли добавлять новые строки на основе формул, или вычисления с формулами возможны только в столбцах отчета?
Было бы интересно увидеть примеры сложных отчетов в Клике, но пока я видел лишь простые дашборды.

Нет многомерной модели
Есть. Все данные лежат в разрезе аналитик, которые могут быть между собой связаны в виде иерархий. Расчет данных выполняется на языке, который понимает многомерную сущность данных.
OFFTOPIC: Или вы имели в виду "многомерную модель TM1"?


Я не имел в виду ТМ1, имел в виду физические OLAP-кубы или представление реляционных данных в виде измерений в Default BI. Было бы интересно увидеть, где в Клике создаются иерархии, можно ли раскрывать дерево иерархии, видя мемберы на разных уровнях. Или в Клике обычные поля реляционных таблиц.
Я не имею ничего против Essbase, могу лишь сказать что это достаточно сложное и тяжелое решение. Default BI мне приходилось прикручивать к Essbase, но вот насколько хорошо работает Клик поверх Essbase...

По поводу семантического слоя - на мой взгляд, в ХД по-хорошему надо избегать русских названий таблиц и полей, а в семантическом слое можно переименовывать все в бизнес-термины. В мета-слое можно определять, что для одной задачи выполняется Inner Join, а для другой - Outer Join, можно создавать алиасы к таблицам. Работать в Клике без семантического слоя конечно можно, но это как-то не солидно выглядит, то же самое что строить небоскреб на болоте без фундамента.

нет блока для моделирования/бюджетирования
Нету. Да что вы про бюджетирование повторяете каждый раз? Если нужно построить бюджетный процесс, пусть клиент выбирает адекватное решение из всех вариантов на рынке. Например, отличное решение для бюджетирования -- Oracle Hyperion Planning, Гартнер со мной согласен. Клик его отлично понимает в качестве источника данных, кстати.


Если мы вводим данные в Oracle Hyperion Planning - Клик может сразу обновить свой отчет, обращаясь напрямую к Oracle Hyperion Planning, или Клик должен закачать в себя все данные?
Будет интересно узнать у моих знакомых заказчиков, хотят ли они получить связку Клик + Oracle Hyperion Planning, или предпочтут решение от одного вендора (такое как TM1 + default BI ;)
13 июн 16, 17:16    [19288462]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 217
Jurii
В Клике нет функционала для разработки сложных отчетов.
Вас обманули. В Клике можно разработать очень сложную визуализацию


Можно ли в Клике натаскивать строки в отчет, перетаскивая мемберы из одного или разных измерений? Или можно только перетащить в целом измерение? Можно ли те или иные строки раскрывать в другие мемберы из других измерений? Можно ли добавлять новые строки на основе формул, или вычисления с формулами возможны только в столбцах отчета?
Было бы интересно увидеть примеры сложных отчетов в Клике, но пока я видел лишь простые дашборды.

Воспользуйтесь приглашением Георгия и посетите партнерский семинар Клика, вы удивитесь тому на сколько сложными могут быть дашборды. Если коротко, то ОЧЕНЬ СЛОЖНЫЕ :) Вы даже не поймете, что они были сделаны в BI, а не сверстаны веб-дизайнером на заказ.

Касательно перечисленного вами функционала -- он охватывает одну конкретную область, то что Гартнер и остальные называют "enterprise reporting" -- это форматированные табличные отчеты.

Если для вас BI это в первую очередь "форматированные таблички", то Клик вам не подойдет.

Ухищрения с pixel-perfect форматированием обычно нужны для бизнеса, который не может или не хочет учить новые инструменты. Или ИТ не хочет менять устоявшиеся подходы к сопровождению и развитию информационных систем.

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

Кстати, для форматирования строчек в табличках мой любимый инструмент -- Oracle BI Publisher -- очень гибкая и удобная для разработчика штука. Умеет кучу внешних источников, в том числе кубы через MDX, умеет их склеивать и дает разработчика возможность самим тюнить запросы к внешним системам, добиваясь максимальной производительности. В общем, рекомендую. Да, в нем нет (если не использовать полный стек Oracle BI) семантической модели, но она не особо нужна если задача разработчика выдро*ить отчет с точностью до пикселя -- плюшки от наличия семантической модели ничто по сравнению с задачей форматирования.



Jurii
Нет многомерной модели
Есть. Все данные лежат в разрезе аналитик, которые могут быть между собой связаны в виде иерархий. Расчет данных выполняется на языке, который понимает многомерную сущность данных.
OFFTOPIC: Или вы имели в виду "многомерную модель TM1"?


Jurii
Я не имел в виду ТМ1, имел в виду физические OLAP-кубы или представление реляционных данных в виде измерений в Default BI. Было бы интересно увидеть, где в Клике создаются иерархии, можно ли раскрывать дерево иерархии, видя мемберы на разных уровнях. Или в Клике обычные поля реляционных таблиц.

Красивых дервьев в визуальном представлении отчета нет. Ну и что? Связи между уровнями иерархий он помнит и умеет не показывать лишнего -- "не показывать лишнего" это изначальная фишка Клика, то что они сами называли "ассоциативной моделью". Функционально интерфейс аналогичен переходу по дереву иерархии.

Сходу в голову приходит всего один случай, когда важно видеть иерархию в виде дерева, чтобы понимать результат расчета и вообще потому что так принято :) -- это план счетов/ иерархия финансовых показателей.

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



Jurii
Default BI мне приходилось прикручивать к Essbase, но вот насколько хорошо работает Клик поверх Essbase...
Если мы вводим данные в Oracle Hyperion Planning - Клик может сразу обновить свой отчет, обращаясь напрямую к Oracle Hyperion Planning, или Клик должен закачать в себя все данные?

Онлайн доступа (кроме упомятуго DIRECT QUERY для точечного получения пары показателей) у Клика никуда нет и Oracle Hyperion Planning/Essbase не исключение. Но закачивать все данные не нужно. Достаточно вытащить подмножество куба, связанное с конкретным отчетом и его путями дриллинга. Для онлайн отчетов у Hyperion Planning есть собственные встроенные формы и отчеты, их использовать удобнее всего, в том числе удобнее чем Default BI :)

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

Примеры использования Клик + Hyperion Planning/ Essbase в России есть. Большая компания, инструменты выбирались под разные задачи, а потом пришла здравая идея их объединить. Опережая ваше предложение -- нет, Default BI тут комплексно преимуществ не имел бы -- Клик и Hyperion пришли ну совершенно из разных задач и разных подразделений. В этом кейсе я чисто гипотетически готов был бы сравнить Hyperion Planning vs Cognos TM1 в качестве системы бюджетирования (тут можно было бы покопаться и посравнивать конкретный функционал), то Клик для своей задачи и подхода к внедрению был вне конкуренции :) Подробности о кейсе у Георгия :)



Jurii
Будет интересно узнать у моих знакомых заказчиков, хотят ли они получить связку Клик + Oracle Hyperion Planning, или предпочтут решение от одного вендора (такое как TM1 + default BI ;)

Ваши клиенты, я уверен, используют Default BI на 100% и ценят вас и вашу команду как экспертов :) Переучивать их на что-то другое и менять партнеров будет однозначно вредно.


Jurii
По поводу семантического слоя - на мой взгляд, в ХД по-хорошему надо избегать русских названий таблиц и полей, а в семантическом слое можно переименовывать все в бизнес-термины.

Если делать совсем по-хорошему, то вы правы. Но порядок должен идти от хранилища, а семантическая модель в BI должна лишь добавлять синтаксический "сахарок". Но если в Хранилище уже наведен порядок, то семантическая модель в BI перестает быть киллер-фичей.



Jurii
В мета-слое можно определять, что для одной задачи выполняется Inner Join, а для другой - Outer Join, можно создавать алиасы к таблицам.

Хороший аргумент.
Коллеги, специалисты по Клику, прокомментируйте плиз как лучше решить эту задачу? Сделать вьюху в Хранилище, или как?


Jurii
Работать в Клике без семантического слоя конечно можно, но это как-то не солидно выглядит, то же самое что строить небоскреб на болоте без фундамента.

Проигнорирую эту аналогию, как неконструктивную :)



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

Инсталлировать конечно тяжеловато -- помимо самого сервера, база, веблоджик, пяток java-приложений... Это результат модели продаж Оракла, изначально сервер ставился очень просто. Оракл предпочитает продавать Essbase в составе других продуктов. Default BI и TM1 в частности разве не требуют установки аналогичного зоопарка компонент?

Функционально Essbase очень универсален. А с появлением Hybrid Storage (пару лет назад всего, надо отметить) ему вообще нет равных -- язык расчетов позволяет брать данные из любой точки многомерного куба и записывать в любую точку куба по любой матической логике (где не хватает встроенной, можно добавлять свои функции на Java -- например, для решения систем линейных уровней для аллокаций) + к этому возможна очень быстрая агрегация в разрезе больших измерений (сотни тысяч и миллионы элементов).
13 июн 16, 18:52    [19288732]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 217
К слову, а что же я считаю киллер-фичами в Клик?

Клик =
движок агрегации данных
+ движок многомерной математики
+ скриптовый язык для ETL по импорту данных в "движок агрегации данных"
+ интерфейс анализа данных аналитиком ("простые дашборды")
+ среда разработки и публикации комплексных информационных панелей для широких масс пользователей (сайты насыщенные показателями и диаграммами, 50 слоев для графических элементов а-ля Фотошоп).

И все это буквально в одном интерфейсе, то есть если у вас есть хранилище или какой-нибудь другой источник, то вы ставите сверху "комбайн" под названием Клик и быстро получаете результат. И результат этот не просто "сумма" по аналитикам на десктопе -- Клик внедряется и используется в том же реальном мире, что весь остальной "серьезный" BI -- банки, телекомы, ритейл, продажи, склады, клиенты -- устанавливается на мощных серверах с кучей процессоров и памяти и используется десятками и сотнями пользователей... Неужели у кого-то есть иллюзии, что компании всерьез решают "так эту мега важную вещь мы делаем на серьезной BI-платформе, а этот лоховской BI пусть клепают на Клике"? Как я понял из кейсов Георгия, Клик как раз влезает без мыла в тех ситуациях когда классические платформы сливают по совокупности причин :)

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

Кстати, я совсем не специалист по Клику. Я смотрю на него со стороны, но вполне профессиональным взглядом, имея опыт в настройке других аналитических инструментов и приложений и более-менее понимая какие задачи пытаются с их помощью решать организации в реальном мире.
13 июн 16, 20:23    [19288964]     Ответить | Цитировать Сообщить модератору
 Re: Qlik продался Thoma Bravo  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3902
Roman Kolchin
К слову, а что же я считаю киллер-фичами в Клик?

Клик =
движок агрегации данных
+ движок многомерной математики
+ скриптовый язык для ETL по импорту данных в "движок агрегации данных"
+ интерфейс анализа данных аналитиком ("простые дашборды")
+ среда разработки и публикации комплексных информационных панелей для широких масс пользователей (сайты насыщенные показателями и диаграммами, 50 слоев для графических элементов а-ля Фотошоп).

И все это буквально в одном интерфейсе, то есть если у вас есть хранилище или какой-нибудь другой источник, то вы ставите сверху "комбайн" под названием Клик и быстро получаете результат. И результат этот не просто "сумма" по аналитикам на десктопе -- Клик внедряется и используется в том же реальном мире, что весь остальной "серьезный" BI -- банки, телекомы, ритейл, продажи, склады, клиенты -- устанавливается на мощных серверах с кучей процессоров и памяти и используется десятками и сотнями пользователей... Неужели у кого-то есть иллюзии, что компании всерьез решают "так эту мега важную вещь мы делаем на серьезной BI-платформе, а этот лоховской BI пусть клепают на Клике"? Как я понял из кейсов Георгия, Клик как раз влезает без мыла в тех ситуациях когда классические платформы сливают по совокупности причин :)

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

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


Похоже Юрий решил диверсифицировать свой бизнес.
14 июн 16, 01:42    [19289635]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / OLAP и DWH Ответить