Um BI em tempo real não significa um DW em tempo real…

“…a inteligência de negócios em tempo real não é a mesma coisa que Data Warehousing em tempo real, ter um não significa ter o outro.”… 

por Peter Scott da Rittman Mead Consulting. 

Um dos pontos em que eu toco no início da minha palestra “Carregando o DW na Hora em que a Informação Acontece” é que a inteligência de negócios em tempo real não é a mesma coisa que Data Warehousing em tempo real, ter um não significa ter o outro.

As pessoas podem fazer, e, de fato, várias fazem, o direcionamento de seus relatórios de BI para os sistemas transacionais de origem e, para essas pessoas, não há Data Warehouse envolvido. Inversamente outros populam seus Data Warehouses continuamente em tempo real através de uma rotina de recuperação, digamos de ‘gotejamento’, cada vez que temos uma nova ‘gota’ de informação o processo de carga é iniciado, pois esse é o único jeito de carregar os dados em tempo real, ou seja, quando eles acontecem, mas optam por manter os relatórios alinhados a eventos ocorridos no passado (como até a meia noite de ontem) para que os usuários vejam as alterações ocorridas hoje apenas no dia seguinte.

Então, se é possível fazer BI em tempo real diretamente nos sistemas de origem, por que ter o Data Warehouse? Na minha opinião, processos de Data Warehouse significam três procedimentos: proteger a fonte transacional de excessivas consultas potencialmente ‘pesadas’, prejudicando a performance do sistema OLTP, agir como uma plataforma para se conformar dados de vários sistemas de origem e permitir o uso de informações que tenham as chamadas ‘alterações lentas’ (SCD) e necessitem de históricos.

Assumindo que precisamos BI em tempo real, mas não um Data Warehouse em tempo real, precisaremos misturar funcionalidades transacionais e analíticas (relatórios) no mesmo ‘sistema’. Embora se possa argumentar que um sistema como o da Oracle Exadata V2 permite ‘misturar’  relatórios analíticos e cargas de trabalhos transacionais, poucas empresas têm o Exadata implementado e ainda assim, para muitas pessoas isso significa que eles estão misturando duas cargas de trabalho distintas em uma plataforma projetada para uma carga de trabalho. Operações DML que são projetados para inserir ou atualizar uma única linha o mais rápido possível são misturados com consultas que acessam um grande número de linhas com base em uma combinação de predicados que pode muito bem não ser indexados no sistema OLTP. Além disso, algumas das características do banco de dados que auxiliam o desempenho em um Data Warehouse, como índices bitmap e consulta paralela pode realmente inibir o desempenho dos sistemas transacionais. O problema fundamental da carga de trabalho ‘misturada’ é que, se o recurso está ocupado fazendo uma coisa não está, portanto, disponível para fazer outra coisa e o desempenho para todos os usuários sofre.

Algumas ‘coisas’ podem ser feitas para reduzir o impacto da consulta BI nos sistemas de origem. Podemos usar o conceito de federação de dados em uma ferramenta de geração de relatórios, como Oracle Business Intelligence Enterprise Edition – OBIEE e restringir a fonte transacional a dados atuais, além de usar um DW separado, talvez com dados pré-agregados para fornecer informações históricas, eliminando a necessidade de repetidamente acessar toda a base de dados do sistema transacional, reduzindo o volume dos dados acessados e com isso diminuir o conflito com a atividade transacional.

Claro que ainda precisamos de um processo que atualize o DW, mas que agora pode ser adiado para um momento posterior. No entanto, a federação tem suas desvantagens, onde antes tínhamos apenas uma consulta agora temos duas e os resultados dessas duas consultas precisam ser unidos e esse processo tem que acontecer no servidor de BI, consumindo memória e recursos de processamento para se juntar os conjuntos de resultados.

Outra coisa que poderíamos fazer seria usar um banco de dados de backup ou réplica para ser a fonte de informação analítica, reduzindo assim o impacto sobre a fonte transacional (mas não eliminá-lo totalmente, pois qualquer tipo de replicação tem algum impacto, uma vez que irá envolver algum processo em execução a favor ou contra a fonte). Nós poderíamos usar uma instância de espera do sistema OLTP (standby instance usado para crash recovery, por exemplo) para os relatórios analíticos, mas precisamos considerar os requisitos de licenciamento da réplica, a localização da réplica (pode ser em um local diferente) e o que acontecerá se precisarmos utilizar o sistema de espera (standby instance) para o seu real propósito de continuidade de negócios, – perderemos o BI quando isso acontecer?

Talvez uma melhor abordagem seja a construção de uma réplica do banco, para os relatórios analíticos específicos. Esta réplica pode ter o tamanho certo e ter o licenciamento de produtos apropriados para uma carga de relatórios analíticos. Não tem que ser réplica completa do sistema de origem, apenas das tabelas de interesse, se não temos interesse em consultas/relatórios no assunto auditoria, por exemplo, as tabelas de auditoria e log (journal), referentes a esse assunto não precisam ser replicadas.

Na verdade, podemos sofisticar essa réplica para os relatórios analíticos fazendo as mudanças no banco de dado de modo a ficar com uma melhor orientação OLAP, o que pode incluir a exclusão de índices inúteis e possivelmente de particionamento dos dados para permitir uma melhor expurga dos dados. A adição de índices bitmap pode ser um passo mais adiante, uma vez que estamos, essencialmente, recebendo as atualizações e inserções linha por linha, o que resulta em uma menor ocorrência de bloqueio de tabelas, como ocorre com as mudanças nos índices bitmaps.

Podemos até combinar a abordagem federado com uma réplica do banco de dados e usar a réplica como fonte para as transações recentes e Data Warehouse para os dados históricos, e se optarmos por implementar a nossa réplica em um banco de dados rápido, poderemos obter um excelente desempenho com baixo impacto sobre a fonte transacional.

Até a próxima!!!

Publicado em DW/BI. 3 Comments »

3 Respostas to “Um BI em tempo real não significa um DW em tempo real…”

  1. Rodrigo Says:

    Este blog tem informações sérias, atualizadas e úteis na identificação de soluções técnicas.
    Obrigado Lito!
    Rodrigo

  2. Ioshiori Kuba Says:

    Acredito que DW / BI em tempo real terá forte abordagem nos negócios, permitindo a comunicação imediata com seus clientes, oferecendo serviços e produtos no tempo “certo”.

  3. Thiago Says:

    De uma certa forma, poderiamos utilizar uma stage area para trabalhar com os relatórios analiticos?
    Uma vez que esta ocasionalmente fica ociosa durante o período comercial.


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: