Marcos técnicos do Apache Hadoop 3

Apresentação realizada por Silas Tailer no Big Data Week São Paulo 2018 [http://sao-paulo.bigdataweek.com].

O Hadoop e seu Ecossistema estão em constante evolução desde 2007, e agora ele encontra-se disponível para o público em geral ou através de vendors em sua terceira versão. Venha entender quais são as principais modificações nessa plataforma que vem revolucionando o mundo de TI nos últimos anos.

Transcript

1. Silas Tailer Marcos Técnicos Do Apache Hadoop 3
2. Consultor Big Data SILAS TAILER Silas Tailer é um consultor Big Data pela Accenture e professor de MBA em Big Data pela FIAP. Foi Instrutor Oficial Cloudera e é certificado como Cloudera Certified Administrator e Hortonworks Certified Administrator. Possui mais de 10 anos com infraestrutura de servidores e mais de 4 anos de experiência em ambientes produtivos de Big Data. Graduado e pós-graduado em Segurança da Informação. /bdwbrasil /bdwbrasil /silastailer http://sao-paulo.bigdataweek.com/
3. MOTIVAÇÕES PARA O HADOOP 3 ▪ HDFS erasure coding ▪ Isolamento de Classpath ▪ YARN – Execução de serviços de longa duração – Alterações de Interface do Usuário – Conteinerização Oportunística ▪ Upgrade de requisito mínimo da versão JAVA ▪ 6 anos de bugfix, melhorias e alterações desde o lançamento do Hadoop 2
4. HDFS ERASURE CODING
5. COMO FUNCIONA O ERASURE CODING ▪ Opera em blocos de dados de tamanho uniforme ▪ Um codec utiliza como entrada um número de bloco de dados e gera um número de blocos de paridade ▪ Esse processo é chamado de codificação ▪ Um bloco perdido pode ser reconstruído através da computação nos blocos remanescentes ▪ Esse processo é chamado de decodificação X Y X⊕Y 0 0 0 0 1 1 1 0 1 1 1 0 1 ⊕ 0 ⊕ 1 ⊕ 1 = 1 EXEMPLO paridade 1 ⊕ 0 ⊕ ? ⊕ 1 = 1 (1 ⊕ 0) ⊕ 1 ⊕ 1 = ? (1 ⊕ 1) ⊕ 1 = ? 0 ⊕ 1 = ? —› 1 bit recuperado
6. COMO FUNCIONA O ERASURE CODING ▪ XOR é limitado pois tolera apenas uma única falha de bloco de dado ▪ Para solucionar isso foi utilizado outro codec, o chamado Reed-Salamon (RS) ▪ O RS é configurado com dois parâmetros, k e m ▪ RS(k,m) multiplica o vetor k, bloco de dados, com um Gerador de Matrix (GT ) ▪ Gera um vetor codeword com k e m Fonte: Cloudera®, Setembro de 2015
7. REPLICAÇÃO VS. ERASURE CODING B1 RB1 B2 B3 RB2 RB3 RB1 RB2 RB3 3 replicas 3 blocos de dados ou seja 200% de sobrecarga hdfs:///data/bdw18 384 mb 128mb × 9 = 1152mb
8. REPLICAÇÃO VS. ERASURE CODING B1 P1 B2 B3 P2 ou seja 67% de sobrecarga hdfs:///data/bdw18 384 mb 3 blocos de dados 3 blocos de paridade EC Reed-Salamon(3,2) 128mb × 5 = 640mb
9. REPLICAÇÃO VS. ERASURE CODING B1 P1 B4 B6 P3 ou seja 40% de sobrecarga hdfs:///data/bdw18 384 mb 10 blocos de dados 4 blocos de paridade B4 B2 B5 B7 B8 B3 B10 P2 P4 38,4mb ×14 = 537,6mb RS (10,4)
10. RECONSTRUÇÃO COM ERASURE CODING B1 P1 B2 B3 P2 EC Reed-Salamon(3,2) ▪ Em caso de perda de um bloco, o erasure coding deverá realizar a leitura dos blocos restantes e o um bloco de paridade ▪ O código de reconstrução processará o algoritmo de recuperação do bloco B3 B1 B2 P1 B3
11. CARACTERÍSTICAS DO ERASURE CODING ▪ Melhoria da eficiência de armazenamento do HDFS – Aproximadamente duas vezes mais eficiente quando comparado ao fator de replicação padrão (3) – Redução da sobrecarga de 200% para um valor de até 40% ▪ Escrita paralela entre o cliente, que realiza o cálculo da paridade em tempo de escrita, e os datanodes ▪ Utiliza o algoritmo de correção de erros de código Reed-Solomon ao invés da replicação – Suporte para múltiplas políticas de erasure coding – RS(3,2), RS(6,3), RS(10,4) ▪ Pode melhorar a resiliência do dado, blocos que eventualmente forem perdidos, podem ser reconstruídos a partir dos restantes – RS(6,3) pode tolerar 3 falhas – RS(10,4) pode tolerar 4 falhas
12. IMPLICAÇÕES DA IMPLEMENTAÇÃO DO EC ▪ Os dados do arquivo podem ser distribuídos em vários nodes e racks ▪ As operações de leituras e escritas são remotas e entre racks quando houver ▪ O processo de reconstrução utiliza intensivamente a camada de rede, lendo RS(k, m) blocos ▪ Processadores Intel podem utilizar a biblioteca ISA-L para melhoria de desempenho durante execução de funções EC – Possibilitando maior velocidade de codificação/decodificação por ser realizada como uma instrução nativa ▪ Idealmente aplicável na criação de históricos de dados
13. DESEMPENHO DO ERASURE CODING 186 61 361 0 50 100 150 200 250 300 350 400 R E P L I C A Ç Ã O N E W J A V A C O D E R I S A - L C O D E R TAXA DE ESCRITA HDFS (MB/S) 195 154 534 0 100 200 300 400 500 600 R E P L I C A Ç Ã O N E W J A V A C O D E R I S A - L C O D E R TAXA DE LEITURA HDFS (MB/S) Fonte: Cloudera®, Setembro de 2015 ▪ 11 nodes (1 NameNode, 9 DataNodes, 1 Client Node) ▪ Comunicação através de rede de 10 GigE. ▪ Cliente escrevendo/lendo um arquivo de 12 GB ▪ Neste gráfico, foi testado a retirada de dois DN durante o processo de leitura
14. ARQUITETURA HDFS COM EC HDFS Client ... EC EC EC EC Schema Block Group Block Group EC EC Schema NameNode EC Novos Componentes Componentes Legados Erasure Coding Manager Erasure Coding Client Erasure Coding Worker
15. ARQUITETURA HDFS COM EC ▪ EC Client indica a extensão para o cliente HDFS que distribui dados de/para vários DataNodes ▪ EC Manager reside no NameNode e gerencia os block groups do Erasure Coding – Responsabilidades incluem alocação de grupos, posicionamento, monitoramento de integridade e coordenação do trabalho de recuperação – Em cada operação o EC Manager informa ao EC Worker qual block group e o codec schema a ser utilizado ▪ EC Worker é um daemon que aguarda comandos do EC Manager para recuperação ou conversão de blocos de dados – Atende a essas solicitações através da obtenção de dados dos DataNodes, da realização de cálculos de codec, da construção de blocos recuperados ou convertidos e, se necessário, enviando esses blocos para EC Workers adicionais – Os DataNodes não tomam conhecimento do Erasure Coding durante operações normais de I/O
16. ISOLAMENTO DO CLASSPATH
17. ISOLAMENTO DO CLASSPATH ▪ Usuários que desenvolvem aplicações podem ter de utilizar arbitrariamente bibliotecas para utilização de sistemas de arquivo, como por exemplo o HDFS ou HBase. ▪ No Hadoop 2 esse cenário podia acarretar em alterações de comportamento ou falhas na execução da aplicação. – O HDFS poderia fazer uso da mesma biblioteca internamente e a versão em tempo de execução dessa biblioteca selecionada pela aplicação poderia ser conflitante.
18. ISOLAMENTO DO CLASSPATH Aplicação Hadoop Client Hadoop Server APPLICATION SIDE CLIENT SIDE conflito! Cenário comum quando usado bibliotecas como: • Guava • Apache Common • Jackson Aplicação APPLICATION SIDE Hadoop Client CLIENT SIDE Hadoop Server FRAMEWORK SIDE coexistem!
20. HISTÓRICO DE EXECUÇÕES NO YARN Resource Manager jobs Qual estado do meu job? Job History Server HDFS NodeManager
21. HISTÓRICO DE EXECUÇÕES DO SPARK Resource Manager jobs Qual estado do meu job? Job History Server Spark History Server
22. APPLICATION TIMELINE SERVICE v2 ▪ Armazena eventos e dados de execuções das aplicações e do sistema – Distribuído – Escalável – Modelo de Dados Estruturados ▪ Atualizado em tempo real – Status do Aplicativo – Métricas de Aplicativos – Métricas do Sistema ▪ Alimentado pelo ResourceManager, NodeManager e ApplicationMaster ▪ Rest API
23. APPLICATION TIMELINE SERVICE v2 Resource Manager jobs Qual estado do meu job? Application Timeline Service HBase
24. FLUXOS JOB APP 4 EXECUÇÃO 1 EXECUÇÃO 2 APP 3 APP 2 APP 1 TENTATIVA 1 TENTATIVA 1 TENTATIVA 1 TENTATIVA 2 TENTATIVA 1 EXECUÇÕES APLICAÇÕES YARN TENTATIVAS APP CONTAINÊRES CONTAINER 1 CONTAINER 1 CONTAINER 1 CONTAINER 1 CONTAINER 2 CONTAINER 1 CONTAINER 2 CONTAINER 3 FLUXOS ATS v2
25. FLUXOS ATS v2
26. FLUXOS ATS v2
27. NOVA INTERFACE DO YARN ▪ Rich Client Application – Construída em Node.js e Ember ▪ Melhora a visibilidade na utilização do cluster – Memória, CPU – Por filas e aplicativos – Gráficos Sunburts para filas hierárquicas – Mapa de calor do NodeManager ▪ Integração ATSv2 – Plotagem dos eventos de início/fim do contêiner – Fácil de capturar atrasos na execução de aplicações
28. VISÃO GERAL DO CLUSTER
29. VISÃO GERAL DAS APLICAÇÕES
30. ACOMPANHAMENTO DE FILAS
31. MAPA DE CALOR DOS NODEMANAGERS
32. AINDA É POSSÍVEL ACESSAR O HISTORYSERVER
33. CONTÊINERES OPORTUNÍSTICOS ▪ Podem ser transmitidos para um NodeManager mesmo que sua execução não possa ser iniciada imediatamente ▪ São enfileirados no NodeManager até que os recursos necessários estejam disponíveis para uso ▪ Caso haja a necessidade de utilização do recurso por um processo comum, o container pode ser finalizado e retornará para a fila
34. APPLICATION TIMELINE SERVICE v2 Resource Manager Timeline Reader Hbase Node Manager Application Master Timeline Collecter Timeline Collecter
36. Atualização do JDK ▪ A versão suportada anteriormente pelo Hadoop 2, Oracle JDK 7 teve seu ciclo de vida finalizado em Abril de 2015 ▪ A versão 8 suporta novas funcionalidades como: – Expressões Lambda – Stream API ▪ Melhorias de desempenho para classes HashMaps, IO/NIO, etc ▪ Correções e aperfeiçoamentos em requisitos de segurança
37. OUTRAS ALTERAÇÕES RELEVANTES
38. OUTRAS ALTERAÇÕES RELEVANTES ▪ Suporte para mais de dois NameNodes ▪ Federação Baseada em Roteamento para o HDFS – Adicionado roteamento em uma camada RPC para prover a visualização de múltiplas Federações de namespaces no HDFS ▪ Federação Baseada em Roteamento para o YARN ▪ Melhorias nos Agendadores do YARN ▪ Suporte ao Docker no YARN
39. OUTRAS ALTERAÇÕES RELEVANTES ▪ Otimização nativa à nível de tarefa para o framework MapReduce – Pode resultar em um ganho de desempenho acima de 30%, particularmente efetivo para jobs que possuam muito shuffle. ▪ Portas padrões de vários serviços foram alteradas – NameNode: 50070 —› 9870 – DataNode: 50070 —› 9870 ▪ Balanceador intra-datanode – Os DataNodes geralmente possuem diversos discos, em eventual falha, não havia balanceamento entre eles
40. OBRIGADO
41. Referências Bibliográficas HDFS Erasure Code Storage Same Reliability At Better Storage Efficiency HDFS Erasure Coding In Action Hadoop 3 In A Nutshell Introduction To Hdfs Erasure Coding In Apache Hadoop Apache Hadoop v3 Big Data Analytics with Hadoop 3. Alla, Sridhar. Publicado por Packt Publishing em 2018. What's new in Hadoop 3.0. Templeton, Daniel; Wang, Andrew. Publicado por Strata Data Conference em 2018.