Неофициальный форум разработчиков QlikView и Qlik Sense

Форум разработчиков QlikView и Qlik Sense. Получи любые ответы на вопросы по QlikView и Qlik Sense в течении нескольких часов!

Вы не вошли.

Готовые решения на платйорме QlikView

#1 2015-02-11 17:49:45

Qliker
Участник
Зарегистрирован: 2015-02-10
Сообщений: 20
Windows 7Chrome 40.0.2214.111

Скрытые ограничения QlikView - всё действительно так плохо?

Нашёл разгромную статью о QlikView и о "скрытых ограничениях" этой платформы.

Мой вольный перевод некоторых пунктов:

  • Модель данных QlikView не является ассоциативной в классическом понимании

  • Объём анализируемых данных ограничен оперативной памятью сервера, даже учитывая компрессию QlikView не подходит для действительно больших данных.

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

  • Нет возможности создания Pixel-Perfect отчётов, т.к. QlikView - изначально создавалась не для построения статических отчётов.

  • Ограниченые возможности ETL. Загрузка данных происходит с помощью скрипта загрузки, это часто бывает трудоёмкой задачей, особенно в случае если требуется обработать слабо структурированые данные.

Хотелось бы услышать комментарии экспертов smile
Спасибо!

Редактировался Qliker (2015-02-11 17:50:12)

Неактивен

#2 2015-03-06 14:54:16

Alexander
Участник
Зарегистрирован: 2015-03-06
Сообщений: 3
Windows 7Chrome 40.0.2214.115

Re: Скрытые ограничения QlikView - всё действительно так плохо?

Qliker пишет:

Модель данных QlikView не является ассоциативной в классическом понимании

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

Qliker пишет:

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

Смотря что называть большими данными. Есть реальные примеры работы с миллиардами транзакций. Да, некоторое ограничение в части оперативной памяти имеется, но насколько оно критично при решении поставленных задач. Это ограничение с лихвой компенсируется скоростью работы. На мой взгляд, оно того стоит. Если нужно работать со 100500-ми терабайтами данных, то есть системы, которые работают с таким объемом, но там запускаешь отчет и пол дня ждешь когда он сформируется. Опять же эффективность и целесообразность такой работы под вопросом.

Qliker пишет:

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

Насколько мне известно, в QV есть возможность использовать MDX запросы при обращении к MS кубам, совсем недавно искал подобную информацию. Только вот вопрос спорный что быстрее и проще. Если Qlik позволяет решить бизнес задачу быстро и без MDX запросов, то разве плохо что они не используются smile

Qliker пишет:

Нет возможности создания Pixel-Perfect отчётов, т.к. QlikView - изначально создавалась не для построения статических отчётов.

В самом QlikView их нет, однако в линейке есть дополнительный модуль NPrinting, который как раз и предназначен для подготовки Pixel-Perfect отчётов.

Qliker пишет:

Ограниченые возможности ETL. Загрузка данных происходит с помощью скрипта загрузки, это часто бывает трудоёмкой задачей, особенно в случае если требуется обработать слабо структурированые данные.

Обработка слабо структурированных данных - это всегда трудоемкая задача, вне зависимости от инструмента))))
Опять же, если стаит задача быстро подготовить аналитику для бизнеса, то это Qlik. Если стоит задача в ковырянии, обработке исходных данных и подготовки идеального хранилища, то это несколько другая история.


Если кратко, то как-то так smile

Неактивен

Сейчас в этой теме форумчан: 0, гостей: 1
[Bot] claudebot

Подвал форума

Под управлением FluxBB
Модифицировал Visman

[ Сгенерировано за 0.029 сек, 9 запросов выполнено - Использовано памяти: 1.53 Мбайт (Пик: 1.67 Мбайт) ]