Сайзинг и масштабирование серверов для QlikView  

С чего начать при внедрении или масштабировании серверов QlikView

При планировании внедрения QlikView, не важно, новое ли это внедрение или расширение существующего, вопрос сайзинга крайне важен. Приложение QlikView весьма прожорливо и капризно (смотреть системные требования сервера QlikView). Основная причина, почему внедрение QlikView в компании было не успешным, в подавляющем большинстве случаев было связано с тем, что отклик приложения на действия пользователя был очень медленным. Мы поговорим том, как потребность в ресурсах зависит от следующих факторов:

  • Объем данных;
  • Количество пользователей;
  • Количество приложений;
  • Дизайн приложений;

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

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

В самом конце мы поговорим о средстве анализа и предсказания масштабируемости серверов QlikView - Scalability Center.

Итак приступим.

 

Четыре фактора при масштабируемости QlikView

 

Фактор 1. Сайзинг по объему данных

Хорошо известно, что объем данных, генерируемый компанией, быстро растет. Объем данных растет, одновременно и растут требования к системе бизнес-аналитики, - она должна сохранять высокую производительность и предсказуемое время отклика. Для традиционных решений, это приводит к использованию более дорогих технологий ускорения запросов к базам данных, а результат использования таких технологий не всегда соответствует ожиданиям. Для новых технологических решений, in-memory, таких как QlikView, важно понимать высокую степень зависимости от доступных ресурсов оперативной памяти (RAM).

Подход QlikView к сайзингу объема данных

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

Поскольку сервер QlikView работает по технологии in-memory, вполне понятно, что чем больше добавлено данных, тем больший объем оперативной памяти понадобится. Если наступит ситуация нехватки оперативной памяти, то сервер QlikView будет использовать виртуальную память операционной системы (жесткий диск, как память в дополнение к имеющейся памяти), производительность сильно пострадает, а время отклика приложения для пользователя станет неприемлемым. Стоимость оперативной памяти постоянно снижается, так что добавление оперативной памяти при увеличении объема данных - это относительно небольшие дополнительные расходы. Сервер QlikView также применяет комплексные алгоритмы сжатия данных для того, чтобы как можно более эффективно использовать доступную оперативную память. Компрессия может составлять от 20% до 90% в зависимости от природы данных.

Зачем увеличивать ресурсы процессора при росте объема данных – не так очевидно, как в случае с оперативной памятью. Процессор задействуется при любом взаимодействии пользователя с приложением Qlikview. Например, когда пересчитывается диаграмма или задана новая выборка. Для любого приложения, время ответа на запрос пользователя зависит от способности процессора обработать запрос, выполнить пересчет и обновить интерфейс. Так что чем больше данных добавляется к приложению, тем большее количество пересчетов должен выполнить процессор.

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

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

RAM = (RAMuser × No. users) + RAMinitial, где:

RAMinitial = QVWsizedisk × FileSizeMultiplier – начальный объем памяти, которое занимает приложение;

RAMuser = RAMinitial × userRAMratio – это объем памяти, который требует каждый пользователь;

QVWsizedisk = SourceData × (1 – CompressionRatio) – это объем на диске, требуемый для размещения QVW файла – приложения;

Мы полагаем, что:
userRAMratio: находится в диапазоне от 1% до 10%;
FileSizeMultiplier: находится в диапазоне от 2 до 10;
CompressionRatio: находится в диапазоне от 20% до 90%;

Рассмотрим пример сайзинга:

Исходные данные: 50Гб
CompressionRatio: 90%
FileSizeMultiplier: 8
userRAMratio: 10%
No.users (количество одновременных пользователей): 30

QVWsizedisk = 50GB × (1 - 0.9) = 5GB;

RAMinitial = 5GB × 8 = 40GB;

RAMuser = 40GB × 10% = 4GB;

Для 30 пользователей:
RAM = (4GB × 30) + 40GB = 160GB;

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

Линейное масштабирование известной модели данных и дизайна приложения

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

Упрощенно, можно представить этот метод в виде следующих шагов:

  1. Измерение характеристик производительности небольшого внедрения (измерение времени отклика на действие пользователя);
  2. Оценка использования процессора и памяти в таком внедрении;
  3. Проведение линейной экстраполяции, используя ожидаемые дополнительные данные и количество пользователей;

Интеллектуальное распределение данных – горизонтальное масштабирование

Когда дело доходит до анализа быстро растущих данных, лучшие практики говорят, что предпочтительней попытаться разделить данные, чем пытаться анализировать все данные. Приведем в пример данные о продажах по всему миру. Для небольшой компании использование одного QlikView вполне допустимо и обоснованно. Для большой компании – такой подход не практичен из-за очень больших объемов данных и большого количества пользователей.

В этом случае используется QlikView Publisher, который берет большое исходное приложение и нарезает его на более мелкие (например, по странам). Эти более мелкие приложения затем становятся доступны клиентам на сервере QlikView.

QlikView внедрения масштабируются горизонтально добавлением нового сервера и организацией кластера с технологией балансировки нагрузки. В сценарии, иллюстрированном ниже, имеется по QlikView серверу, закрепленному за каждым подразделением (QlikView Server Finance и QlikView Server Operations), каждый из которых содержит приложения, необходимые для соответствующего подразделения.

горизонтальное масштабирование QlikView

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

многоуровневая архитектура QlikView

Вертикальное масштабирование

Вертикальное масштабирование являет собой подход, при котором к серверу добавляется большее количество ресурсов процессора и памяти.

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

Умная загрузка данных

Эффективная стратегия при работе с увеличивающимся объемом данных – это использование инкрементных загрузок. Хотя этот подход больше относится к построению модели данных, а не к масштабируемости, стоит отметить его, поскольку это важная характеристика приложения QlikView.

Инкрементальная загрузка – это загрузка только изменившихся или новых транзакций, а не всей базы данных. Такая загрузка может стать частью регулярно запланированного процесса загрузки и реализовывать многоуровневый подход к хранению данных. Инкрементальная загрузка позволяет добавить данные к приложению быстрее, нежели это было бы с загрузкой полной базы. В результате пользователи могут быстрее получить доступ к обновленным данных.

инкрементальная загрузка данных в QlikView

Пример анализа большого количества данных

Большой продавец одежды с 70ГБ данных.

Для анализа 70 ГБ данных ритейлер выбрал QlikView. Компания занимается производством и продажей мужской и женской одежды во множестве стран по всему миру и показывает многомиллиардную выручку. Как большинство похожих организаций, эта компания испытывала трудности с использованием имеющегося арсенала традиционных аналитических средств, поскольку бизнес пользователи постоянно нуждались в новых отчетах и свежих аналитических данных.

Компания выбрала QlikView для обеспечения работы более 200 одновременно работающих пользователей в планировании производства и продажах, которые должны были анализировать более 500 миллионов строк данных и при этом упростить и улучшить процесс принятия решения.

Использовался многоуровневый подход, QlikView Publisher сервер, на котором находились 15 исходных QVW файлов, каждую ночь данные (70ГБ) загружались из разных источников: DB2, MS Excel, Oracle. Среднее время загрузки составляло 4 часа. В первой части оптимизации данных было создано 5 QVD файлов, размер которых варьировался от 250МБ до 60ГБ, которые стали опосредованно хранить данные из баз данных. Из этих файлов пользовательские приложения и забирали данные. В этом внедрении, 4 сервера (QlikView Server) с 64 CPU и 256ГБ памяти были запущены в режиме кластера и один сервер (QlikView Publisher) с 32 CPU и 128ГБ памяти под управлением операционной системы Windows Server.

анализ больших данных в QlikView

 

Вернуться к содержанию

 

Фактор 2. Сайзинг по количеству пользователей

Теперь к следующему фактору масштабируемости QlikView – количество пользователей.

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

Задача ИТ подразделения – понимать характеристики масштабируемости приложений и быть готовыми к предсказуемому и пропорциональному увеличению ресурсов для поддержки потребностей.

Подход QlikView к масштабированию количества пользователей

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

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

QlikView использует in-memory хранение данных: все данные каждого конкретного анализа QlikView помещаются в оперативную память. Когда первый пользователь открывает документ QlikView, становится необходим объем оперативной памяти от 2-х до 10-х раз больший, чем размер приложения QVW. В этот объем входят также вспомогательные данные, такие как индексы, ассоциации и т.д. Добавление конкурентных пользователей вызывает потребность в выделении дополнительной оперативной памяти. Даже если одна общая выборка используется всеми пользователями, у каждого пользователя есть свое собственное состояние сессии, которое требует дополнительного объема оперативной памяти.

Общее правило, которое используется для оценки дополнительных ресурсов на пользователя, звучит так: на каждого пользователя необходимо добавить от 1% до 10% оперативной памяти, от объема, необходимого для работы первого пользователя.

Например, имеется 1ГБ документ .QVW, который занимает 4ГБ в памяти для первого пользователя (для примера мы используем фактор 4, хотя этот параметр может различаться в зависимости от природы данных). Второй пользователь может увеличить потребность в оперативной памяти на 10%. В результате для двух пользователей оперативная память должна быть не менее 4.4ГБ. Третий пользователь увеличит потребность до 4.8ГБ и т.д.

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

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

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

Кластеризация и балансировка нагрузки

Кластеризация – возможность объединить несколько серверов в один кластер, где обращения происходят к кластеру, а механизм балансировки нагрузки распределяет запросы по наименее загруженным серверам (или по другому заранее определенному алгоритму). Кластеризация и балансировка нагрузки эффективная методика для увеличения количества пользователей. QVS кластер (который использует QlikView AccessPoint как балансировщик нагрузки) автоматически отправляет новый запрос на самый свободный сервер из кластера (тот, на котором используется меньше ресурсов процессора или памяти). Таким образом отклик сервера будет наилучшим и работа пользователя быстрее и комфортней. (Сделаем небольшую ремарку, QlikView сделан таким образом, чтобы помогать аналитику исследовать данные. Ассоциативная модель построения, похожая на принцип работы человеческого мозга, должна помочь аналитику интуитивно шаг за шагом приближаться к сути явлений. Но это все актуально только тогда, когда время обновления таблиц и диаграмм составляет максимум несколько секунд. Если каждая новая выборка занимает 20-30 секунд, то аналитик очень быстро теряет нить анализа из-за отвлекающих факторов и растущего раздражения. Поэтому, в системе QlikView, как нигде, быстрота работы очень сильно связана с качеством. Большинство не успешных внедрений QlikView связано как раз с неприемлемым временем отклика на выборку).

Еще раз повторим последний тезис, таким образом отклик сервера будет наилучшим и работа пользователя быстрее и комфортней. И достигается это простым добавлением сервера в кластер. Еще один побочный эффект кластеризации – высокая доступность приложения. Так как при выходе из строя одного из серверов, его пользователи будут автоматически распределены между оставшимися в строе серверами. Ниже на иллюстрации покзан типичный QVS кластер.

балансировка пользователей QlikView по серверам с помощью access point

Пример – большое количество пользователей

Большая производственная компания, более 8000 пользователей.

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

Используя данные из Teradata, SQL Server, DB2 и Sybase, компания сейчас использует QlikView для анализа продаж, поставок, анализа ИТ и анализа 6 сигма.

15 продакшн QlikView серверов, 4 сервера QlikView для разработчиков приложений, 11 QlikView Publisher используются для поддержки загрузки и распределения данных.

Сотни приложений QVW, среди которых наиболее распространенное приложение для анализа продаж на местах. Это приложение обслуживает потребности более 8000 пользователей каждое утро понедельника. Оно привязано к базе Active Directory с более чем 400 000 пользователями. Наибольший QVW занимает 600МБ на диске.

Для анализа продаж компания имеет 2 документа QlikView по 500МБ, загружающих 500 миллионов строк, 300 столбцов и формирующих 1800 документов через QlikView Publisher за выходные. 400 документов запускается ежедневно, наибольший из которых 1.1ГБ на диске и содержит 40 миллионов строк.

масштабирование QlikView по количеству пользователей

 

Вернуться к содержанию

 

Фактор 3. Сайзинг по количеству приложений

Следующий фактор масштабируемости – количество приложений.

В большинстве случаев, QlikView начинается с небольшого внедрения, обычно на одно подразделение и содержит одно приложение. Но быстро растет, так как компании сразу видят быстрый возврат инвестиций от подхода к бизнес-аналитике QlikView. Другие подразделения начинают создавать собственные приложения и очень скоро внедрение превращается в сотни приложений, охватывающих несколько подразделений по географически распределенным представительствам. А в каждом конкретном подразделении, скорость распространения увеличивается, более широкому спектру пользователей необходим доступ к данным для более эффективной работы. Все это накладывает дополнительные требования к ИТ в различных ракурсах, таких как загрузка данных, управление данными, управление пользователями.

Подход QlikView к масштабированию количества приложений

Важно не упускать из вида определение «приложения», использующегося в этом разделе. Вообще, приложение в QlikView это файл, который:

  1. Используется для анализа, визуализации и представления данных пользователем, известен как QVW файл;
  2. Используется как оптимизированное хранилище данных приложения без интерфейса, известен как QVD файл;

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

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

Посмотрим на пример:

требования к приложениям QlikView, пример

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

большое ресурсоемкое приложение QlikView

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

Сценарий 1. Одно приложение покрывает все потребности

Создается документ QlikView под названием Orders Dashboard, содержащий все необходимые столбцы данных из 609 миллионов записей. Это будет очень большой документ и он покажет наихудшее быстродействие из представленных сценариев.

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

Сценарий 2. Три приложения, сегментированных по детализации

Три документа QlikView: Orders Dashboard (Отчет - 1.8 миллионов строк), Order Analysis (Анализ заказов - 46 миллионов строк) и Orders Detail (Детализация заказов - 609 миллионов строк). Модель данных для этих QlikView документов будет почти одинаковой, тогда как будет различаться детализация. Пользователи будут переходить от Dashboards к Analysis и далее к Details. Преимуществом такого подхода будет поддержка большего количества одновременно работающих пользователей, поскольку меньшие приложения занимают меньше места в оперативной памяти. Работа меньших приложений будет быстрее.

оптимизированное приложение QlikView

Сценарий 3. Пять приложений, сегментированных по предметной области

Первый документ – dashboard (5 миллионов строк), другие четыре – специфичные для той или иной предметной области документы (32 миллиона строк в каждом). Модель данных для приложений будет похожа, но выборки будут производиться по различным измерениям из базовой модели. Каждое из 4-х приложений может использовать данные из своего файла данных QVD.

приложения QlikView сегментированные по предметной области

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

масштабирование количества приложений QlikView

Пример – большое количество приложений

Sandvik, 50 миллионов строк данных, более 100 источников данных, 3000 пользователей.

Sandvik – многопрофильный холдинг, занимающийся производством, добычей, строительством. 3000 пользователей QlikView, среди которых продавцы, закупка, HR и обслуживающий персонал. Компания начала с анализа доходности заказчиков, используя данные из нескольких систем. Сейчас у Sandvik более 400 приложений QlikView, наибольшее из которых содержит 50 миллионов строк, взятых из хранилищ, насчитывающих терабайты данных. QlikView использует данные из DB2, SAP BW, iSeries, Microsoft SQL Server, Oracle, текстовые файлы – более 100 источников.

 

Вернуться к содержанию

 

Фактор 4. Сайзинг по дизайну приложения

Следующий фактор масштабируемости – дизайн приложения.

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

Подход QlikView к дизайну приложений

Отметим лишь некоторые факторы, влияющие на эффективность работы приложения.

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

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

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

Вот несколько факторов дизайна, влияющих на производительность:

  • Избегайте использования большого количества списков на одной закладке;
  • Не злоупотребляйте таблицами данных и сводными таблицами;
  • Избегайте повторного использования больших выражений;
  • Не используйте макросы;
  • Избегайте использования большого количества текстовых объектов со сложными вычислениями: используйте диаграммы для вывода похожих метрик;
  • Избегайте использования функции date(Now), лучше используйте today(). Now() будет пересчитываться каждую секунду;
  • Избегайте использования отдельных значений в поле, например используйте (495) 201-7545 вместо 4952017545. Разделяйте адреса на отдельные поля, не помещайте их вместе;
  • Не загружайте поля данных, если не планируете их использовать. Избегайте выбирать * при выборе загружаемых данных;
  • Если таблица содержит большое число записей, задавайте условие расчета, чтобы сузить выборку перед тем, как ее увидеть;
  • Не обязательно распространять все приложение целиком, используйте QlikView Publisher, чтобы добиться меньшего размера приложения.

Влияние дизайна интерфейса на использование памяти

В зависимости от определения объекта, объем памяти, необходимый для отображения, может сильно отличаться. Например, если мы берем таблицу, которая доступна продавцу, отражающую продажи, затраты и маржу, то эта таблица будет небольшой. А если разработчик приложения добавит измерение «продукт», а в базе данных хранится, скажем, 10 миллионов продуктов, то отображение таблицы потребует значительно больший объем оперативной памяти.

Даже не агрегированные данные требуют оперативной памяти для отображения. Список с 50 миллионами записей будет требовать серьезных ресурсов просто для отображения. Это особенно справедливо для таблиц и прочих сильно детализированных объектов. Например, в таблице пять полей: продавец (3 отдельных вхождения), регион (3 отдельных вхождения), заказчик (200 отдельных вхождений), дата (3652 отдельных вхождений) и заказ (50 миллионов отдельных вхождений). Мы создаем структуру, которая потребует 250 миллионов ячеек (50 миллионов вхождений, на 5 столбцов), хранимых в памяти. Показ этого объекта потребует большого количества ресурсов. Практика показывает, что этот объект лучше не показывать, пока мы не ограничим количество строк к показу.

Количество просмотренных объектов интерфейса

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

Кешированные выборки

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

Почему архитектура влияет на масштабируемость

Как мы уже показывали ранее, дискуссия от масштабируемости QlikView разворачивается вокруг рекомендуемого подхода к архитектуре и внедрению приложения. Например, для ИТ профессионалов важно хорошо понимать, что QlikView рекомендует делать с большим объемом данных. Примеры из жизни демонстрируют, почему про активный подход может дать еще лучшую производительность.

Сценарий 1

800 миллионов строк данных и 500 пользователей. 10% одновременно работающих пользователей. Первоначально, было только одно приложение QlikView и были проведены тесты производительности.

все пользователи QlikView работают с большим приложением

Общее время ожидания составило 5.6 часов для 50 одновременно работающих пользователей. Среднее время отклика составило 5 секунд. Производительность была признана неприемлемой, исходя из объема оперативной памяти в системе. После этого было создано меньшее приложение, базирующееся на агрегированных данных (в организации признали, что не всем пользователям нужна столь детализированная информация). Ниже показаны результаты теста комбинации этих приложений.

разные группы пользователей QlikView работают с разными данными и приложениями

Видно, что использовав очень простой подход к архитектуре QlikView (2 документа вместо одного, предоставляющие необходимый уровень детализации пользователям, которым это необходимо), производительность была улучшена на 300%. Помимо этого, понадобилось меньше мощностей, хотя решение и данные остались теми же.

Сценарий 2

Две компании внедрили QlikView для обработки одинакового объема данных (примерно 800 миллионов строк) и имеют одинаковую конфигурацию серверов (16 CPU и 64 ГБ памяти). Однако внедрение одной из этих компаний может обслуживать в 5 раз больше пользователей, чем другой.

QlikView проактивный дизайн приложений

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

 

Вернуться к содержанию

 

Центр масштабируемости QlikTech

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

  1. Теоритическая производительность широкого спектра приложений может быть проверена и снижен риск неправильных заключений;
  2. Хорошо видно, как разработаны и как используются документы QlikView;
  3. Используя центр масштабируемости можно посмотреть, как поведет себя приложение при дальнейшем масштабировании.

Методология

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

  • Обычно самое загруженное время для QlikView – сразу за обновлением данных;
    • Тесты должны проводиться после перезагрузки QVS и очистки кеша;
  • Типичный пользовательский сценарий может быть симулирован при определении какие объекты скорее всего будут использованы для анализа и какие таблицы скорей всего будут интересны типичному пользователю;
    • В тестах должны содержаться шаблоны действий, которые скорей всего выполнит пользователь;
  • Каждый пользователь скорее всего сделает разное выделение одного и того же объекта;
    • Тест должен сделать выделение внутри объекта случайным (одни пользователи выберут одну страну, другие – другую);
  • Обычно пользователю нужно время подумать между кликами;
    • Тест должен учитывать временные задержки между кликами. Эти временные задержки могут быть разными в зависимости от типа приложения и роли пользователя;
  • В среднем пользователь, скорее всего, совершит определенное количество кликов. Поскольку количество конкурентных пользователей должно сохраняться, должны инициироваться новые сессии;
    • Как только пользователь выполнил свое последнее действие должна создаваться новая сессия;

Эта методология позволит определить, как определенное приложение QlikView будет функционировать в определенных обстоятельствах. Важно понимать, что результат будет зависеть от того, как выглядит приложение и какое мы предполагаем поведение пользователя. Каждый виртуальный пользователь (ВП) производит определенный набор действий. Если время обдумывания действия мало, то количество действий за единицу времени будет больше, и тем меньшее количество одновременных пользователей мы сможем обслужить. И наоборот. Поэтому важно ставить реалистичные величины для:

  • Количества конкурентных виртуальных пользователей;
  • Время обдумывания действий;
  • Количество действий пользователя на сессию;


 
Калькулятор облачного хостинга QlikView SaaS/PaaS (по требуемым мощностям)
Калькулятор облачного хостинга QlikView SaaS/PaaS(по объему анализируемых данных)
Рассчитать и купить
(495) 201-QLIK (201-7545)
qlik@v-grade.ru
  

Содержание: