OLTP e OLAP - É de comer? Se for, me serve um de cada!

Faaaala, galera! Tudo bem com vocês? Tenho certeza que o titulo desse post te despertou curiosidade! E não, não são de comer! ( hehe ). Hoje eu quero te explicar sobre esses dois ambientes de banco de dados (SQL Server, por exemplo), o que são cada um deles, qual a finalidade e como combinar os dois.

Vamos começar com o ambiente OLTP (Online Transaction Processing), ou simplesmente "ambiente transacional" que é o banco de dados que as aplicações conectam no dia a dia para inserir, alterar e excluir dados. Esse é o ambiente principal e mais comum quando pensamos em um sistema/aplicação seja ela desktop, web ou até mesmo aplicativo mobile.

Pensando em um ambiente de banco de dados SQL Server, você tem lá o banco oficial da aplicação que é usada pelos usuários o dia todo, inserem as movimentações, alteram cadastros, vida real mesmo.

* Aplicação envia e solicita dados o tempo todo para o banco SQL Server.

O segundo ambiente é o OLAP (Online Analytical Processing), local específico para realizar análises de dados, com a crescente que estamos hoje de projetos de BI esse ambiente tem se tornado cada vez mais necessário nas empresas. Consiste em um ambiente separado do oficial(OLTP), caracterizado pelo que chamamos de Data Warehouse (que pode ser um banco de dados SQL Server também, mas nesse caso como se fosse um repositório de dados), existem algumas outras possibilidades também como criar um ambiente de análise de dados com uma replicação do banco oficial, mas conceitualmente a boa prática recomenda a criação de um Data Warehouse (claro que isso vai variar de caso pra caso, custos, tamanho do projeto, mas vamos assumir aqui como um excelente ponto de partida a criação do DW). A engenharia de dados permite também a criação de "pipelines de dados" em um outro conceito que não vem ao caso aqui nesse post, será assunto para um próximo.

Nesse cenário as aplicações de análise de dados apenas consomem os dados do Data Warehouse.

Até aqui você já entendeu cada um dos dois ambientes, para o que são utilizados, mas, saiba que existe um grande problema que ocorre muito hoje, na minha visão primeiro por falta de conhecimento de processo dos profissionais envolvidos nos projetos (nem sempre tem DBA na parada) e segundo porque não existe uma preocupação com a sustentação do projeto, se olha muito para o resultado final apenas (Dashboards bonitos e tal, nada contra, mas devemos ter atenção a isso).

Dá uma olhada na imagem abaixo, isso é muito comum de se encontrar por aí. Os "dois ambientes em um", você tem um banco de dados SQL Server que é o principal que a aplicação utiliza, ou seja, você tem os usuários inserindo, alterando e excluindo dados dela o tempo todo e ao mesmo tempo, o projeto de BI esta acessando essa mesma base para ler os dados e gerar os dashboards de análise de dados. Em algum momento esse ambiente vai ficar muito crítico, isso se não parar.

Geralmente, processos de análise de dados são pesados e esse consumo esta indo direto para o banco de produção da aplicação, é muito provável que os usuários da aplicação comecem a sentir problemas de performance no uso das telas e processos do sistema.

Qual o caminho então para usar um cenário que não tenha esse tipo de problema de sobrecarregar o ambiente de forma que tanto a aplicação com os usuários quanto o processo de análise de dados possam trabalhar de forma independente sem um afetar o outro? Vamos combinar os dois ambientes.

Primeiro passo é que é necessário ter ao menos um outro servidor para subirmos um segundo ambiente SQL Server, nesse segundo ambiente pode ser criado o Data Warehouse (vou chamar de DW a partir daqui para facilitar, ok?) e no meio dos dois ambiente temos um processo chamado ETL (Extract, Transform, Load), esse processo é fundamental para que tudo funcione. Ele fica responsável por se conectar na base principal do sistema (OLTP) e copiar os dados que precisam ser analisados, depois da cópia existe a etapa da transformação, que é onde existe a possibilidade de tratar esses dados copiados da base oficial, aplicar regra de negócio neles, formatar de outra maneira, enfim, o que o pessoal do BI precisar e por fim na terceira fase do ETL ele "despeja" esses dados (agora tratados) no DW. Assim, as aplicações de análise de dados se conectam na base DW para ler o que precisa e gerar os dashboards. Nesse caso temos dois processos separados, os dois ambientes cumprindo perfeitamente o seu papel e principalmente, sem concorrer um com o outro.

Bacana não é?!?! Em alguns casos o ETL pode entregar os dados para um Data Lake (mas isso também não é assunto para esse post, apenas menciono para que você saiba).

Talvez você possa estar se perguntando, a análise dos dados aí nesse exemplo não seria em tempo real então? E a resposta mais simples é Não! O processo de ETL pode ser automatizado/agendado mas geralmente roda poucas vezes no dia, se for preciso mais ai já precisa se atentar em relação aos recursos do ambiente.

O ETL pode ser feito de várias formas, desde a mais simples com um JOB, por exemplo, ou até usar um pacote no Integration Service para criar um fluxo de tarefas que trata os dados e entrega no destino final.

É claro que para criar um ambiente dessa maneira não é algo que ocorre do dia pra noite, mas o DBA SQL Server precisa ter esse conhecimento para orientar e sugerir aos clientes esse tipo de solução. Isso traz mais disponibilidade para o banco de dados e da também mais corpo para que o projeto ande bem por mais tempo. Veja na ilustração abaixo o fluxo sugerido aqui no nosso exemplo.

1 - Usuários inserem dados no banco oficial

2 - Processo de ETL é iniciado

3 - Dados que serão analisados são copiados

4 - Ocorre a transformação desses dados "brutos" que chegaram de forma que eles possam ser usados para gerar valor para a empresa

5 - Armazenado no DW

6 - Aplicações de análise de dados consomem esses dados no DW

O DBA SQL Server pode ser o responsável por configurar todo esse processo do início ao fim, por isso é importante que você conheça sobre o assunto!

Gostou do post? Compartilha com seus colegas que querem ser um DBA SQL Server! Nos acompanhe em nossas redes sociais! Grupo VIP Telegram: DBA On boarding Youtube(vídeos novos todas as quartas): DBA On boarding Face & Instagram(conteúdo diário): DBA On boarding Até a próxima, tchau!

#comunidadebd