iT-Tech
Gostaria de reagir a esta mensagem? Crie uma conta em poucos cliques ou inicie sessão para continuar.
Últimos assuntos
» Cálculo de horas extras
ETL – Extração, Transformação e Carga de Dados EmptySex 13 Out - 10:25 por Felipe Naibert

» Exportar Arquivos em quantidades (blocos) fixos de linhas.
ETL – Extração, Transformação e Carga de Dados EmptyQui 20 Ago - 12:17 por Miro

» GRUPO DE ESTUDOS AUDIT ANALYTICS
ETL – Extração, Transformação e Carga de Dados EmptyTer 9 Jun - 9:22 por Miro

» Cálculo do número da Semana no ano
ETL – Extração, Transformação e Carga de Dados EmptySeg 11 maio - 11:18 por Miro

» A ordem dos argumentos altera o tempo de processamento
ETL – Extração, Transformação e Carga de Dados EmptyQui 23 Abr - 14:50 por Miro

» Como pegar dados únicos de um campo?
ETL – Extração, Transformação e Carga de Dados EmptySeg 23 Fev - 19:33 por Fernanda

» Existe algum comando no Analyzer que eu realize as instruções do SQL?
ETL – Extração, Transformação e Carga de Dados EmptyQua 18 Fev - 9:22 por Raphael Moita Bertolino

» Lei de Benford: How Forensic Accountants Use Benford's Law To Detect Fraud
ETL – Extração, Transformação e Carga de Dados EmptyQua 24 Dez - 7:53 por Márcia

» Importação de PDF
ETL – Extração, Transformação e Carga de Dados EmptyTer 9 Dez - 13:23 por Fernanda


ETL – Extração, Transformação e Carga de Dados

Ir para baixo

ETL – Extração, Transformação e Carga de Dados Empty ETL – Extração, Transformação e Carga de Dados

Mensagem  Raphael Moita Bertolino Qua 15 Ago - 10:17

Fase extremamente critica de um Data Warehouse, pois envolve a movimentação dos dados de origem nos sistemas transacionais e/ou sistemas legados, obedecendo as regras de negócio. A mesma se dá basicamente em três passos, extração (E), transformação (T) e carga (L – Loader) dos dados, esses são os mais trabalhosos, complexos e também muito detalhados, embora tenhamos várias ferramentas (falaremos mais abaixo) que nos auxiliam na execução desse trabalho.

O primeiro passo a ser tomado no processo de ETL: a definição das fontes de dados e fazer a extração deles.

As origens deles podem ser várias e também em diferentes formatos, onde poderemos encontrar desde os sistemas transacionais das empresas até planilhas, flat files (arquivos textos) , dados do Mainframe, etc.
O segundo passo: transformar e limpar esses dados. Mas, o que, afinal de contas, é isso?

É muito comum, na obtenção dos dados que, no mais das vezes, são antigos e desconhecidos, encontrarmos muito ‘lixo’ e inconsistências. Por exemplo. Quando um vendedor de linhas telefônicas for executar uma venda, ou inscrição, ele está preocupado em vender, e não na qualidade dos dados que está inserindo na base, então se por acaso o cliente não tiver o número do CPF a mão, ele cadastra um número qualquer, desde que o sistema aceite, um dos mais utilizados é o 999999999-99. Agora imagine um diretor de uma companhia telefônica consultar o seu Data Warehouse (DW) para ver quais são os seus maiores clientes, e aparecer em primeiro lugar o cliente que tem o CPF 999999999-99 ? Seria no mínimo estranho. Por isso, nessa fase do DW, fazemos a limpeza desses dados, para haver compatibilidade entre eles.
Além da limpeza, temos de fazer na maioria das vezes uma transformação, pois os dados provêm de vários sistemas, e por isso, geralmente uma mesma informação tem diferentes formatos, por exemplo: Em alguns sistemas a informação sobre o sexo do cliente pode estar armazenada no seguinte formato : “M” para Masculino e “F” para Feminino, porém em algum outro sistema está guardado como “H” para Masculino e “M” para Feminino, em outro ainda, podemos encontrar “1” para Masculino e “2” para Feminino, e assim sucessivamente. Quando levamos esses dados para o DW, deve-se ter uma padronização deles, ou seja, quando o usuário for consultar o DW, ele não pode ver informações iguais em formatos diferentes. Assim sendo, quando fazemos o processo de ETL, transformamos esses dados e deixamos num formato uniforme sugerido pelo próprio usuário, como por exemplo “M” para Masculino e “F” para Feminino. No DW, teremos somente M e F, fato esse que facilitará a análise dos dados que serão recuperados pela ferramenta OLAP.
Além desses exemplos acima, nós podemos integrar todas fontes de dados num único banco. Com isso não existirão mais “ilhas” de dados, mas sim teremos informações ricas e totalmente integradas.

Como o volume de dados é muito grande, há muitos casos que não temos condições de processar as extrações e transformações na janela de tempo em que o DW não está sendo usado, então temos de fazer uso do que chamamos de staging área para conseguirmos executar os processos com sucesso. Segundo Kimball, a Staging Area é parte do Data Warehouse responsável por receber a extração, transformação e carga (ETL) das informações dos sistemas transacionais legados, para posterior geração dos Data Marts de destino, com as características:

A Staging Area é considerada área fora do acesso dos usuários.
A Staging Area não deve suportar queries dos Usuários.
Ela pode ser composta por flat files (arquivos textos) ou tabelas de banco de dados na terceira forma normal (normalizadas).
A seguir são apresentados alguns dos fatores que devem ser analisados antes de começar a fase de extração dos dados:

A extração de dados do ambiente operacional para o ambiente de data warehouse demanda uma mudança na tecnologia. Os dados são transferidos de bancos de dados hierárquicos, tal como o adabas, ou de bases do grande porte, como o DB2, para uma nova estrutura de SGBD relacional para Data Warehouse, tal como o DB2 UDB, Oracle, Teradata e etc;
A seleção de dados do ambiente operacional pode ser muito complexa, pois muitas vezes é necessário selecionar vários campos de um sistema transacional para compor um único campo no data warehouse;
Outro fator que deve ser levado em conta é que dificilmente há o modelo de dados dos sistemas antigos, e se existem não estão documentados;
Os dados são reformatados. Por exemplo: um campo data do sistema operacional do tipo DD/MM/AAAA pode ser passado para o outro sistema do tipo ano e mês como AAAA/MM;
Quando há vários arquivos de entrada, a escolha das chaves deve ser feita antes que os arquivos sejam intercalados. Isso significa que se diferentes estruturas de chaves são usados nos diferentes arquivos de entrada, então deve-se optar por apenas uma dessas estruturas;
Os arquivos devem ser gerados obedecendo a mesma ordem das colunas estipuladas no ambiente de data warehouse;
Podem haver vários resultados. Dados podem ser produzidos em diferentes níveis de resumo pelo mesmo programa de geração das cargas;
Valores default devem ser fornecidos. As vezes pode existir um campo no data warehouse que não possui fonte de dados, então a solução é definir um valor padrão para estes campos.
O data warehouse espelha as informações históricas necessárias, enquanto o ambiente operacional focaliza as informações pontuais correntes. A parte de carga dos dados também possui uma enorme complexidade, e os seguintes fatores devem ser levados em conta:

A parte de Integridade dos dados. No momento da carga é necessário checar os campos que são chaves estrangeiras com suas respectivas tabelas para certificar-se de que os dados existentes na tabela da chave estrangeira estão de acordo com a tabela da chave primária;
Se a tabela deve receber uma carga incremental ou a carga por cima dos dados. A carga incremental normalmente é feita para tabelas fatos e a carga por cima dos dados é feita em tabelas dimensões onde o analista terá que deletar os dados existentes e incluí-los novamente. Mas em alguns casos poderá acontecer que as tabelas de dimensões tem de manter o histórico, então o mesmo deverá ser mantido (slowly change dimension);
Apesar de existirem ferramentas de ETL como o DTS (Data Transformation Service), Data Stage, ETI, Business Objects Data Integration, Sunopsis – atual Oracle Data Integrator, Oracle Warehouse Builder e o Informática, ainda tem-se a necessidade de criar rotinas de carga para atender determinadas situações que poderão ocorrer. Pode ser em shell script, SQL puro ou em C, quando precisa de performance.

As ferramentas de ETL mais utilizadas no mercado são o Data Stage da IBM, o ETI da ETI Corporation, Sagent da Group 1 Software, Informática Power Center da Informática, DTS da Microsoft, Pentaho (Open Source), Talend (Open Source), Sunopsis e o Oracle Warehouse Builder da Oracle. Todos tem os seus diferenciais e cada um poderá ser utilizado dependendo do caso de cada empresa. Algumas ferramentas tem a curva de aprendizado mais suave, outras um pouco mais íngrime, mas em certos casos mesmo sendo uma ferramenta de difícil aprendizado exigindo maiores investimentos em pessoal, serão compensados com a performance e flexibilidade da mesma. Há outras ferramentas que tem custo zero de aquisição pois, vem embutida junto com um SGBD (Sistema Gerenciador de Banco de Dados), mas em contrapartida são bastante limitadas no tocante a extração de dados e exigem uma maior codificação dos processos de ETL, em relação as outras e por fim tem as open source que, dependendo do porte do projeto, podem atender satisfatoriamente.

O que vale dizer é que uma ferramenta de ETL tem grande valia, principalmente se os sistemas OLTP (transacionais) são muitos, pois elas são uma poderosa fonte de geração de metadados, e que contribuirão muito para a produtividade da sua equipe, porém deve-se tomar muito cuidado ao escolhe-la. Seja minucioso, teste o máximo de ferramentas que puder e veja qual é a mais adequada ao seu caso, pois elas exigem um alto investimento, tanto em capacitação, quanto na própria aquisição. Em alguns casos é interessante o auxílio de profissionais externos para a escolha. O fato verdadeiro é que os benefícios serão bastante vistosos e a produtividade aumentará consideravelmente.

Fonte: http://litolima.com/2010/01/13/etl-extracao-transformacao-e-carga-de-dados/

Raphael Moita Bertolino

Mensagens : 26
Data de inscrição : 02/05/2012

Ir para o topo Ir para baixo

Ir para o topo

- Tópicos semelhantes

 
Permissões neste sub-fórum
Não podes responder a tópicos