Sobre cubos OLAP

Publicado: julho de 2016

Aplicável a: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

A ilustração a seguir mostra uma imagem do SQL Server BIDS (Business Intelligence Development Studio) que representa as principais partes necessárias aos cubos OLAP. Essas partes são: fonte de dados, exibição da fonte de dados, cubos e dimensões. As seções a seguir descrevem as partes do cubo OLAP e as ações que os usuários podem executar com elas.

Uma fonte de dados é a origem de todos os dados que estão contidos em um cubo OLAP. Um cubo OLAP conecta-se a uma fonte de dados para ler e processar dados brutos a fim de executar agregações e cálculos para as medidas associadas. A fonte de dados de todos os cubos OLAP do Service Manager são os data marts, o que inclui os data marts tanto do Operations Manager, quanto do Configuration Manager. As informações de autenticação sobre a fonte de dados devem ser armazenadas no SSAS (SQL Server Analysis Services) para se estabelecer o nível correto de permissões.

Exibição da fonte de dados

A DSV (exibição da fonte de dados) é uma coleção de exibições que representam as tabelas de dimensões, fatos e subdimensões da fonte de dados, como os data marts do Service Manager . A DSV contém todas as relações entre tabelas, como chaves primárias e estrangeiras. Em outras palavras, a DSV especifica como o banco de dados do SSAS será mapeado para o esquema relacional e fornece uma camada de abstração por sobre o banco de dados relacional. Usando esse camada de abstração, podem ser definidas relações entre tabelas de fatos e de dimensões, ainda que nenhuma relação exista no banco de dados relacional de origem. Também podem ser definidos na DVS cálculos nomeados, medidas personalizadas e novos atributos que podem não existir nativamente no esquema dimensional do data warehouse. Por exemplo, um cálculo nomeado que define um valor booliano para Incidents Resolved calculará o valor como verdadeiro se um status de incidente for resolvido ou fechado. Usando o cálculo nomeado, o Service Manager pode definir uma medida para exibir informações úteis, como a porcentagem de incidentes resolvidos, o número total de incidentes resolvidos e o número total de incidentes que não estão resolvidos.

Outro exemplo rápido de um cálculo nomeado é ReleasesImplementedOnSchedule. Esse cálculo nomeado faz uma rápida verificação do status de integridade na série de registros de liberação cujas datas finais são menores ou iguais à data final agendada.

Cubos OLAP

Um cubo OLAP é uma estrutura de dados que supera limitações de bancos de dados relacionais, proporcionando rápida análise de dados. Os cubos OLAP podem exibir e somar grandes volumes de dados, embora também forneçam aos usuários acesso pesquisável a quaisquer pontos de dados, para que os dados possam ser acumulados, decompostos e analisados, conforme a necessidade para tratar da maior variedade de questões relevantes à área de interesse do usuário.

Dimensões

Uma dimensão no SSAS faz referência a uma dimensão do data warehouse do Service Manager . No System Center 2012 - Service Manager, uma dimensão é, grosso modo, equivalente a uma classe de pacote de gerenciamento. Cada classe de pacote de gerenciamento possui uma lista de propriedades, ao passo que cada dimensão contém uma lista de atributos, sendo cada atributo mapeado para uma propriedade em uma classe. As dimensões permitem filtrar, agrupar e rotular os dados. Por exemplo, você pode filtrar computadores por sistema operacional instalado e agrupar pessoas em categorias por sexo ou idade. Em seguida, os dados podem ser apresentados em um formato no qual são classificados naturalmente por essas hierarquias e categorias, para permitir uma análise mais aprofundada. As dimensões também possuem hierarquias naturais para permitir que os usuários façam “drill down” em níveis mais detalhados. Por exemplo, a dimensão Data possui uma hierarquia que pode ser detalhada sucessivamente por Ano, Trimestre, Mês, Semana e Dia.

A ilustração a seguir mostra um cubo OLAP que contém as dimensões de Data, Região e Produto.

Por exemplo, os membros da equipe Microsoft podem querer um resumo rápido e simples das vendas do console de jogos do Xbox 360 em 2010. Eles podem detalhar ainda mais para obter números de vendas para um período de tempo mais direcionado. Os analistas de negócios podem querer examinar de que modo as vendas de consoles Xbox 360 foram afetadas pelo lançamento de novas experiências, como o console com novo design e o jogo sem controlador Kinect para Xbox 360. Isso ajuda a determinar quais tendências de vendas estão ocorrendo e quais são as possíveis revisões necessárias à estratégia de negócios. Por meio da filtragem na dimensão Data, essas informações podem ser rapidamente fornecidas e consumidas. Essa segmentação e análise de dados é possível somente porque as dimensões foram projetadas com atributos e dados que podem ser facilmente filtrados e agrupados pelo cliente.

No System Center 2012 - Service Manager, todos os cubos OLAP compartilham um conjunto comum de dimensões. Todas as dimensões utilizam o data mart do data warehouse primário como fonte, mesmo em cenários com vários data marts. Em cenários com vários data marts, isso pode, possivelmente, levar a erros de chave de dimensão durante o processamento do cubo.

Grupo de medidas

Um grupo de medidas tem o mesmo conceito que um fato em uma terminologia de data warehouse. Assim como fatos contêm medidas numéricas em um data warehouse, um grupo de medidas contém medidas para um cubo OLAP. Todas as medidas em um cubo OLAP derivadas de uma única tabela de fatos em uma exibição de fonte de dados também podem ser consideradas como um grupo de medidas. Pode haver ocasiões, entretanto, em que haverá várias tabelas de fatos das quais se derivam as medidas em um cubo OLAP. Medidas do mesmo nível de detalhe são unidas em um mesmo grupo de medidas. Grupos de medidas definem quais dados serão carregados no sistema, como os dados serão carregados e como os dados serão associados ao cubo multidimensional.

Cada grupo de medidas também pode conter uma lista de partições, que mantêm os dados reais em seções separadas e não sobrepostas. Os grupos de medidas também contêm design de agregação, que define os conjuntos de dados pré-resumidos que são calculados para cada grupo de medidas, para melhorar o desempenho das consultas do usuário.

Medidas

Medidas são os valores numéricos que os usuários desejam segmentar, dividir, agregar e analisar; são um dos motivos fundamentais de se construir cubos OLAP usando a infraestrutura de data warehouse. Usando SSAS, você pode construir cubos OLAP que se aplicarão às regras de negócios e aos cálculos para formatar e exibir medidas em um formato personalizado. Boa parte de seu tempo no desenvolvimento de cubos OLAP será gasto determinando e definindo quais medidas serão exibidas e como elas serão calculadas.

Medidas são valores que, geralmente, são mapeados para colunas numéricas em uma tabela de fatos do data warehouse, mas também podem ser criadas em atributos de dimensão e de dimensão de degeneração. Essas medidas são os valores mais importantes de um cubo OLAP que são analisados e são o principal interesse dos usuários finais que pesquisam o cubo OLAP. Um exemplo de uma medida que existe no data warehouse é ActivityTotalTimeMeasure. ActivityTotalTimeMeasure é uma medida de ActivityStatusDurationFact que representa o tempo que cada atividade permanece em um determinado status. O nível de detalhe de uma medida é composto por todas as dimensões que são referenciadas. Por exemplo, o nível de detalhe do fato de relação ComputerHostsOperatingSystem consiste nas dimensões Computador e Sistema Operacional.

Funções de agregação são calculadas sobre as medidas para permitir ainda mais análise dos dados. A função de agregação mais comum é a Soma. Por exemplo, uma consulta comum de cubo OLAP soma o tempo total de todas as atividades que estão In Progress. Outras funções de agregação comuns incluem Mín., Máx. e Contagem.

Depois que os dados brutos são processados em um cubo OLAP, os usuários podem executar consultas e cálculos mais complexos usando expressões multidimensionais (MDX) para definirem suas próprias expressões de medida ou membros calculados. MDX é um padrão do setor para consulta e acesso a dados armazenados em sistemas OLAP. O SQL Server não foi projetado para trabalhar com o modelo de dados com suporte a bancos de dados multidimensionais.

Busca detalhada (drill down)

Quando faz uma busca detalhada de dados em um cubo OLAP, o usuário está analisando os dados em um nível diferente de resumo. O nível de detalhe dos dados muda conforme o usuário vai detalhando a busca, examinando os dados em diferentes níveis na hierarquia. À medida que detalha sua busca, o usuário passa de informações resumidas para dados mais focados. Encontram-se, a seguir, exemplos de busca detalhada (drill down):

• Fazer uma busca detalhada nos dados para examinar informações demográficas sobre a população dos Estados Unidos, depois sobre o Estado de Washington, depois sobre a área metropolitana de Seattle, depois sobre a cidade de Redmond e, por fim, sobre a população na Microsoft.

• Fazer uma busca detalhada sobre os números das vendas de consoles Xbox 360 no ano civil de 2011, depois no quarto trimestre do ano, depois no mês de dezembro, depois na semana anterior ao Natal e, por fim, na Véspera de Natal.

Drill-through

Quando os usuários executam uma consulta "drill-through”, eles desejam ver todas as transações individuais que contribuíram para os dados agregados do cubo OLAP. Em outras palavras, o usuário pode recuperar os dados em um menor nível de detalhe para um respectivo valor da medida. Por exemplo, ao receber os dados de vendas de um determinado mês e a categoria de produto, você pode executar uma consulta drill-through desses dados para ver uma lista de cada linha da tabela que está contida nessa célula de dados.

É comum os termos “drill down” e “drill-through” serem confundidos. A principal diferença entre eles é que a busca detalhada (drill down) opera em uma hierarquia de dados pré-definida — por exemplo, EUA, depois Washington, depois Seattle — dentro do cubo OLAP. Uma consulta drill-through vai diretamente ao menor nível de detalhe dos dados e recupera um conjunto de linhas dessa fonte de dados, que foram agregados em uma única célula.

Indicador chave de desempenho

As organizações utilizam KPIs (indicadores chave de desempenho) (para indicar a integridade de seus negócios e seu desempenho, medindo seu progresso em relação às metas. Os KPIs são métricas de negócios que podem ser definidas para monitorar o progresso em relação a certos objetivos e metas predefinidos. Um KPI geralmente possui um valor fixado e um valor real, que representa uma meta quantitativa crítica para o sucesso da organização. Os KPIs geralmente são exibidos em grupos em um scorecard para mostrar a integridade geral dos negócios em um instantâneo rápido.

Um exemplo de KPI seria concluir todas as solicitações de alteração dentro de 48 horas. Um KPI pode ser usado para medir a porcentagem de solicitações de alteração resolvidas dentro desse período. Você pode criar painéis para representar KPIs visualmente. Por exemplo, pode ser conveniente definir um valor fixado de KPI de até 75% para a conclusão de todas as solicitações de alteração dentro de 48 horas.

Partições

Uma partição é uma estrutura de dados que mantém alguns ou todos os dados em um grupo de medidas. Cada grupo de medidas é dividido em partições. Uma partição define um subconjunto dos dados de fatos que estão carregados no grupo de medidas. O SSAS Standard Edition permite uma única partição por grupo de medidas, ao passo que o SSAS Enterprise Edition permite que um grupo de medidas contenha várias partições. Partições são um recurso transparente ao usuário final, mas têm maior impacto sobre o desempenho e a escalabilidade dos cubos OLAP. Todas as partições de um grupo de medidas sempre existem no mesmo banco de dados físico.

As partições possibilitam que um administrador gerencie melhor um cubo OLAP e aprimore o desempenho de um cubo OLAP. Por exemplo, você pode remover ou reprocessar os dados em uma partição de um grupo de medidas sem afetar o restante do grupo de medidas. Quando você carrega novos dados em um tabela de fatos, apenas as partições que devem conter os novos dados são afetadas.

O particionamento também melhora o desempenho de consulta e processamento de cubos OLAP. O SSAS pode processar várias partições paralelamente, levando a um uso muito mais eficiente dos recursos de memória e da CPU no servidor. Ao mesmo tempo que executa uma consulta, o SSAS também busca, processa e agrega dados de várias partições. Somente partições que contêm os dados relevantes para uma consulta são verificados, o que reduz a quantidade geral de entrada e saída.

Um exemplo de uma estratégia de particionamento é colocar os dados de fato para cada mês em uma partição mensal. No fim de cada mês, todos os novos dados entram em uma nova partição, levando a uma distribuição natural de dados com valores não sobrepostos.

Agregações

As agregações em um cubo OLAP são conjuntos de dados resumidos antecipadamente. Eles são análogos a uma instrução SQL SELECT com uma cláusula GROUP BY. O SSAS pode usar essas agregações quando responde perguntas para reduzir a quantidade de cálculos necessários, retornando as respostas rapidamente ao usuário. Agregações internas no cubo OLAP reduzem a quantidade de agregação que o SSAS tem para executar no momento da consulta. A criação das agregações corretas pode melhorar drasticamente o desempenho da consulta. Isso geralmente é um processo evolutivo em todo o ciclo de vida útil do cubo OLAP, pois suas consultas e uso são alterados.

Um conjunto base de agregações geralmente é criado e será útil para a maioria das consultas do cubo OLAP. As agregações são criadas para cada partição de um cubo OLAP em um grupo de medidas. Quando uma agregação é criada, determinados atributos de dimensões são incluídos no conjunto de dados resumido anteriormente. Os usuários podem consultar rapidamente os dados com base nessas agregações quando navegam no cubo OLAP. As agregações devem ser cuidadosamente criadas, pois o número de agregações possíveis é tão grande que a criação de todas elas levaria um tempo e espaço de armazenamento não aceitável.

Service Manager usa as duas opções a seguir ao criar e projetar agregações nos cubos OLAP do Service Manager :

• Ganhos de Desempenho

• Otimização Baseada no Uso

A opção Ganhos de Desempenho define a porcentagem de agregações que é criada. Por exemplo, definir essa opção como o valor padrão e recomendado de 30% significa que as agregações serão criadas para proporcionar ao cubo OLAP um ganho estimado de desempenho de 30%. No entanto, isso não significa que 30% das agregações possíveis serão criadas.

A otimização baseada no uso possibilita que o SSAS registre as solicitações de dados, de forma que quando uma consulta for executada, as informações entrarão no processo de design de agregação. Em seguida, o SSAS revisa os dados e recomenda quais agregações devem ser criadas para proporcionar o melhor ganho estimado de desempenho.

Personalizando o Data Warehouse