ETL

ETL
Extract – Transform - Load
1
Um pouco sobre mim: Sávio Teles
• Mestre em Computação (UFG) - Sistemas Distribuídos
• Doutorando em Computação (UFG) - Big Data
• Atualmente lidera a equipe de Big Data da goGeo
• Trabalha desde 2008 com Big Data
Contato:
https://www.linkedin.com/in/savio-teles-6707b111/
savioteles@gmail.com
2
Agenda
• Introdução ao Big Data ETL

• Aplicações
• Requisitos de sistemas ETL
• Estruturas de dados de ETL
• Arquitetura do sistema ETL
• Staging Area
• Estudos de Caso
3
ETL é realmente importante?
4
Data warehouse
Data warehouse é um sistema que extrai, limpa, padroniza
e entrega os dados das fontes de dados em um
armazenamento dimensional dos dados permitindo
implementar consultas e análises para o propósito de
tomada de decisões.
Fonte: Ralph Kimball, Joe Caserta: The Data Warehouse ETL Toolkit; Wiley 2004
A parte mais visível para os clientes é “Consultar e Analisar”
A parte mais complexa e demorada é “extrair, limpar,

padronizar e entregar”
5
Arquitetura padrão
6
GRANDE quantidade de
dados
estão sendo geradas em
real-time
7
BIG DATA ETL –
A NOVA GERAÇÃO DO ETL
8
O que representa 60 segundos
de dados?
9
10 10
Processo Tradicional de ETL
11
Processo Tradicional de ETL
12
Esperando o ETL terminar...
13
Big Data ETL
14
Big Data ETL
15
Hadoop
16
5 Vs de Big Data
Data Lake
18
Data Lake
19
ALGUMAS APLICAÇÕES
20
Monitoramento de tráfego
21
Monitoramento de tráfego
 Arquitetura para Stream e complex event
processing (CEP processing).
 Entrada baseada em sensores.
 Usa informação colaborativa (crowdsourcing)

para resolver problemas de insegurança da
fonte de dados.
 Dataset de 13GB por mês da cidade de Dublin

(Irlanda).
Smart Grid
23
Projeto de Smart Grid em L.A.
• 1.4 milhões de consumidores
• Otimização de demanda energética
• Predição de pico de demanda
• Fonte de dados:
– AMIs ( Advanced Metering Infrastructure)
• 3 TB de dados por dia
24
Redes de Sensores
25
Detecção de eventos em tempo
real usando o Twitter
Agência de meteorologia do Japão

26
Detecção de eventos em tempo
real usando o Twitter
• Detecção de eventos como: tufões,
terremotos,...
• Usuários de Twitter atuam como sensores;
• Estima localização usando Filtro de
Kalman e de partículas;
• Detecta 96% de furacões reportados na
agência de meteorologia do Japão
27
Aplicações necessitam...
Grande Volumes de Dados
Em real-time
Continuamente
Produzindo ações e informações
28
LEVANTANDO OS REQUISITOS
29
Levantando os Requisitos
• Reunir em único lugar todos os requisitos e limitações
que podem afetar o sistema ETL.
• Momento de tomar as decisões, exercitar seu julgamento
e potencializar sua criatividade
• Identificar as decisões arquiteturais que você precisa no
início do seu projeto ETL
• Essas decisões irão guiar o que você fizer na
implementação
• A arquitetura afeta a configuração do hardware, software
e do modelo de programação.
30
Levantando os Requisitos
• Necessidades do Negócio
• Perfil dos Dados
• Requisitos de Segurança
• Integração dos Dados
• Latência dos Dados
• Arquivamento e Linhagem
• Interfaces de Entrega para o Usuário Final
• Habilidades Disponíveis
• Licenças Legadas
31
Necessidades do Negócio
• Identificar o conjunto de
informações que o time de
ETL deve ser introduzido.
• Requisitos dos usuários finais
• Requisitos de negócio
• Guiar a escolha das fontes de
dados
• Alinhamento de expectativas
• Precisa ser constantemente
revisado e rediscutido.
32
Perfil dos Dados
• Precursor para projetar qualquer tipo de sistema que
utiliza dados
• Sistemática avaliação da qualidade, escopo e contexto
das fontes dos dados
• Descobrir o que existe nos dado
• Obter métricas da qualidade dos dados
• Levantar os riscos envolvidos em criar as regras de
negócio
• Descobrir os metadados incluindo padrões de valores
• Entender os desafios relacionados aos dados para evitar
custos não previstos
33
Perfil dos Dados
34
Requisitos de Segurança
35
Requisitos de Segurança
• Continua sendo uma reflexão tardia e indesejável
• A segurança deve assumir que os dados devem estar
restritos apenas àqueles que devem ter conhecimento
dos dados.
• A segurança não deve ser definida por usuários finais,
mas por papéis
• O time de ETL não deve se preocupar com o projeto e
gerenciamento da segurança do usuário final.
• O time de ETL deve ter total acesso aos dados
• Time de ETL deve estar em uma sub-rede separada
• Segurança deve ser estendidas aos Backups.
36
Integração dos Dados
• Tornar possível que todos os sistemas trabalhem juntos
sem problemas.
• Integrações de dados devem primeiro lidar com os dados
primários de transações dos sistemas da empresa.
• Envolve estabelecer nomes comuns dos atributos.
• Estabelece conteúdos e unidades de medida comuns.
37
Latência dos Dados
• Descreve quão rápido os dados devem ser entregues aos
usuários finais
• Tem grande efeito na implementação e arquitetura do
sistema
• A maior parte dos fluxos de dados em batch podem ser
tratados com processamento paralelo e hardware mais
potentes
• Se a latência for um requisito altamente prioritário, então
o sistema ETL deve ser convertido de orientado a batch
para orientado a streaming.
38
Arquivamento e Linhagem
• O Data Storage necessita de várias cópias dos dados
antigos para comparação com os novos dados ou para
reprocessamento.
• É recomendável que os dados sejam armazenados nos
pontos onde ocorreram grandes transformações.
• O armazenamento deve ocorrer depois dos passos de
extração, limpeza, conformidade e entrega dos dados.
• Mas, quando o armazenamento (escrita dos dados no
disco) se torna arquivamento (manter os dados
indefinitivamente)?
39
Arquivamento e Linhagem
• O Data Storage necessita de várias cópias dos dados
antigos para comparação com os novos dados ou para
reprocessamento.
• É recomendável que os dados sejam armazenados nos
pontos onde ocorreram grandes transformações.
• O armazenamento deve ocorrer depois dos passos de
extração, limpeza, conformidade e entrega dos dados.
• Mas, quando o armazenamento (escrita dos dados no
disco) se torna arquivamento (manter os dados
indefinitivamente)?
• Resposta conservadora: arquivar todos os dados
armazenados.
40
Interfaces de Entrega
• O time de ETL, trabalhando junto com o time de
modelagem, deve ter a responsabilidade pelo conteúdo
final.
• Tornar as aplicações para o usuário final simples e
rápidas
• O time de ETL e de modelagem devem trabalhar
próximos dos desenvolvedores da aplicação final para
determinar os requisitos finais dos dados.
• Cada aplicação tem certos pontos sensíveis que
deveriam ser evitados e certas funcionalidades que
deveriam ser mais exploradas caso os dados estejam no
formato correto.
41
Habilidades disponíveis na equipe
• As grandes decisões na construção de um sistema ETL
são tomadas baseadas em quem vai construir e gerenciar
o sistema
• Você não deve ir na direção técnica no qual os
empregados e gerentes não se sentem familiarizados
sem considerar seriamente as implicações.
42
Licenças Legadas
• As maiores decisões de projeto poderão ser
tomadas pelo Gerente Sênior insistindo que
você utilize as licenças legadas.
43
Comprar uma ferramenta ETL?
– “Depende!!”
– Vantagens de comprar uma ferramenta ETL
• Desenvolvimento mais rápido, barato e simples
• Profissionais com grande conhecimento do
negócio, quanto os programadores podem utilizar
as ferramentas ETL de forma efetiva.
• Muitas ferramentas de ETL possuem integração
com diversas fontes de dados, bancos de dados e
ferramentas de BI.
• A ferramenta ETL lida com toda a complexidade de
dependências e tratamento de erros.
44
• Vantagens de comprar uma ferramenta ETL
– Fornecem análises de dependência (olhar para frente)
e linhagem dos dados (olhar para trás).
– Possuem conectores para a maioria de fonte de dados
e os sistemas de destino.
– A ferramenta ETL deve cuidar das conversões de tipos
complexos de dados.
– Oferecem funcionalidades de encriptação e
compressão dos dados
– Gerenciamento do balanceamento de carga entre
servidores
45
• Vantagens de construir a solução de ETL.
– Permite validar os passos no fluxo do ETL verificando
a consistência dos dados a cada etapa.
– Em alguns casos, os requisitos das ferramentas ETL
não atendem aos requisitos da aplicação.
– A construção da ferramenta permite ter flexibilidade
ilimitada, não ficando limitado às funcionalidades das
ferramentas de ETL.
– Em alguns casos, a baixa complexidade da solução
ETL requerida pela sua empresa não vale a pena a
compra de uma ferramenta ETL.
46
Batch vs Streaming
• Batch
– A arquitetura padrão para um sistema ETL
– Os dados fluem através do sistema e resulta em uma
inserção em lote no Data Storage.
• Streaming
– Fluxo de dados a nível de registro
– Fluxo contínuo da fonte de dados para o Data Storage
e aplicações
• Mudança de Batch para Streaming pode
mudar tudo!
47
Dependências de tarefas
• Horizontal
– Permite que os dados sejam carregados dos bancos
de dados de forma independentes
– Geralmente significa que os passos de extrair, limpar,
padronizar e carregar não são sincronizados entre os
jobs.
• Vertical
– Sincroniza dois ou mais fluxos
– Todos os jobs chegam juntos as etapas de
padronização e carregamento
48
Automatização do Scheduler
• Decisão arquitetural importante: qual o nível de
controle do sistema de automatização da
execução do sistema ETL?
• Em um extremo, todos os jobs são iniciados por
humanos
• Em outro extremo, uma ferramenta master
gerencia todos os jobs
– Sabe quais jobs executaram corretamente
– Espera por vários status do sistema estarem
satisfeitos
49
Tratamento de Exceções
• O tratamento de exceções não deveria ser uma
série randômica de pequenos alertas
armazenados em arquivos
• Cada instância de exceção deveria conter
– Nome do processo
– Hora que a exceção foi lançada
– Severidade da exceção
– Ação subsequente tomada
– Último status de resolução da exceção
50
Recuperação e Reinicialização
• Você deve construir seu sistema ETL com a
habilidade de recuperar de finalizações abruptas de
um job e reiniciar
• Jobs ETL devem ser reentrantes, ou seja, os jobs
podem ser executados concorrentemente de forma
segura.
51
Processar com disco ou memória
• A decisão do arquiteto de ETL.
• Determinar o equilíbrio correto entre o custo de
I/O e o processamento em memória
• A questão de determinar se armazena ou não os
dados temporários depende de dois objetivos
conflitantes:
– Carregar os dados da fonte original até o Data
Storage o mais rápido possível.
– Habilidade de recuperar de falhas sem reiniciar desde
o início do processo.
52
ESTRUTURAS DE DADOS - ETL
53
Estruturas de dados em ETL
• Flat Files: quando os dados são armazenados
em linhas e colunas no arquivo de sistema de
forma a emular uma tabela do banco de dados.
54
• Bancos de dados relacionais
– Armazenamento dos dados de staging em Bancos de dados
relacionais.
– Especialmente apropriado quando não existe uma ferramenta
ETL.
55
• XML
– Linguagem para comunicação de dados.
– Capacidade de declarar estruturas hierárquicas. Essa
estrutura não é diretamente mapeada em tabelas
relacionais.
56
• Fact Tables
57
• Dimension Tables
• O modelo dimensional não antecipa ou depende de
usos de consultas desejadas
• Atributos podem ser adicionados incrementalmente
durante a vida do Data Storage
• O arquiteto responsável pelo Data Storage deve
identificar essas oportunidades para adicionar novos
atributos e requisitar ao time ETL.
• Os atributos podem estar no formato textual e
numérico.
58
• Atomic e Aggregate Fact Tables
• Geralmente, os usuários não desejam analisar fatos a nível
transacional porque a cardinalidade de cada dimensão é muito
alta.
• Entretanto, é necessário armazenar fatos a nível atômico para
produzir snapshots periódicos de fatos requisitados por
usuários.
• Quando o usuário requisitar os dados, você pode migrá-los da
camada de armazenamento para a camada de apresentação.
• Uma boa prática é particionar as tabelas porque as
agregações são geralmente baseadas em períodos
específicos - por exemplo mensalmente.
59
• Fontes de dados não estruturados
60
EXTRAÇÃO – TRANFORMAÇÃO -
CARREGAMENTO
61
Back Room vs Front Room
62
Back Room – Preparando os dados
63
Extração de dados
• A integração de todos os sistemas é o principal
desafio para extrair valor dos dados.
• O primeiro passo da integração é extrair os
dados das fontes primárias.
• O processo de ETL precisa de forma efetiva
integrar sistemas com diferentes:
– Sistemas de Gerenciamento de Banco de Dados
– Sistemas Operacionais
– Hardware
– Protocolos de Comunicação
64
Extração de dados
• Modelo lógico de dados
– Criar e documentar um plano de integração
– Identificar os candidatos a fontes de dados
– Contemplar, para cada um dos atributos, o tipo de
dado, tamanho e opcionalidade.
– Representar fielmente o NEGÓCIO, e NÃO
necessariamente a base de dados desejada
– Conter os nomes de entidades e atributos de acordo
com algum padrão adotado na organização
65
Extração de dados
• Mapa lógico de dados
66
Extração de dados
• Relatório de rastreamento do sistema fonte dos
dados.
67
Transformação dos dados
• Limpeza e Normalização
dos dados
• Be Thorough: sistema como
fonte de dados confiável
• Be Fast: processar grandes
volumes de dados em
pequenas janelas de tempo.
• Be Corrective: Corrigir
problemas de qualidade de
dados o mais breve.
• Be Transparent: Expor os
problemas que impactam na
qualidade dos dados
68
Carga dos dados
• Scripts em shell, python, ...
• Hardcoded in Java, python, ...
• Ferramentas ETL construídas
internamente
• Ferramentas ETL
consolidadas e otimizadas
– Pentaho
– IBM InfoSphere DataStage
– Oracle Data Integrator
– CloverETL
69
STAGING AREA
70
Staging Area
71
Staging Area
• Área de armazenamento dos dados temporários
do ETL
• A Staging Area deve ser administrada apenas
pelo time de ETL
• Usuários não são permitidos nesta área por
qualquer razão
• Relatórios não podem acessar dados nesta área
• Apenas processos de ETL podem ler e escrever
na Staging Area
72
Projeto da Staging Area
• O arquiteto ETL deve fornecer ao time de administração
do banco de dados e do S.O. uma estimativa de
utilização de espaço e parâmetros de configuração dos
bancos de dados e sistema de arquivos necessários.
73
• Table Name: o nome da tabela ou arquivo na
staging area. Existe uma linha na planilha para
cada “staging”
74
• Update Strategy: indica como a tabela é mantida.
– Tabela persistente: dados serão adicionados, atualizados e talvez
deletados.
– Tabelas transientes: tabelas recarregadas a cada processo ETL.
75
• Load Frequency: revela como a tabela é
carregada ou modificada pelo processo ETL
– Geralmente diariamente, mas pode ser em qualquer
intervalo de tempo.
76
• ETL job: tabelas são populadas ou atualizadas
pelos jobs ETL
– Quando muitos jobs afetam uma tabela, são listados
todos os jobs nesta planilha
77
• Initial Row Count: o time de ETL deve estimar quantas
linhas cada tabela na staging area irá conter inicialmente
– Esse valor é geralmente baseado no número de tuplas da
fonte/destino de dados.
78
• Average Row Length: estimar o tamanho de cada
linha da tabela de staging
– No Oracle, por exemplo, o DBMS STATS pode ser
utilizado
79
• Grows With: define quando cada tabela na staging area
cresce.
– Nem sempre as tabelas crescem a cada vez que são acessadas.
– Esse campo é baseado na regra de negócio
80
• Expected Monthly Rows: número de linhas que cresce na
tabela por mês.
– Estimativa baseada no histórico e regras de negócio.
– Alocar o espaço previamente.
81
• Expected Monthly Bytes: valor em bytes de
crescimento da tabela por mês.
– Cálculo: Average Row Length X Expected Monthly
Rows.
82
• Initial Table Size: valor em bytes ou megabytes
do tamanho inicial da tabela
– Cálculo: Average Row Length X Initial Row Count.
83
• Table Size 6 Months: estimativa do tamanho das tabelas
depois de 6 meses
– Cálculo: (Average Row Length X Initial Row Count) + (Average
Row Length X Expected Monthly Rows X 6) / 1,048,576)
84
Padrões de projeto e planejamento
• A staging area deve ser gerenciada e mantida como
qualquer outro banco de dados no seu ambiente.
• Muitas staging areas são administrada com
desenvolvedores tendo acesso a tudo (criar, deletar e
modificar tabelas)
• Naturalmente essa área deve ser controlada com apenas
o arquiteto de dados tendo acesso a projetar ou modificar
as tabelas.
• Desenvolvedores são bem criativos: se você constrói uma
tabela, é esperado que ela seja utilizada por outra pessoa
para finalidades que você nunca imaginou!
85
• Análise de impacto
– Examina os metadados associados às tabelas para
determinar o que será afetado por alguma mudança
na estrutura ou conteúdo.
– Responsabilidade onerosa já que mudanças nos
dados podem ser contínuas.
– Apenas o processo ETL sabe exatamente quais
elementos estão conectados.
– Comunicação entre o time de ETL e o time de banco
de dados é crucial para assegurar uma apropriada
análise de impacto das mudanças.
86
• Captura dos Metadados
– Linhagem dos dados: conjunto de transformações aplicados nos
dados entre a fonte dos dados e o Data Storage.
– Definições de negócio: toda tabela criada na staging area vem de
definições de negócio que são capturadas na camada de
apresentação.
– Definições técnicas: descreve os atributos físicos dos dados
(estrutura, formato e localização) propriamente documentados
para minimizar ambiguidade e assegurar reusabilidade.
– Metadados dos processos: o time de ETL deve saber exatamente
quantos registros foram carregados em cada etapa com sucesso.
87
• Convenção de
nomenclatura
– As tabelas de dados devem ser
padronizadas com uma
nomenclatura definida pelo
arquiteto.
– Uma boa prática é aplicar o
mesmo padrão de nomenclatura
dos bancos de dados para as
tabelas da staging area.
– Não esqueçam de
DOCUMENTAR!!
88
Aspectos para ter em mente
• Gerenciabilidade
• Mantenabilidade
• Transparência
• Escalabilidade
• Flexibilidade
• Complexidade
• Possibilidade de realizar auditoria
• Testabilidade
• Tolerância a falhas
89
ESTUDOS DE CASO
90
Estudo de Caso 1: Varejista
• Trabalhamos na matriz de uma grande rede de
supermercados com mais de 100 filiais.
• Cada supermercado tem mais de 60.000
produtos individuais (SKU).
– 55.000 de fornecedores
– 5.000 próprios
• Dados de compras dos consumidores
• Controle de estoque dos produtos
91
Estudo de Caso 1: Varejista
92
Estudo de Caso 2: Bancos
• Trabalhamos em uma grande instituição
financeira com milhões de clientes.
• Armazenamos os dados de cada cliente do
nosso banco.
• Mantemos o histórico de todas as transações
feitas pelos clientes do nosso sistema.
93
Estudo de Caso 2: Bancos
94
Estudo de Caso 3: Telecom
• Trabalhamos em uma empresa de telefonia
com milhões de clientes.
• Armazenamos os dados de cada cliente.
• Mantemos o histórico de ligações de cada
cliente.
95
Estudo de Caso 4: Utility de Energia
• Trabalhamos na CELG com milhares de
clientes.
• Mantemos o histórico de consumo de cada
cliente.
• Mantemos o histórico de pagamentos das
contas de energia de cada cliente.
96
Estudo de Caso 5: Transporte aereo
• Trabalhamos em uma grande empresa aerea
com milhares de passageiros por dia.
• Armazenamos os dados de cada passageiro.
– Dados pessoais
– Forma de pagamento
– Perfil do cliente: gold, diamante, etc...
• Armazenamos os dados de cada vôo.
97
Estudo de Caso 6: Plano de Saúde
• Trabalhamos em uma grande empresa de
plano de saúde com centenas de milhares de
clientes.
• Mantemos os dados de cada prestador
– Clínicas, hospitais, etc...
• Armazenamos os dados de cada utilização do
plano de saúde por parte do cliente
98
Estudo de Caso 6: Plano de Saúde
99
Estudo de Caso 7: eCommerce
• Trabalhamos em uma grande empresa de
vendas de produtos na internet com milhares
de vendas todo dia.
• Mantemos os dados de cada produto
• Armazenamos os dados de cada compra
100
Estudo de Caso 7: eCommerce
101
Estudo de Caso 8: Seguradora
• Trabalhamos em uma grande Seguradora que
oferece seguros para residências, automóveis
e seguros pessoais.
• Mantemos os dados de cada produto
segurado
• Armazenamos os dados de cada utilização do
seguro por parte do cliente
102
Referências
• KIMBALL, Ralph; CASERTA, Joe. The Data Warehouse? ETL
Toolkit: Practical Techniques for Extracting, Cleaning,
Conforming, and Delivering Data. John Wiley & Sons, 2011.
• DOAN, AnHai; HALEVY, Alon; IVES, Zachary. Principles of data
integration. Elsevier, 2012.
• KRISHNAN, Krish. Data warehousing in the age of big data.
Newnes, 2013.
• ROLDÁN, María Carina. Pentaho Data Integration Beginner's
Guide. Packt Publishing Ltd, 2013.
• Big Data ETL:
– https://www.slideshare.net/SparkSummit/spark-summit-keynote-by-suren-
nathan
– https://software.intel.com/sites/default/files/article/402274/etl-big-data-with-
hadoop.pdf
103
Referências
• FRIEDMAN, Ellen; TZOUMAS, Kostas. Introduction to Apache
Flink: Stream Processing for Real Time and Beyond. 2016.
• NARKHEDE, Neha; SHAPIRA, Gwen; PALINO, Todd. Kafka: The
Definitive Guide. 2016.
• JAIN, Ankit; NALYA, Anand. Learning storm. Packt Publishing, 2014.
• KARAU, Holden et al. Learning spark: lightning-fast big data
analysis. " O'Reilly Media, Inc.", 2015.
• DEROOS, Dirk et al. Hadoop for Dummies. John Wiley & Sons,
Incorporated, 2014.
• MITCHELL, Ryan. Web scraping with Python: collecting data from
the modern web. " O'Reilly Media, Inc.", 2015.
104
105

ETL - Aula 1

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ETL - Aula 1

Caricato da

Copyright:

Formati disponibili

Extract – Transform - Load

• Introdução ao Big Data ETL

A parte mais visível para os clientes é “Consultar e Analisar”

A parte mais complexa e demorada é “extrair, limpar,

 Entrada baseada em sensores.

 Usa informação colaborativa (crowdsourcing)

 Dataset de 13GB por mês da cidade de Dublin

Agência de meteorologia do Japão

Produzindo ações e informações

Potrebbero piacerti anche