ETL

Extract – Transform - Load

Professor: Sávio S. Teles de Oliveira

1
 Agenda
• Configurando o Ambiente
• Revisando a aula anterior
• Staging Area
• Web Scraping e Web Crawling
• Streaming Processing
• Evolução do estudo de caso de ETL para
trabalhar com Real Time Analytics

2
CONFIGURANDO O AMBIENTE DA
MÁQUINA VIRTUAL

3
 Download dos frameworks
• Flink-Kafka: http://bit.ly/2xUjgnD
• Kafka 0.11: http://bit.ly/2yC2mfj
• Kafka 0.8: http://bit.ly/2yIyvUH
• Spark: http://bit.ly/2zEiv3X

4
 Configurando a rede
• Escolha a máquina virtual ETL e clique em Configurações

5
 Configurando a rede
• Selecione a aba Rede do lado esquerdo.

6
 Configurando a rede
• Dentro da aba Rede: Clique em “Habilitar Placa de Rede” e
selecione a opção “Placa em modo Bridge” em “Conectado
a”. Clique em OK para salvar.

7
RECAPITULANDO...

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

9
Data Lake

10
Data Lake

11
 Estruturas de dados em ETL
• Fontes de dados não estruturados

12
 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

13
STAGING AREA

14
Staging Area

15
 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

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

17
 Projeto da Staging Area
• Table Name: o nome da tabela ou arquivo na
staging area. Existe uma linha na planilha para
cada “staging”

18
 Projeto da Staging Area
• 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.

19
 Projeto da Staging Area
• Load Frequency: revela como a tabela é
carregada ou modificada pelo processo ETL
– Geralmente diariamente, mas pode ser em qualquer
intervalo de tempo.

20
 Projeto da Staging Area
• 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

21
 Projeto da Staging Area
• 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.

22
 Projeto da Staging Area
• Average Row Length: estimar o tamanho de cada
linha da tabela de staging
– No Oracle, por exemplo, o DBMS STATS pode ser
utilizado

23
 Projeto da Staging Area
• 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

24
 Projeto da Staging Area
• 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.

25
 Projeto da Staging Area
• Expected Monthly Bytes: valor em bytes de
crescimento da tabela por mês.
– Cálculo: Average Row Length X Expected Monthly
Rows.

26
 Projeto da Staging Area
• Initial Table Size: valor em bytes ou megabytes
do tamanho inicial da tabela
– Cálculo: Average Row Length X Initial Row Count.

27
 Projeto da Staging Area
• 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)

28
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!

29
 Padrões de projeto e planejamento
• 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.

30
 Padrões de projeto e planejamento
• 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.

31
 Padrões de projeto e planejamento
• 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!!

32
Aspectos para ter em mente
• Gerenciabilidade
• Mantenabilidade
• Transparência
• Escalabilidade
• Flexibilidade
• Complexidade
• Possibilidade de realizar auditoria
• Testabilidade
• Tolerância a falhas

33
WEB CRAWLING & SCRAPING

34
Web Crawling e Scraping

35
Web Scraping
• Prática de coletar dados da Web que não seja
por API ou intermédio humano (Browser)
• O QUE É WEB SCRAPING?
– Scripts automatizados
– Solicitar páginas HTML
– Fazer o parsing e análise do arquivo
– Minerar informações e metadados da URL
– Gerar bases de dados
– Abrir portas para Machine Learning, Sales, Marketing,
Hacking, Big Data e etc..

36
Por quê usar WEB SCRAPING?
• Navegadores são muito bons! (Mas não
são a única opção)
• Coletar e processar grande quantidade de
dados
• Ir onde nenhum buscador jamais foi…
• Banco de dados estendido, de uma até 1
zilhão de páginas

37
QUANDO USAR?
• Quando você está coletando dados de
vários sites
• Quando o site não tem uma API coesa
• Quando você precisa de um conjunto de
dados não disponíveis na API
• A origem não tem infraestrutura ou
conhecimento técnico para criar uma API
• Quando a API tem limite de
velocidade/requisição.
38
QUANDO USAR?
• Buscadores
• Indexação e Ranking de conteúdo (SEO)
• Mineração de dados
• Encontrar oportunidades comerciais,
reclamações, contatos, pessoas, sales,
identificação de leads e etc

39
 Scrapy
• Framework livre escrito em Python
• Scraping e web crawling
– Usado para extrair dados estruturados de
páginas web.
• Instalação
–sudo pip install scrapy
–scrapy startproject <nome_do_projeto>
–cd <nome_do_projeto>
–spark crawl <nome_do_projeto>

40
 Hands on
• Instalação
–sudo apt-get install python-pip
–sudo pip install --upgrade pip
–sudo pip install scrapy
• Download do projeto: http://bit.ly/2gy3nkj
• Descompacte o arquivo do projeto
• Entre na pasta do projeto: cd farmacia
• Execute o projeto: scrapy crawl farmacia

41
Data Stream

42
 Definições
Tuplas são compostas por estruturas chave/valor:
Chave possui o timestamp da tupla.

Em ambientes de Stream:
As fontes geradoras são implementadas por estruturas como por exemplo
Spouts no Storm.

2/"abc" .... 4/“xyz"

43
 Definições
 Tuplas podem ser:
 Estruturadas ou não estruturadas:

 Necessário realização de pré-processamento dos dados.

 O formato chave/valor das tuplas:

 É chamado de data schema.

 Permite diferentes tamanhos e tipos de entradas.

Timestamp - src - port - dest - port

.... ....
Tupla

44
 Dado no stream source

A quantidade de dados recebidos é de

tamanho ilimitado.

 O volume de dados é contínuo/variável:

 Tipicamente imprevisível.

45
A entrada é variável e tipicamente imprevisível

46
Operadores

47
 Operadores

 Recebem tuplas.
 Processam/modificam as tuplas.
 Geram novas tuplas.

Tupla Tupla OP Tupla Tupla

48
Definições dos operadores
Operadores

Stateless Stateful
(map, filter)

Blocking Non-Blocking
(join, freq. item set) (count, sum)

49
Definições dos operadores
 Stateless (Sem Estado):
Precisam apenas da tupla da entrada para geração da tupla de
saída.
Exemplos: map/filter.
 Statefull (Com Estado):
 Blocking (Bloqueante):

Requer todas as tuplas necessárias para então realizar o

processamento.
Exemplos: join/freq.
 Non Blocking (Não Bloqueante):
Requer o resultado do processamento das tuplas anteriores e da
tupla atual.
Exemplos: count/sum.

50
Tipos de operadores
Filtragem (filter)
Sem estado (Stateless).

Agregação (aggregate)
Não Bloqueante (Statefull).

Junção (join)
Bloqueante (Statefull).

Divisão (split)
Sem estado (Stateless).

Machine Learning (complex)

Bloqueante/Não Bloqueante.

51
 Definição de janela

Tamanho da janela (unidades de tempo ou número de tuplas)

Tupla Tupla Tupla Tupla Tupla Tupla Tupla TuplaTupla Tupla Tupla Tupla Tupla

Início Fim

52
 Definição de Avanço
Início Antigo Fim Antigo

Tupla Tupla Tupla Tupla Tupla Tupla Tupla

avanço
Tupla Tupla Tupla Tupla Tupla Tupla Tupla

Novo Início Novo Fim

53
 Modelo de
Programação

54
 NiagaraCQ
Granules
Cougar
TelegraphCQ
S4
STREAM
Storm
Aurora/Medusa
BusinessEvents
Samza
StreamBase
Spark Streaming
Borealis
Oracle CEP
MillWheel
InfoSphere
TimeStream
Streams
Flink Streaming
Stream Mill

1a. Geração 2a. Geração 3a. Geração

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014

55
 Gerações segundo a maioria dos autores

1a Geração 2a Geração 3a Geração

Data Stream Management Stream Processing System

Continuous Query
System

Centralizado Massivamente
Distribuído
Paralelo

Única Máquina Sistemas Distribuídos Cloud computing

SQL-based/ Linguagens comuns para

Baseados em SQL
visual drag-and-drop dadados

Heinze (2014)
56
Batch Vs. Stream Batch

Stream

Hadoop Storm

Batch Near Real-Time

Flink
Stream (RT)

57
Plataformas
Storm

58
 Conceitos (Storm)

 Proposto inicialmente por Nathan Mars (BackType):

 Escrito em Clojure e Java.

 Utilizado com objetivo principal:

 Processamento de dados em tempo real (RT).
 Principal ambiente SPS (RT) da atualidade.

 Principal empresa/ferramenta utilizadora do Storm:

 Twitter (Adquiriu os direitos do Storm comprando a BackType).
 Projeto foi doado a Apache posteriormente.

59
Conceitos (Storm)
Principais componentes formadores de um grafo:

 Spout:
 Fonte geradora do Streaming (Tuplas).

 Bolt:
 Unidades de processamento/transformação dos dados (Tuplas).

 Sink:
 Similar ao bolt porém não gera dados de saída.
 Usado para exportação de dados do ambiente de SPS.

60
Topologia

61
Arquitetura do Storm
Message Queue
(opicional)

Nó mestre Coordenador do Despacha tarefas Executa

Cluster para workers tarefas

62
Exploração do
Paralelismo

63
Paralelismo Estático

2
3

4
1

64
Plataformas
Apache Kafka

65
 Plataforma Apache Kafka
• Modelo Publish & Subscribe
– Leitura e escrita de fluxo de dados como um sistema
de troca de mensagens
• Processamento
– Escrita de aplicações de streams escaláveis que
processam eventos em tempo real
• Armazenamento
– Armazena o fluxo de dados de forma segura em um
ambiente distribuído, replicado e tolerante à falhas.

66
Plataforma Apache Kafka

67
Plataforma Apache Kafka

68
Plataforma Apache Kafka

69
Plataforma Apache Kafka

70
Plataforma Apache Kafka

71
Plataforma Apache Kafka

72
 Hands-on com Apache Kafka
• Entrar dentro da pasta do Kafka
• No terminal, inicie o Zookeeper
– bin/zookeeper-server-start.sh
config/zookeeper.properties
• Em outro terminal, inicie o servidor do Kafka
– bin/kafka-server-start.sh config/server.properties
• Em outro terminal, crie um tópico do Kafka
– bin/kafka-topics.sh --create --zookeeper
localhost:2181 --replication-factor 1 --partitions 1 --
topic test

73
 Hands-on com Apache Kafka
• Em outro terminal, envie algumas mensagens
– bin/kafka-console-producer.sh --broker-list
192.168.1.63:9092 --topic test
• Abra um novo terminal para receber as
mensagens
– bin/kafka-console-consumer.sh --bootstrap-server
192.168.1.63:9092 --topic test --from-beginning

74
Plataformas
Spark Streaming

75
Processamento de fluxo de dados discreto
Roda um stream como uma sequência de jobs
determinísticos batchs muito pequenos
live data stream
Spark
 Corta o live stream em batches de X Streaming
segundos

 Spark trata cada batch de dados como um batches of X

RDDs e processa-os usando operadores seconds

 Finalmente, os resultados processados da

operação RDD são retornados em batches
Spark
processed
results

Resilient Distributed Dataset (RDD): é uma estrutura onde os dados estão em memória e
podem ser recuperados sem a necessidade de replicação.

76
Processamento de fluxo de dados discreto
Roda um streaming como uma sequência de jobs
determinísticos batchs muito pequenos
live data stream
Spark
 O tamanho do batch é tão pequeno como ½ Streaming
segundo, latência ~ 1 segundo
batches of X
seconds
 Potencial para combinar processamento em
batch e streaming no mesmo sistema
Spark
processed
results

77
Arquitetura do Spark

78
 Mecanismo de Tolerância a Falhas
 RDDs sabem a seqüência de tweets Entrada de
operações que o criou de uma entrada RDD dados
de dados original tolerante a falhas replicada em
memória

 Batches de entrada de dados são

replicados em memória de múltiplos flatMap
nós workers, sendo assim tolerante a
falhas
hashTags
RDD
 Data perdidos devido a falhas do Partições perdidas
são recomputadas
worker podem ser recomputados a em outros workers
partir da entrada de dados.

79
 Hands-on com Spark + Kafka
• Análise de Sentimento do Twitter
• Façam o download: http://bit.ly/2gyHQYx

80
Plataformas
Flink

81
 Arquitetura Lambda
A arquitetura Lambda [Marz, 2013], seria mais
adequada para descrever os atuais sistemas de Big
Data [Kir15],[Cae16] .

82
 4ª Geração de processamento de dados

• Alguns autores importantes como o Buyya,

redefinem o Flink como um sistema de 4ª.
Geração por suportar:
– Algoritmos Iterativos;
– Possuir mecanismos internos de otimização;
– Por seguir o modelo da arquitetura Lambda;
– Por ser uma arquitetura de programação híbrida;
• Permitir execuções em batch e real-time simultâneo.

83
 Plataforma Apache Flink

• Processamento batch e/ou stream (programação

híbrida)
• Abstrações de programação em Java, Scala e Python
• Tem um gerenciador de execução de alto
desempenho e otimização automática de código.
• Suporte nativo para iterações incrementais ou não
incrementais
• Expressa DAGs de operações.

84
 Plataforma Apache Flink

• A programação de transformações de conjuntos

de dados.
– Os conjuntos de dados são inicialmente criados a
partir de alguma fonte (leitura de arquivos ou coleções
locais).
• Os resultados são retornados via sinks.
• Não tem um Storage próprio.
• Grava diretamente em um arquivo distribuído ou
em uma saída padrão.

85
Arquitetura do Apache Flink

86
 Transformações Apache Flink

• FlatMap: A partir de um elemento produz zero ou mais elementos;

• MapPartition: Transforma uma partição paralela em uma única

chamada de função e produz um número arbitrário de resultados;

• Filter: Avalia uma função booleana para cada elemento e mantém

aqueles para os quais a função retorna verdadeiro;

• Reduce: Combina um grupo de elementos em um único elemento;

• Aggregate: Agrega um conjunto de valores em um único valor;

• E outras

87
Plataformas
Apache Flume

88
 Plataforma Apache Flume
• Distribuído
• Confiável
• Robusto e tolerante a falhas
• Serviço para coleta, agregação e
movimentação de grande volume de dados
• Arquitetura simples e flexível baseado no
fluxo de dados baseado em streaming
• Modelo de dados extensível para aplicações
de análises online

89
 Plataforma Apache Flume
• Fontes de dados comuns:
– Logs de aplicações
– Dados de sensores
– Dados geolocalizados
– Redes sociais

90
 O que o Apache Flume faz?
Funcionalidade Descrição

Dados de Ingestão de dados das múltiplas fontes dentro do Hadoop

Streams para armazenamento e análises.

Isolar os Sistema de armazenamento temporário para lidar com

sistemas picos de escrita, quando a taxa de dados de entrada
excede a taxa que deve ser escrita para o destino.
Garantia de Utiliza um canal baseado em transações para garantir
entrega dos entrega confiável de mensagens.
dados
Escalabilidade Permite adicionar recursos computacionais ao cluster para
Horizontal permitir lidar com um maior volume de dados.

91
Plataformas
Apache Sqoop

92
 Plataforma Apache Sqoop
• Ferramenta para importação de dados de
bancos de dados relacionais
• Pode ser utilizado também para exportar
dados do Hadoop para bancos de dados
relacionais.
• Trabalha bem com RDBMS com conectividade
JDBC

93
 Plataforma Apache Sqoop
• Armazena os dados no HDFS
– Permite mapear os dados de entrada dos bancos
de dados relacionais para o Hbase e Hive
• Utilizado para transferência e importação de
dados de forma paralela
• Ajuda a mitigar a carga excessiva de sistemas
externos.
• Provê interação com os dados de forma
programática.

94
 Plataforma Apache Sqoop
• sqoop import --connect jdbc:postgresql://hdp-
master/sqoop_db --username sqoop_user --password
postgres --table cities
• sqoop export --connect jdbc:postgresql://hdp-
master/sqoop_db --username sqoop_user --password
postgres --table cities --export-dir cities

95
Plataformas
Apache Beam

96
 Plataforma Apache Beam
• Modelo de programação simples para batch e
streaming.
• Executa pipelines em múltiplos ambientes de
execução.
• Permite escrever e compartilhar novos SDKs,
conectores IO e bibliotecas de transformação.

97
Plataforma Apache Beam

98
A evolução do Apache Beam

99
Comparação entre
Plataformas

100
101
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