OBIEE – Implementação de tabelas agregadas para desempenho de performance.

Share Button

A suíte do OBIEE possui uma implementação de tabelas agregadas através de uma construção nativa partindo do próprio Administrator Tool que você irá encontrar a partir da página 372 do livro Oracle Business Intelligence 11g Developers Guide do nosso guru Mark Rittman.

Entretanto, por questões de performance de processamento, em alguns ambientes com grande volume de dados, tive que construir as tabelas agregadas fisicamente no banco com seus respectivos índices e demais atribuições. Este tipo de configuração é realizado de forma peculiar no repositório de metadados, no qual estarei exemplificando neste artigo.

 

Case – Acompanhamento de Vendas:

Montei um exemplo simples de Data Warehouse de “Vendas” com poucas linhas de dados, onde tenho uma tabela fato com granularidade em nível de dia com três medidas: quantidade de produtos vendidos, preço unitário do produto e valor total da venda, todas analisadas por suas respectivas dimensões. Observe o modelo de dados que desenvolvi utilizando a ferramenta de designer Oracle Data Modeler:

 

Banco de Dados:

Exemplificando isso em consulta SQL através da ferramenta Oracle SQL Developer no banco de dados DW, temos o seguinte resultado a baixo, observe que as somas das medidas estão dispostas diariamente:

 

Repositório de Metadados (RPD):

No Administrator Tool a modelagem do RPD segue idêntica ao do modelo físico do banco de dados. Observe:

 

OBIEE:

Veja na imagem a seguir o resultado final das métricas de nossa tabela fato “Vendas” dispostos no nível de granularidade por dia. Observe que como no DW, em um único mês temos mais de um registro por dia:

 

Implementação:

No cenário ilustrado anteriormente, se o número de transações diárias for excessivamente alto, podemos ter um problema de performance no processo que o OBIEE executa no banco de dados para agregação das métricas. Devido a necessidade de ler muitas linhas de registro a cada execução de relatório ou dashboard.
Considerando que que muitas vezes, o menor nível (no caso o dia) não é o mais recomendado para ser é utilizado em relatórios gerenciais, uma vez que os conceitos de BI são voltados para uma visão macro do negócio inicialmente e os detalhes se expandem apenas em casos mais críticos.
Por isso estaremos implementando em nosso modelo, uma nova tabela fato em nosso banco de dados DW, com a informação das vendas agregada por mês.
Dessa forma, quando um relatório é executado no BI a query que a aplicação irá executar no banco de dados, ao invés de ler várias linhas e agrupá-las em um registro mensal irá apenas ler uma linha de registro por mês. Quando se trata de uma tabela fato com bilhões de registros, a melhoria de desempenho é bastante notável.

  • Modelo de Dados: A estrutura da nova tabela fato, que será agregada por mês é exatamente a mesma da tabela fato diária, o ideal é que a fato agregada ela faça os mesmos Joins (relacionamentos) com as dimensões da tabela fato dia. Observe o desenho do modelo de dados com a fato agregada:

 

  • Banco de Dados – DW: Fisicamente no banco de dados a querie que o BI irá executar retornará os dados em uma estrutura semelhante a imagem ilustrada abaixo. Observe que às medidas foram sumarizadas e agrupadas por mês. Geralmente essa tabela agregada depois de criada é carreada em uma etapa no fluxo de carga depois da carga da tabela fato diária. Em uma arquitetura como essa implementação de ETL é realizada através do client Oracle Data Integrator – ODI.

 

  • Repositório de Metadados – RPD: Nesta sessão é onde ocorrem as implementações para que as duas tabelas e os dois modelos trabalhem de forma coerente ao modelo de negócios. Na imagem a baixo temos a demonstração da camada semântica antes da implementação da tabela fato agregada. Observe que na camada do meio “Mapeamento de modelo de negócios” temos somente a “Fato Vendas Diária”.

Para realizar a implementação devemos primeiramente mapear os Joins da camada “Física” obedecendo o desenho do modelo de dados visto no tópico anterior:

Agora, o restante da implementação pode ser realizado de diversas formas, por exemplo, é possível criar um novo “Data Mart” para trazer a informação da tabela agregada, ou acrescentar a tabela agregada ao “Data Mart” existente. As customizações podem ser realizadas de acordo com a necessidade de negócio do cliente.

Neste case, preferi adotar somente às métricas agregadas ao “Data Mart” existente pois acredito que desta forma conseguimos manter uma camada de “Apresentação” mais limpa para o usuário final, sem redundâncias de informações. Para isso, iremos seguir os passos:

1 – Selecionar as colunas de medidas da tabela agregada existente na camada física do repositório.
2 – Renomear a Fato para “Fato Vendas” para que o nome fique mais coerente com a informação. Arrastar as colunas selecionadas para dentro dela.
3 – Renomeie as medidas cada uma com seu entendimento de negócio, diárias e mensais (Não esqueça de definir a regra de agregação).
4 – Observe que a fato passa a ter dois “Data Sources” pois está recendo medidas de duas tabelas diferentes (Fato Vendas Diária e Fato Vendas Mensal).
5 – Arraste as colunas modificadas para a camada de “Apresentação” do seu repositório, em seguida salve e publique seu RPD.

 

Resultados:

Na ilustração a seguir temos um relatório no OBIEE utilizando as métricas diárias do acompanhamento de vendas, mostrando o registro de vendas em seu menor nível de granularidade, relatórios assim são mais indicados para uma análise mais detalhada do evento de negócio em questão:

A seguir temos uma análise semelhante a anterior, porém utilizando as medidas da tabela fato agregada por mês, mostrando o histórico do padrão dos eventos ao longo dos meses. A consulta dessas informações já consolidadas retorna muito mais rápido o resultado no OBIEE, melhorando o desempenho e performance do banco de dados e da aplicação:

Carina Mendes.