Abordagens e considerações de desempenho em cenários e soluções de planejamento de BI

Artigo
03/07/2017

Aplica-se a: SharePoint Server 2010 Enterprise

Tópico modificado em: 2016-11-30

Neste artigo:

Considerações sobre desempenho
Segurança e funções

Considerações sobre desempenho

Design e configuração

Mantenha o tamanho das dimensões tão pequeno quanto o necessário para o processo de planejamento.
Mantenha o número mínimo necessário de dimensões usadas em um cubo para o planejamento.
Evite cálculos MdxScript quando possível e use ao máximo os cálculos no lado do cliente, como cálculos relacionais ou do Excel em planilha, agendados para execução periódica (ou seja, conversão de moeda).
Ao usar regras MdxScript, verifique atentamente não só a exatidão lógica, mas também o respectivo desempenho. Às vezes, é possível escrever a instrução MdxScript de uma forma um pouco diferente, mas com a mesma equivalência lógica, para conferir maiores ganhos de desempenho.
Evite hierarquias computacionais muito profundas.
Evite consultas MDX complexas ao projetar relatórios e formulários de entrada. Consultas que contêm a instrução “WITH” e outros membros calculados farão com que o computador do Microsoft SQL Server Analysis Services (SSAS) utilize uma lógica de cache limitada, o que resulta em menor escala e desempenho
Se você estiver trabalhando com um conjunto de dados muito grande, crie várias partições para gerenciar melhor quais dados são estáticos e quais são voláteis.
Evite a segurança em nível de célula em definições de segurança de função, pois a lógica de armazenamento em cache fica limitada quando esse tipo de segurança é aplicado.

Tamanho, layout e uso de formulário

Projete formulários (Tabelas Dinâmicas) que utilizem filtros e segmentação de dados para limitar o número de células e consultas no formulário; ou seja, não projete o formulário com todas as entradas de dados possíveis e visíveis, mas forneça um filtro ou uma segmentação de dados para que o layout (tamanho) desse formulário permaneça consistente sob o ponto de vista de layout e, em seguida, seja dinamizado com as devidas alterações na segmentação de dados.
Quando existem várias tabelas dinâmicas, o tempo de consulta e de resposta aumenta. A prescrição é limitar o número de tabelas dinâmicas na mesma planilha e na mesma pasta de trabalho.
Ao criar formulários e relatórios, defina o padrão para os filtros como um membro de nível mais inferior na hierarquia. Isso permite que as consultas padrão parem de utilizar cálculos de agregação desnecessários no cubo.
Não mantenha alterações muito grandes no lado do cliente (por exemplo, em alterações de write-back de Tabelas Dinâmicas do Excel). Em vez disso, publique incrementalmente essas alterações no servidor para obter um nível ideal de desempenho de tempo de execução do SQL Server Analysis Services.

Suporte para usuários remotos

Os usuários remotos na WAN podem ter uma conexão de rede e tempos de resposta mais lentos. Para atender a esses usuários remotos, convém fazer o seguinte:
Forneça-lhes suas próprias instâncias SQL/SharePoint o mais próximo possível de seus respectivos locais físicos.
Forneça-lhes acesso aos Serviços de Área de Trabalho Remota do Excel em um computador mais próximo do servidor SQL/SharePoint.

Para obter mais informações, consulte o white paper do SQL Server 2008 sobre o guia de desempenho do Analysis Services.

Considerações sobre ETL

O ETL é o processo de extrair dados de sistemas de origem, transformando esses dados e os carregando no modelo de dados. O SQL Server Integration Services é a principal tecnologia da Microsoft para trabalhar com processos de ETL. Os integradores de dados criam pacotes do SSIS usando o Microsoft BIDS, que inclui os seguintes benefícios:

Acesso a uma grande biblioteca de lógicas de ETL internas para operações que incluem mesclagem de conjuntos de dados, pesquisas de coluna e tratamento de erros, entre outras.
Rápida transferência no carregamento de dados da origem para o destino.
Interface do usuário para visualizar o processo de ETL.

O planejamento de pacotes de ETL pode ser dividido nas seguintes áreas:

Importação de dados para dimensões, hierarquias e fatos.
Exportação de dados de tabelas de fatos para sistemas de origem.

Importação de dados

Para a nossa solução, criaremos uma tabela de preparo para cada uma das tabelas de dimensões, hierarquias e fatos existente no banco de dados relacional. As tabelas de preparo serão usadas inicialmente como a tabela de destino para o carregamento de dados a partir do sistema de origem. É possível realizar ETL sem usar tabelas de preparo, pois o SSIS tem a capacidade de transformar a maior parte dos dados na memória e de os carregar diretamente nas tabelas da solução. Entretanto, os benefícios do uso de tabelas de preparo incluem:

Fazer instantâneos de tabelas e relações do sistema de origem para facilitar o descarte de uma versão dos dados sem riscos de perder o acesso futuro ao sistema de origem ou ficar sujeito a alterações de dados inesperadas.
Fácil auditoria dos dados de preparo antes de publicá-los nas tabelas da solução. Por exemplo, você pode optar por fazer um carregamento em massa para todas as tabelas da solução somente depois que alguém verificar se as tabelas de preparo estão corretas.

Após o carregamento dos dados nas tabelas de preparo e a conclusão das transformações necessárias, o processo de carregamento das tabelas de preparo para as tabelas da solução pode ser iniciado. Com o SSIS, o carregamento das tabelas de preparo para as tabelas da solução pode ser tão fácil quanto mapear colunas da tabela de origem para colunas da tabela de destino. Como o SSIS fornece um conjunto de recursos muito avançados para ETL, sugerimos uma leitura adicional a respeito desse tópico no white paper de introdução aos Serviços de Integração do SQL Server 2008.

Dica

Simplifique o modelo de recuperação SQL ao realizar o ETL. Isso melhora o desempenho porque reduz a sobrecarga de registros em log desnecessários no banco de dados.

Exportação de dados

É comum na maioria dos cenários que, após a conclusão de um processo de planejamento, os resultados precisem ser coletados e processados para reexportação no sistema de origem, onde eles serão mantidos e disponibilizados para requisitos de relatórios.

Na nossa solução, como os dados já estão armazenados nas tabelas de fatos de maneira normalizada, sua preparação para exportação só requer algumas simples junções com as tabelas de dimensões.

Entretanto, a exportação de dados pode se tornar um tanto complicada quando os dados a serem exportados não existem na tabela de fatos, ou melhor, só existem como cálculos no cubo. Como superar esse cenário? A resposta é usar consultas distribuídas específicas no cubo OLAP. Para obter mais informações, consulte Guia de modelagem e relatórios de planejamento para cenários e soluções de planejamento de BI.

Segurança e funções

A segurança deve ser definida no banco de dados do SSAS por meio de funções de segurança. Para obter o máximo de desempenho, é melhor manter o nível mais simples possível de segurança.

O nível mais alto de segurança é a segurança de banco de dados. É recomendável que cada operador de informações que precise de acesso ao modelo de dados tenha pelo menos a ‘definição de leitura’ no banco de dados.

O segundo nível mais amplo de segurança é definido no cubo. Esse nível controla em que partes os cubos individuais têm capacidades somente leitura ou de leitura/gravação ou são inacessíveis.

O próximo nível de segurança é definido em dimensões. Você pode optar por deixar membros específicos de uma dimensão visíveis ou ocultos. Convém parar na segurança de dimensão para obter o desempenho ideal do SQL Server Analysis Services.

Se você definir a segurança no nível mais baixo de acesso, será no nível da célula. Nesse caso, o desempenho sairia prejudicado, pois a lógica de armazenamento em cache ficaria seriamente limitada a consultas de qualquer usuário cuja segurança estivesse definida no nível de célula.

É possível criar funções de segurança no banco de dados do SQL Server Analysis Services usando o Microsoft SQL Server BIDS.

É importante observar que o BIDS pode fazer a definição de configurações de segurança altamente complexas. Além disso, sua configuração e manutenção podem exigir mais habilidades técnicas avançadas de um administrador. Entretanto, esta pode ser uma boa área de personalização, em que a segurança pode ser definida em qualquer outro lugar, seja com uma planilha estruturada ou com uma tabela vinculada do SharePoint que depois possa ser inserida em um módulo de conversão e, no final das contas, atualizar a segurança OLAP de forma apropriada.

Segurança complexa

A segurança dinâmica do SQL Server 2008 Analysis Services também pode ser configurada quando as funções padrão do SQL Server Analysis Services são insuficientes para incluir todas relações complexas existentes. O cenário ocorre quando

Cada operador de informações exige acesso a um conjunto específico de membros de dimensão
Existem algumas sobreposições em requisitos de segurança dimensional, ou seja, há muitas combinações exclusivas de membros de dimensão atribuídos a diferentes operadores de informações.

Share via