O cinto de utilidades ETL

 Na postagem anterior, ficaram algumas questões a serem respondidas. Para responder a estas questões, vamos criar um cenário hipotético.

A empresa na qual você trabalha demandou a criação de uma base de dados OLAP para subsidiar um Data Warehouse. Essa empresa possui dois Sistemas OLTP para apoiar o trabalho desempenhada por ela: Um sistema de gestão administrativo no qual são mantidos o cadastro dos funcionários entre outros e outro sistema de gestão para gerir vendas efetuadas pela Empresa. Ao demandar a criação da base OLAP, o solicitante indicou aonde obter aos dados que irão compor a base em questão, com a finalidade de analisar as vendas efetuadas pelos funcionários da Empresa. Parte dessas informações encontram-se na base de dados que subsidia o sistema administrativo. Outra parte, pode ser obtida na base de dados do sistema que subsidia o sistema de vendas e ainda há informações constantes em planilhas preenchidas pelos vendedores e por seus gerentes.

Daí você pensa: Vou fazer um select desses dados nas bases de dados indicadas e fazer um insert no banco de dados OLAP. Simples assim! Simples? Como fica a questão das planilhas? E ainda como vincular as informações extraídas desses sistemas e das planilhas mencionadas? Além disso, verificou-se que os dados contidos nessas bases de origem possui formatos distintos, ou seja, não seguem um padrão único. 

Chega a fazer a gente pensar que com a solução do Select/Insert é impossível resolver essa questão. Impossível não é, mas daria um "trabalhão" danado. Ainda mais, se levássemos em consideração a atualização periódica dessa base OLAP.

Complicou, né? E para descomplicar, surgiram no mercado ferramentas que fazem esse trabalho de Extração, Tranformação e carga dos dados.

ETL, vem do inglês Extract Transform Load, ou seja, Extração Transformação Carga. O ETL visa trabalhar com toda a parte de extração de dados de fontes externas, transformação para atender às necessidades de negócios e carga dos dados dentro do Data Warehouse. 

Abaixo, uma ilustração do processo

Vamos descrever as atividades envolvidas nesse processo:

Na extração, é feita a coleta de dados dos sistemas de origem , extraindo-os e transferindo-os para o ambiente de DW, permitindo ao sistema de ETL operar sobre os dados de forma independente.

 Na etapa de transformação, é feita a limpeza, os ajustes e a consolidação dos dados ingeridos. É nesta etapa que realizamos os devidos ajustes, podendo assim melhorar a qualidade dos dados e consolidar dados de duas ou mais fontes. O estágio de transformação aplica uma série de regras ou funções aos dados extraídos para ajustar os dados a serem carregados. Algumas fontes de dados necessitarão de muito pouca manipulação de dados. Em outros casos, pode ser necessários trabalhar algumas transformações, como por exemplo, junção de dados provenientes de diversas fontes, seleção de apenas determinadas colunas e tradução de valores codificados. Por exemplo, se o sistema de origem armazena 1 para sexo masculino e 2 para feminino, mas o data warehouse armazena M para masculino e F para feminino.

A entrega ou Carga dos dados, consiste em fisicamente estruturar e carregar os dados para dentro da camada de apresentação seguindo o modelo dimensional. Dependendo das necessidades da organização, este processo varia amplamente. Alguns data warehouses podem substituir as informações existentes semanalmente, com dados cumulativos e atualizados, ao passo que outro DW (ou até mesmo outras partes do mesmo DW) podem adicionar dados a cada hora. A latência e o alcance de reposição ou acréscimo constituem opções de projeto estratégicas que dependem do tempo disponível e das necessidades de negócios. 

Há ainda a parte de Gerenciamento que é composta por serviços para auxiliar no gerenciamento do DataWarehouse. Aqui existem tasks específicas para gerenciamento de jobs, planos de backup, verificação de itens de segurança e compliance.

A intenção aqui, era fazer um overview sobre o assunto. Existem diversas ferramentas deste tipo no mercado. Cabe a vocês pesquisarem sobre elas:

• Data Stage da IBM 
• PowerCenter da Informatica
• Data Integrator da Oracle
• SSIS – Sql Server Integration Services da Microsoft

Hoje com o crescimento dos projetos de Big Data aumenta-se mais ainda a necessidade de fazer ETL entre plataformas heterogêneas, para isso, projetos como o Hadoop, possuem ferramentas próprias para carga de dados, como :

SQOOP – Ferramenta para movimentar dados dentre bancos de dados relacionais e o ambiente Hadoop.

HIVE – Ambiente de SQL sobre um cluster Hadoop.

PIG – Ferramenta de Script para transformação e processamento de dados.

SPARK – Framework de processamento em memoria.

É isso!

Modelagem dimensional na prática

 Em outro post, tentei desmistificar o conceito de Data warehouse. Voltando a ler o Post, senti falta de um exemplo prático que mostrasse as vantagens e desvantagens de modelar de forma dimensional uma base de dados para atender a um DW.  A ideia deste post é tentar apresentar uma resposta a estas questões.

Conforme mencionado no outro post, o DW visa resolver questões de performance na execução das consultas.  E como se resolve isso? A forma encontrada foi modelar a base de um jeitão meio diferente, o que ficou conhecido como Modelagem dimensional.

A Modelagem dimensional é uma técnica de design de banco de dados projetada para suportar consultas de usuários finais em um Data Warehouse.  

A ideia é que os usuários consigam fazer consultas sem necessitar da ajuda de profissionais especializados em SQL. 

Em modelos relacionais, é prezada a questão da normalização. Na modelagem dimensional, para melhorar o desempenho das consultas, há redundância planejada dos dados, compensando os gastos com armazenamento e atualização das informações, fazendo com o que a base de dados fique de certo modo desnormalizada.

O modelo dimensional é composto por tabelas fato e por tabelas conhecida como dimensões.

Na prática, a tabela fato armazena as chaves das dimensões e armazena também as métricas a serem analisadas por quem vier a consultar o DW.

Já as tabelas de dimensão são compostas basicamente de atributos que descrevem as entidades envolvidas no modelo. 

Modelando desta forma, o modelo fica parecido com uma "estrela"

Nesse modelo os dados são desnormalisados para evitar joins entre tabelas, diminuindo o tempo de consultas, no entanto devido a repetição de dados, utiliza mais espaço em disco. A vantagem desse modelo é a eficiência na extração de dados, o que é um grande diferencial em se tratando de um datawarehouse.

A chave da tabela fato é uma chave composta, uma vez que trata-se da junção das chaves das tabelas de dimensão.

Importante também é não misturar os fatos. Exemplo: A finalidade é analisar o volume de vendas? Devemos criar uma tabela fato específica para isso. Ao analisar o volume de compras, deve-se criar outra tabela fato com essa finalidade.

Quando a quantidade de atributos das dimensões é muito grande,  costuma-se normalizar as tabelas de dimensão. Neste caso, o modelo fica parecendo um floco de neve (Snow Flake ). Isto porque cada tabela de dimensão seria normalizada, "quebrando-se" a tabela original ao longo de hierarquias existentes em seus atributos. 

A adoção de um modelo ou de outro de implementação trás vantagens e desvantagens em relação a performance das consultas e volume de armazenamento dos dados. Cabe aos analistas decidirem qual será a melhor abordagem.

Cheguei a conclusão de que a melhor maneira de entender a modelagem dimensão é através de exemplos. Abaixo coloquei alguns exemplos de modo a clarear o entendimento deste tipo de modelagem.

Exemplo de um modelo conceitual

Exemplo de modelo para análise de despesas

Exemplo de modelo para análise de produção

A dica aqui é procurar nos pais dos burros (Google) mais modelos de modo a fixar a ideia desse tipo de modelagem.

Como entrevistar os usuários de um DW? Segue um texto legal do Piton nesse link https://rafaelpiton.com.br/blog/data-warehouse-como-modelar/

E aí? O post deu uma clareada? Em caso afirmativo, fico satisfeito. Tem outras questões a serem respondidas. Como importar os dados da origem de dados que comporão as tabelas do DW? Como atualizar esses dados ao longo do tempo? Se os dados que vierem compor o DW provierem de fontes de dados distintos, com formatos diferentes, como unificar o padrão desses dados? A resposta a essas perguntas estará em outro post sobre ETL.

Valeu!!!