Amazon emr cluster hadoop pronto para usar na nuvem aws
-
Upload
amazon-web-services-latin-america -
Category
Software
-
view
251 -
download
5
Transcript of Amazon emr cluster hadoop pronto para usar na nuvem aws
São Paulo
Amazon Elastic MapReduce
melhores práticasFelipe Garcia, Amazon Web Services
28 de Maio, 2015 | São Paulo, SP
Computação Armazenamento
Infraestrutura Global AWS
Banco de Dados
Serviços de Aplicativos
Implantação e Administração
Rede
Análise
Amazon Elastic MapReduceGerenciado, cluster elástico de Hadoop (1.x & 2.x)
Integra com Amazon S3, Amazon DynamoDB, Amazon
Kinesis e Amazon Redshift
Instale Storm, Spark, Presto, Hive, Pig, Impala, &
ferramentas de usuário final automaticamente
Suporte nativo para instâncias Spot
Banco de dados HBase NoSQL integrado
Amazon EMR
Amazon EMR
Amazon EMR é como qualquer outro Hadoop
Baseado na versão open source do Apache
Hadoop, ou 3 versões de MapR
Acesse todas as configurações do Hadoop
Acesso root as instâncias
Instale qualquer software no cluster
Versão comum de ferramentas (Hive, Pig, Impala)
Configuração
Configurando Hadoop
--bootstrap-actions Path=s3://elasticmapreduce/bootstrap-actions/configure-hadoop
--keyword-config-file – mescla valores com novo arquivo de config.
--keyword-key-value – sobrescreve pares chave-valor específicos
Nome do Arquivo de
Configuração
Palavra Chave do
Arquivo de
Configuração (keyword)
Atalho Para o Nome do
Arquivo
Atalho Para Par Chave-
Valor
core-site.xml core C c
hdfs-site.xml hdfs H h
mapred-site.xml mapred M m
yarn-site.xml yarn Y y
Configurando Hadoop
Configurando o número de mappers por task tracker--bootstrap-actions Name=ConfigurarMappers,Path=s3://elasticmapreduce/bootstrap-actions/configure-hadoop,Args=[-M,s3://myawsbucket/config.xml,-m,mapred.tasktracker.map.tasks.maximum=2]
Útil para Tasks de Mapper com baixo consumo de memória
Mais trabalho pode ser feito pela instância
Configurando Hadoop
Configurando o tamanho do bloco HDFS para
1MB--bootstrap-actions Path=s3://elasticmapreduce/bootstrap-actions/configure-hadoop,Args=[-m,dfs.block.size=1048576]
Útil quando pequenos arquivos são utilizados no
HDFS
Configurando Hadoop 1
Reutilizar os mappers--bootstrap-actions Path=s3://elasticmapreduce/bootstrap-actions/configure-hadoop,Args=[-m,mapred.job.reuse.jvm.num.tasks=N]-1 = Sempre
Tempo de início de um Mapper é de ~ 2-20 seconds
Útil para Tasks com um grande número de Mappers
Mappers devem ser “limpos” depois da execução (relevantepara Java)
Configurando a JVMConfigura o heap size, Java opts, e sobrescrever o hadoop-user-env.sh
Hadoop 1namenode, datanode, jobtracker, tasktracker, ou client
Hadoop 2namenode, datanode, resourcemanager, nodemanager, ou client
--bootstrap-actions Path=s3://elasticmapreduce/bootstrap-actions/configure-daemons,Args=[–{namenode}-heap-size=2048,--{namenode}-opts=-XX:GCTimeRatio=19]
Amazon EMR – recursos exclusivos
Amazon EMR –
recursos exclusivos
Amazon S3 / Amazon EMR
Visão Consistente
Bootstrapping
Resize do Cluster
Cluster transientes e Spot
Utilizar diferentes tipos de instância
Amazon EMR Visão Consistente
Fornece uma ‘visão consistente’ do dado armazendo no S3, de dentro do cluster
Certifica que todos arquivos criados porum Step estão disponíveis para os Steps seguintes
Usa diretamente EMRFS para importar e sincronizar dados com o S3
Re-tentativas configurável e metastore
Novo arquivo de configuração emrfs-site.xml
fs.s3.consistent* System propertiesEMRfs
HDFS
Amazon EMR
Amazon S3 Amazon
DynamoDB
Registro de arquivos
processadosArquivos
Amazon EMR Visão Consistente
Gerencie dados no EMRFS usando o cliente emrfs:
emrfs– describe-metadata, set-metadata-capacity, delete-
metadata, create-metadata, list-metadata-stores –Trabalhar com os metadados armazenados
– diff – Exibe o que está no bucket e não está no índice
– delete – Remove entradas do índice
– sync – Certifica que o índice está sincronizado com um bucket
– import – Importa itens do bucket no índice
Tamanho de arquivo & Compressão
Melhores práticas para tamanho de arquivos
Evite arquivos pequenos sob qualquer custo
Qualquer coisa menor que 100MB
Uma Task de Mapper é gerada para cada quebra de
arquivo
Cada Mapper/Reducer lança uma nova JVM (Hadoop 1)
Tempo de CPU é requerido para lançar uma nova JVM
Impacto do tamanho do arquivo no Map/Reduce
Tasks de Mapper demoram 2 seg para iniciar e estarem prontas para
processar
10TB de 100MB
= 100.000 mappers * 2 seg
= 55 horas CPU gastas configurando Tasks de Mappers
Impacto do tamanho do arquivo no Map/Reduce
Tasks de Mapper demoram 2 seg para iniciar e estarem prontas para processar
10TB of 1GB Files
= 10.000 Mappers * 2 sec
= 5 horas CPU gastas configurando Tasks de Mappers
Boa prática: Tamanho do arquivo no
S3Qual é o melhor tamanho de arquivo no S3 para o
Hadoop?
Em torno de 1 a 2GB
Porque?
Boa prática: Tamanho do arquivo no
S3
Tempo de vida de uma Task não deve ser menor
do que 60 segundos
Uma Task atinge até de 10 a 15MB/s de
velocidade ao S3
≈60 seg * 15MB 1GB
E se eu tiver arquivos
pequenos?
Lidando com arquivos pequenos
Use S3DistCP para
juntar arquivos
pequenos
S3DistCP usa uma
expressão regular para
combinar arquivos
pequenos em maiores
aws emr add-steps --cluster-id <cluster>
--steps Name=GroupSmallFiles,
Type=CUSTOM_JAR,
Args=files,home/hadoop/lib/emr-s3distcp-1.0.jar,
src,s3://meubucketaws/logs,
dest,hdfs:///local,
groupBy,.*(i-\w.log).*,
targetSize,128…
CompressãoSempre comprima arquivos no S3
Comprima o resultado de uma Task
Reduz a banda utilizada entre o Amazon S3 e o Amazon EMR
Reduz custos de armazenamento
Reduz I/O de disco
Aumenta a velocidade do seu Job
CompressãoTipos compressão:
Alguns são rápidos, MAS oferecem menos redução de espaço
Alguns são eficientes no espaço, MAS lentos
Alguns podem ser divididos, outros não
Algorítmo % Compressão Velocidade
Compressão
Velocidade
Descompressão
GZIP 87% 21MB/s 118MB/s
LZO 80% 135MB/s 410MB/s
Snappy 78% 172MB/s 409MB/s
CompressãoSe for sensível a latência, compressão mais rápida é uma melhor escolha
Se tiver uma grande quantidade de dados, utilize algum com maior compressão
Se não tiver nenhum requisito específico, escolha o LZO
Utilize o S3DistCP para altrar o tipo de compressão dos seus arquivos
-outputCodec,lzo
Amazon S3 & HDFS
Boa prática: Amazon S3 como fonte de dados
primária
Use Amazon S3 como sua
fonte de dados permanente
HDFS para armazenamento
temporário entre jobs
Nenhum passo adicional para
copiar dados para HDFS
Amazon EMR Cluster
Task Instance GroupCore Instance Group
HDF
S
HDF
S
Amazon S3
Benefícios: Amazon S3 como fonte de dados
primária
Capacidade de desligar seu cluster
Benefício FANTÁSTICO!!
Durabilidade 99.999999999%
Benefícios: Amazon S3 como fonte de dados
primária
Sem necessidade de escalar HDFS
Capacidade
Replicação para durabilidade
Amazon S3 escala para os seus dados
Tanto para IOPs como para armazenamento
Benefícios: Amazon S3 como fonte de dados
primária
Capacidade de compartilhar dados entre múltiplos
clusters
Difícil de fazer com HDFS
EMR
EMR
Amazon
S3
Benefícios: Amazon S3 como fonte de dados
primária
Tire vantagem das funcionalidades do Amazon S3
Criptografia server-side
Políticas de ciclo de vida
Versionamento para proteger contra corrupção de dados
Crie clusters elásticos
Adicione nós, para ler mais dados do Amazon S3
Com os dados salvos no Amazon S3, remova nós
E sobre a localidade dos dados?
Rode os clusters na mesma região que o seubucket do Amazon S3
Os nós do Amazon EMR tem uma conexão de alta velocidade com o Amazon S3
Se o seu job é dependente de CPU/Memória, localidade dos dados não fará muita diferença
Boa prática: HDFS para baixa latência
Use HDFS para workloads
que necessitem de acesso
repetido ao dados
Use Amazon S3 sua fonte
de dados permanente
Amazon EMR Cluster
Task Instance GroupCore Instance Group
HDF
S
HDF
S
Amazon S3
Boa prática: HDFS para baixa latência
1. Dado armazenado no
Amazon S3
Boa prática: HDFS para baixa latência
2. Crie o cluster Amazon EMR e
copie o dado para o HDFS
com S3DistCP
S3D
istC
P
Boa prática: HDFS para baixa latência
3. Processe o dado em HDFS
Boa prática: HDFS para baixa latência
4. Armazene os resultados no
Amazon S3
S3D
istC
P
Boa prática: HDFS para baixa latência
Boa prática para workloads com I/O intensivo
Benefícios do Amazon S3 discutidos anteriormente, ainda se aplicam
Durabilidade
Escalabilidade
Custo
Acréscimo na complexidade operacional
Fluxo com Amazon S3
& HDFS
Estendendo o Amazon EMR
Ações de bootstrap e ferramentas do Amazon
EMR
EMR
HDFS
Pig
Ferramentas de macro do Amazon EMR
Hive 0.13.1• Suporte a ORC
• Funções Window
• Tipos decimais
• Comando TRUNCATE
• Melhor otimizador
(menos necessidade
de hinting)
Pig 0.12.0• Transmite UDF’s não
escritos em Java
• Suporte nativo a Avro
• Suporte nativo a
Parquet
• Tipos de dados
melhorados
Impala 1.2.4 • SQL engine em memória
• Suporte a tabelas
HBASE
• Suporte a Parquet –
formato de arquivo
orientado a coluna
• Consultas e console
interativo
HBase 0.94.18• Banco de dados
• Snapshots
• Cache de leitura
melhorado e
otimização de busca
• Transações
melhoradas
Leia dados diretamente do
Kinesis no Hive, Pig,
Streaming e Cascading
Sem persistência intermediária
de dados requerida
Maneira simples de introduzir fontes de dados em
tempo real, em Sistemas de Processamento em
Batch
Suporte a múltiplas aplicações & Checkpoint
automático
Integração do Amazon EMR com Amazon Kinesis
drop table call_data_records;
CREATE TABLE call_data_records (start_time bigint,end_time bigint,phone_number STRING,carrier STRING,recorded_duration bigint,calculated_duration bigint,lat double,long double
)ROW FORMAT DELIMITEDFIELDS TERMINATED BY ","STORED BY'com.amazon.emr.kinesis.hive.KinesisStorageHandler'TBLPROPERTIES("kinesis.stream.name"="TestAggregatorStream");
Integrando Amazon EMR com Amazon
Kinesis
Apache Hue
• Interface de usuário para o Hadoop
• Buscador de arquivos para Amazon S3 & HDFS
• Editor de consulta para Hive/Pig/Impala
• Visualização de alocação de Containers/Tasks para para os nós, arquivos de log, monitoramento de processo
• Suporte para autenticação LDAP
• Suporte a Metastore Remoto
Criando novas ações de bootstrap
Bash shell script
Executa como root
Armazenado no Amazon S3
Executado na criação ou redimensionamento do cluster
Dimensionando seu cluster
Alocação de recursos da instância
Hadoop 1 – Número estático de Mappers/Reducers
configurado nos nós do cluster
Hadoop 2 – Número variável de aplicações Hadoop
baseadas em quebras de arquivo e memória
disponível
Útil para entender dimensionamento antigo vs novo
Número de Tasks* = MapReduce RAM / Container Max RAM
Escolhendo o tipo de instância EMRInstância EC2
Map
Tasks
Reduce
Tasks
m1.small 2 1
m1.large 3 1
m1.xlarge 8 3
m2.xlarge 3 1
m2.2xlarge 6 2
m2.4xlarge 14 4
m3.xlarge 6 1
m3.2xlarge 12 3
cg1.4xlarge 12 3
cc2.8xlarge 24 6
c3.4xlarge 24 6
hi1.4xlarge 24 6
hs1.8xlarge 24 6
cr1.8xlarge &
c3.8xlarge48 12
1
2
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
0
50
100
150
200
250
300
Memory (GB) Mappers* Reducers* CPU (ECU Units) Local Storage (GB)
Tipos de nós e tamanhos do Amazon EMR
Use família m1 e c1 para testes funcionais
Use m3 e c3 xlarge, e nós maiores para workloads de
produção
Use cc2/c3 para trabalhos intensivos de memória e CPU
Instâncias hs1, hi1, i2 para workloads HDFS
Prefira um cluster menor de nós maiores
Família de instâncias M1/C1
Amplamente usada por clientes do Amazon
EMR
Entretanto, utilização de HDFS é
tipicamente baixa
M3/C3 oferecem melhor $/benefício
M1 vs. M3
Instância Custo / Task Mappper Custo / Task Reducer
m1.large $0.08 $0.15
m1.xlarge $0.06 $0.15
m3.xlarge $0.04 $0.07
m3.2xlarge $0.04 $0.07
C1 vs. C3
Instância Custo / Task Mapper Custo / Task Reducer
c1.medium $0.13 $0.13
c1.xlarge $0.35 $0.70
c3.xlarge $0.05 $0.11
c3.2xlarge $0.05 $0.11
Quantos nós eu preciso?
Calculando o tamanho do cluster
1. Estime o número de Tasks que o seu Job precisa.
2. Escolha uma instância e anote o número de Tasks que ela pode rodar em paralelo.
3. Escolha algumas amostras de dados para efetuar o teste de carga. O número de arquivos deve ser o mesmo número obtido no passo 2.
4. Rode um cluster Amazon EMR com um nó de um único núcleo e processe os arquivos do passo 3.
Anote o tempo total que o cluster levou para processaros seus arquivos.
Calculando tamanho do cluster
Total de Tasks * Tempo total para processar os arquivos
Capacidade de Tasks da instância * Tempo desejado de processamento
Número estimado de nós:
Exemplo: Calculando tamanho do
Cluster1. Estime o número de Tasks que seu Trabalho precisa
150
2. Escolha uma Instância e anote o número de Tasks que ela pode executar em paralelo
m1.xlarge com capacidade de 8 Tasks porinstância
Exemplo: Calculando tamanho do
Cluster
3. Precisamos escolher alguns arquivos de
amostra para executar nossos testes. O número
de arquivos deve ser o mesmo obtido no passo
2.
8 arquivos selecionados para o teste
Exemplo: Calculando tamanho do
Cluster
4. Execute um cluster Amazon EMR com um Nó
com um único núcleo, e processe os arquivos
escolhidos no passo 3. Anote o tempo total de
processamento dos arquivos.
3 minutos para processar 8 arquivos
Exemplo: Calculando tamanho do
Cluster
Total de Tasks * Tempo total para processar os arquivos
Capacidade de Tasks da instância * Tempo desejado de processamento
Número estimado de nós:
150 * 3 min 8 * 5 min
= 11 m1.xlarge
Clusters Transientes
Redimensionamento do Cluster
Amazon EMR te dá a habilidade de redimensionar o cluster sob demanda
Simplesmente troque número de instâncias no grupo Core ou Task, e o Amazon EMR provisionará a nova capacidade
Processamento continua durante o redimensionamento
Amazon EMR: Nós do tipo Core
Master Instance Group
Amazon EMR cluster
HDFS HDFS
Executam
TaskTrackers
(Compute)
Executam DataNode
(HDFS)
Core Instance Group
Amazon EMR: Nós do tipo Core
Pode adicionar Nós
do tipo Core
Mais espaço HDFS
More CPU/Memória
Master Instance Group
Amazon EMR cluster
HDFS HDFS HDFS
Core Instance Group
Amazon EMR: Nós do tipo Core
Não é possível
remover Nós do tipo
Core devido ao
HDFS
Master Instance Group
HDFS HDFS HDFS
Amazon EMR cluster
Core Instance Group
Amazon EMR: Nós do tipo Task
Executa TaskTrackers
Sem HDFS
Lê do HDFS dos Nós do
tipo Core
Master Instance Group
HDFS HDFS
Amazon EMR cluster
Task Instance GroupCore Instance Group
Amazon EMR: Nós do tipo Task
Pode adicionar
Nós do tipo Task
Master Instance Group
HDFS HDFS
Amazon EMR cluster
Task Instance GroupCore Instance Group
Amazon EMR: Nós do tipo Task
Mais CPU
Mais Memória
Master Instance Group
HDFS HDFS
Amazon EMR cluster
Task Instance GroupCore Instance Group
Amazon EMR: Nós do tipo Task
É possível
remover Nós do
tipo Task quando
o processamento
terminar
Master Instance Group
HDFS HDFS
Amazon EMR cluster
Task Instance GroupCore Instance Group
Casos de uso para redimensionamento do
cluster
Cluster sempre ligado que é expandido durante o horário
comercial
Adicionar Nós do tipo Task quando a carga de trabalho variar
em volume, para atender o tempo de processamento
fixo/desejado
Reduzir Nós do tipo Core com instâncias on-demand
adicionando Nós do tipo Task com instâncias spot
Quando devo redimensionar?
Monitorando o Amazon EMR
Amazon EMR é integrado com o Amazon CloudWatch
Granularidade de 5 minutos
Detalhes sobre:Estado do Cluster
Desempenho Map/reduce
Estado do nó
Taxas de I/O
HBase
Amazon
CloudWatch
Monitorando o Amazon EMR
Monitoramento chave para desempenhoTasks de Map executando/pendentes
Tasks de Reduce executando/pendentes
Bytes lidos/escritos no Amazon S3
Utilização HDFS %
Como monitoramento influencia o dimensionamentoAdicione Nós quando número de Tasks de Map/Reduce pendentes > 0
Para otimização de custos, quando o tempo de execução < 60 minutos,
pare de escalar
Monitorando o Amazon EMR
Sumário
Utilize o Amazon S3 como sua fonte de dados final para durabilidade
Pratique arquitetura em nuvem com Clusters transientes
Use o redimensionamento de Cluster Resize + Instâncias Spot para aumento
de desempenho e redução de custos
Migre para as novas famílias/tipos de instância para melhor desempenho/$
Use o CloudWatch para monitorar e saber como e quando utilizar o
redimensionamento
Obrigado!