Сайзинг для QlikView и Qlik Sense

Сайзинг для Qlik Sense и QlikView

Сайзинг – это расчет состава программно-аппаратного комплекса, предназначенного для решения определенных задач. Подход к сайзингу QlikView и Qlik Sense – единый, поэтому мы будем составлять спецификации на закупку программных и аппаратных средств для платформы Qlik (а какой конкретно продукт вы выберете здесь уже не так важно).

Почему сайзингу стоит уделять отдельное внимание?

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

Сайзинг для Qlik: как правильно?

Самый корректный расчет сайзинга можно сделать на основе уже имеющегося приложения Qlik Sense или QlikView, или по крайней мере его прототипа (прототип можно разработать в зависимости от сложности задач за 1неделю – 1 месяц). И тому есть несколько причин:

  • Точное понимание объема данных в приложении Qlik, а не на основе хранящихся в компании данных, которые будут использоваться для аналитики
  • Способы применения расчетных формул показателей в приложении Qlik, специальных конструкций Qlik, например, set-analysis (их использование в конкретных объектах визуализации и объем ресурсов, который необходим для вычислений)
  • Использование расширений (extensions) для визуализации или бизнес-логики
  • Количество пользователей конкретного приложения Qlik
  • Корпоративные требования к безопасности, отказоустойчивости, организации разработки, тестирования и публикации приложений бизнес-аналитики

Сайзинг для Qlik Sense и QlikView

«Qlik является очень гибким инструментом, сценарии использования которого существенно зависят от множества факторов: квалификации разработчика, выбранного пути разработки приложения, конкретного набора данных и решаемой задачи заказчика. Поэтому сайзинг любого решения на QlikView является настолько многопараметрическим, что любые попытки оформить его в строгую табличную форму без привязки к конкретному приложению просто обречены на недостоверность. Именно поэтому правильное поведение состоит в создании прототипа, параметры которого в плане сайзинга будут не обсуждаться на уровне абстракций, а могут и должны быть четко измерены»
Архитектор решений Qlik
СЕРГЕЙ ПОЛЕХИН

Когда у специалиста Консультационной Группы АТК на руках есть информация по конкретному прототипу приложения, мы подготовим максимально точный и полноценный расчет с основными параметрами сайзинга:

  • Объем оперативной памяти (RAM),
  • Процессоры (CPU) – количество и производительность,
  • Количество серверов и тип узлов кластера
  • Количество и тип лицензий Qlik (Named User и Document User для QlikView и Professional и Analyzer для Qlik Sense)

От чего зависит расчет сайзинга Qlik

Поскольку QlikView и Qlik Sense – in-memory платформы, они чувствительны к объему оперативной памяти сервера. Соответственно, основные показатели, на которых мы строим рекомендации по серверному оборудованию для Qlik включают – RAM, CPU (количество и производительность), количество серверов и тип узлов кластера. Сейчас кратко рассмотрим, из чего складываются рекомендации по сайзингу по каждому из пунктов:

RAM: количество оперативной памяти для Qlik

Объем требуемой оперативной памяти и производительность приложения чаще всего зависят от:
  1. Объема данных единовременно загружаемых в оперативную память и анализируемых пользователями. При этом у архитектора Qlik всегда есть степень свободы по загрузке всего объема или требуемой его части. В зависимости от выбранной стратегии может потребоваться либо более мощное оборудование «железо», либо в случае использования нескольких серверов или создания цепочечных приложений — большее количество лицензий Qlik.
  2. Выбранной модели данных. Здесь надо отметить, что ассоциативная модель данных Qlik это не реляционная модель, это инструмент для пользователя, а не для разработчика приложения. Исходя из этого, компетентный архитектор обычно использует несколько моделей для решения различных задач пользователя. Более того, в процессе эксплуатации может потребоваться переход от одной модели к другой, что упростит и повысит степень гибкости работы пользователя, но может потребовать дополнительного объема оперативной памяти.
  3. Количества полей в модели данных. Очевидно, что большее количество полей потребует большего объема оперативной памяти.
  4. Выбранных сценариев работы с данными. Если пользователь использует многопараметрический сравнительный анализ, то памяти будет расходоваться больше по сравнению с тем, если бы пользователь работал в терминах классической отчетности.
  5. Специфики конкретных наборов данных. Дело в том, что алгоритм компрессии данных платформы Qlik основан на хранении только уникальных значений данных, встречающихся в полях модели данных. Поэтому эффективность сжатия данных в оперативной памяти  будет существенно зависеть от степени повторяемости загруженных данных. Обычно коэффициент сжатия варьируется в пределах 4–6, но может достигать и 10. Хотя на некоторых наборах данных может не достигать и 2.
  6. Степени гибкости сценариев анализа, предоставляемых пользователю. Как правило всегда большая степень гибкости будет требовать большего объема оперативной памяти.
  7. Используемого количества и сложности объектов визуализации данных. Большее количество объектов визуализации единовременно отображаемых на экране, требует большего количества оперативной памяти.
  8. Количества пользователей, одновременно работающих с приложением. Для каждого пользователя, работающего с приложением резервируется объем оперативной памяти, в котором хранится состояние выборок данных, сделанных пользователем.

CPU: производительность процессоров для Qlik

Требуемая производительность процессора чаще всего зависит от приведенных ниже параметров (в основном эти параметры уже были описаны выше):
  1. Объема данных, анализируемых пользователем.
  2. Выбранной модели данных.
  3. Количества полей в модели данных.
  4. Сложности и количества вычислений, выполняемых на этапах загрузки данных и на этапе работы с приложением конечными пользователями.
  5. Количества пользователей работающих с приложением.
  6. Возможности кэширования вычислений, выполняемых Qlik. Возможность и степень кэширования зависит от объема оперативной памяти, доступной для кэширования расчетов пользователей. Также эффективность работы кэша зависит от поведения конечных пользователей, т.е. от количества повторных обращений к одним и тем же наборам данных со стороны пользователей.
  7. Степени гибкости сценариев анализа, предоставляемых пользователю.
  8. Используемого количества и сложности объектов визуализации данных. Большее количество объектов визуализации единовременно отображаемых на экране, требует большего количества оперативной памяти.
  9. Выбранная модель безопасности данных, и ряд других характеристик приложения также существенно влияют на объем вычислений, необходимых для обработки процессорами сервера.

Сервера: количество серверов и их роли для Qlik

В данном разделе, мы перечислим от чего зависит требуемое количество серверов и соответствующих им лицензий:
  1. Существующих стандартов на использование оборудования у заказчика и существующих требований по быстродействию. Поскольку Qlik легко масштабируется, то в зависимости от выбранной стратегии масштабирования, можно увеличивать производительность индивидуальных серверов (Scale-Up), увеличивать количество серверов (Scale-Out) или использовать оба способа одновременно. Например, даже при работе с большими объемами данных, как правило, всегда есть альтернатива одному большому и дорогому серверу. В частности, архитектор имеет возможность разделения приложения на несколько приложений, выполняемых на отдельных, сравнительно недорогих по аппаратному оснащению серверах.
  2. Существующих требований к отказоустойчивости решения. Очевидно, что больший уровень отказоустойчивости может потребовать создания кластера серверов Qlik. Кластеризация в свою очередь может быть использована на различных архитектурных уровнях решения: кластеризация на уровне загрузки данных, кластеризация на  уровне обслуживания пользователей, кластеризация веб-сервисов. Возможно использование и любых комбинаций этих кластеров.
  3. Существующие требования в плане управления версиями и надежностью решения могут потребовать создания выделенных зон разработки и тестирования приложений перед переносом их в среду эксплуатации. Организация таких зон тестирования и разработки может потребовать использования дополнительных серверов (и серверных лицензий Qlik).
  4. Выбранная модель безопасности данных, требуемые направления масштабирования (загрузка данных или обслуживание конечных пользователей), а также ряд других характеристик решения также могут существенно влиять  на количество серверов в составе решения.

ВЫВОДЫ

Для решения различных задач требуемый объем оперативной памяти, производительность процессоров и количество узлов кластера Qlik (при необходимости построения кластера) могут существенно отличаться в зависимости от способа реализации решения. Поэтому мы в статье не приводим примеры сайзинга – параметры сервера для QlikView или Qlik Sense лучше фиксировать только в рамках конкретного прототипа приложения и проведенного на его основе нагрузочного тестирования.
Наша команда готова разработать для Вас прототип решения Qlik и рассчитать сайзинг для использования платформы Qlik.

Рекомендуем другие материалы по Qlik Sense и QlikView:

  • Адрес:Адрес: Москва, ул. Барклая, д.6, стр.3
  • Телефон:+7 (495) 937-16- 50
  • Email:consult@atkcg.ru