tcc unime bsi trajano comparando ferramentas etl para dw
DESCRIPTION
TCC Unime BSI Trajano Comparando Ferramentas ETL Para DWTRANSCRIPT
UNIÃO METROPOLITANA DE EDUCAÇÃO E CULTURA - CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
TRAJANO CARLOS MONTASSIER NETO AVALIAÇÃO DAS FERRAMENTAS ETL OPEN-SOURCE TALEND E
KETTLE PARA PROJETOS DE DATA WAREHOUSE EM EMPRESAS DE PEQUENO PORTE
LAURO DE FREITAS 2012
TRAJANO CARLOS MONTASSIER NETO
AVALIAÇÃO DAS FERRAMENTAS ETL OPEN-SOURCE TALEND E
KETTLE PARA PROJETOS DE DATA WAREHOUSE EM EMPRESAS DE PEQUENO PORTE
Trabalho de Conclusão de Curso apresentado ao curso de Bacharelado em Sistema de Informações da UNIME, como requisito parcial para obtenção de grau de Bacharel em Sistema de Informação. Orientador: Professor Pablo Passos Nascimento.
LAURO DE FREITAS
2012
AGRADECIMENTOS
Em primeiro lugar, agradeço a Deus, que me deu forças e clareou o meu caminho,
ajudando-me a superar as dificuldades e os obstáculos, mas no final, fui presenteado por
este momento.
A minha Mãe Cecilia (in memoriam), a quem dedico essa realização e que, durante
muitos anos, foi para mim um exemplo de força e superação.
Um especial agradecimento a minha esposa, Rosangela e ao meu filho Vitor, que
me apoiaram em todos os momentos desta trajetória. Obrigado por compartilharem comigo
essa caminhada; sem essa força não seria possível chegar ao fim.
Igualmente agradeço aos meus tios Sylvio e Deolinda(in memoriam), sempre
presentes na minha vida e responsáveis por um apoio incondicional no momento em que
mais precisei no início de minha carreira profissional. Obrigado pelo carinho e o afeto que
têm me concedido.
Aos familiares e amigos, que estiveram ao meu lado ou de alguma forma fizeram
parte desta história, dando-me forças para superar e não desistir e ainda me ajudando a
esquecer as dificuldades desse percurso através dos momentos descontração e alegria em
que passamos juntos.
Também, não menos importante, meu agradecimento à direção da empresa Morais
de Castro, que me apoiou e me incentivou-me a realizar o curso superior.
A todos os Mestres com quem tive o prazer de compartilhar conhecimento nesse
período, um muito obrigado. E, em especial, ao meu orientador Professor Pablo Passos, que
acreditou em meu potencial e, com dedicação e empenho, ajudou-me a realizar este
trabalho além de ser uma figura fundamental nesta orientação desde seu nascimento. Ao
Coordenador Jorge Farias, que sempre se mostrou interessado em apoiar e ajudar seus
alunos. Por fim, não poderia deixar de agradecer a minha Professora Cristiane Dutra por
sua colaboração ajudando a engrandecer o resultado deste trabalho.
RESUMO
Ferramentas de ETL são aplicações de software cuja função, em termos gerais, é
extrair dados de diversas fontes, transformar esses dados para garantir padronização e
consistência das informações carregá-los para um ambiente de consulta e análise,
conhecido como data warehouse. As diversas ferramentas de ETL disponíveis no mercado
atualmente possuem as funções básicas com características bem semelhantes e o nível de
sofisticação fica por conta de recursos mais específicos que vão diferenciar umas das
outras. Na perspectiva das empresas de pequeno e médio porte, às quais possuem uma
capacidade de investimento em ferramental tecnológico limitada, as ferramentas ETL open
source configuram-se como uma alternativa interessante uma vez que o licenciamento e as
atualizações são gratuitos. Através de pesquisas realizadas por organizações especializadas,
foi possível identificar as ferramentas Kettle e Talend como as mais importantes atualmente
no universo das ferramentas ETL open-source. Tal fato expõe a necessidade de desenvolver
um método para avaliar as ferramentas ETL open-source Talend e Kettle/Pentaho através
da definição de critérios relativos às características e funcionalidades importantes para a
construção de um projeto de DW. Os resultados de cada um dos critérios foram coletados
através da utilização das ferramentas em um estudo de caso prático no âmbito de uma
empresa de pequeno porte.
Palavras-chave: Ferramenta ETL, Kettle, Talend, CloverETL, Business Intelligence, Data
Warehouse.
ABSTRACT
ETL tools are software applications whose function, in general terms, is to extract
data from several sources, then transform it to ensure standardization and consistency of
information, upload it to an environment of consultation and analysis, known as data
warehouse. The several ETL tools available on the market these days have the basic
functions with very similar characteristics and the level of sofistication is on more specific
features that will differentiate one another. From the perspective of small and medium
businesses, which have a limited capacity of investment in technological tools, the ETL
open-source tools are an interesting alternative since the licensing and upgrades are for free.
Through research conducted by organizations it was possible to identify the Kettle and
Talend as the currently most important ones in the world of ETL open-source tools. This
fact explains the need to develop a method to evaluate the ETL open-source Talend and
Kettle / Pentaho tools by defining criteria pertaining to the characteristics and features that
are important to build a DW project. The results of each of the criteria were collected
through the use of tools in a practical case study within a small business.
Keywords: ETL Tools, Kettle, Talend, CloverETL, Business Intelligence, Data Warehouse.
LISTA DE FIGURAS
Figura 1 – O Ambiente de um Data Warehouse ................................................................... 19
Figura 2 - Staging Area ou ODS .......................................................................................... 22
Figura 3 – Arquitetura de Data Mart Independente ............................................................. 23
Figura 4 – Arquitetura de Data Mart Integrado ................................................................... 24
Figura 5 – Modelo de Implementação Top Down em Data Mart Dependente .................... 25
Figura 6 – Modelo de Implementação Botton Up para Data Mart Independente ................ 27
Figura 7 – Modelo Multidimensional Snowflake ................................................................. 30
Figura 8 – Modelo Multidimensional Star Schema .............................................................. 31
Figura 9 – Representação de Granularidade ......................................................................... 32
Figura 10 - Dimensão que Muda Lentamente Tipo-1 .......................................................... 34
Figura 11 - Dimensão que Muda Lentamente Tipo-2 .......................................................... 35
Figura 12 - Dimensão que Muda Lentamente Tipo-3 .......................................................... 36
Figura 13 - Estratégia de Carregamento de Tabelas de Fatos de Nível Básico .................... 37
Figura 14 – Representação das Origens de Metadados ........................................................ 40
Figura 15 – Modelo Clover Designer ................................................................................... 49
Figura 16 – Modelo Talend Open Studio ............................................................................. 53
Figura 17 – Modelo PDI / Kettle .......................................................................................... 56
Figura 18 - Ambiente OLAP - Modelagem Esquema Star .................................................. 61
Figura 19 - Ambiente Transacional – Modelagem 3FN ....................................................... 62
Figura 20 – Menu Conexão Banco de Dados no Kettle/Pentaho ......................................... 63
Figura 21 - Conexão Banco de Dados no Kettle/Pentaho .................................................... 63
Figura 22 – Menu Conexão Banco de Dados no Talend ...................................................... 64
Figura 23 - Conexão Banco de Dados no Talend ................................................................. 64
Figura 24 - Movimentação de Dados para Staging Area no Kettle ...................................... 65
Figura 25 - Movimentação de Dados para Staging Area no Talend .................................... 66
Figura 26 – Componente tMap do Talend Open Studio – Tabela Cliente ........................... 67
Figura 27 – Componente tMap do Talend Open Studio – Calculo da Margem de
Contribuição ......................................................................................................................... 67
Figura 28 – Componente Database Lookup do Kettle – Tabela Cliente .............................. 68
Figura 29 – Componente Calculator do Kettle – Calculo da Margem de Contribuição ...... 68
Figura 30 – Componente Dimension Lookup/Update do Kettle – SCD tipo 1 e 2 .............. 71
Figura 31 – Componente ‘tPostgreSqlSCD’ do Talend – SCD tipo 1, 2 e 3 ....................... 72
Figura 32 – Componente ‘Database lookup’ do Kettle – Carga Tabela Fato Vendas.......... 72
Figura 33 – Componente ‘tMap’ do Talend – Carga Tabela Fato Vendas........................... 73
Figura 34 – Modelo do Talend – Carga Tabela Fato Vendas ............................................... 73
Figura 35 – Exemplo Facilidade para Criar Componentes a Partir de Conexões ................ 75
Figura 36 - Controle de Versão da Transformação no Kettle............................................. 105
Figura 37 - Controle de Versão da Transformação no Talend ........................................... 106
Figura 38 - Consulta Versão de um Trabalho no Talend ................................................... 107
Figura 39 – Consulta Histórico das Versões de um Trabalho no Talend ........................... 107
Figura 40 - Controle de “Status” das Versões de um Trabalho no Talend ......................... 108
Figura 41 – Exemplo de Tratamento de Erro no Kettle ..................................................... 109
Figura 42 - Conjunto de Componentes para Manipulação de Erros no Talend ................. 110
Figura 43 - Exemplo Relatório Análise de Impacto no Kettle ........................................... 111
Figura 44 - Exemplo de Rastreabilidade e Propagação de Atributos no Kettle ................. 112
Figura 45 - Relatório de Rastreabilidade dos Atributos no Kettle ..................................... 113
Figura 46 - Exemplo de Propagação de Atributos no Talend ............................................ 113
Figura 47 - Exemplo de Rastreabilidade e Manipulação de Atributos no Talend .............. 114
Figura 48 - Relatório de Documentação Automática do Kettle ......................................... 115
Figura 49 - Chamada ao Gerador de Documentação no Talend......................................... 115
Figura 50 - Relatório de Documentação no Talend ............................................................ 116
Figura 51 - Exemplo de Compartilhamento de Recursos do Kettle ................................... 117
Figura 52 - Modelo de um Painel com “Jobs” e Metadados Compartilhados no Talend .. 118
Figura 53 - Exemplo de Execução Passo-a-Passo no Kettle .............................................. 119
Figura 54 - Modelo dos Painéis de Depuração Passo-a-Passo no Talend .......................... 120
Figura 55 - Exemplo de Configuração do Ponto de Parada no Kettle ................................ 120
Figura 56 - Exemplo de Configuração do Ponto de Parada no Talend .............................. 121
Figura 57 - Exemplo do Recurso de Validação no Kettle .................................................. 122
LISTA DE GRÁFICOS
Gráfico 1 – Quadrante Mágico para Ferramentas de Qualidade de Dados .......................... 52
Gráfico 2 – Por Categoria de Requisitos .............................................................................. 88
LISTA DE TABELAS
Tabela 1 – Vantagens e Desvantagens da Implementação TOP DOWN .............................. 25
Tabela 2 – Vantagens e Desvantagens da Implementação BOTTON-UP ............................ 26
Tabela 3 – Matriz de Processo de Negócio - Parte 1 ............................................................ 59
Tabela 4 – Matriz de Processo de Negócio – Parte 2 (continuação) .................................... 59
Tabela 5 – Requisitos Relevantes com as Respectivas Avaliações ...................................... 81
Tabela 6 - Pontuações por Item de Requisito ....................................................................... 87
Tabela 7 - Resumo das Pontuações por Categoria de Requisitos ......................................... 88
LISTA DE SIGLAS
3FN Terceira Forma Normal
API Interface de Programação de Aplicativos
BI Business Intelligence
DB2 Banco de Dados da IBM
DM Data Mart
DSS Sistema de Suporte a Decisão
DW Data Warehouse
EIS Sistema de Informações Executivas
ER Entidade de Relacionamento
ETL Extract, Transformation and Load
IDC International Data Corporation
MDM Master Data Management
MPP Multi-Processamento Paralelo
ODBC Open Database Connectivity
ODS Staging Area ou Operacional Data Store
OLAP On-line Analitycal Processing
OLTP On-line Transactional Processing
PDI Pentaho Data Integration
SAD Sistema de Apoio a Decisão
SAP Sistemas Aplicativos e Produtos - Software Gestão Empresarial
SGBD Sistema Gerenciador de Banco de Dados
SMP Multi-processamento Simétrico
TXT Padrão de Arquivo Texto
VM Máquina Virtual
XML Padrão de Arquivo
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................. 12
2 Data Warehouse ................................................................................................................. 18
2.1 A HISTÓRIA DO EIS AO DATA WAREHOUSE ....................................................... 18
2.2 CONCEITOS E PROPRIEDADES DO DATA WAREHOUSE .................................. 19
2.3 ARQUITETURA DO DATA WAREHOUSE ............................................................... 21
2.3.1 Staging Area ................................................................................................................ 21
2.3.2 Data Mart ..................................................................................................................... 23
2.4 FORMAS DE IMPLEMENTAÇÕES ............................................................................ 24
2.5 ETAPAS DA IMPLANTAÇÃO DO PROJETO ........................................................... 28
2.5.1 Modelagem .................................................................................................................. 28
2.5.2 ETL ............................................................................................................................. 33
2.5.3 ANÁLISE DE INFORMAÇÕES ................................................................................ 41
3 ETL – EXTRAÇÃO, TRANSFORMAÇÃO E CARGA DE DADOS ............................ 42
3.1 ABRANGÊNCIA DO ETL ........................................................................................... 42
3.2 ETAPAS DO PROCESSO DE ETL ............................................................................. 43
4 FERRAMENTAS DE ETL .............................................................................................. 45
4.1 CONCEITO ................................................................................................................... 45
4.2 CARACTERÍSTICAS E BENEFÍCIOS ....................................................................... 45
4.3 MODELO OPEN SOURCE .......................................................................................... 47
4.3.1 Ferramenta CloverETL ............................................................................................... 48
4.3.2 Ferramenta TALEND ................................................................................................. 51
4.3.3 Ferramenta KETTLE (PENTAHO)............................................................................. 54
5 Estudo de caso: empresa de pequeno Porte ...................................................................... 57
5.1 ANÁLISE DE REQUISITOS E DESENVOLVIMENTO DA MATRIZ DO PROCESSO DE NEGÓCIO ................................................................................................. 58
5.2 DEFINIÇÃO DO MODELO DIMENSIONAL ............................................................ 60
5.3 EXTRAÇÃO DOS DADOS, MOVIMENTAÇÃO PARA STAGING AREA .............. 62
5.4 NECESSIDADES DE TRANSFORMAÇÃO, DIMENSÃO E FATO ........................ 66
5.5 PLANEJAMENTO DE CARGA DAS DIMENSÕES ................................................. 69
5.6 PLANEJAMENTO DE CARGA DA TABELA FATO ............................................... 72
5.7 NOTAS DO DESENVOLVIMENTO ........................................................................... 74
6 AVALIAÇÃO DAS FERRAMENTAS DE ETL ............................................................. 78
6.1 IDENTIFICAÇÃO DOS REQUISITOS ........................................................................ 78
6.2 AVALIAÇÃO DOS REQUISITOS .............................................................................. 79
6.2.1 Resumo das pontuações ............................................................................................... 86
7 CONCLUSÃO ................................................................................................................... 89
REFERÊNCIAS: .................................................................................................................. 91
ANEXO 1 – INFRA-ESTRUTURA UTILIZADA NA EXECUÇÃO DO LABORATÓRIO .............................................................................................................................................. 94
ANEXO 2 – LISTA DE CRITÉRIOS PARA AVALIAÇÃO DAS FERRAMENTAS ETL .............................................................................................................................................. 95
ANEXO 3 – ANÁLISE COMPLEMENTAR DOS CRITÉRIOS RELEVANTES .......... 105
12
1 INTRODUÇÃO
A economia mundial, nas últimas décadas, vem migrando de uma economia
industrial, voltada ao produto, em que os bens manufaturados são o principal fator, para
uma economia baseada na informação e no conhecimento (MACHADO, 2008). E, neste
cenário, encontra-se a maioria das empresas, revendo seus sistemas de gestão e muitas
delas em pleno processo de implantação do Planejamento Estratégico, buscando um sistema
que forneça informações que agregue valor ao seu negócio. Ou seja, informações que sejam
de rápido acesso, fácil de consultar, que integre as diversas fontes de dados e que esses
estejam organizados em um formato padronizado de tal modo que possa fornecer subsídios
aos níveis gerenciais e direção no apoio às decisões estratégicas.
Para atender a essa demanda, essas empresas vêm buscando desenvolver seus sistemas
de apoio à decisão baseado em arquiteturas de DW (data warehouse). No entanto, a grande
maioria enfrenta dificuldades logo de início na escolha pelo modelo de desenvolvimento e
quais ferramentas serão utilizadas, uma vez que, independente do modelo adotado, será
necessário cumprir o processo de extração, transformação e carga de dados, também
conhecido como ETL (Extract, Transform and Load). Esta é a fase mais crítica, complexa e
demorada na construção de um data warehouse, cuja finalidade é aglutinar os dados de
múltiplas origens e integrar em um formato padronizado e consistente para ser carregado no
data warehouse.
Segundo Corey (2001, p. 227), “os sistemas de origem tem os dados; o data
warehouse é estruturado para apresentar informações e o processo de ETL é a caixa preta
que transforma os primeiros no último.”. Desta forma, o conceito de ETL contribui
fortemente no processo de construção do data warehouse, visto que tem a responsabilidade
de capturar, transformar e consolidar os dados dos sistemas transacionais, também
conhecido como OLTP (On-line Transactional Processing), assim como moldar esses
dados e entregá-los formatados em dimensões estruturadas com o objetivo de facilitar aos
sistemas de consultas ou OLAP (On-line Analitycal Processing) disponibilizando, assim, a
inteligência empresarial para ser explorada pelos usuários finais. Entende-se por “captura e
consolidação” de dados um complexo trabalho de congregar fontes de dados de diversas
origens com formatos e critérios variados em um único ambiente consistente e organizado.
13
Existe uma advertência comum entre dois dos principais “gurus” sobre data
warehouse, a exemplo de Ralf Kimball e Bill Inmon. Eles afirmam que a atividade de ETL
ocupa boa parte do tempo em projetos data warehouse, algo que varia entre 60% até 80%
do tempo total gasto em um projeto. E esse percentual pode se acentuar ou não se a opção
for pelo desenvolvimento manual do código ou pelo uso de ferramentas especializadas em
ETL.
Vale observar que, quando a opção for por implementação manual de rotinas ETL, o
desenvolvedor poderá encontrar possíveis limitações ou dificuldades em tarefas que vão
exigir do desenvolvedor um grande esforço de trabalho, além de um tempo maior de
dedicação, assim como ficará mais suscetível a ocorrência de erros durante o
desenvolvimento do código, consequentemente deixando de ganhar produtividade no
projeto e principalmente não garantindo a qualidade das informações armazenadas para as
análises dos gestores que podem levar a decisões equivocadas, trazendo sérios prejuízos
para as organizações. Segundo Corey (2001), as principais dificuldades em uma
implementação manual estão no desenvolvimento de código, nas funções de metadados
(detalhes no capítulo 2.5.2.3), nas conexões com ambientes heterogêneos, no próprio
gerenciamento do desenvolvimento, assim como na elaboração da documentação do
projeto.
Considerar a alternativa pelo uso de ferramentas de ETL frente ao desenvolvimento
manual é algo importante, por tratar-se de um conjunto de recursos que apoia a construção
de um data warehouse. Essas ferramentas de ETL disponibilizam recursos, como: geração
de metadados; conectividade nativa com os principais SGBD (Sistema Gerenciador de
Banco de Dados) dentre outros tipos de arquivos como XML, planilhas e TXT; funções
facilitadoras para transformação de dados; melhor aproveitamento para reutilização de
códigos; solução para gerenciamento centralizado de projetos; facilidade no
desenvolvimento de código através de diagramas; facilidade na elaboração da
documentação técnica, entre outros.
Desta forma, é possível afirmar que há benefícios em utilizar uma ferramenta ETL
ante o desenvolvimento manual, salvo necessidades muito específicas em que às
ferramentas ETL não atendem de forma esperada. Segundo Corey (2001, p. 226) “bons
programadores podem escrever bons processos de ETL. E geralmente podem fazer melhor
14
do que qualquer ferramenta ETL”, porém Corey (2001, p. 226) ainda complementa dizendo
“…uma ferramenta ETL reúne dados sobre os processos de ETL, os torna reutilizáveis, é
mais fácil de gerenciar e transferir conhecimento…”
Como bem coloca Corey (2001), não é impossível desenvolver um data warehouse
sem utilizar ferramentas de ETL, entretanto a utilização deste recurso trará, além dos
benefícios já citados, a qualidade como um todo para o projeto. Atualmente, o mercado
dispõe de uma enorme variedade de ferramentas de ETL com recursos e características bem
diversificadas. Na perspectiva das empresas de pequeno e médio porte, às quais possuem
uma capacidade de investimento em ferramental tecnológico limitada, as ferramentas ETL
open source configuram-se como uma alternativa interessante, pois o licenciamento e os
upgrades (atualizações) são gratuitos.
Outro fator que confirma a possibilidade de utilização das ferramentas ETL open
source é que as principais funcionalidades existentes nos software proprietários já estão
disponíveis na versão de código aberto. Com isso, o padrão oferecido pelas ferramentas de
ETL atendem satisfatoriamente as necessidades para esse porte de organizações.
Também há evidências sobre o grau de maturidade do modelo open source para
ferramentas de ETL com crescente aderência até entre as organizações mais
regulamentadas. Isso mostra que apresenta níveis confiáveis de execução. Segundo o artigo
publicado pela COMPUTERWORD (2010), metade de um universo de 300 organizações
pesquisadas de grande porte já está comprometida com soluções de código aberto e outros
28% já realizaram testes ou empregam esse tipo de software em serviços mais específicos.
A pesquisa intitulada “Visão Geral do Mercado: Ferramentas ETL Open Source”
realizada pela Forrester Research (2007) relata a existência de dezenas de projetos de
código aberto que realizam uma ou mais funções de ETL. Contudo, pondera que apenas
algumas destas soluções oferecem um conjunto mais completo de recursos e dentre as que
se encaixam dentre as mais completas soluções open-source destacam-se o Kettle e Talend.
De acordo com a pesquisa, as características técnicas desses projetos têm muito mais
semelhanças do que diferenças. Além disso, suas estratégias de mercado representam o
grosso de sua diferenciação em relação às demais soluções open-source.
A identificação das ferramentas citadas como as mais importantes atualmente no
universo de ferramentas ETL open-source expõe a necessidade de uma avaliação mais
15
aprofundada no tocante às funcionalidades e características destas soluções. Esta questão se
configura como motivador para avaliação do emprego destas ferramentas em um estudo de
caso prático em uma empresa de pequeno porte, o que permitiu a definição da solução que
melhor se adequou ao contexto de avaliação.
1.1 OBJETIVO
O objetivo deste trabalho é desenvolver um método para avaliar as ferramentas ETL
open-source Talend e Kettle/Pentaho através de critérios relativos às características e
funcionalidades destas soluções. Os resultados de cada um dos critérios definidos foram
identificados através da utilização das soluções em um estudo de caso prático no âmbito de
uma empresa de pequeno porte. A comparação dos resultados obtidos permitiu a definição
da solução que melhor se adequou ao contexto de avaliação.
1.2 MOTIVAÇÃO
Durante muitos anos, as empresas buscaram aprimorar os elementos de controle
operacional, primeiro com os sistemas funcionais, depois evoluíram para automação dos
processos e, atualmente, o foco está direcionado para o tratamento das informações
estratégicas. Essa necessidade de transformar os dados operacionais em informações de
valor sempre existiu, porém, como bem coloca Machado (2008, p.15), “as falhas
estruturais, os custos de desenvolvimento de sistemas, entre outros, sempre deixaram para o
último lugar as necessidades executivas de informação.” Um exemplo prático é o próprio
estudo de caso aplicado neste trabalho, cujo projeto pertence a uma empresa de médio porte
que já consolidou sua etapa de automação dos processos e agora deseja investir na
implantação de um data warehouse. E, entre as principais dificuldades, passou-se pela
decisão de escolha de uma ferramenta ETL, uma das razões que motivou o
desenvolvimento de uma metodologia para escolha de ferramenta ETL. Outra motivação
16
foi destacar a importância merecida à etapa de ETL quase sempre renegada a segundo
plano nos projetos de BI, que é bem lembrada por Gonçalves (2003, p. 4) quando diz:
Os fornecedores de software que atuam nesta área preocupam-se em desenvolver as ferramentas finais para os usuários, mas esquecem de tratar a questão da integração de dados, um requisito para o data warehouse e algo que somente as ferramentas ETL podem atender.
1.3 METODOLOGIA
Para o desenvolvimento deste trabalho é importante que conceitos de Data
Warehouse, suas etapas de construção, principalmente a ETL, e o papel das ferramentas
ETL sejam bem definidos. Para essa tarefa, é imprescindível uma revisão bibliográfica a
respeito do estado da arte para os tópicos citados.
Além disso, foi realizado levantamento das principais características e recursos
oferecidos pelas ferramentas de ETL Open Source. Uma análise documental dos produtos
de ETL selecionados foi realizada através de pesquisas nos sites dos fornecedores,
trabalhos bibliográficos correlatos e avaliações de organizações independentes.
A análise propiciou a definição dos critérios para avaliação das ferramentas em
questão e os resultados desta avaliação foram aferidos a partir de um estudo de caso de
implantação de DW em uma organização de pequeno porte. Este laboratório funcionou
como uma forma de validação do método de avaliação de ferramentas ETL open-source,
objetivo deste trabalho.
1.4 ORGANIZAÇÃO DO TEXTO
A organização deste trabalho está dividida em sete capítulos descritos a seguir:
17
O primeiro capítulo faz uma breve introdução sobre o cenário atual das empresas,
também procurando demonstrar o objetivo, a metodologia e motivação do conteúdo
abordado neste trabalho.
No segundo capítulo, são descritos os conceitos básicos, a arquitetura, elementos e
fundamentos sobre data warehouse.
No terceiro capítulo, são definidos os conceitos sobre ETL, sua abrangência e as
etapas.
O quarto capítulo mostra o que é e o que faz uma ferramenta ETL, assim como uma
breve referência sobre as ferramentas CloverETL, Talend e Kettle/Pentaho.
No quinto capítulo, é apresentado o desenvolvimento do estudo de caso de um data
mart para uma empresa de pequeno porte.
No sexto capítulo, está registrada a avaliação das ferramentas ETL open-source alvo
do trabalho com a classificação e pontuação dos requisitos para o desenvolvimento do
estudo de caso.
O sétimo capítulo finaliza com a conclusão dos resultados obtidos e sugestões para
trabalhos futuros.
Três anexos fazem parte deste trabalho, onde o primeiro descreve a infra-estrutura
utilizada no estudo de caso; o segundo traz uma lista de critérios importantes para avaliação
das ferramentas ETL que serviu como base para o foco do trabalho que é a avaliação de
ferramentas ETL open-source voltada para projetos de DW em empresas de pequeno porte;
e o terceiro apresenta uma análise complementar dos critérios relevantes aplicados no
estudo de caso.
18
2 DATA WAREHOUSE
Neste capítulo, aborda-se a fundamentação teórica do trabalho, cujo objetivo é prover o
conhecimento básico para o entendimento dos conceitos que envolvem a construção de um
data warehouse, além de mostrar uma breve história da evolução do DW, a arquitetura, as
formas e etapas de implementação do DW.
2.1 A HISTÓRIA DO EIS AO DATA WAREHOUSE
As primeiras aparições de desenvolvimento de sistemas para fornecimento de
informações empresariais foi com a chegada das planilhas eletrônicas por volta de 1990,
conhecidos como Sistemas de Informações Executivas – EIS e, nessa época, seu
desenvolvimento era restrito à equipe de TI com conteúdos limitados e cálculos simples de
somas, contagens e acessando os dados diretamente no ambiente operacional.
Já no final dos anos 90, com a evolução das aplicações, surgiram os Sistemas de
Apoio a Decisão – SAD ou Sistemas de Suporte a Decisão – DSS, facilitado pelas
linguagens de 4º geração. Isso permitiu que o usuário final assumisse um papel mais ativo,
proporcionando maior flexibilidade nos relatórios e nas consultas sob demanda.
Todavia, a extração dos dados ainda era de fontes relacionais pouco versáteis para
atender as expectativas das necessidades gerenciais. Outro problema surgiu quando houve a
necessidade de se pesquisar um histórico mais antigo dos dados, porque os ambientes
operacionais não se mantêm muitos anos armazenados. Além disso, o desempenho era
prejudicada com o uso concorrente do ambiente operacional.
O novo conceito, válido até os dias atuais, mas ainda em franca evolução, ficou
conhecido como data warehouse – DW, ou “armazém de dados”, com objetivos bem
definidos: fornecer informações confiáveis a partir de uma base corporativa única e
integrada; proporcionar acesso rápido aos usuários finais sem depender do pessoal de TI; e
19
permitir que os próprios analistas de negócio produzam modelos do tipo ad-hoc, ou seja,
sob demanda (COREY, 2001).
De acordo com Gonçalves (2003), o DW pode ser considerado como a separação
física entre os sistemas de dados operacionais (aplicativos que controlam as funções críticas
do negócio da empresa) e os sistemas de suporte à decisão de uma empresa. Esse conceito
define bem os elementos da arquitetura física, como ilustra a figura 1, o modelo de
ambiente data warehouse.
Figura 1 – O Ambiente de um Data Warehouse
Fonte: MACHADO, 2008, p. 26
2.2 CONCEITOS E PROPRIEDADES DO DATA WAREHOUSE
O barateamento de armazenamento de dados em disco propiciou às organizações
guardarem seus dados operacionais por muito mais tempo, porém o imenso volume de
dados armazenados neste formato dificulta seu aproveitamento na preparação de
informações estratégicas na tomada de decisão. Alguns motivos levam a isso: dados
20
dispersos, falta de integração com outras bases de dados, o formato não adequado para
favorecer consultas a um grande volume de dados, ausência de estrutura para uma visão
unificada dos dados entre outros. Esses problemas tornaram-se um grande desafio para as
organizações e foi para atender a essa demanda que surgiu os data warehouse
(GONÇALVES, 2003).
Segundo Corey (2001 apud INMON, 1997, p.12), para um data warehouse é
necessário atender as seguintes propriedades:
. Orientado ao assunto: Refere-se ao formato da organização das informações de
modo a facilitar as consultas, ou seja, os dados serão agrupados por assunto dos
negócios da empresa, por exemplo: vendas, compras, produção, RH e etc.
. Integrado: O data warehouse tem a função de armazenar os dados em um único
ambiente, integrando dados de diversas fontes, arquivos XML, entre outros. No
entanto, para a real integração, é necessário adotar alguns cuidados antecipadamente
ao armazenamento no data warehouse.
. Não volátil: Além de garantir a durabilidade das informações no tempo, essa
propriedade também garante que os usuários somente terão acesso ao data
warehouse com a possibilidade de somente leitura. Isso não significa que não
haverá atualização dos dados, mas ocorrerá através de novas cargas de dados e, uma
vez carregado, não mais poderá ser apagado. Diferentemente dos ambientes
transacionais – OLTP, por intermédio das aplicações, os usuários podem executar:
inclusão, alteração, exclusão e consulta dos dados.
. Variante no tempo: Sem o elemento tempo, o data warehouse não teria muito
sentido. O registro dos históricos das atualizações permite ao usuário conhecer qual
era o estado de um determinado dado após uma atualização, uma vez que as novas
entradas sempre serão mapeadas em um novo registro, ou seja, os dados contidos
referem-se a algum momento de tempo específico. Para isso, os registros, quando
carregados, recebem um atributo da unidade de tempo e nunca mais são atualizados.
É essa característica que possibilita os analistas de negócios fazerem análises de
tendências e visualizarem as variações das informações ao longo do tempo. E a
21
maior justificativa para os grandes volumes de dados dos data warehouse é
exatamente a necessidade de manter os registros de históricos por tempo a fio.
2.3 ARQUITETURA DO DATA WAREHOUSE
Segundo Machado (2008), a arquitetura define o modelo lógico da instalação,
independente da estrutura física do data warehouse. A escolha da arquitetura passa por uma
decisão gerencial que está relacionada a fatores relativos à infra-estrutura disponível pelo
formato da instalação, se central ou distribuída em instalações remotas ou locais. Também
se devem levar em consideração os recursos disponíveis para investimento, porte da
empresa e a cultura dos usuários, etc.
Corey (2001) comenta que há uma infinidade de possibilidades ao se adotarem
estratégias para construir um data warehouse, inclusive a de não ter um data warehouse em
situações onde os sistemas transacionais – OLTP sejam suficientemente fortes para suportar
consultas dos usuários finais. Obviamente, são situações onde não existe necessidade de
integração com outras fontes de dados.
2.3.1 Staging Area
A Staging area ou Operational Data Store – ODS é um armazenamento de dados
intermediário, entre os sistemas transacionais e o data warehouse, cuja finalidade é facilitar
a integração entre esses dois ambientes. Essa técnica por um lado, exige mais uma etapa no
desenvolvimento do projeto e uma demanda maior por espaço em disco; por outro, os
ganhos podem ser muito maiores, como por exemplo, o desempenho durante o processo de
atualização do DW, também diminui o tempo de concorrência com o ambiente transacional
durante a leitura dos dados. Nesta etapa já é possível aplicar a “limpeza” dos dados e tirar
as inconsistências. Do mesmo modo, em ambientes complexos e heterogêneos, a Staging
area possibilita integrar todos os tipos de dados em um único formato fazendo com que a
22
carga para o DW seja de uma única fonte. Inicialmente essa área de armazenamento era
temporária. Com a evolução do ambiente, outras finalidades surgiram tornando esses dados
permanentes, e úteis para análises e metadados. A figura 2 exemplifica o elemento staging
area em um ambiente do data warehouse.
Dois modelos podem ser adotados em uma estratégia de staging area, ou seja, de
acordo com a localização física pode ser:
1) Local - quando a staging area está dentro do mesmo servidor OLTP; ou
2) Remoto – quanto localizada no mesmo ambiente do data warehouse, ou em seu
próprio ambiente em um servidor independente.
Recomenda-se cuidado na configuração da staging area no modelo local, pois pode
afetar o desempenho do ambiente transacional.
Figura 2 - Staging Area ou ODS
Fonte: MACHADO, 2008, p. 38
23
2.3.2 Data Mart
Os data mart – DM são subconjuntos do data warehouse - DW, normalmente
orientados por assunto de uma determinada área da organização, como finanças, vendas,
RH, ou organizado para atender as necessidades das informações por região geográfica, por
exemplo, cidades, estados países, unidades, filiais, etc. Essa técnica de agrupamento das
informações em data mart também contribui significativamente para os modelos de
implementação do data warehouse.
2.3.2.1 Arquitetura Independente
Nessa arquitetura, os dados são agrupados de forma a atender apenas as
necessidades específicas de um departamento, não tem um foco corporativo, isto é, as
informações de um data mart não serão vistas por outro data mart de outras áreas de
negócio da organização. Outra característica é que os dados são extraídos dos sistemas
transacionais – OLTP diretamente para o data mart. As vantagens deste modelo saõ sua
rápida implementação, visto que não há necessidade de pensar no data warehouse como um
todo, também apresenta baixo impacto nas necessidades de recursos tecnológicos, assim
como custos mais diluídos no projeto como afirma Machado (2008). A figura 3 demonstra
uma arquitetura de data mart independente.
Figura 3 – Arquitetura de Data Mart Independente
Fonte: MACHADO, 2008, p. 50
24
2.3.2.2 Arquitetura Integrada (ou Dependente)
A arquitetura integrada é o próprio data warehouse distribuído em múltiplos data
mart, isto é, mesmo que a implementação seja realizada separadamente por grupos de
trabalho ou departamento, os dados serão integrados ou interconectados, dando a
possibilidade dos dados serem vistos por todos os data mart. Assim, há uma maior visão
corporativa dos dados e aumento da capacidade de relacionamento das informações nas
consultas e análises empresariais. Como um aumento significativo da complexidade dos
requisitos do produto final, assim como o tempo de desenvolvimento e uma maior
capacitação técnica do pessoal de TI, consequentemente haverá um custo mais elevado no
projeto (MACHADO, 2008). A figura 4 demonstra uma arquitetura de data mart integrado.
Figura 4 – Arquitetura de Data Mart Integrado
Fonte: MACHADO, 2008, p. 51
2.4 FORMAS DE IMPLEMENTAÇÕES
Dentre as formas de implementações mais conhecidas, existem a Top Down e
Bottom Up, a opção por um modelo ou outro tem forte influência da arquitetura escolhida.
A implementação Top Down caracteriza-se por maior abrangência no projeto do data
warehouse. As definições de requisitos e modelagens conceituais envolvem todos os
departamentos da organização. Recomenda-se que todas as informações sobre o ambiente
25
transacional – OLTP, formatação e limpeza dos dados devam ser analisados antes de iniciar
a implementação. Desta forma, o modelo favorece a arquitetura de integrada dos data mart,
pois os dados para alimentar os data mart terão sua origem no data warehouse
(MACHADO, 2008). No entanto, existem vantagens e desvantagens em cada modelo,
como pode ser observado na tabela a seguir algumas características do modelo Top Down.
Tabela 1 – Vantagens e Desvantagens da Implementação TOP DOWN
Vantagens Desvantagens
Herança de arquitetura: dados e estrutura aproveitados do DW facilitam a manutenção.
Implementação muito longa: dificulta a garantia de apoio político e financeiro no projeto.
Visão de empreendimento: ou visão corporativa, todos os dados do negócio estão integrados.
Alta taxa de risco: inexistem garantias para o investimento nesse tipo de ambiente.
Repositório de metadados (1) centralizado e simples: facilidade na manutenção dos metadados
Heranças de cruzamentos funcionais: exige alta capacidade técnica dos desenvolvedores e usuários finais.
Controle e centralização das regras: garante a existência de um único conjunto de aplicações para extração e transformação dos dados, além de centralizar a manutenção e monitoração.
Expectativas relacionadas ao ambiente: a demora do projeto pode induzir expectativas nos usuários.
Fonte: MACHADO, 2008, p. 53 (Adaptada)
A figura a seguir demonstra o modelo da implementação top down para um data mart
dependente.
Figura 5 – Modelo de Implementação Top Down em Data Mart Dependente
Fonte: MACHADO, 2008, p. 53
26
Ao contrário da implementação top down, a botton up tem sua implementação mais
facilitada, porque não necessita do grande tempo requerido no levantamento de requisitos.
Deste modo, permite o desenvolvimento departamentalizado sem se preocupar com a visão
geral da empresa, mas com o propósito de desenvolvimento incremental do data warehouse
a partir dos data mart independentes. Assim sendo, o maior problema deste modelo é a
padronização na modelagem dimensional e no padrão metadados, podendo ocorrer
redundância de dados e inconsistência entre os data mart. Na tabela 2 pode ser visto as
principais vantagens e desvantagens do modelo botton-up.
Tabela 2 – Vantagens e Desvantagens da Implementação BOTTON-UP
Vantagens Desvantagens
Implementação rápida: desenvolvimento direcionado reduz o tempo de entrega do data mart.
Perigo de legamarts: uma das maiores preocupações da arquitetura data mart
independentes é acabar sendo transformada em sistemas legados que dificultam quando não inviabilizam futuras integrações, passando a ser parte de um problema e não a solução.
Retorno rápido: baseado na arquitetura independente, aumenta a confiança da organização permitindo uma base para investimentos adicionais.
Desafio de possuir a visão de empreendimento: durante o desenvolvimento, existe a difícil missão de manter um rígido controle no enfoque do negócio como um todo.
Manutenção do enfoque da equipe: esse modelo permite que a equipe priorize as principais áreas de negócios.
Administrar e coordenar múltiplas equipes e iniciativas: caso ocorra desenvolvimento em paralelo dos data mart, é necessário rígido controle da equipe para não perder a padronização das regras.
Herança incremental: reduz o risco do projeto como um todo, dado que o aprendizado da equipe cresce a medida que for desenvolvendo passo a passo.
A maldição de sucesso: quando entregue um data mart, os usuários felizes ficam querendo mais informações para o seu projeto. Enquanto isso, os próximos terão que aguardar por mais tempo. Nestes casos, será necessário vencer desafios políticos.
Fonte: MACHADO, 2008, p. 55. (Adaptação)
27
A figura seguinte ilustra o modelo da implementação botton up para um data mart
independente.
Figura 6 – Modelo de Implementação Botton Up para Data Mart Independente
Fonte: MACHADO, 2008, p. 55
Machado (2008) também sugere a implementação combinada que alguns autores
preferem chamar de híbrida. Este modelo tem o propósito de unir as vantagens dos
paradigmas top down e botton up de uma forma geral. Nesta abordagem, executa-se a
modelagem de dados do date warehouse com uma visão macro e, posteriormente, serão
feitas as partes de interesse por processo ou atividades que constituirão os data mart. A
principal vantagem desse modelo é a garantia da padronização dos dados, uma vez que
haverá um molde único a ser seguido para o desenvolvimento de todos os data mart.
28
2.5 ETAPAS DA IMPLANTAÇÃO DO PROJETO
Antes de iniciarmos o desenvolvimento das etapas da implantação de um projeto de
data warehouse, é necessário já ter vencido a fase de estudo prévio do levantamento dos
requisitos com os usuários chave da organização para definição da arquitetura do data
warehouse, o modelo da staging area, assim como o formato do desenvolvimento
(abordagem incremental: Top-Down ou Bottom-Up) e, desta forma, entender os processos
de negócios, identificar os processos mais importantes e cruciais e, finalmente, priorizar os
assuntos a serem implementados. A seguir serão descritas as etapas de: Modelagem,
Granularidade, ETL e Análise das Informações.
2.5.1 Modelagem
O modelo é uma forma de abstração do mundo real e modelar é uma maneira de
visualizarmos aquilo que desejamos realizar. No nosso caso, a modelagem dos dados para o
ambiente do data warehouse deve atender dois requisitos básicos: ser performática para
consultas analíticas e clara para que os próprios usuários possam realizar suas consultas ad
hoc1. Como bem coloca Machado (2008, p. 65) “A maioria das técnicas de modelagem
concorda que a aplicação completa da teoria relacional não é apropriada para data
warehouse.”, ou seja, os princípios básicos das técnicas de modelagem na terceira forma
normal não se aplicam para ambientes de apoio a decisões, uma vez que são complexas
(por requer diversos joins2 entre suas tabelas) e não respondem com velocidade desejável às
consultas que demandam grandes volumes de dados.
Segundo Machado (2008), as duas técnicas mais utilizadas Entidade
Relacionamento (ER) e Multidimensional são aceitas para modelagem em ambientes de
data warehouse, contudo o modelo ER necessita de características específicas para suportar
o ambiente de análise multidimensional.
1 Ad-hoc é a capacidade um produto oferece ... 2 É a junção ou relacionamento entre de uma ou mais tabelas de um banco de dados.
29
A modelagem multidimensional tem o objetivo de sumarizar, reestruturar e oferecer
uma visualização dos dados comuns do negócio que forma priorizar o suporte às consultas
analíticas. Para tanto, emprega três elementos básicos:
- FATOS: consiste em um conjunto de dados que contém métricas que representam
uma transação ou evento de negócio. A particularidade do fato é que seu conteúdo é
representado por valores numéricos agrupados em tabela denominada de fato.
- DIMENSÕES: as dimensões é que proporcionam as formas de visualizar os
eventos do negócio, ou seja, os fatos. A característica da dimensão é determinar o contexto
dos assuntos do negócio, por isso o conteúdo de seus atributos não é numérico, e sim
conteúdos descritivos que classificam os elementos do fato. Exemplos de dimensões:
Cliente, Produto, Fornecedor e Tempo.
- MEDIDAS: as medidas são os atributos numéricos de um fato. Para Machado
(2008), é o elemento que permite demonstrar o desempenho de um indicador de negócios
relativo às dimensões de compõem um fato. Exemplos de medidas são: quantidade vendida,
valor faturado, quantidade devolvida, margem bruta e custo da venda.
2.5.1.1 Tipos de Medidas da Tabela Fato
Na tabela fato, existem as métricas numéricas dos negócios as quais serão
analisadas pelos usuários para a tomada de decisões. Os atributos para definir essas
métricas numéricas podem ser classificados de acordo com as características:
- Aditivas: As medidas podem ser somadas em todas as dimensões, além de permitir
a soma ao longo de todas as dimensões. Normalmente representado por valores e
quantidades e ocorrência;
- Semi-Aditivas: As medidas podem ser somadas em apenas algumas dimensões e o
atributo, quando somado ao longo de uma dimensão, não tem qualquer significado.
Exemplo desde tipo de atributos são saldos de estoque, saldo conta corrente, e etc.;
- Não-Aditivas: As medidas não podem ser somadas em qualquer dimensão, pois a
soma não possui qualquer significado ao longo das dimensões do esquema, como exemplo
a temperatura.
30
A seguir serão apresentadas as principais técnicas de modelagem e suas
características.
2.5.1.2 Técnicas de Modelagem Dimensional
2.5.1.2.1 Snowflake
O modelo multidimensional Snowflake ou floco de neve apresenta-se na disposição
de uma estrela com a tabela fato ao meio com as dimensões a sua volta, no entanto essas
dimensões podem sofrer decomposição em uma ou mais hierarquias, ou seja, ocorre a
aplicação da terceira forma normal nas entidades de dimensões. Essa técnica tem a
vantagem de economizar o espaço em armazenamento por evitar as redundâncias de dados,
contudo pode prejudicar o desempenho das consultas assim como a clareza por parte dos
usuários, por existirem mais joins entre essas tabelas (MACHADO, 2008). A seguir a figura
que exemplifica esse modelo.
Figura 7 – Modelo Multidimensional Snowflake
Fonte: MACHADO, 2008, p. 95
31
2.5.1.2.2 Star Schema
O modelo multidimensional Star Schema ou esquema estrela também apresenta-se
na disposição de uma estrela com a tabela fato ao meio e as várias dimensões ao seu redor.
Não existe a normalização nas entidades de dimensões, sendo que o relacionamento da
tabela fato acontece através de simples ligações entre essas duas tabelas. Desta forma,
privilegia a clareza para o usuário e melhor desempenho nas consultas em prejuízo a uma
maior ocupação de armazenamento. O modelo Star Schema é eleito pela maioria dos
autores como uma técnica de modelagem lógica que demonstra os dados em um padrão
intuitivo para os usuários, onde é capaz de balancear rapidez nas consultas e volume dos
dados em disco (MACHADO, 2008).
Figura 8 – Modelo Multidimensional Star Schema
Fonte: MACHADO, 2008, p. 93
32
2.5.1.3 Granularidade
Independente da implementação ou da arquitetura a ser adotada no desenvolvimento
do data warehouse, um dos fatores mais críticos no processo de modelagem dos dados é a
definição da granularidade. Machado (2008, p. 59) refere-se bem à granularidade de dados
como “nível de sumarização dos elementos e de detalhe disponíveis nos dados,
considerando o mais importante aspecto no projeto de um data warehouse”. E uma das
razões desta importância é o intenso efeito que ela pode provocar no volume de dados
armazenado no data warehouse que afetará o tempo de resposta nas consultas. Sendo
assim, tanto o técnico como o usuário devem estar interados deste efeito no momento de
definir os requisitos de granularidade e entender bem que, quanto mais detalhes há nos
dados, menor é a granularidade e maior a possibilidade de análise do negócio. Por outro
lado, o desempenho nas consultas estaria comprometida pelo maior volume de dados
armazenado. Por isso, recomenda Machado (2008) para este problema o método do “bom
senso” e da análise detalhada das necessidades, inclusive com propostas alternativas para
uma correta granularidade do projeto. A figura abaixo exemplifica uma situação de
armazenamento de diferentes granularidades.
Figura 9 – Representação de Granularidade
Fonte: MACHADO, 2008, p. 61.
33
2.5.2 ETL
O processo de ETL (extração, transformação e carga de dados) deve fazer parte de
qualquer projeto de data warehouse. Essas etapas são responsáveis pela movimentação dos
dados entre o ambiente transacional e o analítico com implementação de regras de
transformação para garantir a consistência e qualidade dos dados. Esse processo pode ser
desenvolvido manualmente (por código), entretanto atualmente existem diversas
ferramentas de ETL que agilizam na construção e gerenciamento desse processo de forma
segura e eficaz.
Além disso, o ETL pode ser comumente aplicado em outras áreas de inteligência de
negócios permitindo alimentação de dados para a análise de várias formas: a) Relatórios; b)
Dashboards (painéis, balanced scorecard); c) Indicadores de Desempenho ("KPIs"); d)
Multi-dimensional (OLAP); e) Análise exploratória (data mining) (ATOL, 2007). Para
detalhar este tema, teremos um capítulo completo dedicado ao ETL.
2.5.2.1 Estratégias de Carregamento das Dimensões
Essencialmente, podemos mencionar três tipos de estratégias de carregamento de
dimensão. Cada qual trata de forma diferenciada a alteração dos dados da tabela dimensão,
na forma de captura e na manutenção dos históricos. Em comum, essas estratégias sempre
comparam os dados de entrada com os dados já existentes. Kimball (2002) foi quem
primeiro conceituou as necessidades de alterações nas tabelas de dimensões, isto é,
atributos que podem mudar ao longo do tempo e, para atender a essa necessidade, Kimball
definiu três técnicas para Slowly Changing Dimensions ou simplesmente SCD:
Tipo 1 - Sobreposição de valores;
Tipo 2 - Criação de um novo registro na dimensão (controle de versão);
Tipo 3 - Criação de campos que permita acompanhar a evolução dos valores.
34
Para Corey (2001), determinar qual método deve-se aplicar exige um diálogo com
os modeladores e analista sobre a natureza dos dados na origem e no destino.
Antes de detalhar as estratégias de carregamento, para um melhor entendimento é
importante conceituar a função das chaves artificiais (alguns autores preferem chaves
substitutas) introduzidas nas dimensões em substituição a chave primária natural. Com a
finalidade de proporcionar maior flexibilidade na construção do data warehouse e,
principalmente, garantir maior agilidade de leitura dos dados pelas ferramentas de consulta
ou aplicações OLAP. Uma vez que as chaves artificiais têm o formato numérico e
sequencial em substituição todos os campos de uma chave natural.
2.5.2.1.1 Estratégia: Dimensão que Muda Lentamente - Tipo-1
É a forma mais simples de atualização da dimensão. Neste caso não existe o registro
de históricos, ou não há preservação de campos que estão sendo atualizados. Com base nos
valores da chave natural, o registro é atualizado com os dados do registro de entrada
(COREY, 2001). A seguir uma ilustração desse modelo.
Figura 10 - Dimensão que Muda Lentamente Tipo-1
Fonte: COREY, 2001, p. 244.
35
2.5.2.1.2 Estratégia: Dimensão que Muda Lentamente - Tipo-2
Quando a regra de negócio exige a preservação de uma determinada informação que
seja crítica, ela é mantida na dimensão com o mesmo conteúdo quando os fatos ocorreram
associados a sua época. O funcionamento desta estratégia baseia-se na verificação de
alteração em algum dos campos marcados como “crítico”. Caso ocorra mudança, o registro
será marcado como “expirado” e uma nova chave artificial é gerada para um novo registro
de entrada é inserido. Caso contrário, os dados serão simplesmente atualizados conforme
estratégia Tipo-1 (COREY, 2001). Como se observa na figura 11 mostra o modelo tipo 2.
Figura 11 - Dimensão que Muda Lentamente Tipo-2
Fonte: COREY, 2001, p. 245.
36
2.5.2.1.3 Estratégia: Dimensão que Muda Lentamente - Tipo-3
Nessa estratégia a regra de negócio também exige a preservação de uma
determinada informação que seja crítica com as mesmas regras de controle de alteração dos
tipos 1 e 2. Porém, limita-se a manter um histórico de ‘n’ valores, com o descarte do valor
mais antigo. Um exemplo no qual é utilizado esse tipo de controle é no atributo estado civil
do cliente quando é necessário conhecer apenas a situação atual e, no máximo, ter o registro
no histórico da situação anterior (COREY, 2001). A figura 12 exemplifica o modelo tipo 3.
Figura 12 - Dimensão que Muda Lentamente Tipo-3
Fonte: COREY, 2001, p. 246.
37
2.5.2.2 Estratégias de Carregamento da Tabela Fato
De modo geral, as tabelas fato de nível básico sempre acrescentam novos dados.
Comenta Corey (2001) que “a natureza das tabelas de fatos deve ser tal que todos os novos
dados devem estimular eventos ou transações exclusivos de suas extrações de sistema de
origem.”. Os passos para o carregamento da tabela fato devem-se, primeiramente, associar
cada fato às suas respectivas chave de dimensão por meio da chave natural. Uma vez
verificada a integridade, recupera-se o valor da chave artificial para destino do registro do
fato (COREY, 2001). A figura 13 demonstra essa estratégia.
Figura 13 - Estratégia de Carregamento de Tabelas de Fatos de Nível Básico
Fonte: COREY, 2001, p. 247.
Segundo Kimball (2004), na preparação da carga das tabelas fatos, existe um
conjunto de desafios:
38
A carga inicial é o primeiro desafio: como lidar com um volume imenso de dados
no menor tempo possível? Uma recomendação apresentada por Kimball é a boa gestão de
índices, por exemplo: antes de carregar uma tabela fato, podem-se desabilitar todos os seus
índices em um processo de pré-carga, para, depois, reconstruir os índices assim que a carga
for completada em um processo de pós-carga. “Os índices são potencializadores de
rendimento no momento da consulta, mas eles ‘matam’ o desempenho na carga de tabelas
que são fortemente indexadas…” (KIMBALL,2004, p.224).
O processo de atualização da tabela fato é outro desafio. Uma técnica indicada por
Kimball (2004, p.228) é a separação das operações de “inserções” das “atualizações”, mas
complementa, “apenas separar essas operações não basta, é importante priorizar as
‘atualizações’ e, em seguida, processar as ‘inserções’ na tabela fato”. Kimball também
adverte sobre a utilização de comandos SQL nas operações de inserções. Isso deve ser
evitado, uma vez que as ferramentas ETL possuem recursos para processamento de dados
em massa com balanceamento de carga por exemplo, oferecendo um desempenho mais
eficiente.
Outra questão abordada por Kimball (2004, p.228) é quanto à decisão para o tipo de
carga da tabela fato entre as opções: INSERÇÃO (limpeza e carregamento total); ou
INCREMENTAL (atualização dos registros existentes e inserção dos novos). Segundo
Kimball (2004, p. 228), devem ser evitadas as atualizações em registros, pois isso demanda
enormes sobrecargas no SGDB, causadas pelo preenchimento do log rollback3, por isso, em
muitos casos, é melhor excluir os registros que seriam atualizados e recarregá-los em
processamento de massa. Entretanto, o próprio Kimball (2004) adverte que, na escolha da
estratégia, deve-se levar em consideração a proporção de registros que estão sendo
atualizados versus o número de linhas existentes. Isso desenha um fator crucial na escolha
da técnica ideal e, geralmente, necessitam ser complementados com a execução de testes
para identificar cada situação em particular.
3 Recurso utilizados pelos gerenciadores de banco de dados para recuperação de registro em caso de falha.
39
Também a politica de correções dos registros na tabela fato deve estar alinhada com
a estratégia de carregamento da tabela fato. Para Kimball (2004, p.229), são três as
possibilidades para corrigir um registro na tabela fato:
1 – Negar o fato: Negar um erro implica na criação de uma duplicata exata do
registro errôneo quando as medidas são resultado das medidas iniciais multiplicado por -1.
Dessa forma, as medidas negativas invertem o fato na tabela anulando o registro original.
Muitas razões existem para negar um erro ao invés de usar outras abordagens para corrigir
dados de fato, a principal é para fins de auditoria. Outra razão é o melhor desempenho, uma
vez que evita atualizações de registros.
2 – Atualizar o fato: Implica em atualizar a informação no próprio o registro
(UPDATE), lembrando que atualizações em tabelas fato pode ser um esforço de
processamento intensivo, uma vez que a maioria dos sistemas de gerenciamento de banco
de dados, para esse tipo de transação, aciona um log rollback e isso reduz o desempenho da
carga.
3 – Apagar e recarregar o fato: Para Kimball(2004), a maioria dos arquitetos ETL
concorda que a exclusão de erros é a melhor solução para corrigir os dados em suas tabelas
fato. Uma desvantagem discutível é sobre as versões atuais dos relatórios. Quando
comparados com os que foram gerados anteriormente, eles não vão reconciliar. Por outro
lado, se se aceita que está mudando os dados, em qualquer das políticas utilizada para
atingir o objetivo da correção, a maioria dos relatórios existentes não consideram a
alteração de dados uma coisa ruim, desde que a versão atual represente a verdade.
2.5.2.3 Metadados
Para Gonçalves (2003), o metadados está para o data warehouse como o catálogo
de livros está para uma biblioteca. A função deste artefato é de documentar informações
tanto de sistema como de usuário. Machado (2008) define os metadados como dados de
nível mais alto que representam os dados de níveis inferiores que compõem a estrutura do
data warehouse.
40
Esses dados têm o papel de identificar a origem dos dados que mantêm o data
warehouse e se estende a toda documentação produzida durante o projeto, desde material
originado nas entrevistas com usuários até as documentações dos artefatos do sistema,
como por exemplo, modelo de dados, especificação dos arquivos (chaves e atributos),
histórico de extrações, controle de acesso, entre outras informações. Por ter estas
características de implementação, os metadados podem ser classificados em dois grupos: os
metadados técnicos, utilizados pelos desenvolvedores e analistas, e os metadados de
negócio, empregados pelos executivos e analistas de negócios.
Os metadados técnicos têm a função de fornecer segurança aos usuários técnicos
(desenvolvedores e administradores de banco de dados), e a certeza de que os dados estão
válidos. Estes dados são críticos para a manutenção e a evolução do sistema. Já os
metadados de negócio, como o próprio nome diz, são o elo entre o data warehouse e os
usuários de negócio (executivos e analista de negócio) e têm a finalidade de demonstrar a
origem dos dados no data warehouse, regras de transformação que foram aplicadas,
confiabilidade e contexto dos dados (MACHADO, 2008). A figura 14 ilustra bem as
possíveis origens do metadados.
Figura 14 – Representação das Origens de Metadados
Fonte: MACHADO, 2008, p. 306.
41
2.5.3 ANÁLISE DE INFORMAÇÕES
Nesta etapa do projeto, está disponibilizado para os usuários finais todo potencial de
análise dos dados que, normalmente, requer ferramentas específicas para o ambiente OLAP
(on-line analitycal processing) ou processamento analítico on-line, que trata das
informações na esfera tática e estratégica das organizações. Da mesma forma que no
ambiente OLTP, também existem aplicações que manuseiam os dados para o
processamento de informações OLAP e exploram os dados de um data warehouse. Afirma
Corey (2001, p. 616) que “O OLAP proporciona aos usuários a capacidade de ter idéias
sobre os dados, que anteriormente eles não podiam conseguir através de modos de
visualização rápida, coerente e fáceis de usar e interativos para uma variedade de
informação”. Para tanto, as características das consultas aos ambientes analíticos
necessitam atender os seguintes requisitos básicos:
- Proporcionar operações que mostram as maiores ocorrências, comparações entre
períodos, variações em percentual, médias, somas ou valores acumulados, entre outras
funções matemáticas e estatísticas;
- Permitir descoberta de tendências e cenários;
- Outras análises multidimensionais, tais como: slice e dice (que são formas de
mudança da visualização das dimensões), drill down e roll up (que determina a maneira de
navegação entre os níveis de detalhamento do dados), drill across (comando para pular um
nível intermediário dentro de uma mesma dimensão), pivot table (manipula o ângulo pelo
qual os dados são vistos, ou seja, troca de linha por coluna e vice-versa).
Segundo Machado (2008, p. 86) “As ferramentas OLAP são as aplicações às quais
os usuários finais têm acesso para extrair os dados de suas bases e construir os relatórios
capazes de responder às suas questões gerenciais.”
42
3 ETL – EXTRAÇÃO, TRANSFORMAÇÃO E CARGA DE DADOS
O objetivo deste capítulo é mostrar os conceitos básicos sobre ETL, abordando seu
significado e sua importância como fator crítico na construção de um projeto para data
warehouse ou BI e o que precisa ser feito para consolidar os dados para atender a
inteligência empresarial, demonstrando as necessidades de cada uma de suas etapas e seu
funcionamento.
3.1 ABRANGÊNCIA DO ETL
Segundo Corey (2001), ferramentas certas devem fazer parte de um projeto de DW,
assim como um gerenciamento central dará apoio nas tarefas de movimentação de dados e,
preparando uma boa arquitetura de ETL, vai possibilitar uma melhor implementação do
projeto.
Logo após as etapas de levantamento das necessidades de informações, requisitos
do projeto e definição da modelagem dos dados a serem apresentados no data warehouse, o
passo seguinte é identificar a origem dos dados, local onde são processados nos sistemas
transacionais da organização. Desta forma, inicia-se a etapa de ETL que é uma das mais
críticas no projeto de data warehouse, pois é a etapa que envolve a movimentação de dados
entre os ambientes transacionais e o ambiente de consulta analítica.
O grau de dificuldade, na integração dos dados entre estes ambientes – OLTP e DW
- depende diretamente de como será o cenário a enfrentar nos sistemas de origem, que
podem estar armazenados em esquemas comuns (homogêneos) ou em estruturas diferentes
(heterogêneas); em um banco de dados comum ou com os dados espalhados por diferentes
bancos. Quanto à localização geográfica dos dados pode estar dispersos ou centralizada em
um único local, assim como as características de plataformas de hardware e sistemas
operacionais irão influenciar na complexidade do projeto.
Certamente uma implementação inconsistente ou equivocada no processo ETL
tornará as informações armazenadas no DW não confiáveis para uma tomada de decisão.
43
Aliado às questões técnicas, não podemos esquecer quais são os limites de recursos
financeiros destinados ao projeto para que não ocorram surpresas com falta de recursos
depois de já iniciado o desenvolvimento, portanto um bom planejamento do cronograma
financeiro é essencial para o projeto (COREY, 2001).
3.2 ETAPAS DO PROCESSO DE ETL
Basicamente as atividades que envolvem a etapa de ETL estão agrupadas em três
passos. O primeiro é representado pela (E) extração dos dados de origem, que pode
envolver conexões com fontes de diversas origens como os SGBD, estes também de
diferentes fabricantes, planilhas eletrônica, arquivos XML, arquivo texto, arquivos não
estruturados, entre outros. Para Corey (2001, p.239), é importante ter “uma definição
concisa dos mapeamentos dos dados de origem [...] sem uma definição clara de onde
começar e onde terminar a tarefa será um trabalho de conjectura que produzirá dados
inúteis”.
O segundo passo está nas atividades de (T) transformação dos dados. É o trabalho
que concentra o maior esforço de análise, consequentemente gasta-se maior tempo, embora
o grau de dificuldade dependa diretamente de fatores que são determinados pela qualidade
dos dados de origem, das regras de negócios a serem aplicadas e da disponibilidade ou não
de documentação atualizada das bases de dados transacionais.
Segundo Corey (2001), não existe um ponto determinado onde vão ocorrer as
transformações, elas podem ocorrer durante a extração, na movimentação dos dados na
staging area, ou até na carga dos dados no DW mesmo que raros, mas sempre com o
objetivo de transformar os dados em informação.
Alguns destes trabalhos de transformação de dados implicam: na limpeza de dados
desnecessários. Deste modo, eliminando o “lixo” que acaba prejudicando ou, até mesmo,
poluindo as consultas; também a agregação ou segregação de campos ou conversão de
campos, como exemplo mudar de numéricos para caracteres e os diversos formatos de
datas, campos calculados, tratamento de valores nulos e entre outros; mas, sobretudo,
devem-se tratar as inconsistências causadas pela violação de integridade referencial ou má
44
definição de tipos de dados ou ainda dados cadastrados de forma duplicada, para que a falta
de padronização do ambiente transacional não venha a comprometer a qualidade das
informações no ambiente do DW.
Um exemplo clássico de falta de padronização de dados são as diversas formas de
representar o atributo “sexo” e, para resolver esse problema, é preciso criar uma regra para
harmonizar a informação, conforme ilustrado no quadro abaixo:
Quadro 1 – Formas de Apresentação de um Atributo
Ambiente Transacional Ambiente DW
M = (masculino) Masculino
F = (feminino) Feminino
H = (homem) Masculino
M = (mulher) Feminino
0 = (masculino) Masculino
1 = (feminino) Feminino
Fonte: Autoria própria (2011)
Já no último passo, a (L) carga - L do inglês load - requer do desenvolvedor o
conhecimento das estratégias para alimentação das tabelas para o ambiente do DW de
acordo com o esquema multidimensional adotado. Além das estratégias de carregamento e
atualização das tabelas de dimensão e fato (visto com mais detalhes no item 2.5.2), também
inclui a periodicidade de carregamento dos dados. Algumas tabelas podem exigir
carregamento a cada hora, outras diariamente ou semanalmente. Além disso, é
imprescindível que cada etapa seja iniciada somente após o término com sucesso da etapa
anterior (COREY, 2001).
45
4 FERRAMENTAS DE ETL
Neste capítulo, descreve-se o que é e o que faz uma ferramenta ETL, suas
características e benefícios, assim como as ferramentas de ETL que são objeto deste
trabalho, segundo a perspectiva de seus fabricantes como solução de extração,
transformação e carga de dados para um data warehouse.
4.1 CONCEITO
Ferramentas de ETL são aplicações de software cuja função é extrair dados
transacionais de diversas fontes ou origens, transformar esses dados para garantir
padronização e consistência das informações e carregá-los para um ambiente de consulta e
análise, conhecido como data warehouse.
Mas, as ferramentas de ETL não têm apenas funções de carga de dados para data
warehouse. É possível constatar, por exemplo, entre as ferramentas pesquisadas
(PENTAHO; KETTLE, 2011) e (TALEND, 2011), inúmeras aplicações que tratam de
movimentação de dados: em aplicações WEB, consolidação de dados, backup seletivos,
integração de dados não estruturados, entre outros recursos mais sofisticados como o
Gerenciamento de Dados Mestre, conhecido pelo acrônimo MDM, recurso disponível na
versão open source do Talend Open Studio (mais detalhes descritos em cada tópico das
ferramentas de ETL).
4.2 CARACTERÍSTICAS E BENEFÍCIOS
As diversas ferramentas de ETL disponíveis no mercado atualmente possuem as
funções básicas com características bem semelhantes. O nível de sofisticação fica por conta
de recursos mais específicos que vão diferenciar uma das outras.
46
Algumas das principais características são: ter conectividade com os principais
bancos de dados, com arquivos planos e planilhas; suportar as principais plataformas de
hardware e sistemas operacionais; possuir recurso de depuração como breakpoint e
execução passo-a-passo; componentes para manipulação de string (agregar, desagregar,
limpar), funções matemáticas, execução de scripts com inserção de códigos pelo
desenvolvedor sendo SQL, Java, Perl ou, até mesmo, linguagem proprietária como é o caso
do CloverETL; administração e gerenciamento do projeto; e uma boa interface gráfica e
intuitiva.
Os fabricantes pesquisados (CLOVERETL, 2011), (PENTAHO; KETTLE, 2011) e
(TALEND, 2011), descrevem como as ferramentas de ETL podem beneficiar frente ao
desenvolvimento manual:
• Implementando rotinas de Extrações e Cargas: Desenvolver conectores para
extração e carga de dados com uma ferramenta de ETL é muito mais simples e
rápido do que desenvolver manualmente, uma vez que codificar os drives de
conexão com bancos de dados exige especialistas com conhecimentos bem
específicos.
• Na manutenção de Extrações e Cargas: As tarefas de manutenção, mesmo que
por outras equipes, são mais fáceis de realizar em relação à manutenção em
rotinas desenvolvidas por código.
• No desempenho: Em geral, as ferramentas de ETL empregam métodos mais
performáticos, principalmente quando o processamento envolve grandes
volumes de dados.
• Em processamento paralelo: Normalmente as ferramentas de ETL têm recursos
nativos de paralelização e de fácil implementação.
• Na escalabilidade: Com as ferramentas de ETL é mais fácil aplicar upgrade,
distribuir ou balancear a carga do processamento entre vários servidores.
• Na transparência dos conectores: Alteração ou o surgimento de nova conexão de
fontes de dados com uma ferramenta de ETL fica totalmente transparente para o
restante do fluxo.
• Em reuso de funções: As ferramentas de ETL facilitam a reusabilidade de
funções no decorrer do desenvolvimento do projeto (isso não é copiar-colar).
47
• Com re-inicialização de processamento: Com as ferramentas de ETL, é possível
retomar a execução de carga a partir do ponto de para.
• Na permanência de metadados: As ferramentas mantêm disponíveis os
metadados gerados, facilitando identificar dados não íntegros ao final do
processo.
• Com documentação facilitada: As ferramentas de ETL possuem recursos para
gerar documentação automaticamente.
4.3 MODELO OPEN SOURCE
Atualmente as ferramentas de ETL open source já atingiram um nível de
maturidade bastante satisfatório, visto que os produtos para “Integração de Dados” já
surgem com destaque nos principais institutos de pesquisas independentes como, por
exemplo: Gartner e Forrester Research.
Outro fator relevante é o baixo custo inicial dos projetos dado que as licenças open
source são gratuitas, há também facilidades de customização por ser um padrão de
desenvolvimento de software colaborativo que comporta a criação de novos modelos de
negócios alternativos ao modelo tradicional comercial de licença. Muito embora ainda
existam recomendações para quem pretende adotar o modelo open source principalmente
no que diz respeito às limitações das versões gratuitas (GARTNER, 2010), como exemplo:
- Conectividade: nem todos conectores nativos estão disponíveis em produtos na
versão gratuita, por exemplo: DB2 da IBM, SAP entre outros padrões mais complexos
executados em mainframes (instalações de grande porte);
- Grandes volumes de dados: É importante considerar o quesito desempenho antes de
adotar sua ferramenta de ETL, pois operações com grandes volumes de dados e uma
pequena janela para processar esses lotes se configura um grande desafio. A maioria dos
fornecedores de ferramentas ETL open source mencionam que podem suportar altos
volumes de dados - e eles provavelmente podem em determinadas situações. Mas, se está
48
considerando um produto para uma atividade que exige alto desempenho e escalabilidade,
deve ser extremamente minuciosa em seu teste de alta disponibilidade e suporte a failover4;
- Desenvolvimento Colaborativo: Um benefício significativo para trabalho em equipe
é a capacidade de gerenciar um grande número de desenvolvedores, arquitetos,
modeladores, programadores e administradores de dados, assim como compartilhar os
metadados, mapeamento e reutilização de objetos dentro de projetos complexos.
- Transformação complexa: Funcionalidades e assistentes para transformações
robustas, para projetos que exigem gerenciar um grande volume de regras complexas.
- Carga em tempo real: É a capacidade de identificar e capturar dados acrescentados,
apagados ou atualizados em uma base e entregá-los, em tempo real, ao data warehouse,
garantindo informações confiáveis e imediatas para decisões de negócios, ou seja,
informações de qualidade em tempo real.
Observa-se que a maioria das limitações possíveis em versão gratuita das
ferramentas de ETL open source são pouco prováveis que sejam utilizadas em organizações
ou projetos de pequeno e médio porte, por isso a decisão de optar por uma tecnologia open
source gratuita ou comercial deve ser técnica, baseada na sua estratégia do seu negócio, e
não por preferências particulares ou ideológicas (DEVELOPER WORKS IBM, 2011).
A seguir serão apresentadas as ferramentas de ETL: CloverETL, Kettle (Pentaho) e
Talend. Uma breve apresentação segundo documentações disponíveis por seus próprios
fabricantes.
4.3.1 Ferramenta CloverETL
O CloverETL (2011) é uma plataforma de alto desempenho para integração de
dados que permite transferir esses dados entre diferentes locais. Permite extrair informações
de qualquer tipo de fontes de dados, validado e modificado ao longo do caminho, depois
4 Failover consiste na capacidade de um processo ser assumido por outro serviço automaticamente quando ocorrer uma interrupção por falha.
49
escrito em um ou mais destinos. A figura 15 mostra um exemplo do fluxo de modelagem de
dados com alguns componentes.
Figura 15 – Modelo Clover Designer
Fonte: CloverETL, 2011
De acordo com a CloverETL (2011), o seu produto para integração de dados
promete economizar tempo e esforço, não apenas para o desenvolvimento de
transformações e migrações de dados, mas também na manutenção permanente.
O mecanismo do CloverETL utiliza alguns conceitos-chave para descrever como os
dados devem ser manipulados. Possibilita aos desenvolvedores compor uma descrição
visual do fluxo do processamento dos dados, chamado algoritmo de transformação de
grafos. Os gráficos são compostos por blocos de construção, ou seja, componentes do
Clover Designer, o coração de todas as edições CloverETL. Ele fornece uma maneira fácil
de colocar para fora graficamente as mais complexas transformações de dados. Arraste e
solte a partir de uma paleta de componentes de transformação de dados e, em seguida,
configurá-los (CLOVERETL, 2011).
O projeto CloverETL (2011) é baseado em Java, conduzido pela companhia Javlin
Consulting fundada no ano de 2002, cujo presidente e co-fundador é o engenheiro David
Pavlis. Além da licença open source possui a versão comercial diferenciada com garantia e
suporte.
50
Contudo, após uma avaliação minuciosa da documentação disponibilizada pelo
próprio fabricante da ferramenta CloverETL (2011), foi constatado que a versão community
(ou open source) possui algumas restrições que impactaram no desenvolvimento do estudo
de caso proposto neste trabalho, dentro do propósito de não ter que utilizar código
(linguagem de programação ou scripts) para compensar a deficiência ou a falta de qualquer
componente. Dentre as restrições da versão do CloverETL Community, os principais
componentes são (CLOVERETL, 2011):
ApproximativeJoin – une dados classificados a partir de duas fontes de dados em
uma chave de correspondência comum.
DBJoin - recebe os dados através de uma única porta de entrada, une com dados de
uma tabela de banco de dados. E estas duas fontes de dados podem, potencialmente, ter
estruturas de metadados diferentes.
ExtMergeJoin – o propósito geral desse “Joiner” é mesclar dados classificados a
partir de duas ou mais fontes de dados em uma chave comum.
LookupJoin – a função principal desse “Joiner” é mesclar dados de uma tabela
potencialmente desordenado com outra fonte de dados, pesquisando com base em uma
chave comum.
DataIntersection – o componente recebe dados classificados a partir de duas
entradas, compara e une as chaves em ambos os registros. Entre os componentes é o mais
citado nos tutoriais como exemplos de integração de dados na carga das tabelas de
dimensões e fato.
Fact Table Load Wizard – assistente para facilitar o desenvolvimento na carga da
tabela fato.
A importância de alguns desses componentes para o estudo de caso é evidenciada
no uso de fluxos/rotinas de carregamento das tabelas de dimensão e fato. A ausência destes
componentes impediu a avaliação de importantes e obrigatórios requisitos aplicados no
estudo de caso: União, necessário para carga da tabela fato; e Dimensão de alteração lenta,
51
imprescindível na carga das dimensões tipo 1, 2 e 3 (lista completa dos critérios para
avaliação disponível no ANEXO 2).
4.3.2 Ferramenta TALEND
Segundo a Talend (2011), a ferramenta Talend Open Studio é uma solução versátil
para integração de dados. Este produto pode melhorar significativamente a eficiência de
projetos no trabalho com movimentação de dados também disponibiliza um ambiente de
desenvolvimento gráfico e fácil de usar. Possui suporte para a maioria dos tipos de fonte de
dados além de vários componentes para integração, migração e operações de sincronização
de dados.
Com uma comunidade forte e atuante de usuários que oferecem testes e retorno
contínuo, a Talend é uma das maiores companhias de desenvolvedores de software de
código aberto, oferecendo uma gama de soluções de middleware5 que abordam as
necessidades de gerenciamento de dados e integração de aplicações. Em pouco tempo, a
Talend tornou-se umas das líderes reconhecidas no mercado open source de gerenciamento
de dados. A aquisição em 2010 da empresa Sopera lhe colocou no posto de líder em
integração de aplicativos de código aberto, o que tem reforçado a evidência da Talend neste
mercado.
Muitas das grandes organizações ao redor do mundo vêm utilizando os produtos e
serviços da Talend para otimizar os custos de integração de dados, na melhoria da
qualidade de dados Master Data Management6 (MDM) e na integração de aplicações. Com
um número crescente de downloads de produtos e clientes pagantes, a Talend oferece as
5Middleware, também conhecido como mediador, é uma camada de software posicionada entre o código das
aplicações e a infra-estrutura de execução. 6 MDM Gerenciamento de Dados Mestres, é uma das tecnologias para soluções de integração de dados, com o objetivo de gerenciar múltiplos domínios de dados em um sistema único, hierarquizando de forma complexa as informações. A necessidade deste tipo de solução surge do fato de contarmos com muitas cópias da mesma informação, espalhadas por diversas áreas da organização. Outro ponto em comum entre as soluções MDM é a capacidade de lidar com os problemas causados por dados imprecisos, incompletos, inconsistentes e duplicados. “O aperfeiçoamento dos Dados Mestres está diretamente ligado ao aumento da eficiência operacional” (B2B MAGAZINE, 2011, p. 1).
52
soluções mais utilizadas de gerenciamento de dados com boa presença no mundo
(TALEND, 2011).
A Talend (2011) refere-se ao seu produto como uma visão completamente nova que
se reflete na forma como utiliza a tecnologia, bem como no seu modelo de negócio. A
empresa quebra o modelo tradicional de propriedade, fornecendo soluções de software
aberto, inovador e poderoso com a flexibilidade para atender a gestão de dados e integração
de aplicações às necessidades de todos os tipos de organizações.
Pela primeira vez uma companhia de código aberto aparece no “Quadrante Mágico” 7 do Gartner na categoria de “Integração de dados” em 2009 e 2010 e, em 2011, como
“Qualidade de dados”. A Talend faz sua entrada no quadrante como “visionária” baseada
na sua visão global e capacidade de execução. Veja o gráfico a seguir.
Gráfico 1 – Quadrante Mágico para Ferramentas de Qualidade de Dados
Fonte: GARTNER, 2011, p. 1
7 Para uma empresa ser incluída no “Quadrante Mágico”, precisa ter em seu portfólio de tecnologia com todas as capacidades que o Gartner considera mais importante no conjunto de todas as capacidades que são esperados a partir das ferramentas de “integração de dados” e/ou de “qualidade de dados”.
53
Uma ferramenta com características para o tratamento da “Qualidade dos dados”
fornece vasta funcionalidade, tais como análise, combinação, limpeza, normalização, dados
duplicados, entre outros.
O Talend Open Studio é uma ferramenta desenvolvida em Java baseada em
arquitetura modular formada por: Gerenciador gráfico de negócios, Gerenciador gráfico de
processo ETL, Gerenciador de metadados, Repositório de processos (apenas na versão
comercial), Interface web services8 e Monitor de Processos. Usando a API do sistema
podem ser desenvolvidos novos componentes personalizados pelo usuário.
O gerenciador gráfico de processos ETL é executado dentro do ambiente Eclipse,
por isso é um sistema “gerador de código”, responsável pela execução dos processos ETL,
ou seja, o Talend não requer um servidor de execução de processos ETL. A vantagem da
geração de código é que é mais simples integrar os processos ETL dentro de outros
aplicativos e os modelos são de portabilidade muito mais flexível.
A figura 16 exemplifica o fluxo de um modelo de negócio na ferramenta Talend
Open Studio versão 4.1 (Talend, 2011).
Figura 16 – Modelo Talend Open Studio
Fonte: Talend, 2011
8 Web Service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Permite às aplicações enviar e receber dados em formato XML.
54
Em sistemas com mecanismo de “geração de código”, permite a integração do
código gerado dentro de outras soluções, além de ter maior portabilidade. Produtos como
SpagoBI9, Ingres10, Teradata11 e JasperSoft12 são exemplos de uso do Talend integrado
como seu componente ETL padronizado.
O Talend Open Studio foi disponibilizado no mercado em 2005 pela empresa
Talend com sede na França, país com uma forte política de apoio a Software Livre e código
aberto. Analistas de TI como Forrester Research13, IDC14 e Bloor Research15 colocam o
Talend como o melhor sistema open source para atender necessidades de integração de
dados.
4.3.3 Ferramenta KETTLE (PENTAHO)
De acordo com a Pentaho (2011), o Pentaho Data Integration – PDI, também
conhecido como Kettle, é a ferramenta de ETL da Pentaho. Esse produto foi desenvolvido
em Java e é totalmente baseado em metadados16. No Kettle, o conceito de processo ETL
clássico (extração, transformação e carregamento) foi ligeiramente modificado, porque é
composto por quatro elementos ETTL, que significam:
- Extração de dados das bases de dados de origem;
- Transporte dos dados;
- Transformação dos dados;
- Carregando (Loading) dados em um data warehouse.
9 SpagoBI Studio é um ambiente para desenvolvimento OLAP. 10 Ingres provedor de soluções para gerenciamento e integração de dados e BI. 11 Teradata Inteligência em otimização de negócios em mineração de dados e BI. 12 Jaspersoft OLAP é um ambiente (software) de análise de dados. 13 Forrester Research é uma empresa de pesquisa tecnológica e de mercado que fornece conselhos pragmáticos à líderes mundiais em tecnologia e negócios. 14 International Data Corporation (IDC) é a principal provedora global de inteligência de mercado, serviços de consultoria e eventos para a tecnologia, telecomunicações, tecnologia da informação e dos mercados consumidores. 15 Bloor Research é uma das principais organizações independente de pesquisa em tecnologia da Europa. 16 Processo de criação em metadados: Camada física, camada de negócios e camada de visualização.
55
Assim, Kettle é um conjunto de ferramentas e aplicativos que permite manipulações
de dados através de múltiplas fontes. Abaixo são descritos os principais componentes do
Pentaho Data Integration – PDI (PENTAHO, 2011):
1. Spoon - uma ferramenta gráfica utilizada para modelar o fluxo de dados de um
processo de transformações ETTL. Desempenha as funções de fluxo de dados
típicos como a leitura, validação, refino, transformação, gravação de dados em uma
variedade de diferentes fontes de dados e destinos. As transformações projetadas em
Spoon podem ser executadas com Pan e Kitchen.
2. Pan - é uma aplicação dedicada para executar transformações de dados projetados
em Spoon.
3. Chef - uma ferramenta para automatizar tarefas de atualização do banco de dados de
uma forma complexa.
4. Kitchen - é um aplicativo que ajuda a executar as tarefas em modo de lote,
geralmente usando uma programação que torna fácil para iniciar e controlar o
processamento ETL.
5. Carte - um servidor web que permite o monitoramento remoto dos processos ETL
através de um navegador web.
Embora as ferramentas de ETL sejam mais frequentemente usadas em ambientes de
data warehouses, o Kettle também pode ser aplicado para outros fins:
- Migrar dados entre aplicações ou bases de dados;
- Exportar ou importar dados entre bancos de dados e arquivos simples;
- Carregar de dados maciçamente em bancos de dados;
- Limpar e analisar dados;
- Integrar aplicações.
56
Segundo a Pentaho (2011), o PDI/Kettle é fácil de usar e todo processo é criado
com uma ferramenta gráfica onde você especifica o que fazer sem escrever código para
indicar como fazê-lo; por isso pode-se dizer que o PDI/Kettle é orientado por metadados. A
figura 17 demonstra um modelo de fluxo de processo no Kettle.
Figura 17 – Modelo PDI / Kettle
Fonte: Pentaho, 2011
Conforme a Pentaho (2011), o PDI/Kettle pode ser usado como um aplicativo
independente ou pode ser usado partes da Suite Pentaho. Como uma ferramenta de ETL, é
o produto de código aberto mais popular disponível. O PDI/Kettle suporta uma vasta gama
de formatos de entrada e saída. Além disso, as capacidades de transformação do PDI/Kettle
permitem manipular dados com poucas restrições.
As principais fontes de dados e bases de dados em Kettle ETL são: Qualquer banco
de dados usando ODBC no Windows; Oracle; MySQL; AS/400; MS Access; MS SQL
Server; IBM DB2; PostgreSQL; Intersystems Cachê; Informix; Sybase; dBase; SQL
Firebird; MaxDB (SAP DB); Hypersonic; SAP R / 3 System (usando o plugin
ProSAPCONN).
57
5 ESTUDO DE CASO: EMPRESA DE PEQUENO PORTE
Neste capítulo são descritas e detalhadas as etapas de desenvolvimento do estudo de
caso para o projeto data mart vendas. Como o foco do trabalho está na etapa de ETL, ele
tem o objetivo de criar um mecanismo que ampare na decisão de escolha de uma
ferramenta de ETL para um dado projeto de DW.
O trabalho desenvolvido é um processo simples, mas completo de ETL (extração,
transformação e carga de dados) que será idêntico para cada uma das ferramentas avaliadas
Kettle/Pentaho e Talend Open Studio, para um data mart com o assunto vendas, utilizando
uma base de origem do ERP comercial Protheus versão 10 da Totvs, com dados maquiados
de uma empresa comercial de pequeno porte onde serão aplicados os conceitos e teorias
que vimos ao longo deste trabalho.
A preparação do laboratório envolveu cinco VM´s (máquina virtual) sendo: uma
VM foi reproduzida o ambiente OLTP com o banco de dados do ERP no SGBD SQL
Server 2005 sob o OS (sistema operacional) Windows 2003 Server. Outras duas máquinas
executando em cada uma as ferramentas ETL Kettle e Talend sob o OS Windows XP, por
último a instalação do ambiente data warehouse com o SGBD PostgreSQL sob o OS Linux
Ubuntu. A escolha destes sistemas para o ambiente DW deveu-se pela necessidade de
priorizar os produtos open source. Maiores detalhes sobre as configurações dos ambientes
do laboratório poder ser conferido no Anexo 1.
As etapas utilizadas no desenvolvimento deste estudo de caso foram:
1-Análise de requisitos e desenvolvimento da matriz do processo de negócio;
2-Definição do modelo conceitual (mapeamento da disponibilidade dos dados na
base transacional);
3-Extração dos dados, movimentação para staging area;
4-Necessidades de transformação, dimensão e fato;
58
5- Planejamento de carga das dimensões;
6- Planejamento de carga da tabela fato;
7- Notas do desenvolvimento.
5.1 ANÁLISE DE REQUISITOS E DESENVOLVIMENTO DA MATRIZ DO PROCESSO DE NEGÓCIO
Corey (2001) sugere que, antes da fase de levantamento e análise de requisitos, seja
feito um planejamento inicial. Neste documento, deve-se definir ao menos o patrocinador e
responsável pelo projeto, também deve justificar a necessidade do DW, delimitar o escopo
e construir um plano de longo prazo para o desenvolvimento do projeto.
Na fase seguinte, Corey (2001) recomenda o detalhamento dos requisitos. No estudo
de caso, este item foi alcançado através de reuniões com a direção e gerente de vendas da
empresa que foi objeto para o estudo de caso.
Após levantamento situacional e a assimilação por parte dos usuários quanto a
diferença entre os tipos de informações operacionais e estratégicas, foi possível categorizá-
las dentro do processo de negócio. Além disso, foram identificadas as questões mais
importantes para que priorização dos assuntos a serem praticados, aplicando o critério de
maior interesse e benefício para o negócio da empresa e com alta viabilidade de execução.
Na matriz do processo de negócio, foram descritos as medidas e dimensões
necessárias, assim como o nível de granularidade. Corey (2001) recomenda armazenar o
nível mais detalhado possível, embora isso resulte em requisitos e disco mais elevados, pois
as informações detalhadas tornam-se mais precisas e tem vantagens significativas no
sentido de que é possível reciclar consultas resumidas a partir de informações detalhadas,
mas não o contrário.
59
A seguir as tabelas 3 e 4 representam a Matriz de Processo de Negócio para o
projeto proposto.
Tabela 3 – Matriz de Processo de Negócio - Parte 1 Dimensões do
Negócio Vlr.Receita
- (Devolução) Qtd Venda
- (Devolução) Marg.Contrib - (Devolução)
Qtd Clientes - (Devolução)
Qtd Produtos - (Devolução)
Filial X X X X X
Cliente X X X X
Produto X X X X
Vendedor Interno X X X X X
Vendedor Externo X X X X X
Transportador X X X X X
Tempo (grão data) X X X X X Fonte: Autoria própria (2011).
Tabela 4 – Matriz de Processo de Negócio – Parte 2 (continuação)
Dimensões do Negócio
Esto
rno
ICM
S
Esto
rno
IPI
Cre
d.I
CM
S ST
Cu
sto
Em
bal
age
ns
Vlr
Fre
te V
en
da
Vlr
E.F
.
Vlr
. IC
MS
Vlr
. IP
I
Vlr
. Pis
/Co
fin
s
Cu
sto
Pro
du
to
Filial X X X X X X X X X X
Cliente X X X X X X X X X X
Produto X X X X X X X X X X
Vendedor Interno X X X X X X X X X X
Vendedor Externo X X X X X X X X X X
Transportador X X X X X X X X X X
Tempo (grão data) X X X X X X X X X X Fonte: Autoria própria (2011)
60
5.2 DEFINIÇÃO DO MODELO DIMENSIONAL
O modelo utilizado neste estudo de caso foi o Star Schema por tratar-se de um
modelo já consagrado e defendido pelos principais mentores em data warehouse como
Ralph Kimball e Inmon. E. Como bem coloca Corey (2001, p. 174) “O esquema Star é a
maneira mais popular de construir estruturas de dados data mart de alto desempenho em
um ambiente relacional”.
Em suma, um esquema de dados Star consiste em uma tabela central conhecida
como a tabela de fatos, rodeado por tabelas de dimensões de forma que a tabela fato tenha
indicadores do seu negócio como, por exemplo, o valor das vendas custo do produto e as
dimensões têm informações descritivas sobre os atributos do seu negócio, a exemplo de
cliente, vendedor e produto e outras.
Também foi necessário estabelecer as regras de atualização dos registros de
históricos das dimensões, além de esquematizar as chaves primárias e tipos de chave que
ligam as tabelas fato às dimensões. Pela necessidade de manutenção de históricos de
algumas tabelas, e pelos benefícios de desempenho nas consultas no data warehouse, foi
adotado nesta modelagem o recurso de chaves artificiais, conceituado por Ralf Kimball
(2002).
A seguir está apresentado o modelo arquitetado com base nas informações
levantadas na matriz de processo de negócios: composta por uma tabela Fato - Faturamento
e sete dimensões: Filial, Cliente, Produto, Vendedor Interno, Vendedor Externo,
Transportador e Tempo.
61
A figura 18 demonstra a modelagem dos dados de acordo com o paradigma star
schema.
Figura 18 - Ambiente OLAP - Modelagem Esquema Star
Fonte: Autoria própria (2011)
DIM_CLIENTE
SEQ_CLIENTE
COD_CLIENTE
LOJ_CLIENTE
NOM_CLIENTE
MUN_CLIENTE
UF_CLIENTE
COD_SEGMENTO
NOM_SEGMENETO
DTC_INICIO
DTC_FIM
DIM_FILIAL
SEQ_FILIAL
COD_FILIAL
NOM_FILIAL
DIM_PRODUTO
SEQ_PRODUTO
COD_PRODUTO
FOR_PRODUTO
NOM_PRODUTO
TIP_PRODUTO
GRP_PROTUTO
EMB_PRODUTO
DTC_INICIO
DTC_FIM
DIM_TEMPO
SEQ_TEMPO
DATA
DIA_SEMANA
DIA_MES
SEMANA_MES
MES
NOM_MES
TRIMESTRE
SEMESTRE
ANO
DIM_TRANSPORTADOR
SEQ_TRANSPORTADOR
COD_TRANSPORTADOR
NOM_TRANSPORTADOR
DIM_VENDEDOR_E
SEQ_VENDEDOR_E
COD_VENDEDOR_E
NOM_VENDEDOR_E
DIM_VENDEDOR_I
SEQ_VENDEDOR_I
COD_VENDEDOR_I
NOM_VENDEDOR_I
FAT_FATURAMENTO
NUM_NOTA_FISCAL
SER_NOTA_FISCAL
SEQ_FILIAL
SEQ_CLIENTE
SEQ_PRODUTO
SEQ_VENDEDOR_I
SEQ_VENDEDOR_E
SEQ_TRANSPORTADOR
SEQ_TEMPO
VAL_VENDA
QTD_VENDA
VAL_MARGEM_CONTRIB
VAL_CUST_PRODUTO
VAL_CUST_ICMS
VAL_CUST_IPI
VAL_CUST_PISCOFINS
VAL_CUST_EF
VAL_CUST_FRET_VEND
VAL_CUST_EMBALAGEM
VAL_CUST_EST_ICMS
VAL_CUST_EST_IPI
VAL_CRED_ICMS_ST
QTD_PRODUTOS
QTD_CLIENTE
62
A figura abaixo representa o modelo da fonte dos dados do ambiente transacional
extraído do banco de dados do ERP Protheus 10 da Totvs.
Figura 19 - Ambiente Transacional – Modelagem 3FN
Fonte: Autoria própria (2011)
5.3 EXTRAÇÃO DOS DADOS, MOVIMENTAÇÃO PARA STAGING AREA
A extração dos dados do ambiente transacional para o data warehouse foi realizada
em duas etapas: A primeira foi a movimentação apenas dos dados necessários para um
ambiente intermediário separado do ambiente transacional, ou seja, a staging area. E, com
o objetivo de preservar o desempenho do ambiente transacional, adotou-se o modelo da
staging area remoto, sendo que configurado para hospedar no mesmo ambiente do data
warehouse. Desta forma, na segunda etapa, a extração foi simplificada, uma vez que os
dados já tinham sido filtrados durante a carga da staging area.
Para uma análise justa na comparação entre as ferramentas de ETL, em todas as
ferramentas foram criados os mesmos projetos de nome “StagingArea” para desenvolver a
movimentação dos dados do ambiente transacional – OLTP para uma staging area. Abaixo
está uma representação ilustrativa das configurações para conexão com a fonte de origem
63
no banco de dados “DADOSADVII” no SQL Server 2005. A figura 20 mostra como
configurar uma conexão de fonte ou carga de dados na ferramenta Kettle/Pentaho.
Figura 20 – Menu Conexão Banco de Dados no Kettle/Pentaho
Fonte: Kettle/Pentaho (2011).
As informações que são necessárias para estabelecer a conexão com um banco de
dados são: tipo do banco ou uma conexão ODBC previamente configurada, login e senha,
nome do servidor, porta e nome do banco de dados, como mostra a figura 21.
Figura 21 - Conexão Banco de Dados no Kettle/Pentaho
Fonte: Kettle/Pentaho (2011).
64
Para estabelecer as conexões de input/output no Talend Open Studio, são
necessárias previamente configurá-las, conforme os passos indicados abaixo.
Figura 22 – Menu Conexão Banco de Dados no Talend
Fonte: Talend (2011)
As informações básicas necessárias para estabelecer a conexão com um banco de
dados são: tipo do banco ou uma conexão ODBC previamente configurada, login e senha,
nome do servidor, porta e nome do banco de dados, como mostra a figura 23.
Figura 23 - Conexão Banco de Dados no Talend
Fonte: Talend
65
O processo de movimentação dos dados entre os ambientes transacional e a staging
area priorizou não extrair dos campos desnecessários para o data warehouse, uma vez que
as tabelas do ERP Protheus10 são extremamente grandes, ou seja, muitas colunas
desnecessárias para o projeto. Com isso, além de simplificar as tabelas outro benefício é o
ganho de tempo na janela de transferência para staging area. Devido às características do
ambiente de porte médio em volume de dados, as tabelas são sempre copiadas
integralmente em cada carga. Na sequência, a ilustração do mapeamento das tabelas para
movimentação de dados entre o ambiente transacional e a staging area, igualmente com as
duas ferramentas de ETL Kettle/Pentaho e Talend Open Studio.
A figura abaixo representa o fluxo de dados do ambiente OLTP para staging area com a ferramenta Kettle/Pentaho.
Figura 24 - Movimentação de Dados para Staging Area no Kettle
Fonte: Kettle (2011)
A figura 25 representa o fluxo de dados do ambiente OLTP para staging area com a ferramenta Talend.
66
Figura 25 - Movimentação de Dados para Staging Area no Talend
Fonte: Talend (2011)
5.4 NECESSIDADES DE TRANSFORMAÇÃO, DIMENSÃO E FATO
Das necessidades de transformações de dados, também exigiu-se pouco das
ferramentas, dado a simplicidade do projeto aplicado. Contudo, foi possível analisar alguns
dos componentes existentes nas ferramentas para apoiar nas necessidades nas
transformações de dados, funções de agregação/desagregação, comparações, matemáticas e
principalmente nos componentes utilizados para atualizar as tabelas de dimensões e fato.
Abaixo a figura 26 ilustra o componente utilizado para uma junção das tabelas
Cliente <–> Segmento, mas, com esse componente, também é possível agregar ou
desagregar um dado, implementar funções matemáticas, modificar o tipo do campo, de
numérico para string e vice-versa, entre outros.
67
Figura 26 – Componente tMap do Talend Open Studio – Tabela Cliente
Fonte: Talend (2011)
Com o mesmo componente “tMap”, também foi possível utilizar recursos para
cálculos matemáticos, exemplo do campo “Valor Margem de Contribuição” durante a carga
da tabela fato. Conforme exemplifica a figura a seguir.
Figura 27 – Componente tMap do Talend Open Studio – Calculo da Margem de Contribuição
Fonte: Talend (2011)
Ao contrário do componente tMap da Talend, visto anteriormente, utilizamos o
componente “Database Lookup” do Kettle que não agrega tantas funções, contudo é
flexível o suficiente para utilizá-lo em diversas situações de pesquisa entre tabelas. Abaixo
68
a figura 28 ilustra uma pesquisa do campo de descrição do segmento para “desnormalizar”
a tabela de Cliente.
Figura 28 – Componente Database Lookup do Kettle – Tabela Cliente
Fonte: Kettle (2011)
Diferentemente do Talend, no Kettle empregamos o componente Calculator,
também na carga da tabela fato, para resolver a equação do “Valor Margem de
Contribuição”, conforme mostra a figura 30.
Figura 29 – Componente Calculator do Kettle – Calculo da Margem de Contribuição
Fonte: Kettle (2011)
69
5.5 PLANEJAMENTO DE CARGA DAS DIMENSÕES
Os componentes utilizados para o processo de carga das tabelas de dimensão foram
os que mais exigiram estudo e esforço para entendimento sobre seu funcionamento e para
possibilitar o controle das alterações dos dados nas dimensões, esquemas conhecidos por
SCD (Slowly Changing Dimension) tipos 1, 2 e 3.
Abaixo os exemplos para o resultado esperado nas tabelas de dimensões para cada
tipo de versão com o controle SCD de acordo com os conceitos desenvolvidos por
Kimball(2002):
Tipo 1 – Não existe controle de versão dos registros, as alterações são realizadas no
próprio registro da tabela de dimensão:
Chave Codigo_Vendedor Nome_Vendedor
01 000123 PAULO DA SILVA
02 000323 JOSE RIBEIRO
Tipo 2 – Neste tipo ocorre o controle de versão dos registros na dimensão:
Chave CODIGO NOME_CLIENTE SEGMENTO Version Dtc_ini Dtc_fim
01 099665 BRASIL LIMP QUIMICO 1 01-03-10 NULL
02 043323 TINTAS ESTRELA TINTAS 1 10-05-11 NULL
No exemplo acima, o campo controlado tipo 2 é o “SEGMENTO”. Quando na
ocorrência de alteração, será gerada uma nova chave artificial para o registro. O campo
“Version” será incrementado de ‘1’ e será atualizado o campo ‘Dtc_fim’ indicando o
período de tempo pelo qual ele ficou ativo. Observe que o campo ‘“NOME_CLIENTE”,
70
definido como tipo 1, caso sofra alteração, terá seu histórico corrigido, pois considera-se
que o motivo da alteração foi para corrigir um erro de digitação:
Chave CODIGO NOME_CLIENTE SEGMENTO Version Dtc_ini Dtc_fim
01 099665 BRASIL LIMP LTDA. QUIMICO 1 01-03-10 23-10-11
02 043323 TINTAS ESTRELA TINTAS 1 10-05-11 NULL
03 099665 BRASIL LIMP LTDA. LIMPEZA 2 23-10-11 NULL
Tipo 3 – O controle da alteração é através de uma nova coluna (valor anterior):
Chave CODIGO NOME_CLIENTE SEGMENTO SEGM_ANTERIOR
01 099665 BRASIL LIMP QUIMICO
02 043323 TINTAS ESTRELA TINTAS
Aproveitando o exemplo anterior, apenas o campo ‘SEGM_ANTERIOR’ será
atualizado com a última informação, o nome do cliente também é alterado no próprio
registro:
Chave CODIGO NOME_CLIENTE SEGMENTO SEGM_ANTERIOR
01 099665 BRASIL LIMP LTDA LIMPEZA QUIMICO
02 043323 TINTAS ESTRELA TINTAS
Na ferramenta de ETL Kettle, foi possível aplicar com um mesmo componente, o
“Dimension Lookup/Update”, a carga das tabelas de dimensões Tipo 1 e 2. (Para atender as
alterações do tipo 3, foi utilizado outro componente) Com esse componente, foi possível
controlar a “chave substituta” ou “Technical key Field” e escolher o tipo de recurso de
versão para o tipo 2.
71
A figura a seguir representa um exemplo de como o componente ‘Dimension
Lookup/Update’ foi configurado. Observe que, na aba ‘Field’ em destaque, o controle
‘Type of dimension update’ (tipo de atualização da dimensão) é onde se determina se vai
existir, caso existindo, define o tipo de controle da dimensão, sendo: ‘Punch through’ para
tipo 1 e ‘Insert’ para tipo 2.
Figura 30 – Componente Dimension Lookup/Update do Kettle – SCD tipo 1 e 2
Fonte: Kettle (2011)
Da mesma forma com a ferramenta de ETL Talend, foi possível desenvolver os
controles de alteração lenta das dimensões, utilizando o componente ‘tPostgreSqlSCD’.
Uma diferença sutil com relação ao Kettle é que alguns componentes são exclusivos para
cada tipo de banco de dados. Já com o Talend foi possível resolver todos os tipos de
alteração na tabela de dimensão com um único componente. A utilização do componente é
muito simples e intuitiva, a carga inicial dos campos da tabela é feita na caixa “Unused’ no
campo superior. Em seguida, basta arrastar e soltar o campo na caixa correspondente ao
tipo de versão desejado, assim como a chave artificial e as datas início e fim, veja a
ilustração a seguir.
72
Figura 31 – Componente ‘tPostgreSqlSCD’ do Talend – SCD tipo 1, 2 e 3
Fonte: Talend (2011)
5.6 PLANEJAMENTO DE CARGA DA TABELA FATO
O desenvolvimento do gráfico na ferramenta ETL Kettle utilizou uma estratégia
simples. Apenas com a utilização do componente ‘Database lookup’, foi possível resolver a
questão da carga da tabela fato ‘Vendas’. Abaixo um exemplo de como foram configurados
os campos que comparam as datas início e fim com a ocorrência da venda (fato) na tabela
‘Cliente’.
Figura 32 – Componente ‘Database lookup’ do Kettle – Carga Tabela Fato Vendas
Fonte: Kettle (2011)
73
Para a carga da tabela fato Vendas com a ferramenta ETL Talend Open Studio, o
principal componente utilizado foi o ‘tMap’, como já visto anteriormente na carga de
dimensão com recursos e na utilização de cálculos matemáticos. Sendo um componente
muito versátil nos permitiu, também, aplicá-lo na carga da tabela fato. A figura 33
exemplifica como o componente foi configurado para atender o objetivo de buscar nas
dimensões a chave substituta corretamente com destaque para o ‘Construtor de expressão’
que se comporta como um assistente para comparar as datas.
Figura 33 – Componente ‘tMap’ do Talend – Carga Tabela Fato Vendas
Fonte: Talend (2011)
A figura a seguir mostra como ficou o gráfico completo no Talend para
carregamento da tabela fato Vendas.
Figura 34 – Modelo do Talend – Carga Tabela Fato Vendas
Fonte: Talend (2011)
74
5.7 NOTAS DO DESENVOLVIMENTO
Podem-se destacar algumas considerações relativas às experiências vividas durante
o desenvolvimento do estudo de caso, tais como:
a) Inicialmente ambas as ferramentas, tanto o Talend quanto o Kettle, demonstraram
terem recursos suficientes para atender o projeto proposto, atendendo o requisito de não
necessitar de utilizar programação por código para suprir qualquer deficiência de um
componente.
b) Na etapa de “Extração dos dados, movimentação para staging area”, onde foram
criadas as conexões com os bancos de dados, utilizados componentes de Input/Output.
Embora nas ferramentas não houvesse dificuldades para criar as conexões com o banco de
dados e também atendesse nativamente os bancos de dados do projeto, entre eles o SQL
Server, Oracle, MS Sql Server e o PostgreSQL, também não houve necessidade de baixar
componentes extras ou fazer atualizações. Além disso, todas as ferramentas disponibilizam
o recurso para testar a conexão, entretanto vale ressaltar:
- Kettle: Possui uma interface intuitiva com destaque para um assistente que facilita o
passo-a-passo para criar uma nova conexão e disponibiliza um número significativo (35) de
drivers nativos para conexão com os bancos de dados.
- Talend: Com interface intuitiva e também possuiu um número significativo (34) de
drivers nativos para conexão com os bancos de dados. Outro recurso muito útil é a
facilidade “arrasta-e-solta”. A partir das conexões existentes, é possível selecionar
componentes, por exemplo: input, output, SCD entre outros. A figura 35 mostra essa
facilidade.
75
Figura 35 – Exemplo Facilidade para Criar Componentes a Partir de Conexões
Fonte: Talend (2011)
c) Ainda que o processo de movimentação dos dados entre os ambientes
transacional e a staging area fosse muito simples, é possível destacar algumas diferenças
entre as ferramentas: Kettle/Pentaho e Talend Open Studio.
- Kettle: Com esta ferramenta já foi possível mapear as tabelas desfrutando de um
facilitador, desde que se obedeça a uma sequência de desenvolvimento. Após ligar os
componentes “input – conector – output”, é possível aplicar o assistente para gerar o
mapeamento automático.
- Talend: Ao contrário da ferramenta Kettle, foi necessário inserir mais um componente no
mapeamento de cada tabela: “input – conector – Mapeamento - conector output”. No
entanto, este novo elemento não acrescentou dificuldades, ao contrário, após a definição
dos metadados, nesta ferramenta, o mecanismo de assistência deixa o desenvolvimento bem
simplificado.
76
d) Na operação de “Transformação da Dimensão e fato”, dada a simplicidade do
projeto e o fato de ter trabalhado com os dados de origem de uma única fonte, não houve
exigências destas funções. No geral, nas duas ferramentas pesquisadas, os componentes são
bem flexíveis e permitem agregar vários recursos em um mesmo componente:
- Talend: Como exemplo, temos o componente “tMap” do Talend Open Studio. Com ele é
possível integrar, transformar, unir tabelas, criar novos campos. Comprovou ser um
componente muito poderoso, incluindo um assistente para gerar fórmulas.
- Kettle: Com essa ferramenta, optamos pelo componente “Database Lookup”, com a
função mais específica para pesquisas de dados, mas eficiente e flexível o necessário para
atender o seu propósito. Outras facilidades estão disponíveis, como exemplo um assistente
para carga dos campos das tabelas, gerando código SQL para corrigir a tabela de dimensão.
E, para completar essa fase, recorreu-se a outro componente, “Calculator” e, da mesma
forma, não houve dificuldades na sua aplicação.
e) Na “Carga das Tabelas de Dimensão”, o processo de desenvolvimento na carga
da dimensão ainda que simples, exigiu grande parte do tempo em pesquisa, pois em ambas
as ferramentas ocorreram situações onde a falta de observação de alguns detalhes impediu o
bom funcionamento do componente.
- Kettle: Nesta ferramenta, apesar de não ser um fator critico, foi necessário utilizar mais
de um componente para atender os três tipos de alteração lenta da tabela de dimensão.
Contudo, no Kettle, a representação gráfica para esse processo ficou mais limpa, por não
exigir componentes adereços para o fechamento do processo como um todo. Porém, um
detalhe muito importante que não pode passar despercebido é a nota referente à carga
inicial da tabela, onde exige-se que, na tabela, exista o primeiro registro com a chave
substituta 0 ou 1 e demais campos zerados ou em branco. Caso não exista, o Kettle vai
incluir esse registro, mas para isso é necessário que não exista campo com o tipo ‘NOT
NULL’, senão o processo será abortado com erro de execução.
77
- Talend: Nesta ferramenta foi mais fácil mapear os campos de acordo com as necessidades
de controle de alteração lenta nas tabelas de dimensão, não só porque todos os tipos de
alteração lenta (1, 2 e 3) estão concentrados num único componente, mas também a
facilidade de ‘arrastar e soltar’ os campos entre as caixas de controle. Entretanto, para
execução deste recurso no painel gráfico é necessária a presença de mais dois componentes
‘tPostgreConnection’ e ‘tPostgreCommit’ que funcionam como ‘trigger’ (gatilhos), algo
que não deixa o processo muito intuitivo, pois a compreensão de sua aplicação exigiu um
estudo mais detalhado nos tutoriais e modelos com exemplos.
f) Finalmente na “Carga da Tabela Fato”, última etapa do processo de
movimentação de dados, a carga da tabela fato, ao contrário das dimensões, exigiu um
pouco mais de trabalho manual na criação da rotina, devido ao grande número de campos e
o tratamento da localização das chaves substitutas correspondentes em cada tabela
dimensão.
- Kettle: A representação gráfica nesta ferramenta ilustrada na figura 32 está disposta de
forma sequencial. O componente ‘Database Lookup’ se repete para cada dimensão
objetivando pesquisar a chave substituta correspondente de cada dimensão. Ao final, todos
os campos são gravados na tabela fato. Apesar de haver uma repetição do mesmo
componente de pesquisa ‘Database Lookup’, este fato não aumentou a dificuldade no
desenvolvimento desta etapa. Ao final, aparentou ser mais simples do que no Talend.
- Talend: Já com o Talend, demonstrada na figura 34, o formato de estrela é visualizado,
isso porque o componente ‘tMap’ une todas as tabelas dimensão e fato. Apesar de
centralizar todas as junções (‘join’) em um único componente, isso deixou um pouco mais
trabalhoso para configurar este esquema. Contudo, não prejudicou em nada o objetivo do
projeto.
78
6 AVALIAÇÃO DAS FERRAMENTAS DE ETL
Neste capítulo, descreve-se a avaliação das ferramentas ETL open-source alvo do
trabalho com a classificação e pontuação dos requisitos para o desenvolvimento do estudo
de caso.
A decisão pela escolha de uma ferramenta de ETL para um data warehouse,
infelizmente, é um trabalho que apenas o responsável pelo projeto é capaz de decidir. Como
bem coloca Corey (2001, p. 239),
[...] o único recurso disponível e pronto para resolver todos os problemas de ETL, não são as ferramentas, nenhuma ferramenta individualmente traz uma solução completa, portanto, o único item disponível o tempo todo pronto para resolver os problemas de ETL é VOCÊ.
Desta forma, apenas o gerente do projeto é capaz de saber das necessidades e ter o
conhecimento suficiente das necessidades do seu ambiente. Corey (2001) ainda
complementa dizendo que “VOCÊ pode ser sua própria bala de prata” para o projeto ETL.
Deste modo, a proposta apresentada aqui é um modelo para apoiar na decisão de
uma escolha segura e mais adequada da ferramenta de ETL para um dado projeto de data
warehouse. Entretanto, o resultado apresentado neste trabalho, ou seja, a ferramenta de
ETL selecionada possivelmente será a melhor opção apenas para o projeto proposto no
estudo de caso, podendo ser avaliada outra solução em um contexto diferente. Contudo,
este fato não inviabiliza a metodologia (ou método) que pode ser aplicada em outros
projetos de data warehouse.
6.1 IDENTIFICAÇÃO DOS REQUISITOS
A lista de possíveis requisitos de uma ferramenta ETL para o desenvolvimento de
um projeto de data warehouse foi elaborada a partir de diversas fontes de informações,
sendo que as principais foram:
79
• COREY (2001) capítulo 9 (Fundamentos de uma arquitetura ETL) de seu
livro Oracle 8i Data Warehouse;
• GONÇALVES (2003) capítulo 4 (Ferramentas Existentes) publicado em seu
livro Extração de Dados para Data Warehouse. Neste trabalho, Gonçalves
(2003) também faz comparações dos recursos entre as principais ferramentas
de ETL desta época, abrangendo os produtos comerciais e open source; e a
• PASSIONNED (2011) uma organização de consultoria independente que
elaborou uma pesquisa sobre as principais ferramentas de ETL da
atualidade, comerciais e open source.
Para melhor entendimento e organização, a lista de requisitos foi dividida em nove
grupos: 1) Arquitetura e Escalabilidade; 2) Funcionalidade ETL; 3) Facilidade de uso;
4) Reutilização; 5) Depuração; 6) Mecanismo de processamento; 7) Conectividade;
8) Garantia de qualidade dos dados; e 9) Características Gerais.
A lista completa dos requisitos encontra-se disponível no ANEXO-2 da dissertação,
onde está registrada a importância e objetivo de cada critério pontuado.
6.2 AVALIAÇÃO DOS REQUISITOS
No tocante a projetos de DW em empresas de pequeno porte, alguns requisitos
citados na lista completa do ANEXO II foram excluídos do processo de avaliação por
considerar que tais critérios são incompatíveis com projetos de abrangência limitada. Nesta
linha de pensamento, recursos avançados como suporte a processamento paralelo ou multi-
80
processamento (SMP17 ou MPP18), suporte a Cluster19 e processamento em Grid
20, quando
aplicáveis, estão disponíveis apenas nas versões comerciais destas ferramentas de ETL, o
que foge ao foco do trabalho.
Utilizando essa mesma linha de raciocínio, critérios referentes a desempenho das
ferramentas foram excluídos para não cometer equívocos ou avaliações imprecisas, pois
uma série de variáveis estão ligadas a esta questão, como por exemplo, banco de dados
envolvidos na extração e carga, o hardware, o sistema operacional, a topologia da rede e
outros que dificultariam a medição precisa dos resultados.
Para os indicadores compatíveis com projetos de DW em empresas de pequeno
porte, foi aplicada uma classificação dos requisitos de acordo com a sua relevância, ou seja,
os requisitos foram qualificados em “obrigatórios” ou “desejáveis”, onde esta definição foi
baseada nas necessidades do estudo de caso, no caso um projeto com abrangência limitada.
A concepção da metodologia definiu a aplicação de pesos para os critérios definidos
como obrigatórios e desejáveis com o objetivo de permitir uma avaliação mais justa e
precisa de cada um dos critérios. Para tanto, foi aplicado o peso 1 (um) para os critérios
desejáveis e peso 2 (dois) para os critérios obrigatórios, onde:
- Critérios Desejáveis: requisitos que possuíam atributos importantes para o
desenvolvimento do projeto, porém que sua ausência ou deficiência
não é um fator impeditivo na conclusão do estudo de caso proposto.
- Critérios Obrigatórios: ao contrário dos requisitos desejáveis, sua ausência ou
deficiência traz algum tipo de prejuízo para o desenvolvimento do
projeto.
17 Multi-processamento simétrico. 18 Processamento Paralelo Massivamente. 19 Agrupamento de recursos que fornecem ao sistema a ilusão de um recurso único,utilizado para balanceamento de carga ou para alta disponibilidade. 20 Semelhante ao Cluster, Grid consiste em combinar o poder de processamento de vários computadores interligados em rede para conseguir executar tarefas que não seria possível (ou pelo menos não com um desempenho satisfatório) executar utilizando um único computador.
81
Posteriormente, foi aplicada uma nota entre 1 e 4, para cada critério referente às
ferramentas de ETL alvo do trabalho, baseada na seguinte classificação:
1 – Fraco
2 – Regular
3 – Bom
4 – Excelente
Os critérios, pesos e notas aferidas estão registradas na tabela abaixo. Os detalhes de
cada critério em cada ferramenta estão registrados no anexo III da dissertação.
Tabela 5 – Requisitos Relevantes com as Respectivas Avaliações 1 Arquitetura e Escalabilidade Peso K T 1.10 Controle de versão do sistema
Neste quesito, notou-se uma superioridade na ferramenta Talend, com recursos mais apurados, possibilitando o gerenciamento de versão de cada “Job” dentro de um projeto, além de fácil utilização. Já no Kettle, não encontramos essa facilidade. Mais.
1 2 4
Apesar da relevância, a classificação “desejável” justifica-se por não ser um impeditivo para a conclusão do desenvolvimento.
2 Funcionalidades ETL Peso K T 2.3 União: Essa funcionalidade foi explorada na carga da tabela fato,
através da leitura dos registros transacionais de vendas e com pesquisa das chaves substitutas nas dimensões. As duas ferramentas se saíram bem, contudo no Kettle foi um pouco mais fácil utilizando o componente “Lookupupdate” ao contrário do componente “tMap” no Talend que, apesar de ser muito poderoso, conseguiu congregar muitas tabelas com muitos campos, deixando o desenvolvimento mais trabalhoso. Além disso, o aspecto visual no resultado do gráfico também ficou mais intuitivo no Kettle, podendo ser constatado nas figuras 32, 33 e 34.
2 4 3
82
A qualificação “obrigatório” justifica-se pela importância deste recurso no projeto, sua principal aplicação foi na carga da tabela fato.
2.8 Dimensões de alteração lenta: Ao contrário da carga da tabela fato, na carga das tabelas de dimensões, em ambas as ferramentas exigiram um tempo maior de estudo. Podemos destacar a Talend por possibilitar em um único componente todos os tipos de SCD e com a interface bastante intuitiva, com recursos “arrastar-e-soltar”. Já com o Kettle, o recurso está fragmentado em vários componentes, mas a maior dificuldade encontrada foi resolver algumas “notas” de documentação que não poderiam passar despercebidas, além de não ter um componente específico para o tipo 3 de alteração lenta. A evidência desta avaliação foi demonstrado na figura 30 e nos capítulos 5.5 e 5.7.
2 2 4
Recebeu a qualificação “obrigatório”, uma vez que esse requisito tem grande importância para o projeto, por ser o responsável pela carga das tabelas de dimensões de alteração lenta.
2.10 Tratamento de erros no processamento: Apesar de não ter utilizado essa funcionalidade no projeto, mas pode-se observar que, no Kettle, existe em alguns componentes e funciona como um filtro, destinando linhas com problemas para um ‘step’ (caminho) específico e seguindo o fluxo da transformação apenas as linhas ‘saudáveis’, ou seja, linhas que não causaram nenhum erro na execução da transformação. De forma muito semelhante, o Talend também trata as ocorrências de erros durante o processamento, podendo ser configurado no próprio componente caminhos alternativos (SubJobs) ou utilizar um componente específico para tratamento de erro “tDie’.
1 3 3
Como não houve necessidade de utilizar o recurso no desenvolvimento do estudo de caso, a classificação para esse requisito ficou como “desejável”.
2.11 Análise de impacto: Só encontramos o recurso de “Análise de Impacto” na ferramenta Kettle. Este gera um relatório das etapas da transformação que se utiliza de conexão com banco de dados, fornecendo uma lista informações como: as tabelas acessadas, tipo de acesso se leitura ou gravação, o código da query, entre outros. No Talend, esse recurso só está disponível nas versões pagas, conforme documento Data Integration Features Comparison
Matrix (Talend, 2011).
1 3 0
83
A classificação para esse requisito como “desejável” é de não ter sido um fator condicionante para o estudo de caso desenvolvido, nem impeditivo para a conclusão do projeto.
2.12 Dados linhagem: No Talend, ao modificar qualquer um dos parâmetros de uma entrada na exibição em árvore do repositório, todos os trabalhos usando esta entrada do repositório será afetado pela modificação. Desta forma, a ferramenta solicitará que se propaguem estas modificações a todos os trabalhos que usam a entrada no repositório. De maneira semelhante no Kettle, ocorre a propagação das modificações e, nas duas ferramentas, possuem recursos para exibir em cada passo do processo (componentes) quais os atributos estão entrando e saindo.
2 3 3
O recurso foi um facilitador muito utilizado durante o desenvolvimento do projeto, motivo pelo qual foi classificado como “obrigatório”.
2.13 Documentação automática: A geração de uma documentação automática, incluindo detalhes das configurações da cada componente foram encontrados apenas na ferramenta Talend. Já no Kettle foi verificada a possibilidade de exportar o projeto para o formato “XML” e, a partir deste, gerar a documentação com ferramentas de terceiros, contudo não tão detalhada se comparado com relatório do Talend.
1
1 4
O recurso foi classificado como “desejável”, pois a sua ausência não seria impeditivo para o trabalho.
3 Facilidade de uso Tratando-se dos critérios de julgamento mais subjetivos, os relatos serão baseados nas experiências vivenciadas durante o desenvolvimento do estudo de caso.
Peso K T
3.1 Facilidade de uso: Essa análise ficou dividida. Em alguns pontos, houve mais facilidades de uso com Talend, em outros, com Kettle, o mesmo se aplica a design intuitivo. De uma forma geral, a curva de aprendizagem foi mais rápida no Kettle. Já com o Talend, torna-se mais fácil após um tempo de adaptação trabalhando com a ferramenta.
1 3 2
Para não fugir à regra, o requisito foi classificado como “desejável” por não ser um impeditivo para o desenvolvimento do estudo de caso.
84
3.2 WYSIWYG: Ambas as ferramentas dominam bem esse princípio de “Aquilo você vê é o que você obtém”, evidentemente requer do desenvolvedor um bom domínio das boas práticas de desenvolvimento.
1 3 3
Idem item 3.1.
3.3 Design de tela: Tanto o Kettle quanto o Talend demonstram um equilíbrio na apresentação das telas.
1 3 3
Um bom design é “desejável”, pois não impede o desenvolvimento trabalho.
3.5 Necessidade de Treinamento: Sim, é fundamental a necessidade de treinamento só assim o desenvolvedor será capaz de usufruir de maneira mais eficiente os recursos oferecidos por essas ferramentas na sua totalidade.
2 2 2
A qualificação deste requisito como “obrigatório” justifica-se por entender que se houvesse um treinamento especializado nas ferramentas testadas, antes de iniciar o projeto estudo de caso, o tempo gasto com avaliação seria infinitamente menor e, provavelmente, teria mais qualidade e seria mais abrangente.
3.6 Integralidade do GUI: Para o projeto proposto no estudo de caso foi 100%.
2 4 4
Este item é um dos pré-requisitos “obrigatórios” para aceitar a ferramenta de ETL para avaliação. Ter todos seus componentes integrados ao GUI (Graphical User Interface ou Interface Gráfica para o Usuário).
4 Reutilização Peso K T 4.1 Reutilização de componentes: Dentro do projeto foi pouco
explorado esse requisito, ficou mais visível a reutilização dos metadados e conexões com banco de dados. Mas, essa facilidade foi constatada nas duas ferramentas, tanto na reutilização de componentes como de “Jobs”. Contudo, no Talend, devido a sua característica de desenvolvimento por projetos, facilitou o entendimento deste conceito.
2 3 4
A classificação deste requisito como “obrigatório” deve-se a importância do recurso para garantir qualidade do código e padronização no desenvolvimento, facilitando manutenções corretivas e evolutivas nas rotinas ETL.
85
5 Depuração Peso K T
5.1 Execução Passo-a-passo: Esse recurso foi pouco explorado, pois julgamos que esse tipo de análise exige uma experiência maior do desenvolvedor. Contudo, pode-se observar que o debug no Talend é baseado no Eclipse. Com isso, pode-se seguir a linha de execução e ver o código fonte, como se estivesse programando em Eclipse. Também é possível incluir estatísticas de visualização dos dados ou tempos de resposta na execução da ferramenta gráfica. Já com o Kettle, o depurador é mais simples, mas da mesma forma exige uma boa experiência na interpretação das mensagens de erro.
2 2 3
As funções de depuração mereceram a qualificação de “obrigatório”, pois sem esses recursos seria quase impossível analisar e resolver os problemas durante o processo de desenvolvimento.
5.3 Ponto de Parada (Breakpoints): As duas ferramentas disponibilizam esse quesito, porém vale as mesmas observações do item 5.1.
2 3 3
Idem 5.1.
5.5 Compilador/Validador: O recurso para validação do gráfico antes da execução só foi encontrado no Kettle; no Talend, o recurso não foi encontrado.
1
3 0
O recurso de validação foi qualificado como “desejável”, porque não é um impeditivo para o desenvolvimento do trabalho.
7 Conectividade Peso K T
7.1 Conexões nativas: tanto Kettle como Talend atenderam com conectores nativos os bancos de dados utilizados no estudo de caso, sendo eles SQL Server e PostgreSQL. Além desses conectores, ambas as ferramentas oferecem outras dezenas.
2 4 4
Ter conexão nativa com os principais bancos de dados é uma qualificação “obrigatória”, já que sem o recurso seria um impeditivo para desenvolver o trabalho.
7.6 Plataformas: Tanto Kettle quanto Talend prometem independência de plataforma.
2 4 4
O produto ser compatível com as principais plataformas utilizadas atualmente (Windows e Linux) é um item importante, por isso foi classificado como “obrigatório”.
86
9 Características Gerais Ferramenta ETL Peso K T 9.1 Versão: As versões Open Source disponibilizadas são tão recentes
quanto às versões comerciais. 2 4 4
Esse requisito mostra a importância que o fabricante dá para a versão Open Source, por isso foi classificada como “obrigatória”.
9.2 Motor Gerador de Código: Uma das principais diferenças entre as ferramentas Kettle e Talend é o conceito de construção: – Talend é um gerador de código (Java ou Perl) e Kettle salva seus procedimentos em XML que é executado por um interpretador o “Pan”. No que se refere ao estudo de caso, não houve diferença.
1 4 4
O conceito de construção é relevante, porém “desejável”, porque não interfere em projetos de pequeno porte.
6.2.1 Resumo das pontuações
O resultado da soma das pontuações coloca a ferramenta ETL Talend com uma
pequena vantagem. As maiores diferenças ficaram por conta dos requisitos: recurso de
versionamento; facilidade de uso do componente de carga das tabelas de dimensões com
alteração lenta; e documentação automática, que são os maiores destaques na ferramenta
Talend.
Entretanto, pode parecer uma aparente contradição no grupo “3) Facilidade de uso”
onde há uma pequena vantagem para o Kettle, contudo este fato se explica pela questão de
avaliar o conceito de funcionamento da ferramenta como um todo que teve sua curva de
aprendizagem mais rápida no Kettle do que na ferramenta Talend.
A seguir demonstraremos os quadros com resultados das pontuações atribuídas.
87
Tabela 6 - Pontuações por Item de Requisito Nota Ponderada
Item Requisito Peso K T K T
1 Arquitetura e Escalabilidade 2 4
1.10 Controle de versão do sistema 1 2 4 2 4
2 Funcionalidades ETL 25 27
2.3 União. 2 4 3 8 6
2.8 Dimensões de alteração lenta. 2 2 4 4 8
2.10 Tratamento de erros no processamento 1 3 3 3 3
2.11 Análise de impacto 1 3 0 3 0
2.12 Dados linhagem 2 3 3 6 6
2.13 Documentação automática 1 1 4 1 4
3 Facilidade de uso 21 20
3.1 Facilidade de uso 1 3 2 3 2
3.2 WYSIWYG 1 3 3 3 3
3.3 Design de tela 1 3 3 3 3
3.5 Necessidade de Treinamento 2 2 2 4 4
3.6 Integralidade do GUI 2 4 4 8 8
4 Reutilização 6 8
4.1 Reutilização de componentes 2 3 4 6 8
5 Depuração 13 12
5.1 Execução Passo-a-passo 2 2 3 4 6
5.3 Ponto de Parada (Breakpoints) 2 3 3 6 6
5.5 Compilador/Validador 1 3 0 3 0
6 Mecanismo de processamento 0 0
7 Conectividade 16 16
7.1 Conexões nativas 2 4 4 8 8
7.6 Plataformas 2 4 4 8 8
8 Garantia de Qualidade dos Dados 0 0
9 Características Gerais Ferramenta ETL 12 12
9.1 Versões Open Source disponibilizadas 2 4 4 8 8
9.2 Motor Gerador de Código 1 4 4 4 4
NOTA GERAL 95 99 Fonte: Autoria própria (2011).
88
Tabela 7 - Resumo das Pontuações por Categoria de Requisitos
Item Grupo Critérios Kettle Talend 1 Arquitetura e Escalabilidade 2 4 2 Funcionalidades ETL 25 27 3 Facilidade de uso 21 20 4 Reutilização 6 8
5 Depuração 13 12
6 Mecanismo de processamento - -
7 Conectividade 16 16
8 Garantia de Qualidade dos Dados - -
9 Características Gerais Ferramenta ETL 12 12
TOTAL 95 99 Fonte: Autoria própria (2011).
Gráfico 2 – Por Categoria de Requisitos
Fonte: Autoria própria (2011).
0
5
10
15
20
25
30
Kettle
Talend
89
7 CONCLUSÃO
Certamente ao se perguntar para qualquer especialista que conheça muito bem os
produtos Kettle e Talend qual é a melhor ferramenta de ETL, o especialista, sendo coerente,
jamais indicará uma ou outra ferramenta sem saber qual o propósito de seu projeto.
Diversos estudos comparativos estão disponíveis na Internet, onde podem ser encontrados
dezenas de comentários e estudos, alguns deles até patrocinados pelos próprios fabricantes
sobre características, pontos fracos e pontos fortes, comparativos de medições e
desempenho em relação às ferramentas avaliadas pelo método concebido neste trabalho.
Conforme mencionado em passagens anteriores, não é pretensão deste trabalho
julgar a melhor ferramenta de ETL. A principal contribuição desta pesquisa foi apresentar
um modelo de avaliação de ferramentas ETL que atendesse aos requisitos necessários para
um determinado projeto que necessitasse de uma ferramenta ETL, em especial, projetos em
empresas de pequeno porte.
Pelos estudos realizados, ambas as ferramentas de ETL Open Source Kettle/Pentaho
e Talend Open Studio possuem um grau de maturidade bastante satisfatório e mostraram-se
produtos estáveis, com interface gráfica fácil de utilizar, com boa documentação disponível
e possuem uma ampla base de usuários ativos.
Das principais diferenças encontradas estão: no conceito de construção – Talend é
um gerador de código (Java ou Perl) e Kettle salva seus procedimentos em XML que é
executado por um interpretador, o “Pan”. Nas características apresentadas, percebe-se que o
Kettle tem o foco estratégico voltado para Business Intelligence e gerenciamento de data
warehouse, enquanto Talend é mais abrangente nos recursos, englobando, também aspectos
integração de dados e soluções de gerenciamento de dados, como MDM (gerenciamento de
dados mestres) por exemplo.
Desta forma, obedecendo aos resultados aferidos em relação aos critérios de
avaliação definidos na metodologia proposta deste trabalho, a ferramenta que obteve
pontuação maior no tocante a realidade da empresa de pequeno porte alvo do estudo de
caso foi a ferramenta TALEND.
90
Com isso, conclui-se que os objetivos esperados neste trabalho foram alcançados na
medida em que o método conseguiu evidenciar, dentre um universo de ferramentas ETL
open-source, uma determinada ferramenta que melhor se adequou ao conjunto de requisitos
da empresa de pequeno porte utilizada no estudo de caso a partir dos resultados aferidos e,
além disso, com uma perspectiva positiva de aderência a outros cenários de projetos de
Data Warehouse.
Durante o trabalho de pesquisa e desenvolvimento do estudo de caso, foram
identificados alguns pontos que se encaixam como implementação futura, sendo:
• Aplicação do método proposto em outros cenários de abrangência limitada,
similares ao contexto usado neste trabalho;
• Aplicação do método proposto em cenários de empresas de médio e grande
porte.
• Avaliar a aplicabilidade desta metodologia conjuntamente em ferramentas
ETL comerciais e open-source. Custo de licenciamento (para as soluções
comerciais) é um aspecto importante a ser pontuado.
91
REFERÊNCIAS:
ATOL CONSEILS et Développements. LIVRE BLANC - Les ETL Open Source. Disponível em: www.atolcd.com. Acesso em: 30 jul. 2011. B2B MAGAZINE, Conheça a solução de gerenciamento de dados mestres. Disponível em: http://www.b2bmagazine.com.br/lancamentos/conheca-a-soluc-o-de-gerenciamento-de-dados-mestres. Acesso em: 30 abr. 2011. CASTERS M., BOUMAN R. DONGEN J..Pentaho® Kettle Solutions: Building Open Source ETL Solutions with Pentaho Data Integration Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 Copyright © 2010 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-0-470-63517-9 CLOVERETL, Data Integration Software. Disponível em: www.cloveretl.com. Acesso em: 30 mar. 2011. COREY, Michael et al. Oracle 8i Data Warehouse. Tradução de João Tortello. Rio de Janeiro: Campus, 2001. DEVELOPER WORKS, IBM. Software, Open Source, SOA, Innovation, Open Standards, Trends. Disponível em: https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctaurion/entry/open-source_que_aconteceu_de_2004_para_hoje?lang=pt_br. Acesso em: 30 ago. 2011. FORREST RESEARCH, Making Leaders Successful Every Day. Disponível em: http://www.forrester.com/. Acesso em: 20 jan. 2011. GARTNET. Magic Quadrant for Data Quality Tools, 28 July 2011, Ted Friedman, Andreas Bitterer - Research Note G00214013. Disponível em: http://www.gartner.com/technology/reprints.do?id=1-170DCRV&ct=110819&st=sb&mkt_tok=3RkMMJWWfF9wsRokvq3BZKXonjHpfsX56OUkW6O%252BlMI/0ER3fOvrPUfGjI4ARctlI/qLAzICFpZo2FFMG%252ByQcoQ%253D Acesso em: 30 ago. 2011. GONÇALVES, Marcio. Uma Ferramenta de Extração de Dados para Data Warehouse Baseada em Agentes Distribuídos. Disponível em: http://www.datainfo.inf.br/marcio/download/artigos/mestrado.pdf. Acesso em: 30 mai. 2010. GONÇALVES, Marcio. Extração de Dados para Data Warehouse. Rio de Janeiro: Axel, 2003.
92
KETTLE-COOKBOOK, Auto-documentation tool for Kettle, a.k.a. Pentaho Data Integration. Disponível em http://code.google.com/p/kettle-cookbook/. Acesso em: 15 set. 2011. KIMBALL, Ralf. The Data Warehouse Toolkit: The Complete Guide do Dimensional Modeling. 2 ed. USA: BrianSnapp, 2002. (Chapter 4 – Procuremente p. 89-105) KIMBALL R., CASERTA J., The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleanin. USA: Wiley Publishing Inc., 2004 (Chapter 6 – Delivering Fact Table p. 209-253) LIMA, Carlos Alberto. ETL – Extração, Transformação e Carga de Dados:Uma Etapa Critica do Data Warehouse. Disponível em: http://litolima.wordpress.com/2010/01/13/etl-extracao-transformacao-e-carga-de-dados/. Acesso em: 10 abr. 2011. LUCRÉDIO, Daniel. Uma Abordagem Orientada a Modelos para Reutilização de Software. Tese Doutorado USP – São Carlos –SP, jul. 2009. Disponível em: http://www2.dc.ufscar.br/~daniel/files/teseDoutoradoDanielLucredio.pdf Acesso em: 15 set 2011. MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data Warehouse: Uma visão multidimensional. 4 ed. São Paulo: Érica, 2008. MICROSOFT. Manuais Online do SQLServer 2008: Criando um Pacote ETL Simples. Disponível em: http://msdn.microsoft.com/pt-br/library/ms169917.aspx. Acesso em: 30 abr. 2010. NASCIMENTO, Washington; VASCONCELOS Yasmim. Talend SOA – ESB, Disponível em: http://talendbrasil.com.br/. Acesso em: 30 mar. 2011. PASSIONNED GROUP, ETL Tolls Comparison. Disponível em: http://www.etltool.com/etl-tools-comparison/. Acesso em 03 set. 2011. PENTAHO, Open Source Business Intelligence Disponível em: http://kettle.pentaho.com/ Acesso em: 30 mar. 2011. PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge – PMBOK® Guide 2004. 3. ed. Pennsylvania-USA, 2004. REBOUÇAS, Djalma de P. Planejamento Estratégico: Conceitos, Metodologia e Práticas.5 ed. São Paulo: Atlas, 1997. TALEND, Open Integration Solutions Disponível em: www.talend.com Acesso em: 30 mar. 2011.
93
TALEND, Data Integration Features Comparison Matrix - Talend Open Studio vs Talend Integration Suite Team, Professional, RTx, Enterprise & MPx editions. Disponível em: http://www.talend.com/products-data-integration/Talend-Data-Integration-Features-Comparison-Matrix.pdf. Acesso em: 30 set. 2011. WALLER, Tomas Waller, et al. CloverETL Designer: User's Guide This User's Guide refers to CloverETL Designer 3.1.x release. Published June 2011 Disponível em: www.cloveretl.com. Acesso em: 15 mai. 2011.
94
ANEXO 1 – INFRA-ESTRUTURA UTILIZADA NA EXECUÇÃO DO LABORATÓRIO
A preparação das plataformas para o laboratório envolve a definição de quatro
máquinas virtuais, sendo executadas com o gerenciador VirtualBox versão 4.0.4
executando no host Windows Vista Ultimate 64bits SP2, em um hardware com processador
Intel Core 2 Duo CPU P9600 de 2,66Hz com 4 Gb de Ram e HD de 500Gb. Já as máquinas
virtuais foram definidas com as seguintes características:
1_ Máquina SRVBD: Banco de Dados SQL Server2005, plataforma Windows
Server2003 SP2 com 1Gb de memória. Nesta base encontra-se a fonte de dados do sistema
transacional OLTP, ERP Totvs Protheus 10.
2_ Máquina ETL_02: Instalação da ferramenta de ETL Talend versão 4.1.2,
plataforma Windows XP SP3, com 512 memória.
3_ Máquina ETL_03: Instalação da ferramenta de ETL Kettle versão 4.1.0,
plataforma Windows XP SP3, com 512 memória.
4_ Máquina ETL_04: Instalação do Banco de Dados Postgre versão 9.0.4
plataforma Linux Ubuntu, com 512 memória.
Passos para preparação das máquinas virtuais:
1_ Preparar uma cópia do Banco de Dados transacional, dados do ERP Protheus10;
2_Criar ambiente BANCO PostgreSQL (instalar e criar o banco DW);
3_Criar as tabelas de Dimensões e Fato;
4_Instalar as ferramentas de ETL em cada máquina.
95
ANEXO 2 – LISTA DE CRITÉRIOS PARA AVALIAÇÃO DAS FERRAMENTAS ETL
Arquitetura e Escalabilidade: Tem por objetivo avaliar se as ferramentas
suportam as exigências do projeto, quanto às características: flexibilidade se houver
aumento por demanda de recursos de hardware, plataforma de sistemas operacionais,
necessidades de processamento para um tempo e resposta aceitável, volume de tráfego na
movimentação de dados, balanceamento de carga, espaço para armazenamento, integração
de dados entre plataformas heterogêneas, controle de versão do produto, entre outras
características de construção.
1 Arquitetura e Escalabilidade Relevância
1.1 Suporte processamento paralelo, ou Multi -processamento simétrico (SMP): Necessidade de executar em quais plataformas Windows, UNIX, outros, com processadores que compartilham as suas memórias internas e externas em sistemas SMP?
Não Recurso não requerido no projeto.
1.2 Suporte Processamento Paralelo Massivamente - Massively parallel processing (MPP): Precisa que cada processador em um sistema MPP tem sua memória própria interna e externa e banco de dados para garantir alcançar alto desempenho. Esses bancos de dados devem ser sincronizados?
Não Recurso não requerido no projeto.
1.3 Cluster: Necessidade de um servidor de ETL que suporta balanceamento de carga, trabalhando em 'Cluster' e explora recursos recuperação de falhas?
Não Recurso não requerido no projeto.
1.4 Grid: Requer processamento de ETL executando em um "grid" de computadores ou servidores?
Não Recurso não requerido no projeto.
1.5 Processamento Distribuído: Exige processamento de ETL em diferentes máquinas ou processadores?
Não Recurso não requerido no projeto.
1.6 Dada pipelining: Demanda por processamento otimizado de ETL dividido em fases e executado em diferentes máquinas ou processadores?
Não Recurso não requerido no projeto.
96
1.7 Particionamento: Requer particionamento que determina em que máquina ou processador os dados de um determinado processo deve ser executado?
Não Recurso não requerido no projeto.
1.8 End-to-end para infra-estrutura de BI: Necessita que a ferramenta de ETL troque metadados com, por exemplo, esquemas estrela (Star Schema), OLAP ou ferramentas de relatórios a partir de seu próprio produto ou com produtos terceiros.
Não Recurso não requerido no projeto.
1.9 Suporta CWM: Requer da ferramenta de ETL compatibilidade com CWM - Common Warehouse Meta
Model? Recurso CWM permite intercambiar metadados entre modelos heterogêneos, ou seja, comporta uma melhor administração e integração dos modelos que são metadados, garante a interoperabilidade, facilita o acesso a diferentes metadados que podem ser intercambiados através de eXtensible Meta Data Interchange (XMI)?
Não Recurso não requerido no projeto.
1.10 Controle de versão do sistema: O produto contém um sistema de controle de versão com características check-
in e check-out? Check-in: Submeter ou enviar as alterações da cópia local ao Servidor através do Cliente. Chek-out: Quando não existe cópia local e é necessário baixar todo o projeto do servidor. Nesse processo, é guardado algum tipo de meta-dados (geralmente em pasta oculta) junto dos arquivos baixados.
Sim Facilitador no gerenciamento do desenvolvimento e controle da documentação
Funcionalidades de ETL: Este grupo de requisitos visa avaliar se as ferramentas
de ETL possuem recursos que facilitam o trabalho do desenvolvedor através de
componentes e funcionalidades que não apenas agilizam o desenvolvimento, mas
principalmente garante a qualidade e uniformidade do código. Como exemplo: funções para
carga dos vários tipos de tabelas de dimensão com mudança lenta; funções para carga de
tabela fato; tratamento de erros durante o processamento; análise de impacto se houver
mudanças de regras ou atributos; recursos que permite a rastreabilidade da origem de um
atributo; se existe auto-documentação ou facilitador que gere a documentação do projeto
entre outros.
97
2 Funcionalidade ETL Relevância
2.1 Divisão dos fluxos de dados / alvos múltiplos: é possível ler a fonte de dados uma vez e carregar os resultados em duas ou mais tabelas?
Não Não explorado pelo projeto
2.2 Divisão Condicional: O mesmo que “alvos múltiplos” mas condicional, por exemplo, se a receita for maior que 1000 colocar os resultados na tabela 1 em contrário na tabela 2.
Não Não explorado pelo projeto
2.3 União: Junção de linhas de diferentes tabelas em uma tabela de mesma estrutura.
Sim Recurso com forte possibilidade de aplicação.
2.4 Pivoting (Transformando): É possível transformar trocando os dados de linhas para colunas e vice-versa.
Não Não explorado pelo projeto
2.5 Pesquisas de chave na memória: Você pode carregar uma tabela completamente na memória interna e pesquisar na tabela, sem necessidade de fazer joins?
Não Não explorado pelo projeto
2.6 Pesquisas chaves reutilizáveis em processos: Uma vez a tabela carregada em memória é possível reutilizá-la em outro processo por “chave de referência”?
Não Não explorado pelo projeto
2.7 Ler dados não-estruturados: o produto pode ler dados não estruturados, como texto, email, etc vídeo e, em caso afirmativo, que tipos de arquivos?
Não Não se aplica ao projeto
2.8 Dimensões de alteração lenta: Há suporte na ferramenta para dimensões de alteração lenta? (hm = manual; wizard = assistente; auto = arrasta e solta)
Sim Recurso necessário para o projeto
2.9 Agenda (Scheduler): Existe um “agendador” que suporta dependências?
Não Não explorado pelo projeto
2.10 Tratamento de erros no processamento: Existe tratamento para erro no processamento e é possível prever o percurso alternativo dentro do fluxo do processo quando surge um erro específico?
Sim Recurso com possibilidade de aplicação e de fácil avaliação
2.11 Análise de impacto: é possível fazer uma análise do impacto das mudanças propostas (quando um atributo ou tabela mudar)
Sim Recurso de apoio para o desenvolvimento com possibilidade de aplicação e de fácil avaliação
98
2.12 Dados linhagem: Existe facilidade em rastrear a origem de um atributo/informações de um elemento (análise do impacto invertida)
Sim Recurso de apoio para o desenvolvimento com possibilidade de aplicação e de fácil avaliação
2.13 Documentação automática: É possível documentar e publicar um processo/transformação automaticamente e consultar por um navegador?
Sim Recurso de apoio na documentação
2.14 Suporte para modelos de mineração de dados: É possível durante o processo de carregamento fazer uso dos resultados para um processo de mineração de dados?
Não Não requerido pelo projeto
2.15 Suporte para funções analíticas: Durante o processo de carregamento, é possível invocar os vários tipos de funções analíticas como a previsão, análise na cesta de dados e a regressão?
Não Não explorado pelo projeto
Facilidade de uso: Os requisitos deste grupo tratam de características que avaliam a
forma de manuseio das ferramentas de ETL, se o designer ergonômico facilita o trabalho,
se é envolvente e fácil de aprender, o quanto requer de treinamento especializado. Enfim,
afere a qualidade de usabilidade do software.
3 Facilidade de uso Relevância
3.1 Facilidade de uso: A facilidade de uso do produto, se é intuitivo, fácil de aprender e fácil de aplicar em uma base diária?
Sim Relevante para produtividade e aprendizado
3.2 WYSIWYG: É o princípio do "What You See Is What You Get", ou seja, “O que você vê é o que você obtém” isso aplicado aos dados?
Sim Relevante para produtividade e aprendizado
3.3 Design de tela: O design ergonômico de tela é bem equilibrado?
Sim Relevante para produtividade e aprendizado
99
3.4 Compatibilidade de tarefas ETL / EAI (Integração de Aplicações de Negócios): A ferramenta de ETL elabora as tarefas, na mesma sequência, como um desenvolvedor ETL?
Não Recurso não explorado
3.5 Necessidade de Treinamento: Será necessário treinamento especializado tanto para o desenvolvedor profissional quanto para usuário final de negócios (se for o caso)?
Sim Relevante para produtividade e aprendizado
3.6 Integralidade do GUI: Qual o percentual das funcionalidades que podem ser geradas diretamente da GUI (Graphical User Interface)?
Sim Relevante para produtividade e aprendizado
Reutilização: A reutilização de software é um dos conceitos estudados pela
engenharia de software que visa aumentar a qualidade e produtividade no processo de
desenvolvimento de software, minimizando o esforço e reaproveitando o máximo possível
das experiências vivenciadas em projetos passados (LUCRÉDIO, 2009). Os requisitos deste
grupo tem a finalidade de avaliar se as ferramentas de ETL permitem desenvolver
aplicando esses conceitos padrões, como exemplo na reutilização de componentes, com o
desenvolvimento modular, nas funções de usuários acopladas ao fluxo do processo e etc.,
de forma que permita o reaproveitamento de trabalhos passados em trabalhos futuros.
4 Reutilização Relevância
4.1 Reutilização de componentes: O modelo de desenvolvimento favorece a reutilização de componentes, ou seja, chamada por parâmetros (isto não é o mesmo que copiar-colar)?
Sim Relevante para aplicar padrões de boas práticas de desenvolvimento
4.2 Decomposição: O modelo de desenvolvimento permite dividir os processos em pequenos blocos (programação modular)?
Não Recurso não explorado
4.3 Funções definidas pelo usuário: É possível construir funções definidas pelo usuário e utilizá-los no fluxo do processo?
Não Recurso não explorado no projeto
100
4.4 Comentários sobre a seleção de objetos: Pode-se fazer comentários sobre a seleção de objetos, de tal forma que esses comentários estejam estreitamente relacionados.
Não Recurso não explorado no projeto
Depuração: Os requisitos de depuração tem o objetivo de avaliar as facilidades que
o desenvolvedor encontrará nas ferramentas de ETL para corrigir eventuais problemas
lógicos ou de execução. Como exemplo: executar o processo passo-a-passo ou linha-a-
linha, inserir ponto de parada incondicional ou temporizado, etc.
5 Depuração Relevância
5.1 Execução Passo-a-passo: É possível executar o fluxo de processo passo-a-passo?
Sim Facilitador no desenvolvimento
5.2 Execução Linha por linha: É possível executar o processo de fluxo de linha por linha?
Não Recurso não explorado no projeto
5.3 Ponto de Parada (Breakpoints): Permite definir um ponto de interrupção em uma etapa do processo em particular ou uma linha de dados?
Sim Facilitador no desenvolvimento
5.4 Ponto de Parada Temporizado (Watch Points): Comporta definir pontos de interrupção temporária, de modo que o sistema adie a execução quando uma determinada condição é satisfeita?
Não Recurso não explorado no projeto
5.5 Compilador/Validador: É possível validar o fluxo do processo (e / ou de código) com um clique do mouse e salvar os registros dos erros?
Sim Facilitador no desenvolvimento
Mecanismo de processamento: Estes requisitos permitem aferir como as
ferramentas de ETL atendem os recursos especificamente para o processo de
movimentação de dados, por exemplo: os tipos de integração entre as bases de dados (lote
ou tempo real); a segurança da informação durante o processamento por meio de
101
criptografia; recursos para detectar as mudanças dos dados nos sistemas de origem; se há
integração de dados por demanda; e recursos para compactar os dados nas bases de origem.
6 Mecanismo de processamento Relevância
6.1 Integração em Lote / Tempo Real: A ferramenta de ETL permite o processamento do fluxo da movimentação e transformação dos dados em tempo real ou em lote?
Não Não se aplica ao projeto
6.2 Mecanismo de Mudanças: Como as mudanças nos sistemas de origem são detectadas e inseridas através de: - MQ (message queuing) = Enfileiramento de mensagens; - Logging = Log de banco de dados / journals; - Trigger = Gatilhos de banco de dados?
Não Não se aplica ao projeto
6.3 Integração de dados por demanda: É possível publicar um processo de ETL e / ou atributo de destino em um Web Service?
Não Não se aplica ao projeto
6.4 Compactação de dados: Permite movimentação de dados compactados na origem?
Não Não se aplica ao projeto
6.5 Criptografia de dados: Permite criptografar os dados como recurso de segurança da informação?
Não Não se aplica ao projeto
6.6 Retransmissão de dados: Em caso de interrupção de um processamento, é possível reiniciar a partir do ponto de parada?
Não Recurso não explorado
Conectividade e Plataformas: O grupo de requisitos que avalia a conectividade
tem a finalidade de apurar a disponibilidade de conectores nativos para banco de dados ou
aplicações empresariais (exemplo SAP) e saber se esses conectores suportam
processamento em tempo real. A preferência por conectores nativos deve-se ao fato de
serem mais eficientes se comparados aos ODBC (Object Oriented Database Connectivity)
genéricos, ou pior, a necessidade de desenvolver um conector, assim como saber em quais
plataformas as ferramentas suportam trabalhar.
102
7 Conectividade e Plataformas Relevância
7.1 Conexões nativas: Quantas e quais são as conexões nativas suportado pela ferramenta de ETL? (ODBC, OLE DB e arquivos flat excluídos)
Sim Recurso essencial para o projeto
7.2 Pacotes / aplicações empresariais: Quais pacotes / aplicações corporativas (ERP) a ferramenta de ETL pode ler os metadados com um simples clique do mouse? (por exemplo, SAP, Siebel, PeopleSoft, JD Edwards, Baan)
Não Não se aplica ao projeto
7.3 Conexão em tempo real: Quantos e que tipos de mensagens enfileiradas de produtos podem conectar-se a ferramenta?
Não Não se aplica ao projeto
7.4 Suporte para juntar tabelas na fonte: Você pode juntar duas tabelas e apresentar de forma gráfica, permitindo que o banco execute a conexão em vez de deixar que a ferramenta ETL junte as tabelas?
Não Recurso não explorado no projeto
7.5 Captura de dados Modificados: A ferramenta de ETL conector que suporta a captura de dados modificados (Changed Data Capture), selecionando apenas as alterações (deltas) do banco de dados.
Não Não se aplica ao projeto
7.6 Plataformas: Quais são as plataformas possíveis para executar a ferramenta de ETL?
Sim Recurso essencial para o projeto
Garantia de Qualidade dos Dados: O conceito para o tratamento da qualidade de
dados é muito amplo e tem como objetivo assegurar que os problemas nos dados de origem
não sejam migrados para o DW. Para isso, devem existir recursos nas ferramentas de ETL
que facilitam a identificação e o tratamento das anomalias nos dados através de funções de
transformações ou de validação de dados, entre esses recursos devem contemplar funções
para: normalização ou correção, verificação de dados duplicados, dados nulos, verificação
de valores mínimos ou máximos, entre outros.
103
8 Garantia de Qualidade dos Dados Relevância
8.1
Desenvolvimento em função da qualidade dos dados: Há funções disponíveis suficientes para atender a qualidade dos dados dos ambientes de origem? (por exemplo, uma transformação correspondente, ou um limpador de endereço) lógica fuzzy*. * Lógica fuzzy: Provém à base para geração de técnicas poderosas para a solução de problemas, com uma vasta aplicabilidade, especialmente, nas áreas de controle e tomada de decisão. A força da Lógica Fuzzy deriva da sua habilidade em inferir conclusões e gerar respostas baseadas em informações vagas, ambíguas e qualitativamente incompletas e imprecisas. Neste aspecto, os sistemas de base Fuzzy têm habilidade de raciocinar de forma semelhante à dos humanos. Seu comportamento é representado de maneira muito simples e natural, levando à construção de sistemas compreensíveis e de fácil manutenção.
Não Não se aplica ao projeto
8.2 Desenvolvimento com funções para validação de dados: A ferramenta de ETL tem funções para validação de dados como: "eliminar duplicidades", "valores faltando", ou "dados incorretos"?
Não Recurso não explorado pelo projeto
8.3 Perfil dos dados: Existe recurso para definir perfis de dados, unicidade de valores, distribuição de mínimo e máximo de valores, e assim por diante.
Não Recurso não explorado pelo projeto
Características Gerais: Os requisitos deste grupo têm a finalidade de identificar
algumas das principais características com o objetivo de saber se atenderá a demanda do
projeto quanto a plataforma de execução, se o conceito de construção é adequado às
necessidades, assim como requisito de caráter informativo como saber se a versão do
produto open source acompanha a mesma versão comercial.
9 Características Gerais Ferramenta ETL Relevância
104
9.1 Versão: Versão do produto em avaliação? Open Source Sim Nota para documentar
9.2 Motor Gerador de Código: A ferramenta é fundamentada em um Motor-Base ou Gerador de Código?
Sim Nota para documentar
105
ANEXO 3 – ANÁLISE COMPLEMENTAR DOS CRITÉRIOS RELEVANTES
Neste anexo apresentamos uma análise complementar dos principais critérios que
foram classificados como relevantes para o estudo de caso, no sentido de gerar evidências
em relação aos resultados aferidos nos critérios de comparação das ferramentas Talend
Open Studio e Kettle/Pentaho. Para tanto, são ilustrados com as imagens de cada
ferramenta de ETL.
Lista de requisitos classificado como relevante 1 Arquitetura e Escalabilidade 1.10 Controle de versão do sistema
Neste quesito notou-se uma superioridade na ferramenta Talend, com recursos mais apurados, possibilitando o gerenciamento de versão de cada “Job” dentro de um projeto, além de ser fácil utilização. Já no Kettle, não encontramos essa facilidade.
KETTLE
No Kettle, o gerenciamento de versão é bem simples, é controlado manualmente nas
propriedades do projeto/transformação. Também pode informar o estado da transformação
se está em desenvolvimento ou em produção. A figura a seguir ilustra a tela de controle de
versão no Kettle.
Figura 36 - Controle de Versão da Transformação no Kettle
Fonte: Kettle (2011)
106
TALEND
No Talend Open Studio com o recurso de gerenciamento de versão dos trabalhos, é
possível controlar históricos das versões anteriores. Por padrão, quando você cria um
trabalho, a versão inicial é “0.1”, onde “0” atribuído à versão principal e “1” à versão
secundária. É possível manter o registro das versões anteriores do trabalho, sendo que
qualquer versão anterior é somente para leitura e, portanto, não pode ser modificado.
Outras possibilidades possíveis:
• Salvar um trabalho e incrementar a versão ao mesmo tempo – “Salvar
como”;
• Acesso à lista do histórico das versões de um trabalho e executar
determinadas operações;
• Gerenciar o “status” de cada item na exibição em árvore do repositório.
A figura 37 mostra como é a tela de gerenciamento de versão do Talend.
Figura 37 - Controle de Versão da Transformação no Talend
Fonte:Talend (2011)
107
A figura 38 ilustra um exemplo para consulta de versão de um trabalho e, nas
figuras seguintes (39 e 40), a possibilidade de visualizar o histórico e controle de “Status”
do trabalho.
Figura 38 - Consulta Versão de um Trabalho no Talend
Fonte: Talend (2011)
Figura 39 – Consulta Histórico das Versões de um Trabalho no Talend
Fonte: Talend (2011)
108
Figura 40 - Controle de “Status” das Versões de um Trabalho no Talend
Fonte: Talend (2011)
2 Funcionalidade ETL 2.3 União: Junção de linhas de diferentes tabelas em uma tabela de mesma
estrutura.
As funcionalidades deste quesito foram avaliadas durante o desenvolvimento do
estudo de caso, especificamente na “carga da tabela fato”, as ilustrações e os comentários
podem ser conferidos no tópico 5.6 e 5.7.
2.8 Dimensões de alteração lenta: Há suporte na ferramenta para dimensões de alteração lenta? (hm = manual; wizard = assistente; auto = arrasta e solta)
As funcionalidades deste quesito foram avaliadas durante o desenvolvimento do
estudo de caso, especificamente na “carga das tabelas dimensão”, as ilustrações e os
comentários podem ser conferidos no tópico 5.5 e 5.7.
109
2.10 Tratamento de erros no processamento: Existe tratamento para erro no processamento e é possível prever o percurso alternativo dentro do fluxo do processo, quando surge um erro específico?
Com o tratamento de erros nas ferramentas de ETL, é possível evitar que uma
grande transformação pare no meio por problema em uma única linha, por exemplo.
KETTLE
O recurso “Error Handling” no Kettle funciona como um filtro, destinando linhas
com problemas para um “step” (destino) específico e seguindo o fluxo da transformação
apenas as linhas “saudáveis”, ou seja, linhas que não causaram nenhum tipo de problema na
execução da transformação.
A figura abaixo representa o funcionamento simples para o tratamento de erro, se
algum erro ocorrer na tentativa do Kettle, incluir registros na tabela de “SB1_Produto_SA”,
as linhas com problema serão direcionadas para o “Step” “Registro de Erros” sem
interromper o fluxo da transformação.
Figura 41 – Exemplo de Tratamento de Erro no Kettle
Fonte: Kettle (2011)
110
TALEND
Diferente do Kettle, o Talend Open Studio possuí uma família de componentes para
tratar de “Logs e Erros”. Este grupo de componentes se dedica a captura de informações e
manipulação de erros. Como exemplo o “tAssert” que fornece mensagens de status para
outro componente o “tAssertCatcher” e gera um fluxo de dados para ser salvo em um
arquivo pré-definido. A ilustração a seguir mostra um exemplo dos principais componentes
com o propósito de capturar e armazenar mensagens de “log”, também demonstra como as
propriedades dos componentes “tLogCatcher”, "tDie" e "tWarn" estão intimamente
relacionados ao componente “tLogCatcher”. Também evidencia porque esses componentes
fazem sentido quando usados em conjunto para que os dados de “log” encapsulados sejam
coletados e repassados para a saída definida.
Figura 42 - Conjunto de Componentes para Manipulação de Erros no Talend
Fonte: Talend (2011)
tWarn - Tem a função de fornecer uma mensagem de classificada como prioridade
para o próximo componente. Também dispara um aviso por várias vezes para que o
componente “tLogCatcher” capture
111
tLogCatcher - O propósito é operar como uma função de “log” desencadeada por
um dos três: “Java Exception”, “tDie” ou “tWarn” para coletar e transferir esses dados de
“log”.
tDie - A finalidade é desencadear uma mensagem de “log” para o componente
"tLogCatcher", antes de abortar ou não o processamento.
2.11 Análise de impacto: é possível fazer uma análise do impacto das mudanças propostas (quando um atributo ou tabela mudar)
KETTLE
O recurso “Análise de Impacto” só encontrado na ferramenta Kettle, seu uso é algo
muito simples, apenas tem a função de gerar um relatório de cada uma das etapas da
transformação, fornecendo uma lista informações como: as tabelas acessadas, tipo de
acesso se leitura ou gravação, o código da query. O exemplo abaixo mostra um relatório de
análise de impacto regado pela ferramenta Kettle.
Figura 43 - Exemplo Relatório Análise de Impacto no Kettle
Fonte: Kettle (2011)
TALEND
No Talend esse recurso só está disponível nas versões pagas, conforme documento
Data Integration Features Comparison Matrix (Talend, 2011).
112
2.12 Dados linhagem: Existe facilidade em rastrear a origem de um atributo/informações de um elemento (análise do impacto invertida)
KETTLE
Duas funcionalidades correlatas foram analisadas rastreabilidade e propagação de
campos (atributos) entre os elementos de uma transformação: no Kettle a propagação das
modificações ocorre de maneira natural, uma vez que a configuração do parâmetro
“Distribui os dados para os próximos steps” esteja “ligado”, conforme exemplo ilustrado
abaixo. Também nas propriedades de cada componente é possível exibir os atributos que
estão entrando e saindo especificamente no ponto do componente selecionado.
Figura 44 - Exemplo de Rastreabilidade e Propagação de Atributos no Kettle
Fonte: Kettle (2011)
A figura seguinte mostra um exemplo dos campos de origem ou entrando no
componente “Sort Row”.
113
Figura 45 - Relatório de Rastreabilidade dos Atributos no Kettle
Fonte: Kettle (2011)
TALEND
No Talend, ao inserir ou modificar qualquer um dos parâmetros de uma entrada na
exibição em árvore do repositório, todos os elementos do trabalho usando esta entrada do
repositório será afetado pela modificação. Desta forma, a ferramenta solicitará que você
“propague” estas modificações a todos os elementos dos trabalhos que usam a entrada no
repositório. Como demonstra a figura a seguir.
Figura 46 - Exemplo de Propagação de Atributos no Talend
Fonte: Talend (2011)
114
A figura a seguir mostra o recurso que exibe em cada passo da transformação
(componentes) quais os atributos estão entrando e saindo. Com este recurso também é
possível interferir no fluxo dos dados, ou seja, mudar uma característica do atributo, incluir
ou excluir um atributo.
Figura 47 - Exemplo de Rastreabilidade e Manipulação de Atributos no Talend
Fonte: Talend (2011)
2.13 Documentação automática: É possível documentar e publicar um processo/transformação automaticamente e consultar por um navegador?
KETTLE
Com o Kettle não vimos o recurso de forma direta, o que a ferramenta disponibiliza
é a possibilidade de salvar o projeto em formato XML, para então ser executado com
recursos de terceiros um gerador de documentação. Um exemplo é o Kettle-Cookbook que
é uma ferramenta de auto-documentação para o Kettle (Pentaho PDI). A figura a seguir
demonstra um modelo do relatório em HTML (Kettle-Cookbook, 2011).
115
Figura 48 - Relatório de Documentação Automática do Kettle
Fonte: Kettle-Cookbook (2011)
TALEND
O Talend possui um ótimo gerador de documentação automática, com ele é possível
gerar um relatório em HTML completo e detalhado de uma transformação, com um simples
“clique” do mouse. Veja um exemplo na figura 49 como fazer:
Figura 49 - Chamada ao Gerador de Documentação no Talend
Fonte: Talend (2011)
116
O relatório é bem completo, conforme pode ser observado na ilustração abaixo,
onde mostra um corte do modelo do relatório exibido em HTML, são detalhados todos os
itens do “Sumário” em destaque.
Figura 50 - Relatório de Documentação no Talend
Fonte: Talend (2011)
3 Facilidade de uso
Os requisitos do grupo “Facilidade de uso” refletem apenas o sentimento do autor
deste trabalho, portanto não deve expressar resultado de uma pesquisa empírica por um
grupo de usuários, algo que não foi possível realizar neste trabalho. Portanto, as pontuações
dos quesitos deste grupo foram encontradas a partir das facilidades e dificuldades do
processo de desenvolvimento descritos nos tópicos 5 e 6.
117
4 Reutilização 4.1 Reutilização de componentes: O modelo de desenvolvimento favorece a
reutilização de componentes, ou seja, chamada por parâmetros (isto não é o mesmo que copiar-colar)?
KETTLE
No Kettle foram encontrados dois indicativos que facilitam a reutilização de
componentes, o compartilhamento de “Conexões” e “Steps”, assim como a facilidade de
reutilização das conexões, tipo “arrasta-e-solta” para criar os step. Abaixo a figura ilustra o
mecanismo de compartilhar os recursos.
Figura 51 - Exemplo de Compartilhamento de Recursos do Kettle
Fonte: Kettle (2011)
118
TALEND
Na ferramenta Talend, observou-se que o modelo de desenvolvimento por projeto
facilita o compartilhamento dos recursos de conexão e metadados, ou seja, qualquer
metadado criado dentro de um projeto já fica naturalmente disponível para os “Jobs
Designs”, assim como para outros projetos e usuários. A figura abaixo ilustra a estrutura de
conexões e metadados de um projeto.
Figura 52 - Modelo de um Painel com “Jobs” e Metadados Compartilhados no Talend
Fonte: Talend (2011)
5 Depuração
5.1 Execução Passo-a-passo: É possível executar o fluxo de processo passo-a-passo?
KETTLE
Entre os recursos de depuração no Kettle, existe a possibilidade de executar uma
transformação ou um “Job” passo-a-passo, sendo que o conceito de “passo” refere-se a cada
linha de dados processada em um componente da transformação que, por sua vez, necessita
119
de habilitar as condições para “pausar” um processamento que está associado à
configuração do “breakepoint”, (ver configuração abaixo no item 5.3). A figura seguinte
demonstra como é o funcionamento da execução passo-a-passo e o painel que possibilita o
acompanhamento de cada etapa de processamento conforme foi definido nas condições de
“parada”.
Figura 53 - Exemplo de Execução Passo-a-Passo no Kettle
Fonte: Kettle (2011)
TALEND
Encontramos no Talend vários recursos para depurar um trabalho, existe uma
“perspectiva”, ou seja, um conjunto de painéis dedicados à depuração de uma
transformação e para os desenvolvedores mais experientes permite uma depuração no modo
Java onde é possível acompanhar a execução linha-por-linha do código. A figura abaixo
ilustra o conjunto de painéis de uma perspectiva para depurar um trabalho no Talend e, em
destaque, os botões de controle para avançar, pausar, interromper, saltar um quadro,
retroceder, entre outras funções.
120
Figura 54 - Modelo dos Painéis de Depuração Passo-a-Passo no Talend
Fonte: Talend (2011)
5.3 Ponto de Parada (Breakpoints): Permite definir um ponto de interrupção em
uma etapa do processo em particular ou uma linha de dados?
KETTLE
A configuração de “ponto de parada” no Kettle é quem habilita o recurso de
depuração para execução “passo-a-passo”. A figura seguinte demonstra como pode ser
configurado um “breakpoint” em um ou mais elementos da transformação.
Figura 55 - Exemplo de Configuração do Ponto de Parada no Kettle
Fonte: Kettle (2011)
121
TALEND
Entre os recursos de depuração, também encontramos na maioria dos componentes
do Talend a possibilidade de inserir um “ponto de parada”. A figura a seguir ilustra como
ficam os componentes com o recurso “breakpoint” habilitado e uma série de configurações
possíveis para apoio em uma depuração de alto nível, como por exemplo, ”estatística” em
“Configurações Avançadas” que possibilita acompanhar cada linha de dados processado no
componente.
Figura 56 - Exemplo de Configuração do Ponto de Parada no Talend
Fonte: Talend (2011)
5.5 Compilador/Validador: É possível validar o fluxo do processo (e / ou de código)
com um clique do mouse e salvar os registros dos erros?
KETTLE
O recurso de verificação ou validação da transformação no Kettle é muito útil e
simples de usar, valida o código antes mesmo de executar. A figura abaixo demonstra um
122
exemplo do resultado de uma verificação, sendo que linhas com destaque em verde são
resultado dos testes com sucesso e, em vermelho, caso negativo. O botão “View message”
permite visualizar um relatório com mais detalhes, mas não permite salvar.
Figura 57 - Exemplo do Recurso de Validação no Kettle
Fonte: Kettle (2011)
TALEND No Talend não encontramos esse recurso. 7 Conectividade
7.1 Conexões nativas: Quanto e quais são as conexões nativas suportadas pela ferramenta de ETL? (ODBC, OLE DB e arquivos flat excluídos)
7.6 Plataformas: Quais plataformas possíveis para executar a ferramenta de ETL?
Neste quesito, ambas as ferramentas atenderam com facilidade as necessidades do
projeto, os principais bancos de dados estão disponíveis em mais de três dezenas de
conectores nativos nestas ferramentas. Assim como suportam trabalhar nos principais
sistemas operacionais Linux, Unix e Windows.
123
9 Características Gerais Ferramenta ETL
9.1 Versão: Versão do produto em avaliação? Open Source
9.2 Motor Gerador de Código: A ferramenta é fundamentada em um Motor-Base ou Gerador de Código?
As características de construção, assim como as observações das versões
disponíveis das ferramentas de ETL, estão comentadas no tópico 4.3.