Você está na página 1de 124
UNIÃO METROPOLITANA DE EDUCAÇÃO E CULTURA - CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO TRAJANO

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

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

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.

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

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

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

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:

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.

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

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

data warehouse. Figura 1 – O Ambiente de um Data Warehouse Fonte: MACHADO, 2008, p. 26

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

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

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

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

pois pode afetar o desempenho do ambiente transacional. Figura 2 - Staging Area ou ODS Fonte:

Fonte: MACHADO, 2008, p. 38

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

de data mart independente. Figura 3 – Arquitetura de Data Mart Independente Fonte: MACHADO, 2008, p.

Fonte: MACHADO, 2008, p. 50

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

integrado. Figura 4 – Arquitetura de Data Mart Integrado Fonte: MACHADO, 2008, p. 51 2.4 FORMAS

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

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

dependente. Figura 5 – Modelo de Implementação Top Down em Data Mart Dependente Fonte: MACHADO, 2008,

Fonte: MACHADO, 2008, p. 53

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)

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

de Implementação Botton Up para Data Mart Independente Fonte: MACHADO, 2008, p. 55 Machado (2008) também

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.

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 hoc 1 . 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 joins 2 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.

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.

A

seguir

serão

características.

apresentadas

as

principais

técnicas

2.5.1.2 Técnicas de Modelagem Dimensional

2.5.1.2.1 Snowflake

de

modelagem

e

suas

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

a figura que exemplifica esse modelo. Figura 7 – Modelo Multidimensional Snowflake Fonte: MACHADO, 2008, p.

Fonte: MACHADO, 2008, p. 95

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

dos dados em disco (MACHADO, 2008). Figura 8 – Modelo Multidimensional Star Schema Fonte: MACHADO, 2008,

Fonte: MACHADO, 2008, p. 93

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

armazenamento de diferentes granularidades. Figura 9 – Representação de Granularidade Fonte: MACHADO, 2008, p. 61. 32

Fonte: MACHADO, 2008, p. 61.

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.

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

A seguir uma ilustração desse modelo. Figura 10 - Dimensão que Muda Lentamente Tipo-1 Fonte: COREY,

Fonte: COREY, 2001, p. 244.

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

na figura 11 mostra o modelo tipo 2. Figura 11 - Dimensão que Muda Lentamente Tipo-2

Fonte: COREY, 2001, p. 245.

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

A figura 12 exemplifica o modelo tipo 3. Figura 12 - Dimensão que Muda Lentamente Tipo-3

Fonte: COREY, 2001, p. 246.

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

de Carregamento de Tabelas de Fatos de Nível Básico Fonte: COREY, 2001, p. 247. Segundo Kimball

Fonte: COREY, 2001, p. 247.

Segundo Kimball (2004), na preparação da carga das tabelas fatos, existe um conjunto de desafios:

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 rollback 3 , 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.

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.

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

possíveis origens do metadados. Figura 14 – Representação das Origens de Metadados Fonte: MACHADO, 2008, p.

Fonte: MACHADO, 2008, p. 306.

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.”

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.

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 [

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á

sem uma definição clara de onde

]

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).

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.

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).

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á

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 failover 4 ; - 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.

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

com alguns componentes. Figura 15 – Modelo Clover Designer Fonte: CloverETL, 2011 De acordo com a

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.

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,

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 middleware 5 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 Management 6 (MDM) e na integração de aplicações. Com um número crescente de downloads de produtos e clientes pagantes, a Talend oferece as

5 Middleware, 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).

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

– Quadrante Mágico para Ferramentas de Qualidade de Dados Fonte: GARTNER, 2011, p. 1 7 Para

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”.

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 services 8 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

4.1 (Talend, 2011). Figura 16 – Modelo Talend Open Studio Fonte: Talend, 2011 8 Web Service

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.

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 SpagoBI 9 , Ingres 10 , Teradata 11 e JasperSoft 12 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 Research 13 , IDC 14 e Bloor Research 15 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 metadados 16 . 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.

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.

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

de processo no Kettle. Figura 17 – Modelo PDI / Kettle Fonte: Pentaho, 2011 Conforme a

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).

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;

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.

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 Vlr.Receita Qtd Venda Marg.Contrib Qtd Clientes Qtd Produtos Negócio - (Devolução) -
Dimensões do
Vlr.Receita
Qtd Venda
Marg.Contrib
Qtd Clientes
Qtd Produtos
Negócio
- (Devolução)
- (Devolução)
- (Devolução)
- (Devolução)
- (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 Filial X X X X X X X X X X Cliente
Dimensões do Negócio
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
Estorno ICMS
Estorno IPI
Cred.ICMS ST
Custo Embalagens
Vlr Frete Venda
Vlr E.F.
Vlr. ICMS
Vlr. IPI
Vlr. Pis/Cofins
Custo Produto

Fonte: Autoria própria (2011)

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.

A figura 18 demonstra a modelagem dos dados de acordo com o paradigma star schema.

Figura 18 - Ambiente OLAP - Modelagem Esquema Star

DIM_FILIAL DIM_CLIENTE DIM_PRODUTO SEQ_FILIAL SEQ_CLIENTE SEQ_PRODUTO COD_FILIAL COD_CLIENTE COD_PRODUTO
DIM_FILIAL
DIM_CLIENTE
DIM_PRODUTO
SEQ_FILIAL
SEQ_CLIENTE
SEQ_PRODUTO
COD_FILIAL
COD_CLIENTE
COD_PRODUTO
NOM_FILIAL
LOJ_CLIENTE
FOR_PRODUTO
NOM_CLIENTE
NOM_PRODUTO
MUN_CLIENTE
TIP_PRODUTO
UF_CLIENTE
GRP_PROTUTO
COD_SEGMENTO
EMB_PRODUTO
NOM_SEGMENETO
DTC_INICIO
FAT_FATURAMENTO
DTC_INICIO
DTC_FIM
NUM_NOTA_FISCAL
DTC_FIM
SER_NOTA_FISCAL
SEQ_FILIAL
SEQ_CLIENTE
SEQ_PRODUTO
DIM_VENDEDOR_I
SEQ_VENDEDOR_I
SEQ_VENDEDOR_I
DIM_VENDEDOR_E
SEQ_VENDEDOR_E
COD_VENDEDOR_I
SEQ_VENDEDOR_E
SEQ_TRANSPORTADOR
NOM_VENDEDOR_I
COD_VENDEDOR_E
SEQ_TEMPO
NOM_VENDEDOR_E
VAL_VENDA
QTD_VENDA
VAL_MARGEM_CONTRIB
VAL_CUST_PRODUTO
DIM_TEMPO
VAL_CUST_ICMS
DIM_TRANSPORTADOR
SEQ_TEMPO
VAL_CUST_IPI
SEQ_TRANSPORTADOR
DATA
VAL_CUST_PISCOFINS
COD_TRANSPORTADOR
DIA_SEMANA
VAL_CUST_EF
DIA_MES
NOM_TRANSPORTADOR
VAL_CUST_FRET_VEND
SEMANA_MES
VAL_CUST_EMBALAGEM
MES
VAL_CUST_EST_ICMS
NOM_MES
VAL_CUST_EST_IPI
TRIMESTRE
VAL_CRED_ICMS_ST
SEMESTRE
QTD_PRODUTOS
ANO
QTD_CLIENTE

Fonte: Autoria própria (2011)

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

Totvs. Figura 19 - Ambiente Transacional – Modelagem 3FN Fonte: Autoria própria (2011) 5.3 EXTRAÇÃO DOS

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

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

Figura 20 – Menu Conexão Banco de Dados no Kettle/Pentaho Fonte: Kettle/Pentaho (2011). As informações que

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

de dados, como mostra a figura 21. Figura 21 - Conexão Banco de Dados no Kettle/Pentaho

Fonte: Kettle/Pentaho (2011).

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

abaixo. Figura 22 – Menu Conexão Banco de Dados no Talend Fonte: Talend (2011) As informações

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

porta e nome do banco de dados, como mostra a figura 23. Figura 23 - Conexão

Fonte: Talend

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

24 - Movimentação de Dados para Staging Area no Kettle Fonte: Kettle (2011) A figura 25

Fonte: Kettle (2011)

A figura 25 representa o fluxo de dados do ambiente OLTP para staging area com a

ferramenta Talend.

Figura 25 - Movimentação de Dados para Staging Area no Talend

25 - Movimentação de Dados para Staging Area no Talend Fonte: Talend (2011) 5.4 NECESSIDADES DE

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.

Figura 26 – Componente tMap do Talend Open Studio – Tabela Cliente

– Componente tMap do Talend Open Studio – Tabela Cliente Fonte: Talend (2011) Com o mesmo

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

Talend Open Studio – Calculo da Margem de Contribuição Fonte: Talend (2011) Ao contrário do componente

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

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

Componente Database Lookup do Kettle – Tabela Cliente Fonte: Kettle (2011) componente Calculator, também na

Fonte: Kettle (2011)

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.

Diferentemente do

Talend,

no Kettle empregamos

o

Figura 29 – Componente Calculator do Kettle – Calculo da Margem de Contribuição

o Figura 29 – Componente Calculator do Kettle – Calculo da Margem de Contribuição Fonte: Kettle

Fonte: Kettle (2011)

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

 

099665

01 BRASIL LIMP

QUIMICO

1

01-03-10

NULL

 

043323

02 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”,

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

 

099665

01 BRASIL LIMP

QUIMICO

 
 

043323

02 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.

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

Dimension Lookup/Update do Kettle – SCD tipo 1 e 2 Fonte: Kettle (2011) Da mesma forma

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.

Figura 31 – Componente ‘tPostgreSqlSCD’ do Talend – SCD tipo 1, 2 e 3

‘ tPostgreSqlSCD’ do Talend – SCD tipo 1, 2 e 3 Fonte: Talend (2011) 5.6 PLANEJAMENTO

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

Figura 32 – Componente ‘ Database lookup’ do Kettle – Carga Tabela Fato Vendas Fonte: Kettle

Fonte: Kettle (2011)

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

‘ tMap’ do Talend – Carga Tabela Fato Vendas mostra carregamento da tabela fato Vendas. A

mostra

carregamento da tabela fato Vendas.

A

figura

a

seguir

Fonte: Talend (2011)

como

ficou

o

gráfico

completo

no

Talend

para

Figura 34 – Modelo do Talend – Carga Tabela Fato Vendas

o gráfico completo no Talend para Figura 34 – Modelo do Talend – Carga Tabela Fato

Fonte: Talend (2011)

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.

Figura 35 – Exemplo Facilidade para Criar Componentes a Partir de Conexões

Facilidade para Criar Componentes a Partir de Conexões Fonte: Talend (2011) c) Ainda que o processo

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.

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.

- 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.

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:

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-

processamento (SMP 17 ou MPP 18 ), suporte a Cluster 19 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.

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

 

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

 

1 3

0

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).

 

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

1

3

2

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.

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.

3.2

WYSIWYG: Ambas as ferramentas dominam bem esse princípio

1

3

3

de

“Aquilo você vê é o que você obtém”, evidentemente requer do

desenvolvedor um bom domínio das boas práticas de desenvolvimento.

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

2

2

2

de

treinamento só assim o desenvolvedor será capaz de usufruir de

maneira mais eficiente os recursos oferecidos por essas

ferramentas na sua totalidade.

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

2

4

4

foi

100%.

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.

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

2

2

3

é

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.

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”.

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.

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