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

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

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

transposeRoman Kolchinпропущено...

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

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

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, Гартнер со мной согласен. Клик его отлично понимает в качестве источника данных, кстати.

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

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

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

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

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

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

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



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

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

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

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



JuriiDefault 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 -- например, для решения систем линейных уровней для аллокаций) + к этому возможна очень быстрая агрегация в разрезе больших измерений (сотни тысяч и миллионы элементов).

К слову, а что же я считаю киллер-фичами в Клик?

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

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

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

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