Escalabilidade do Qlik Sense

De Qknow
Ir para: navegação, pesquisa

Introdução

O Qlik Sense é a mais nova plataforma associativa da Qlik® para análise de dados totalmente em memória. De acordo com as escolhas e seleções do usuário o modelo associativo mantém todas as tabelas e dados carregados em uma posição coerente com as seleções, realizando cálculos em tempo de execução sem cubos pre-estabelecidos. O resultado é uma apresentação gráfica rica em conteúdo e livre para o usuário percorrer pela análise a partir de qualquer direção dos dados, acessando os painéis em navegação HTML 5.0 com JSON que possibilita a navegação em praticamente qualquer dispositivo do mercado, includindo Desktops, Latptops, Mobile Devices (tablets ou smartphones), além de análises embutidas em outros portais.

Por meio do modelo associativo presente no QlikView e Qlik Sense o usuário é capaz de pesquisar e navegar em todos os dados carregados sem um caminho definido inicialmente. Ou seja, o usuário não precisa informar a área de tecnologia as perguntas que gostaria de fazer aos dados antes da elaboração dos gráficos, pois pode construir sua análise na medida em que os gráficos respondem aos seus questionamentos anteriores. Aparelhado com um banco de dados colunar em memória, o Qlik possui um núcleo (motor) denominado QIX que permite o usuário navegar livremente nos dados carregados de maneira intuitiva, criando análises que combinam diversas fontes de dados como Excel, Arquivos Textuais, Microsoft Access e bancos de dados como Oracle, SQL Server e mesmo big data como Haddop e Redshift.

Tecnologicamente, o Qlik armazena em memória apenas uma entrada de cada valor encontrado nos dados que são carregados, de maneira que o restante são apontamentos para o local onde o dado deve existir. Este mecanismo exerce uma grande taxa de compressão permitindo que grandes volumes possam ser carregados diretamente na memória e representados como ponteiros, trazendo uma grande velocidade nas análises bem como menor tempo de resposta às interações dos usuários. Para volumes de dados ainda mais expressivos, o Qlik Sense conta com recursos como o On-Demand App Generation e o Direct Discovery, onde cada interação do usuário é recuperada diretamente das fontes de dados e ainda assim associadas ao conjunto que estiver em memória, perpetuando a experiência associativa.


Aspectos Gerais da Escalabilidade

Com o aumento do número de sistemas, usuários, volume de dados e aplicações em Sense (painéis), a escalabilidade torna-se cada vez mais relevante. Os aspectos mais importantes (longe de serem todos) são aqueles ligados a arquitetura, dados, aplicações, usuários e ambiente operacional. No que tange a arquitetura, o Qlik Sense é composto de processos modulares que podem ser escalados na vertical e/ou na horizontal. Ou seja, ao ambiente podem ser adicionados novos recursos computacionais como processador e memória (vertical) ou múltiplos equipamentos podem ser combinados para atender a demanda por um determinado processo (horizontal). No que tange as aplicações é possível prever com certa segurança o consumo de recursos e tempo de resposta na medida em que o Qlik Sense é linearmente escalado. Ou seja, dobrar a capacidade operacional reduz o tempo de resposta pela metade, facilitando a compreensão dos requisitos de infraestrutura para as aplicações. Da mesma forma o acesso a plataforma pelos usuários consome recursos de maneira linear. Ou seja, aumentando o número de usuários reflete de maneira linear no consumo de processador e memória.

QIX Engine01.PNG

Como mencionado, o QIX é o motor associativo em memória do Qlik Sense que indexa os dados que serão utilizados nas análises dos usuários, executando os cálculos em tempo de execução (runtime) ao invés de pré-agregar valores que não podem ser desmembrados posteriormente. Por isso, quando um usuário cria um gráfico com uma agregação, a operação é calculada imediatamente, tal como ocorre quando o usuário realiza algum filtro que altera os valores agregados no gráfico a partir de uma nova percepção. Tudo é calculado em tempo de execução pelo processo do QIX Engine, uma versão 64 bits e multi-thread capaz de usar múltiplos processadores (cores).

Por tratar-se de uma solução totalmente em RAM e não em cache, como ocorre com concorrentes de visualização, a memória precisa ser utilizada de maneira muito eficiente pelo Qlik Sense. Embora muitos processos utilizam memória RAM, é possível destacar três partes principais do uso da memória RAM na estrutura Sense:

  • Todos os dados carregados por uma aplicação (painel) são carregados em memória. Embora pareça um tanto quanto óbvio para uma solução que se diz in-memory, muitos players de mercado adotam esta mesma estratégia de marketing enquanto na prática não são soluções em memória. Há, por exemplo, boas ferramentas de visualização de dados no âmbito das soluções OLAP que persistem em dizer que são totalmente em memória, mas são incapazes de liberar o arquivo de dados que não pode ser movido ou apagado enquanto o usuário está utilizando o painel. No Sense, o arquivo pode ser excluído depois de ter sido carregado em memória, pois todos os dados estão fisicamente hospedados em RAM. Obviamente, excluir o arquivo é apenas uma forma de demonstrar o total uso da RAM e não uma recomendação para que não se perca o projeto.
  • Cálculos e seleções são hospedados em uma parte especial da memória chamada result cache. Um projeto em Qlik Sense é hospedado no servidor em forma de um arquivo com a extensão .QVF (ou .QVW no caso do QlikView) e carregado na memória quando o primeiro usuário acessa o painel. Um segundo usuário acessando o mesmo painel não duplicará os dados em memória, fazendo uso do mesmo conjunto de dados previamente carregado. As interações dos usuários geram cálculos que são executados ad-hoc (em tempo real) e apresentados na interface gráfica. Ao mesmo tempo, o Qlik Sense utiliza de um espaço reservado chamado result cache para manter os cálculos executados, reduzindo os ciclos de CPU se a mesma visualização for solicitada por qualquer usuário. O painel será descarregado da memória quando nenhum usuário estiver utilizando-o.
  • Dados da sessão de cada usuário conectado ao painel. O terceiro bloco de memória refere-se ao uso de RAM pelo ambiente Server para manter o "estado" (posição ou situação) da visualização do usuário conectado no servidor. O "estado" é a posição do que o usuário está visualizando no momento e o servidor se encarrega de manter esta posição enquanto o usuário estiver navegando no painel. Por exemplo, ao executar um determinado filtro o usuário recebe via HTML 5.0 e JSON (JavaScript Object Notation) uma atualização dos gráficos que representam a posição coerente do filtro. Quando uma nova seleção é realizada o servidor deve considerar que aquele usuário já tem um filtro aplicado e agregar um novo filtro ao invés de simplesmente aplicar a solicitação mais recente sem considerar o que o usuário está visualizando. É o "estado" da sessão do usuário, um consumo que varia de 1% a 10% do total de RAM destinado ao painel, por usuário.

Arquitetura Distribuída

Distributed Architecture01.PNG

Por ser construído com diferentes componentes e serviços o Sense é capaz de distribuir a carga por determinado recurso em diferentes nós (múltiplos equipamentos) aumentando horizontalmente a capacidade de atendimento. Estes nós podem ser virtuais (máquinas virtuais) ou físicas (máquinas reais) ou uma combinação destas. Por exemplo, é possível distribuir o QIX em múltiplos "nós" adicionando novos equipamentos na medida da necessidade. Diferente das soluções OLAP tradicionais que dependem de consultas dinâmicas nas plataformas de banco de dados, o Sense hospeda todo o volume em memória e não sobrecarrega os sistemas legados ao adicionar novos "nós" para atendimento as necessidades de infraestrutura.

Quando a capacidade é dobrada adicionando-se novos "nós", é possível assumir que o Sense manterá o mesmo nível de processamento para o dobro de usuários. O administrador pode, adicionalmente, definir que uma determinada aplicação será executada em um único "nó" ao invés de ser distribuída nos demais. O gráfico ao lado demonstra no eixo horizontal a adição de novos "nós" a um ambiente do QIX. É possível notar no eixo da direita do gráfico que o tempo de processamento das CPUs está praticamente estável em 55%, enquanto o número de usuários é acrescido (observe cada barra do gráfico) na mesma proporção de adição de um novo nó, iniciando com 200 e alcançando até 800 cada vez que a capacidade é acrescida.

Portanto, adicionar novos nós aumenta a capacidade de atendimento ao Sense nos serviços disponíveis mantendo um nível praticamente igual do consumo de CPU para cada dobro de usuários. Ou seja, dobrando o número de usuários e adicionando um nó resultará no mesmo consumo médio de processador. Bastante linear e fácil de gerenciar.

Desempenho da Aplicação

Distributed Architecture02.PNG

O desempenho da aplicação depende de três importantes fatores:

  1. Qual a disponibilidade de CPU para atender a demanda realizando os cálculos quando o usuário interagir com o painel.
  2. Qual o número de usuários simultaneamente que atuarão com o projeto demandando cálculos, seleções e filtros.
  3. Qual o total de memória RAM disponível para acomodar os dados necessários (aplicação, estado da conexão e result cache).

Para o uso eficiente dos recursos disponíveis o Senes utiliza de algorítimos que compactam os dados de maneira não proporcional ao volume carregado. Por exemplo, se uma aplicação possui 100 milhões de registros (linhas), adicionar 50 milhões (linhas) pode dar uma conotação de que a memória será acrescida de 50% de consumo, mas não é verdade. Por manter apenas uma cópia de cada entrada de dados o Sense é capaz de compactar os dados in-memory a uma taxa que varia de 30% a 90%. Ou seja, dependendo das características dos dados a adição de novos registros (linhas) não significa o aumento do consumo proporcionalmente, mas desproporcionalmente menor. Em resumo, o dobro de registros não exige o dobro de memória RAM.

A eficiência no uso da memória RAM assegura que adicionar novos registros não exigirá um volume estraordinário e proporcinal de memória, uma preocupação coerente para os administradores de infraestrutura, mas que não se vale no ambiente Sense. Da mesma forma, a adição de registros tem um impacto desproporcionalmente menor no consumo de CPU. Ou seja, na medida em que novas linhas são adicionadas novos ciclos (ou tempo de CPU) são necessários para realizar os cálculos solicitados pelo usuário. Porém, mesmo com novos dados o ciclos não aumentarão proporcionalmente ao número de registros, pois se o cálculo solicitado já existe no result cache o aumento do volume não irá aumentar um só ciclo de CPU. Claro que, por razões óbvias, nem todos os cálculos terão sido solicitados pelo usuário com a adição de novos registros, mas pela característica de manutenção de uma única entrada em memória o Sense é capaz de realizar os cálculos com o mínimo de CPU. Em resumo, o dobro de registros não significa o dobro de CPU.

No gráfico desta seção é possível observar o acréscimo de 50 milhões de registros entre cada carga e note que o aumento do consumo da memória RAM não equivale 50% da segunda carga sobre a primeira, quando o % de registro aumentou nesta proporção. Com a taxa de compressão os dados da primeira carga ocuparam 20,6GB de RAM, enquanto a segunda quase 21,4GB, de longe muito menos do que o dobro dos registros adicionados entre a carga 1 e 2. Ou seja, dobrar o número de registros carregados não promove o dobro do consumo de memória RAM nem de ciclos de CPU.

Camada de Dados

Além das grandes taxas de compressão que são aplicadas nos dados carregados em tempo de execução (in-memory), o Qlik Sense pode estruturar uma camada de arquivos intermediários (opcionais, mas bastante utilizadas) para hospedar os registros obtidos das diversas fontes, arquivos ou bancos de dados. Os arquivos .QVD são estruturados para manter uma forte taxa de compressão de maneira a serem reutilizados em diversos painéis de usuários. Ao invés dos projetos efetuarem leituras repetidas das bases de dados onerando o desempenho do ambiente de produção, uma única leitura pode ser gravada em arquivos com a extensão .QVD.

IncrementalLoad.jpg

Adicionalmente, arquivos .QVD podem ser lidos entre o QlikView e Qlik Sense, criando uma interoperabilidade entre as soluções para clientes que possuem as duas ferramentas. Desta forma, múltiplos arquivos .QVD podem representar tabelas, arquivos ou consultas (SQL) para serem reutilizados por diversos usuários e aplicações Sense (painéis). Arquivos .QVD possuem características de compressão que permitem que a carga seja realizada entre 10 e 100 vezes mais rápido do que qualquer outra operação realizada em um banco de dados tradicional. Ou seja, ao invés de 10 aplicações Sense (painéis) realizarem a leitura 10 vezes em um banco de dados, um único .QVD poderá atender as diversas aplicações com um tempo de carga abruptamente menor. Adote arquivos .QVD para as seguintes condições:

Uma vez que o Qlik Sense é capaz de conectar-se a quase todos os tipos de plataformas de bancos de dados e arquivos de dados, o tempo de recarga dependerá de fatores como o desempenho do sistema de gerenciamento de banco de dados (SGBD), capacidade das CPUs, frequência do clock, velocidade da rede, desempenho do subsistema de discos, tipo de agregações (se houver) durante a execução do script, entre outros. Porém, as características de desempenho do processo de recarga são lineares e permitem uma fácil administração, pois o aumento de registros durante o processo eleva o consumo de RAM e tempo de duração de maneira proporcional e previsível. Por exemplo, se a carga de 50 milhões de registros é realizada em 6 minutos, a carga de 100 milhões de registros levará 12 minutos (com alguma pequena variação). De maneira semelhante, o consumo de memória RAM durante a carga será proporcionalmente acrescida pelo número adicional de registros. Por exemplo, assuma que uma carga de 50 milhões de linhas utilize 12GB de memória (não éuma regra, depende dos dados) e que o aumento de 50 milhões de registros eleve o consumo para 16GB. Logo, é possível afirmar que ao adicionar mais 50 milhões de linhas (em uma terceira operação) fará com que o servidor consuma 20GB de RAM. Portanto, mantém a proporção. A cada 50GB, 4GB de RAM adicionais serão necessários.

Distributed Architecture03.PNG

Conexões Simultâneas

QVS - CPU Usage - v1 0.png

Na medida em que novos usuários conectam ao ambiente Sense Server ou QAP mais uso das CPUs ocorre para atendimento as diferentes requisições. Novamente, o Qlik Sense escala o uso de processador de maneira linear e relativamente bem previsível, já que o aumento do número de conexões eleva o consumo de processador de maneira proporcional. Por exemplo, se um painel possui 60 usuários conectados simultaneamente com um consumo médio de 30% de CPU, elevar o número de usuários em 30 (para 90, digamos) aumentará o uso do processador na mesma escala que novos 30 para 120 usuários. Ou seja, a cada ingresso de 30 usuários o processador é demandado na mesma proporção de acréscimo. Assim, se a CPU foi utilizada em 30% para 60 usuários, para 90 o aumento poderia ser algo em torno de 15% (para 45% total) e, para 120 usuários, mais 15%. Assim, o processamento subirá 15% a cada 30 usuários, tornando o dimensionamento bastante previsível.

Como já mencionado, o Engine é responsável por efetuar os cálculos a partir das interações do usuário. Este recurso é baseado na plataforma 64 bits e utilizará todos os processadores disponíveis com arquitetura multi-thread fazendo com que uma única seleção ou interação seja distribuída em múltiplos cores disponíveis. Quando ocorre uma interação do usuário o Engine aloca o máximo possível de recursos a partir da capacidade disponível, elevando o consumo dos processadores ao necessário para atendimento a requisição. Imediatamente depois, os processadores são reduzidos aos níveis mínimos. Portanto, é bastante comum acompanhar o processador do equipamento Sense Server ou QAP em picos e vales (altas e baixas). Na memória RAM ocorre algo semelhante em termos de linearidade, pois o ingresso de novos usuários aumenta o consumo de memória progressivamente e proporcionalmente. Por exemplo, se com 60 usuários um servidor Sense utiliza 50GB de memória e ao adicionar 30 usuários o consumo aumenta para 60GB, então é possível afirmar que o ingresso de mais 30 (totalizando 120) aumentará o consumo em 10GB, totalizando 60GB. Assim, a cada 30 novas conexões o uso da memória aumentará em 10GB, bastante previsível.

Nota: Este artigo se concentra no modelo de uso e previsão de consumo. O consumo de RAM e CPU dependem de cada projeto. 


Referências

  • DS-Qlik-Sense-Scalability-EN.pdf
  • WP-Tecnical-Brief-Qlik-Sense-Performance-Benchmark-EN.pdf
  • WP-Qlik-Sense-Architectural-Overview-EN.pdf

© 2016 QlikTech International AB. All rights reserved. Qlik®, QlikView®, Qlik® Sense, QlikTech®, and the QlikTech logos are trademarks of QlikTech International AB which have been registered in multiple countries. Other marks and logos mentioned herein are trademarks or registered trademarks of their respective owners.



Assuntos Relacionados



Envelope01.jpg
Procurando Algo? Fale Conosco!



Infraestrutura Sense | Infraestrutura Qlik | Página Principal

Página Principal >> Infraestrutura >> Infraestrutura Qlik Sense >> Escalabilidade do Qlik Sense