qcon rio 2015 - data lakes workshop
TRANSCRIPT
DATA LAKES COM HADOOP E SPARK
AGILE ANALYTICS NA PRÁTICA
Ricardo Wendell [email protected]
João Paulo [email protected]
AGENDA
Introdução
Data Warehousing e projetos tradicionais
Arquiteturas de Data Lake
Hadoop e Spark
Tópicos relacionados
Conclusão2
INTRODUÇÃO
3
4Fonte: http://socialtimes.com/one-minute-internet-infographic_b147855
5
BIG DATA
6
BIG DATAV V V V
7
VOLUME
“DADOS EM REPOUSO”
8
VOLUME2.5 QUINTILHÕES DE BYTES GERADOS POR DIA!
9
VELOCIDADE
“DADOS EM MOVIMENTO”
10
VARIEDADE
“DADOS EM MUITOS FORMATOS”
11
VERACIDADE
“DADOS EM DÚVIDA”
12
DATA SCIENCE
13
14Fonte: http://www.shoesofprey.com/blog/pic/ahFzfnNob2Vzb2ZwcmV5LWhyZHIWCxINQmxvZ0ltYWdlRGF0YRiWxuoJDA.jpg
15Fonte: http://ecx.images-amazon.com/images/I/81D5CBkXL6L._SL1500_.jpg
16Fonte: http://www.portalgildabonfim.com.br/site/wp-content/uploads/2014/02/beneficios-da-castanha-do-para-na-barra-de-cereal.png
17
OPORTUNIDADES
18
VAREJO FINANÇAS SAÚDE MOBILE ONGS FÁBRICAS
OPORTUNIDADES
19
VAREJO FINANÇAS SAÚDE MOBILE ONGS FÁBRICAS
Security/Fraud Analytics
Audio/Image/Video Analytics
Text Analytics
Sensor Data Analytics (IoT)
Marketing Analytics
20
DATA SCIENTIST
DATA ENGINEER
21Fonte: https://www.flickr.com/photos/marsdd/2986989396
22Fonte: http://www.forbes.com/sites/danwoods/2014/08/28/why-you-should-hire-a-robot-to-write-for-you/
23
O S E M N
24
O S E M N
ABORDAGENS TRADICIONAIS
25
DATAWAREHOUSE MULTI-CAMADAS GENÉRICO
26
ANALYTICS TRADICIONAL
27
DATA WAREHOUSING E BI
28
ABORDAGENS TRADICIONAIS
29
ABORDAGENS TRADICIONAIS
30
Grande foco em TI!
“Data warehousing e BI são os maiores gastos no orçamento de CIOs, e têm tido
limitado valor para os negócios.”
— Jeff Smith, CIO da IBM
31
Difere
nciação
O que aconteceu?
DescritivoPor que aconteceu?
Diagnóstico
O que irá acontecer?
Preditivo Como podemos fazer acontecer?
PrescritivoVa
lor
Complexidade
Valo
r
Complexidade
Difere
nciação
O que aconteceu?
DescritivoPor que aconteceu?
Diagnóstico
O que irá acontecer?
Preditivo Como podemos fazer acontecer?
Prescritivo
DATA SCIENCE
BI TRADICIONAL
34
2012
35
HOJE
DATA LAKES E AGILE ANALYTICS
36
37
Fonte: http://martin.kleppmann.com/2015/05/27/logs-for-data-infrastructure.html
38
Fonte: http://martin.kleppmann.com/2015/05/27/logs-for-data-infrastructure.html
39
Fonte: http://martin.kleppmann.com/2015/05/27/logs-for-data-infrastructure.html
40
Fonte: http://martin.kleppmann.com/2015/05/27/logs-for-data-infrastructure.html
ARQUITETURA LAMBDA
41
42
ARQUITETURA LAMBDA
43
ARQUITETURA LAMBDA
44
ARQUITETURA LAMBDA
45
PIPELINE DE DADOS ADAPTATIVO
QUAL O NOSSO DESAFIO?
Dados contidos em múltiplos sistemas
Que são frequentemente armazenados em diferentes formatos
E idealmente ter uma fonte da verdade, de onde derivar os dados
46
Pense em um datamart como uma loja de garrafas
de água: limpa, embalada e organizada para fácil
consumo; o lago de dados é um grande corpo de
água em um estado mais natural.
O conteúdo do lago de dados flui de uma fonte para preencher o lago, e vários usuários podem
vir examinar, mergulhar ou pegar amostras.
James Dixon, CTO of Pentaho
47
An Enterprise Data Lake is an immutable data store of largely un-processed “raw” data, acting as a source for other
processing streams but also made directly available to a
significant number of internal, technical consumers using some
efficient processing engine. Examples include HDFS or HBase within a Hadoop, Spark or Storm processing framework. We
can contrast this with a typical system that collects raw data
into some highly restricted space that is only made available to
these consumers as the end result of a highly controlled ETL
process.
ThoughtWorks Tech Radar
48
PROPRIEDADES DE DATA LAKES
A ingestão dos dados deve ser "push based", ou seja, os dados devem ser "empurrados" para o sistema ao invés de serem ingeridos periodicamente através de processamentos em lote
Os dados ingeridos devem ser armazenados na sua forma mais pura
A solução deve ser escalável horizontalmente, em termos de capacidade de armazenamento e processamento
Não serve ao usuário final, mas sim a usuários técnicos49
OBJETIVOS DO DATA LAKE
Reduzir o custo da ingestão de novos tipos de dados
Diminuir o tempo que leva para que atualizações nos sistemas operacionais cheguem até os sistemas analíticos
Permitir o processamento de volumes de dados bem maiores que os sistemas de DW tradicionais
50
OBJETIVOS DO DATA LAKE
Eliminar gargalos devido à falta de desenvolvedores especializados em ETL ou à excessivo up front design do modelo de dados
Empoderar desenvolvedores a criarem seus próprios pipelines de processamento de dados de uma maneira ágil — quando for preciso e da forma que for preciso — dentro de limites razoáveis
51
52Fonte: http://martinfowler.com/bliki/DataLake.html
53
54
AGILE ANALYTICS
55
O S E M N
Data Scientist Data Engineer Delivery Team
DESCOBRIR ENTREGAREXPERIMENTAR
HIPÓTESE
PROTÓTIPO
PESQUISA
Ideias
Coletar feedack
CONSUMERS
AGILE ANALYTICS
56
57
Conhecimento acionável
Data Science
Data Engineering
Entrega Contínua
Aprendizado Lean
Insights acionáveis=
MÉTODOS TRADICIONAIS E AGILE ANALYTICS
58
PARALELISMO
59
PARALELISMO: DUAS ABORDAGENS
Task Parallel programming
Data parallel programming
60
||-ISMO DE DADOS
Foco em distribuir os dados através de diferentes nós de computação paralela
Cada processador executa a mesma tarefa em diferentes fatias de dados distribuídos
Enfatiza a natureza distribuída dos dados, em oposição ao processamento
61
EXEMPLO
define foo(array d)
if CPU = "a"
lower_limit := 1
upper_limit := round(d.length/2)
else if CPU = "b"
lower_limit := round(d.length/2) + 1
upper_limit := d.length
for i from lower_limit to upper_limit by 1
do_something_with(d[i])
end
62
EXEMPLO
define foo(array d)
if CPU = "a"
lower_limit := 1
upper_limit := round(d.length/2)
else if CPU = "b"
lower_limit := round(d.length/2) + 1
upper_limit := d.length
for i from lower_limit to upper_limit by 1
do_something_with(d[i])
end
63
Acoplamento do código ao número de CPUs da máquina
Você precisa se preocupar em como dividir os dados através dos diferentes nós de computação
Você precisa se preocupar explicitamente em como acumular e consolidar a saída final a partir das
computações em paralelo
COMO UM DESENVOLVEDOR…
Eu quero escrever meu código de tal maneira que ele possa ser executado em paralelo
Eu não quero escrever código baseado em quantas CPUs/máquinas tenho disponíveis no data center
Eu não quero me preocupar em como os dados de entrada devem ser divididos para a execução em paralelo
Eu não quero me preocupar em como a saída final deve ser acumulada e consolidada a partir das unidades rodando em paralelo
64
65
Objetivo Tornar disponível online seu arquivo de 11 milhões de artigos, desde 1851
Tarefa Converter 4TB de imagens TIFF para PDFs
66
Solução Amazon Elastic Compute Cloud (EC2) e Simple Storage System (S3)
Tempo ? Custo ?
67
Solução Amazon Elastic Compute Cloud (EC2) e Simple Storage System (S3)
Em menos de 24h por cerca de $240
HADOOP
68
HADOOP
Framework para armazenamento e computação distribuída para processamento de dados em larga escala
Não impõe restrição aos formatos dos dados sendo processados
Projeto da Apache Software Foundation
Implementado em Java, suportado em todas as plataformas *nix, Windows
Objetivo: computação/armazenamento linearmente escalável usando hardware comum
69
HADOOP
70Fonte: http://hortonworks.com/blog/apache-hadoop-2-is-ga/
HDFS
Sistema de arquivos distribuído Cada arquivo pode estar espalhado por múltiplos nós Clientes podem acessar arquivos de qualquer nó, como se fosse local
Tolerância a falhas e alta disponibilidade
APIs Java/Scala Shell HDFS suporta vários comandos Interface web para navegar pelo sistema de arquivos
71
HDFS: PRINCIPAIS CONCEITOS
Sistema de arquivos hierárquico - similar a Unix/Linux
Metadados de arquivos e diretórios
nome, owner, group owner, permissões, status
Arquivos divididos em blocos, que são distribuídos
72
REPLICAÇÃO DE BLOCOS
73
name:/users/wendell/arquivo.data, copies:2, blocks:{1,3} name:/users/jpaulo/dados.gzip, copies:3, blocks:{2,4,5}
NAMENODE (MASTER)
DATANODES (SLAVES)
1 12
2 24 5
33 4 4
55
PARA QUE CENÁRIOS HDFS NÃO É TÃO BOM ASSIM?
Aplicações de baixa latência
Muitos arquivos pequenos
Acesso aleatório
Updates de dados
Algoritmos iterativos
74
MAP REDUCE
75
MAP SORT / SHUFFLE REDUCE
Fonte: https://mm-tom.s3.amazonaws.com/blog/MapReduce.png
MAP REDUCE: EXEMPLO
76Fonte: https://www.ibm.com/developerworks/community/blogs/bigdata-br/entry/infosphere_biginsights_notas_sobre_hadoop_mapreduce?lang=en
HANDS ON
77
https://goo.gl/quFE6K
78
79
SPARK
PONTOS DE DOR COM MAPREDUCE
Latência
Limitado a fases de Map e Reduce
Não é trivial testar…
Pode resultar em fluxos complexos
Reuso de dados requer escrita no HDFS
80
O QUE É APACHE SPARK?
Cluster Computing Engine
Abstrai o armazenamento e gerenciamento do cluster
Interface de dados unificada
Modelo de programação fácil
API em Scala, Python, Java, R
81
82
ONDE SPARK SE ENCAIXA NO ECOSSISTEMA HADOOP?
83
SPARK E MODOS DE GERENCIAMENTO DO CLUSTER
Standalone
Apache Mesos
Hadoop YARN
84
SPARK E ARMAZENAMENTO
HDFS
HBase
Cassandra
JDBC data sources
* Qualquer fonte de dados que ofereça um InputFormat Hadoop…
85
EXEMPLO DE CONTADOR DE PALAVRAS
val file = sparkContext.textFile("input path")
val counts = file.flatMap(line => line.split(" "))
.map(word => (word, 1))
.reduceByKey((a, b) => a + b)
counts.saveAsTextFile("destination path")
86
COMPARANDO COM MAPREDUCE…
87
RDD: RESILIENT DISTRIBUTED DATASET
Coleção de objetos somente leitura
Particionados através de um conjunto de máquinas
Podem ser reconstruídos caso uma das partições seja perdida
Pode ser reutilizado
Pode ser cacheado em memória
88
RDD: RESILIENT DISTRIBUTED DATASET
Lazily evaluated
Proporciona um reuso de dados eficiente
Várias operações para processamento de dados
89
Conjunto de partições (“splits”) +
Lista de dependências de outros RDDs +
Função para computar uma partição, dadas suas dependências
90
INTERFACE DOS RDDS
Transformações
Retorna um novo RDD com a transformação aplicada
Lazy
Podem ser encadeadas
Ações
Executam o DAG de transformações
91
OPERAÇÕES COM RDDS
RDD: EXEMPLOS DE TRANSFORMAÇÕES
map(f : T ⇒ U) : RDD[T] ⇒ RDD[U]
filter(f : T ⇒ Bool) : RDD[T] ⇒ RDD[T]
flatMap(f : T ⇒ Seq[U]) : RDD[T] ⇒ RDD[U]
union() : (RDD[T],RDD[T]) ⇒ RDD[T]
join() : (RDD[(K, V)],RDD[(K, W)]) ⇒ RDD[(K, (V, W))]
groupByKey() : RDD[(K, V)] ⇒ RDD[(K, Seq[V])]
reduceByKey(f : (V,V) ⇒ V) : RDD[(K, V)] ⇒ RDD[(K, V)]
92
count() : RDD[T] ⇒ Long
collect() : RDD[T] ⇒ Seq[T]
reduce(f : (T,T) ⇒ T) : RDD[T] ⇒ T
lookup(k : K) : RDD[(K, V)] ⇒ Seq[V]
93
RDD: EXEMPLOS DE AÇÕES
TESTANDO…
94
BENCHMARK DE ORDENAÇÃO DE PETABYTES
95
SHUFFLE NÃO É OBRIGATÓRIO
Programas não ficam limitados a fases de map e reduce
Shuffle e sort não são mais obrigatórios entre fases
96
IO REDUZIDO
Não é necessário IO de disco entre fases, devido ao pipeline de operações
Não há IO de rede a não ser que um shuffle seja necessário
97
CACHEAMENTO DE DADOS EM MEMÓRIA
Cache opcional em memória
Engine do DAG pode aplicar otimizações, já que quando uma ação é chamada ele sabe todas as transformações a aplicar
98
HANDS ON
99
IMPALA
100
CLOUDERA IMPALA
101
HANDS ON
102
AVANÇANDO…
103
Zoo keeper
YARN / Mesos
Sqoop
Map Reduce Hive Impala
Hue
Cloudera
TABELA PERIÓDICA DO HADOOP
HDFS
Spark
Zoo keeper
YARN / Mesos
Drill Spark SQL Tez
Oozie SqoopMahout Oryx
Map Reduce Hive Impala
H2O Lens Kylin
File Formats Avro,
Parquet, ORC
HBase
PIG
Cloudera Manager Hue Ambari
Cloudera Hortonworks MapR
TABELA PERIÓDICA DO HADOOP
HDFS
Presto
Falcon GiraphSinga Flume Storm Spark Streaming Samza Kafka Hama
Pivotal
Spark
REEF SamoaData Fu Crunch Book keeper Sentry Aurora Myriad Cascading
Phoenix
NETFLIX ANALYTICS PIPELINE
106
NETFLIX VISION
107
108
E MAIS UM EXEMPLO…
109
CONCLUSÃO
110
111
PENSE GRANDECOMECE PEQUENO
