Com um conjunto cada vez maior de tecnologias para processar grandes volumes de dados, as organizações muitas vezes lutam para entender como construir aplicações escaláveis para suprir esses casos de uso.
Neste webinar, vamos ajuda-lo a entender como simplificar o processamento desses dados como um pipeline que abrange vários estágios, e mostrar-lhe como escolher a tecnologia certa para cada etapa com base em critérios como, estrutura de dados, padrões de design e melhores práticas.
Objetivos de aprendizado:
- Compreender os principais serviços da AWS para Big Data, incluindo S3, Amazon EMR, Kinesis e Redshift.
- Aprender padrões de arquitetura para Big Data
- Ficar por dentro das melhores práticas para a construção de aplicações de Big Data na AWS
2. Agenda
Desafios de big data
Como simplificar o processamento de big data
Quais tecnologias você deve usar?
• Por quê?
• Como?
Arquitetura de referência
Padrões de design
4. Evolução do big data
Lote
Relatório
Tempo real
Alertas
Predição
Previsão
5. Grande número de ferramentas
Amazon
Glacier
S3 DynamoDB
RDS
EMR
Amazon
Redshift
Data Pipeline
Amazon
Kinesis CloudSearch
Aplicativo
habilitado para
Kinesis
Lambda ML
SQS
ElastiCache
DynamoDB
Streams
6. Há uma arquitetura de referência?
Quais ferramentas eu devo usar?
Como? Por quê?
7. Princípios de arquitetura
“Barramento de dados” desconectado
• Dados → Armazenamento → Processamento → Respostas
Use a ferramenta certa para a tarefa
• Estrutura de dados, latência, taxa de transferência, padrões de
acesso
Use ideias de arquitetura Lambda
• Registro imutável (somente anexação), camada de
lote/velocidade/veiculação
Utilize os serviços gerenciados da AWS
• Sem/pouca administração
Big data ≠ grande custo
8. Simplifique o processamento de big data
incluir/
coletar
armazenar processar/
analisar
consumir/
visualizar
Tempo até a resposta (latência)
Taxa de transferência
Custo
10. Tipos de dados
Transacional
• Leituras e gravações no banco de
dados (OLTP)
• Cache
Pesquisar
• Registros
• Streams
Arquivo
• Arquivos de log (/var/log)
• Estruturas e coletores de registros
Stream
• Registros de log
• Sensores e dados de IoT
Banco de
dados
Armazena-
mento
de arquivos
Armazena-
mento
de streams
A
iOS Android
Aplicações
Web
Logstash
RegistroIoTAplicações
Dados
transacionais
Dados de
arquivos
Dados de
fluxo
Aplicações
móveis
Dados de
pesquisa
Pesquisar
Coletar Armazenar
RegistroIoT
13. Opções de armazenamento de fluxo
Serviços gerenciados da AWS
• Amazon Kinesis → fluxos
• DynamoDB Streams → tabela + fluxos
• Amazon SQS → fila
• Amazon SNS → pub/ass
Não gerenciado
• Apache Kafka → fluxo
14. Por que usar o armazenamento de streams?
Desconecte produtores
e consumidores
Buffer persistente
Colete vários streams
Preserve os pedidos dos clientes
Streaming do MapReduce
Consumo paralelo
4 4 3 3 2 2 1 1
4 3 2 1
4 3 2 1
4 3 2 1
4 3 2 1
4 4 3 3 2 2 1 1
Fragmento 1 / Partição 1
Fragmento 2 / Partição 2
Consumidor
1 Contagem
de chaves
vermelhas = 4
Contagem
de chaves
violeta = 4
Consumidor
2 Contagem
de chaves
azuis = 4
Contagem
de chaves
verdes = 4
DynamoDB Stream Kinesis Stream Tópico do Kafka
15. E quanto a filas e pub/sub?
• Desconecte produtores
e consumidores/assinantes
• Buffer persistente
• Colete vários fluxos
• Sem consumo paralelo
para o Amazon SQS
• O Amazon SNS pode
rotear para várias filas
ou funções ʎ
• Sem streaming do MapReduce
Consumidores
Produtores
Produtores
Amazon SNS
Amazon SQS
fila
tópico
função
ʎ
AWS Lambda
Amazon SQS
fila
Assinante
16. Qual armazenamento de fluxo devo usar?
Amazon
Kinesis
DynamoDB
Streams
Amazon SQS
Amazon SNS
Kafka
Gerenciado Sim Sim Sim Não
Pedidos Sim Sim Não Sim
Entrega pelo menos
uma vez
exatamente
uma vez
pelo menos
uma vez
pelo menos
uma vez
Duração 7 dias 24 horas 14 dias Configurável
Replicação 3 AZ 3 AZ 3 AZ Configurável
Taxa de transferência Sem limite Sem limite Sem limite nº aprox. nós
Clientes paralelos Sim Sim Não (SQS) Sim
MapReduce Sim Sim Não Sim
Tamanho do registro 1 MB 400 KB 256 KB Configurável
Custo Baixo Mais alto
(custo da tabela)
Baixo-médio Baixo
(+ admin.)
18. Por que o Amazon S3 é bom para big data?
• Suportado de maneira nativa por estruturas de big data (Spark, Hive, Presto etc.)
• Sem necessidade de executar clusters de computação para armazenamento
(diferente de HDFS)
• Pode executar clusters Hadoop temporários e instâncias do Amazon EC2 Spot
• Vários clusters diferentes (Spark, Hive, Presto) podem usar os mesmos dados
• Número ilimitado de objetos
• Largura de banda muito alta – sem limite agregado de taxa de transferência
• Altamente disponível – pode tolerar falhas de AZ
• Desenvolvido para ter uma durabilidade de 99,999999999%
• Armazenamento em níveis (Standard-IA, Amazon Glacier) por meio da política de
ciclo de vida
• Seguro – SSL, criptografia no lado do cliente/servidor em repouso
• Baixo custo
19. E quanto ao HDFS e ao Amazon Glacier?
• Use o HDFS para dados acessados
com muita frequência (quentes)
• Use o Amazon S3 Standard para
dados acessados com muita
frequência
• Use o Amazon S3 Standard-IA para
dados acessados com pouca
frequência
• Use o Amazon Glacier para arquivar
dados frios
20. Banco de
dados +
Pesquisa
Nível
A
iOS Android
Aplicações Web
Logstash
Amazon
RDS
Amazon
DynamoDB
Amazon
ES
Amazon
S3
Apache
Kafka
Amazon
Glacier
Amazon
Kinesis
Amazon
DynamoDB
Amazon
ElastiCache
PesquisaSQLNoSQLCacheArmazenamentodefluxoArmazenamentode
arquivos
Dados
transacionais
Dados de
arquivos
Dados de
fluxo
Aplicações
móveis
Dados de
pesquisa
Coletar Armazenar
21. Banco de dados + Antipadrão do nível de pesquisa
Banco de dados + Nível de pesquisa
22. Melhor prática - Use a ferramenta certa para a tarefa
Camada de dados
Search
Amazon
Elasticsearch
Service
Amazon
CloudSearch
Cache
Redis
Memcached
SQL
Amazon Aurora
MySQL
PostgreSQL
Oracle
SQL Server
NoSQL
Cassandra
Amazon
DynamoDB
HBase
MongoDB
Banco de dados + Search
24. Qual armazenamento de dados devo usar?
Estrutura de dados → Esquema fixo, JSON, chave-valor
Padrões de acesso → Armazene os dados no formato em
que você os acessará
Características de acesso/dados → quentes, mornos, frios
Custo → Custo certo
25. Estrutura dos dados e padrões de acesso
Padrões de acesso O que usar?
Put/Get (chave, valor) Cache, NoSQL
Relacionamentos simples → 1:N, M:N NoSQL
Joins de várias tabelas, transações, SQL SQL
Facetamento/pesquisa Search
Estrutura de dados O que usar?
Esquema fixo SQL, NoSQL
Sem esquema (JSON) NoSQL, Search
(Chave, valor) Cache, NoSQL
27. Quentes Mornos Frios
Volume MB–GB GB–TB PB
Tamanho do
item B–KB KB–MB KB–TB
Latência ms ms, s min, h
Durabilidade Baixa–alta Alta Muito alta
Taxa de
solicitações Muito alta Alta Baixa
Custo/GB $$-$ $-¢¢ ¢
Dados quentes Dados mornos Dados frios
Características dos dados/do acesso: Quentes, mornos, frios
28. Cache
SQL
Taxa de solicitações
Alta Baixa
Custo/GB
Alta Baixa
Latência
Baixo Alto
Volume de dados
Baixa Alta
Glacier
Estrutura
NoSQL
Dados quentes Dados mornos Dados frios
Baixo
Alto
Pesquisa
29. Amazon
ElastiCache
Amazon
DynamoDB
Amazon
Aurora
Amazon
Elasticsearch
Amazon
EMR (HDFS)
Amazon S3 Amazon Glacier
Latência média ms ms ms, s ms, s s, min, h ms, s, min
(tamanho
aprox.)
h
Volume de
dados
GB GB–TBs
(sem limite)
GB–TB
(No máx.
64 TB)
GB–TB GB–PB
(nº aprox.
nós)
MB–PB
(sem limite)
GB–PB
(sem limite)
Tamanho do
item
B-KB KB
(No máx.
400 KB)
KB
(64 KB)
KB
(No máx.
1 MB)
MB-GB KB-GB
(No máx.
5 TB)
GB
(No máx.
40 TB)
Taxa de
solicitações
Alta -
Muito alta
Muito alta
(sem limite)
Alta Alta Baixa –
Muito alta
Baixa –
Muito alta
(sem limite)
Muito baixa
Custo do
armazenamento
GB/mês
$$ ¢¢ ¢¢ ¢¢ ¢ ¢ ¢/10
Durabilidade Baixa -
Moderada
Muito alta Muito alta Alta Alta Muito alta Muito alta
Dados quentes Dados mornos Dados frios
Dados quentes Dados mornos Dados frios
Qual armazenamento de dados devo usar?
30. Design baseado em custo
Exemplo: devo usar o Amazon S3 ou o Amazon DynamoDB?
“No momento, estou desenvolvendo um projeto que
aumentará muito o uso que minha equipe faz do Amazon
S3. Espero que você possa responder a algumas
perguntas. A iteração atual do design chama muitos
arquivos pequenos, talvez até um bilhão durante o pico.
O tamanho total ficaria na ordem de 1,5 TB por mês…”
Taxa de solicitações
(gravações/s)
Tamanho do
objeto (Bytes)
Tamanho total
(GB/mês)
Objetos por
mês
300 2048 1483 777,600,000
31. Design baseado em custo
Exemplo: devo usar o Amazon S3 ou o Amazon DynamoDB?
https://calculator.s3.amazonaws.com/index.html
Calculadora
mensal
simples
36. Análise interativa
É necessário um grande volume de dados (quentes/frios)
Leva segundos para receber as respostas
Exemplo: painéis de autoatendimento
37. Análise em Batch
É necessário um grande volume de dados (quentes/frios)
Leva minutos ou horas para receber as respostas
Exemplo: geração de relatórios diários, semanais ou
mensais
38. Análise em tempo real
Use uma pequena quantidade de dados quentes para fazer
perguntas
Leva pouco tempo (milissegundos ou segundos) para receber
a resposta
Tempo real (evento)
• Resposta em tempo real a eventos em fluxos de dados
• Exemplo: alertas de faturamento/fraude
Quase em tempo real (microlote)
• Operações quase em tempo real em pequenos lotes de eventos
em fluxos de dados
• Exemplo: métricas de 1 minuto
39. Previsões por meio de Machine Learning
Com o ML, os computadores podem aprender sem ser
programados de maneira explícita
Algoritmos de aprendizagem automática:
Aprendizagem supervisionada ← você “ensina” o programa
- Classificação ← Essa transação é uma fraude? (sim/não)
- Regressão ← Valor da vida útil do cliente?
Aprendizagem sem supervisão ← deixe-o aprender sozinho
- Clustering ← Segmentação de mercado
40. Ferramentas e estruturas de análise
Machine Learning
• Mahout, Spark ML, Amazon ML
Análise interativa
• Amazon Redshift, Presto, Impala, Spark
Processamento em batch
• MapReduce, Hive, Pig, Spark
Processamento de streams
• Microlote: Streaming do Spark, KCL, Hive, Pig
• Tempo real: Storm, AWS Lambda, KCL
Amazon
Redshift
Impala
Pig
Amazon Machine
Learning
Amazon
Kinesis
AWS
Lambda
AmazonElasticMapReduce
ProcessamentodefluxosLoteInterativoML
Analisar
Streaming
41. Qual tecnologia de processamento de fluxos devo usar?
Streaming do
Spark
Apache Storm Biblioteca cliente do
Amazon Kinesis
AWS Lambda Amazon EMR
(Hive, Pig)
Escala/taxa de
transferência
Nº aprox. nós Nº aprox. nós Nº aprox. nós Automático Nº aprox. nós
Lote ou tempo
real
Tempo real Tempo real Tempo real Tempo real Lote
Capacidade de
gerenciamento
Sim (Amazon
EMR)
Faça você
mesmo
Amazon EC2 + Auto
Scaling
Gerenciado
pela AWS
Sim (Amazon EMR)
Tolerância a
falhas
AZ único Configurável Multi-AZ Multi-AZ AZ único
Linguagens de
programação
Java, Python,
Scala
Qualquer
linguagem por
meio do Thrift
Java por meio de
MultiLangDaemon
(.Net, Python, Ruby,
Node.js)
Node.js, Java,
Python
Hive, Pig, linguagens
de streaming
Alta
42. Qual tecnologia de processamento de dados devo usar?
Amazon
Redshift
Impala Presto Spark Hive
Latência da
consulta
Baixa Baixa Baixa Baixa Média (Tez) – Alta
(MapReduce)
Durabilidade Alta Alta Alta Alta Alta
Volume de
dados
No máx.
1,6 PB
Nº aprox. nós Nº aprox. nós Nº aprox. nós Nº aprox. nós
Gerenciado Sim Sim (EMR) Sim (EMR) Sim (EMR) Sim (EMR)
Armazena-
mento
Nativo HDFS/S3A* HDFS/S3 HDFS/S3 HDFS/S3
Compatibilida
de com SQL
Alta Média Alta Baixa
(SparkSQL)
Média (HQL)
AltaMédia
43. E quanto à ETL?
Armazenar Analisar
https://aws.amazon.com/big-data/partner-solutions/
ETL
45. Coletar Armazenar Analisar Consumir
A
iOS Android
Aplicações Web
Logstash
Amazon
RDS
Amazon
DynamoDB
Amazon
ES
Amazon
S3
Apache
Kafka
Amazon
Glacier
Amazon
Kinesis
Amazon
DynamoDB
Amazon
Redshift
Impala
Pig
Amazon ML
Amazon
Kinesis
AWS
Lambda
AmazonElasticMapReduce
Amazon
ElastiCache
PesquisaSQLNoSQLCache
ProcessamentodefluxosLoteInterativo
Registro
Armazenamentodefluxo
IoTAplicações
Armazenamentode
arquivos
Análiseevisualização
Quente
s
Frios
Morno
s
Quente
s
Baixa
Quentes
ML
Rápido
Rápido
Dados
transacionais
Dados de
arquivos
Dados de
fluxo
Notebooks
Previsões
Aplicativos e
APIs
Aplicações
móveis
IDE
Dados de
pesquisa
ETL
Streaming
Amazon
QuickSight
48. Coletar Armazenar Analisar Consumir
A
iOS Android
Aplicações Web
Logstash
Amazon
RDS
Amazon
DynamoDB
Amazon
ES
Amazon
S3
Apache
Kafka
Amazon
Glacier
Amazon
Kinesis
Amazon
DynamoDB
Amazon
Redshift
Impala
Pig
Amazon ML
Amazon
Kinesis
AWS
Lambda
AmazonElasticMapReduce
Amazon
ElastiCache
PesquisaSQLNoSQLCache
ProcessamentodefluxosLoteInterativo
Registro
Armazenamentodefluxo
IoTAplicações
Armazenamentode
arquivos
Análiseevisualização
Quente
s
Frios
Mornos
Quente
s
Baix
a
Quente
s
ML
Rápido
Rápido
Dados
transacionais
Dados de
arquivos
Dados de
fluxo
Notebooks
Previsões
Aplicativos e
APIs
Aplicações
móveis
IDE
Dados de
pesquisa
ETL
Arquitetura de referência
Streaming
Amazon
QuickSight
50. "Barramento de dados" desconectado em várias etapas
Várias etapas
Armazenamento desconectado do processamento
Armazenar Processar Armazenar Processar
processar
armazenar
51. Vários aplicativos (ou conectores) de
processamento podem ler de vários
armazenamentos de dados ou gravar neles
Amazon
Kinesis
AWS
Lambda
Amazon
DynamoDB
Amazon
Kinesis S3
Connector
processar
armazenar
Amazon S3
52. Estruturas de processamento (KCL, Storm, Hive,
Spark etc.) poderiam ler de vários armazenamentos
de dados
Amazon
Kinesis
AWS
Lambda
Amazon
S3
Amazon
DynamoDB
Hive SparkStorm
Amazon
Kinesis S3
Connector
processar
armazenar
53. Streaming do Spark,
Apache Storm
AWS Lambda
KCL
Amazon
Redshift Spark
Impala
Presto
Hive
Amazon
Redshift
Hive
Spark
Presto
Impala
Amazon Kinesis
Apache Kafka
Amazon
DynamoDB
Amazon S3dados
Quentes Frios
Temperatura dos dados
Latênciado
processamento
Baixa
Alta Respostas
Amazon EMR
(HDFS)
Hive
Nativo
KCL
AWS Lambda
Temperatura dos dados x latência do processamento
Batch
54. Análise em tempo real
Produtor
Apache
Kafka
KCL
AWS Lambda
Spark
Streaming
Apache
Storm
Amazon
SNS
Amazon
ML
Notificações
Amazon
ElastiCache
(Redis)
Amazon
DynamoDB
Amazon
RDS
Amazon
ES
Alerta
Estado do
aplicativo
Previsão em
tempo real
KPI
processar
armazenar
DynamoDB
Streams
Amazon
Kinesis
55. Camada em lote
Amazon
Kinesis
dados
processar
armazenar
Amazon
Kinesis S3
Connector
Amazon S3 A
p
l
i
c
a
ç
õ
e
s
Amazon
Redshift
Amazon EMR
Presto
Hive
Pig
Spark resposta
Camada de velocidade
resposta
Camada
de
veiculação
Amazon
ElastiCache
Amazon
DynamoDB
Amazon
RDS
Amazon
ES
resposta
Amazon ML
KCL
AWS Lambda
Streaming do Spark
Storm
Arquitetura
Lambda
56. Resumo
Crie um “barramento de dados” desconectado
• Dados → Armazenamento ↔ Processamento → Respostas
Use a ferramenta certa para a tarefa
• Latência, taxa de transferência, padrões de acesso
Use ideias de arquitetura do Lambda
• Registro imutável (somente anexação), camada de
lote/velocidade/veiculação
Utilize os serviços gerenciados da AWS
• Sem/pouca administração
Crie um design baseado em custo
• Big data ≠ grande custo
Bom dia! Eu sou João Paulo (JP) Santana, Arquiteto de Soluções da AWS
Obrigado pela pela presença de todos e por tomar uma hora da sua agenda para falarmos sobre pardrões de arquitetura para big data na AWS.
Como simplificar o processamento de Big Data através do pipeline de fases de Ingestão, Armazenamento, processamento e visualização.
Em cada um dos passos vamos ver como é importante utilizarmos a ferramenta correta para cada tipo de trabalho.
Vamos ver por que cada ferramenta faz mais sentido dependendo do caso de uso.
Volume: Hoje clientes demandam a construção de aplicações de big data para sustentar um volume de centenas ou milhares de terabytes por dia, isso está ficando normal hoje em dia.
Velocidade: Agora está se tornando normal, milhões de requisições por segundo ao invés de milhares ou centenas.
Variedade: Hoje não precisamos coletar somente dados transacionais, estruturados, existe um valor enorme e dados não estruturados e semi-estruturados os quais as empresas precisam analizar para minerar o ouro contido neles.
Na evolução estamos vendo que workloads estão movendo-se de padrões batch para análises em tempo real, ou próximas de tempo real (near real time)
E também análises preditivas.
Por exemplo, hoje você espera que um provedor de telefonia celular não te envie somente a fatura no final do mes, mas que também possa, analisando seu comportamento de uso, enviar alertas de uso por subscrição ou te proponha planos mais adequados ao seu perfil.
A previsão de ”o que vem por aí” também é mto importante. Prever se um tipo de transação é possívelmente de um valor muito alto, ou se é uma fraude potencial.
Isto está se tornando critico em termos de prover ao cliente um nível de serviço diferencial
A boa notícia (ou a má?) é que, para implementar tudo isso existe hoje uma infinidade de ferramentas.
A esquerda vocês podem ver a infinidade de ferramentas do ecosistema opensource apache (haddoop, hive, pig)
Hoje, se vc for a uma conferencia de big data, Spark é a resposta padrão para qualquer pergunta.
Para motor de busca, Elasticsearch é a resposta padrão para tudo.
O esquilo à esquerda é o Apache Flink, que agora parece estar ameaçando a dominância do Spark.
Do lado direito temos Serviços Gerenciados da AWS muito populares para Big Data (EMR, S3, Kinesis).
Um arquiteto hoje precisa se perguntar, como construo minha arquitetura na nuvem AWS de uma maneira que eu retire dos meus ombros aquilo que não é diferencial para o core business da minha empresa e, desta forma, agrego valor à minha solução de Big Data?
Existe uma arquitetura ”one size fits all”?
Quais ferramentas utilizar?
Vamos tentar a ajuda-los a descobrir a resposta…
Alguns principios de arquiteturas que vêm desafiando o tempo sendo sempre relevantes:
Desacoplar camadas do pipeline…
Usar a ferramenta correta de acordo com os critérios necessários para o caso de uso.
Critérios como: Padrões de acesso, estrutuda do dado, temperatura do dado, etc…
A Arquitetura Lambda tem se tornado um padrão consolidado no mundo de big data.
Tratar casos de processamento em realtime com processamento em batch no mesmo sistema de big data, para trazer ganhos de custo.
Usar serviços gerenciados AWS. Minha habilidade de manter os name e secondary nodes, manter o yarn… faz minha empresa ganhar mais dinheiro?
Big data não tem q ter grande custo. Se o custo é grande, é indicio de que algo foi arquitetado de forma errada.
O pipeline de big data é muito frequentemente similar à este:
No estágio de ingestão ou coleta temos Aplicação, frameworks de logging (fluentd), ou mais recentemente IoT…
Variedade de dados é grande: Dados trasacionais, dados em arquivo, dados não estruturados, streams de dados…
Para armazenar todos esses tipos variados de dados…
… Precisamos nos preocupar com o armazenamento desses dados em stream
Temos opções que podemos classificar em serviços gerenciados e não gerenciados.
Temos aí os serviços gerenciados da AWS para processamentos de dados desse tipo.
E no mundo opensource, o Kafka é muito popular também…
Voltamos áquele ponto: Configurar, monitorar e gerenciar um cluster de Kafka faz minha empresa ganhar mais dinheiro? é diferencial para meu negócio?
Ou posso passar o trabalho não diferencial para a AWS e me focar no meu core business?
Storage de strems no ajuda a desacoplar os produtores de dados dos consumidores
Provê um buffer persistente que o produtor dos dados pode usar, ao invés de ele mesmo armazenar os dados
Coletar vários streams em paralelo.
O importante é que dessa forma conseguimos preservar a autoria do dado e a ordem do dado
Se o dado for escrito com uma chave consistente com o stream ferramentas como o Kinesis e o Kafka irão preservar a sequencia do stream de dados
Isso permitira por exemplo, num caso de um carrinho de compras, enviado os clickstreams, que o consumidor dos dados pudesse dizer quando o cliente abandonou o carrinho, e até fazer predições a esse respeito. Isso pq a sequencia dos dados entrando bate com a sequencia das ações do cliente no website.
Permitiria por exemplo também, calcular máximo e mínimo de uma medição de temperatura para um motor, num caso de uso de IoT, etc
Consumo paralelo: Frequentemente CTO’s querem que seus distintos times consumam dados do mesmo repositório e façam processamentos ou criem aplicações mantendo-se na mesma origem. Assim um time não depende do outro e podem trabalhar em paralelo
Filas e tópicos podem ser usados para desacoplar camadas, criar bufferes persistentes e coletar paralelamente de vários fluxos também
Porém eles não tem a funcionalidade de consumo paralelo consumo e stream de mapreduce
Agora o SQS pode preservar autoria e ordem…
No entanto se um cliente precisa dessas funcionalidades a melhor opção é usar as ferramentas mais especializadas para processamento de streams, que descrivi anteriormente
Aqui fiz uma matriz de comparação entre os atributos necessários para esse caso de uso de armazenamento de streams e as diferentes ferramentas.
Os serviços gerenciados da AWS e o Kafka que é não gerenciado.
Essa tabela pode ajudar na tomada de decisao dependendo do caso de uso.
De maneira geral, Kinesis tem o melhor custo beneficio nessa área.
E no caso de armazenamento de arquivos?
O S3 é o lugar ideal para armazenar dados de Big Data.
Suportada de maneira nativa um grande número de formatos
Desacopla storage de processamento, então vc não precisa persistir os dados no cluster e consequentemente pode ter um cluster efemero
Que vc liga e desliga conforme a utilização para processamento
Datalake
Segurança
Baixo custo
HDFS está sendo usado menos e menos
Pode ser usado como um estagio intermediário para duas fazes de processamento Hadoop
Mas até mesmo para isso, S3 tem uma performance bem alta
Pode ser útil no caso de o cliente querer utilizar um cluster steady state com HBASE… Mas esse caso de uso poderia ser atendido perfeitamente pelo Amazon DynamoDB
S3 também tem multiplas classes de storage para adequar seu dado à sua temperatura
Vamos para bancos de dados…
Usar um mesmo banco de dados relacional para todo tipo de caso geralmente não é uma boa prática…
é necessário utilizar a ferramenta adequada para o trabalho.
Enão se isso é um anti-patern, qual é a boa prática?
A boa prática é pensar o DB em termos de Armazenamento e Search incluindo categorias de dados que se encaixem em Cache, NoSQL, SQL e Search
Como realmente então construir um sistema pensando banco de dados dessa maneira?
Para construir esses sistemas podemos usar serviços gerenciados AWS que se encaixem em cada uma dessas categorias
Cache: Elasticache (Redis e Mencached)
Search: CloudSearch ou ElasticSearch gerenciado
NoSQL: DynamoDB
SQL: RDS
BASE: NoSQL
Basic Availability, Soft-state, Eventual consistency
ACID: SQL
Atomic, Consistent, Isolated, Durable
Para fazer a integração no caso de um sistema que utilize todos esses serviços de consistencia eventual, e deixalos em sincronia
Podemos utilizar o Kinesis KCL ou mesmo funções do AWS Lambda
Qual tipo de banco de dados usar?
Depende da natureza do dado (estruturado, semi, não estruturado)
Como o dado será acessado
Temperatura do dado
E relação entre custo e beneficio
Aqui uma outra tabela que ajuda na tomada de decisão:
Outro fator importante é a temperatuda do dado…
Tipicamente dado quente inclui pequenos datasets que se movem muito rapidamente, talvez centenas ou milhares de requests por segundo, onde a sequencia de acesso é muito rápida.
Ao contrário, dados mais mornos ou frios possuem tamanhos de datasets maiores e a sequencia de acesso é mais baixa.
Normalmente dados quentes são tratados em RAM ou SSD, onde há menor latencia enquanto dados menos quentes são tratados em spinning disks.
Isso também impacta no custo que tende a ser mais alto quanto maior é a temperatura do dado.
Aqui temos um mapa mental de como a temperatura do dado reflete na ferramenta utilizada e também mostra a relação entre custo, latencia e velocidade e volume dos dados
Aqui outra matriz que ajuda na tomada de decisão de que ferramenta utilziar dependendo da temperatura do dado e o impacto em custo e latencia apropriada para cada tipo de workload
Aqui um exercício que mostra como desenhar a arquitetura tendo em mente o custo é extremamente importante.
Neste caso o DynamoDB custaria: 644 dolares
Enquanto o S3 custaria 3932 dolares
Mas o S3 não é extremamente barato?
Sim mas o S3 é desenhado para objetos de tamanho maior e não para essa quantidade e norme de requests/segundo
Enquanto o DynamoDB é desenhado exatamente para sustentar esse tipo de padrão de acesso..
Ja nesse outros cenário onde temos objetos de tamanho maior, de 32 Kb:
O S3 custaria: 4588 dolares
Enquanto o DynamoDB custaria: 10131 dolares
Esse é um exemplo de o quao importante é usar a ferramenta certa para o trabalho e de como isso pode impactar nos custos.
Vamos falar sobre Processamento e análise…
O aspecto de análise podemos categorizar em 4 grupos:
Streams, Batch, Interativo e Machine Learning
Em termos de análise interativa, onde temos um analista em frente de um dashboard explorando dados a resposta é esperada para retornar em segundos.
No caso de Batch, tipicamente estamos tratando com um volume bem grande de dados onde trabalhamos com jobs que levam minutos ou horas para gerar a resposta.
Pequenas quantidades de dados que precisam ser analizadas em segundos ou milisegundos para, por exemplo, alertar rapidamente contrar fraudes.
Utilizando Machine Learning. Suporvisionado, onde você ensina o programa usando alguns datasets exemplo e então faz uma pargunta. Como ”essa transação é fraudulenta?” e a resposta é binária (sim ou não)
Ou, ”por quanto posso vender essa casa?”… ela tem 2 banheiros, está nesse CEP…
Machine learning não supervisionado onde o programa aprende sozinho.
Na amazon.com por exemplo, temos uma variedade de roupas ou sepatos e precisamos categorizar através de algoritmos esse produtos para podermos implementar facetamento…
Em termos de ferramental, esses são os mais populares:
No Amazon EMR vc pode rodar praticamente todas essas ferramentas do Ecosistema Hadoop descritas acima.
Outra matriz para nos ajudar a tomar a decisão de que ferramenta é mais apropriada para cada tipo de caso
Vale lembrar que, em termos de escalabilidade agora o Amazon EMR suporta auto-scaling
Como são muitas as ferramentas essa matriz está em duas partes,
Amazon Redshif terá baixissima latencia se vc está trabalhando com um cluster de dataware house de processamento paralelo massivo.
Impala, recentemente foi adicionado ao EMR. Presto que é utilizado pelo Netflix para seu sistema de cobrança… Estão super felizes com ele.
Vejam que esses sistemas são suportados no Amazon EMR
Nós vamos disponibilizar essa apresentação depois no Youtube e Slideshare para que vocês tenham esse material.
Passando agora para ETL, o Datapipeline é uma ferramenta que pode te ajudar na movimentação de dados entre serviços AWS
Temos também um grande ecosistema de parceiros…
Visualização e consumo dos dados
Dependendo do chapeu que vc tem na empresa, algumas dessas ferramentas podem ser mais interessantes…
Agora temos o Amazon QuickSight disponível na console AWS, como nossa própria ferramenta de visualização.
Utiliza um motor de tratamento dos dados em memória chamado SPICE, que provê baixíssima latencia.
O Kibana também pode ser usado para projetar belos graficos a partir do ElasticSearch gerenciado da AWS.
E temos também vários produtos de parceiros disponíveis no nosso aws marketplace
Notebooks também estão se tornando muito populares, vc pode usar Ipython e Zepelin com Notebooks direto do Amazon EMR
podem fazer uma busca por esse tema no Blog de Big Data da AWS para mais informações de como implementar a solução.
Essa é a arquitetura de referencia que engloba tudo em uma única página para categorizar todas as opções que discutimos.
Construir um pipeline de big data em barramento, com multiplos estágios, como esse no slide, ”armazena, processa, armazena, processa”
Faz muito sentido em vários casos pois os subsistemas podem rodar na sua propria velocidade, podem ser desacoplados tornando o pipeline muito mais eficiente
Essa estratégia em barramento também nos permite criar diferentes camadas de processamento, com uma origem comum mas possívelmente destinos diferentes dependendo do tipo de dado.
Como mostramos antes essa estratégia mtas vezes traz ganhos de custo e performance.
Essa estratégia também permite ter multiplos frameworks de processamento
Fazendo por exemplo processamento de joins de diferente sources, como o Hive nesse caso fazendo joins de dados que estão no DynamoDB com dados provenientes do S3
Esse slide também é mto interessante
Na horizontal: Temperatura
Dado quente à frio, categorizando por exemplo Kinesis, Kafka e DynamoDBcomo armazenamento de dados quentes enquanto EMR e S3 para dados mais frios
Na vertical: Latencia
Categorizando a ferramenta apropriada para cada tipo de cenário (tempo real, batch, interativo) e o tempo de resposta apropriado para cada um.
Agora dando um deep dive nos cenários mais específicos:
Basando-nos nas arquiteturas de referencia AWS
O produtor do dado tipicamente envia o dado para o Amazon Kinesis, Kafka ou DynamoDB Streams. Para a maioria dos casos eu escolheria o Kinesis. A não ser que tenha alguma razão especifica para não…
Para processar o dado podemos usa também serviços gerenciados como o AWS Lambda ou EMR rodando spark streaming ou Storm ou mesmo o KCL
Se vc precisar de alerta, pode usar o SNS, nosso serviço gerenciado de notificações
Para o armazenamento e visualização podemos usar algum desses serviços gerenciados também
Para tomada de ação preditiva em real time usar o Amazon ML
A Famosa Arquitetura Lambda
Aqui eu tenho o Kinesis e duas camadas distintas para processar dados em Stream ou em Batch.
Explicar as camadas…
É extremamente critico ter uma camada de serviço que sirva o dado na forma e padrão necessário pela aplicação que vai consumir o dado
Resumindo
Quando construimos um pipeline de big data, desacoplar as camadas é importante
Usar a ferramenta correta para cada tipo de trabalho é crítico. Usar os padrões q eu demonstrei de latencia, natureza do dado, taxa de transferencia, vai ajudar na tomada de decisão
Usar a arquitetura Lambda usando uma camada para batch e outra para análise em tempo real no mesmo sistema, alimentando uma camada de apresentação comum
Ser consciente com relação a custo quando se desenha a arquitetura também é importantíssimo
Muito obrigado pela presença de todos e espero que essa sessão tenha sido útil para vocês.