{"id":33630,"date":"2019-10-31T21:53:49","date_gmt":"2019-10-31T18:53:49","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-osobennogo-v-cloudera-i-kak-ee-gotovit\/"},"modified":"2019-10-31T21:53:49","modified_gmt":"2019-10-31T18:53:49","slug":"chto-osobennogo-v-cloudera-i-kak-ee-gotovit","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/chto-osobennogo-v-cloudera-i-kak-ee-gotovit","title":{"rendered":"O que h\u00e1 de especial na Cloudera e como prepar\u00e1-la","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

O mercado de computa\u00e7\u00e3o distribu\u00edda e big data, se acreditarmos estat\u00edsticas<\/a><\/noindex>, cresce entre 18-19% ao ano. Isso significa que a escolha de software para esses fins continua sendo uma quest\u00e3o relevante. Neste post, come\u00e7aremos com o porqu\u00ea da necessidade de computa\u00e7\u00e3o distribu\u00edda, abordaremos mais detalhadamente a escolha de software, falaremos sobre o uso do Hadoop com a Cloudera e, por fim, discutiremos a sele\u00e7\u00e3o de hardware e como ele impacta a performance de diferentes maneiras.<\/p>\n

\"O<\/a><\/noindex>
\nPor que a computa\u00e7\u00e3o distribu\u00edda \u00e9 necess\u00e1ria nos neg\u00f3cios convencionais? \u00c9 simples e ao mesmo tempo complicado. Simples \u2014 porque na maioria dos casos realizamos c\u00e1lculos relativamente simples por unidade de informa\u00e7\u00e3o. Complicado \u2014 porque essa informa\u00e7\u00e3o \u00e9 vasta. Muito vasta. Como consequ\u00eancia, \u00e9 necess\u00e1rio processar terabytes de dados em 1000 fluxos<\/a><\/noindex>. Assim, os cen\u00e1rios de uso s\u00e3o bastante universais: os c\u00e1lculos podem ser aplicados em qualquer lugar onde seja necess\u00e1rio considerar um grande n\u00famero de m\u00e9tricas em um conjunto de dados ainda maior.<\/p>\n

Um dos exemplos recentes: a rede de pizzarias Dodo Pizza determinaram<\/a><\/noindex> baseou-se na an\u00e1lise do banco de pedidos dos clientes, que ao escolher uma pizza com recheio aleat\u00f3rio, os usu\u00e1rios geralmente operam apenas com seis conjuntos b\u00e1sicos de ingredientes, al\u00e9m de alguns aleat\u00f3rios. Com isso, a pizzaria ajustou suas compras. Al\u00e9m disso, conseguiu recomendar melhor aos usu\u00e1rios produtos adicionais oferecidos no momento do pedido, o que aumentou os lucros.<\/p>\n

Outro exemplo: an\u00e1lise<\/a><\/noindex> a redu\u00e7\u00e3o de 40% no n\u00famero de itens da loja H&M em algumas filiais, mantendo o n\u00edvel de vendas. Isso foi alcan\u00e7ado excluindo itens com baixa venda, considerando a sazonalidade nas an\u00e1lises.<\/p>\n

Escolha da ferramenta<\/h2>\n

\nO padr\u00e3o da ind\u00fastria para esse tipo de computa\u00e7\u00e3o \u00e9 o Hadoop. Por qu\u00ea? Porque o Hadoop \u00e9 uma excelente estrutura bem documentada (o mesmo Habr publica muitos artigos detalhados sobre isso), acompanhada de um conjunto completo de utilit\u00e1rios e bibliotecas. Voc\u00ea pode fornecer enormes conjuntos de dados, tanto estruturados quanto n\u00e3o estruturados, e o sistema se encarregar\u00e1 de distribu\u00ed-los entre os recursos computacionais. E esses recursos podem ser ampliados ou desligados a qualquer momento \u2014 a famosa escalabilidade horizontal em a\u00e7\u00e3o. <\/p>\n

Em 2017, uma influente empresa de consultoria, a Gartner concluiu<\/a><\/noindex>, que o Hadoop em breve se tornar\u00e1 obsoleto. A raz\u00e3o \u00e9 bastante simples: os analistas acreditam que as empresas come\u00e7ar\u00e3o a migrar em massa para a nuvem, onde poder\u00e3o pagar conforme o uso de recursos computacionais. Outro fator importante que pode \"enterrar\" o Hadoop \u00e9 a velocidade de opera\u00e7\u00e3o. Tecnologias como Apache Spark ou Google Cloud DataFlow s\u00e3o mais r\u00e1pidas do que o MapReduce, que \u00e9 a base do Hadoop.<\/p>\n

O Hadoop se baseia em algumas tecnologias fundamentais, as mais not\u00e1veis sendo o MapReduce (um sistema de distribui\u00e7\u00e3o de dados para c\u00e1lculos entre servidores) e o sistema de arquivos HDFS. O \u00faltimo \u00e9 projetado especificamente para armazenar informa\u00e7\u00f5es distribu\u00eddas entre os n\u00f3s de um cluster: cada bloco de tamanho fixo pode ser alocado em v\u00e1rios n\u00f3s, e a replica\u00e7\u00e3o garante a resist\u00eancia do sistema a falhas de n\u00f3s individuais. Em vez de uma tabela de arquivos, \u00e9 utilizado um servidor especial, denominado NameNode.<\/p>\n

Na ilustra\u00e7\u00e3o abaixo, est\u00e1 o diagrama de funcionamento do MapReduce. Na primeira etapa, os dados s\u00e3o divididos com base em um crit\u00e9rio espec\u00edfico; na segunda, s\u00e3o distribu\u00eddos pelos recursos computacionais; na terceira, \u00e9 realizado o c\u00e1lculo. <\/p>\n

\"O
\nOriginalmente, o MapReduce foi criado pelo Google para suas necessidades de busca. Depois, o MapReduce foi liberado como c\u00f3digo aberto e o projeto foi assumido pela Apache. Enquanto isso, o Google come\u00e7ou a migrar para outras solu\u00e7\u00f5es. Um detalhe interessante: atualmente, o Google possui um projeto chamado Google Cloud Dataflow, que \u00e9 posicionado como o pr\u00f3ximo passo ap\u00f3s o Hadoop, como uma alternativa r\u00e1pida.<\/p>\n

Ao analisar mais de perto, fica evidente que o Google Cloud Dataflow \u00e9 baseado em uma variante do Apache Beam, que inclui um framework bem documentado, o Apache Spark, permitindo afirmar que as velocidades de execu\u00e7\u00e3o s\u00e3o praticamente iguais. Al\u00e9m disso, o Apache Spark funciona muito bem no sistema de arquivos HDFS, o que permite implement\u00e1-lo em servidores Hadoop.<\/p>\n

Adicionando a isso o volume de documenta\u00e7\u00e3o e solu\u00e7\u00f5es prontas para Hadoop e Spark em compara\u00e7\u00e3o ao Google Cloud Dataflow, a escolha da ferramenta se torna clara. Al\u00e9m disso, os engenheiros podem decidir qual c\u00f3digo usar \u2014 para Hadoop ou Spark \u2014 com base nas tarefas, experi\u00eancia e habilidades.<\/p>\n

Nuvem ou servidor local<\/h2>\n

\nA tend\u00eancia de migra\u00e7\u00e3o para a nuvem gerou at\u00e9 mesmo um termo interessante como Hadoop-as-a-service. Nesse cen\u00e1rio, a administra\u00e7\u00e3o de servidores conectados se tornou extremamente importante. Pois, infelizmente, apesar de sua popularidade, o Hadoop puro \u00e9 uma ferramenta bastante complexa de configurar, j\u00e1 que muito do trabalho precisa ser feito manualmente. Por exemplo, \u00e9 necess\u00e1rio configurar os servidores separadamente, monitorar seus indicadores e ajustar cuidadosamente muitos par\u00e2metros. Em suma, \u00e9 um trabalho para entusiastas e h\u00e1 uma grande chance de cometer erros ou deixar algo passar.<\/p>\n

Por isso, diversos distribui\u00e7\u00f5es que oferecem ferramentas convenientes de implanta\u00e7\u00e3o e administra\u00e7\u00e3o tornaram-se muito populares. Uma das distribui\u00e7\u00f5es mais conhecidas que suporta o Spark e simplifica tudo \u00e9 a Cloudera. Ela possui vers\u00f5es paga e gratuita \u2014 e nesta \u00faltima, todas as funcionalidades principais est\u00e3o dispon\u00edveis, sem limita\u00e7\u00e3o do n\u00famero de n\u00f3s. <\/p>\n

\"O
\n
\nDurante a configura\u00e7\u00e3o, o Cloudera Manager se conectar\u00e1 aos seus servidores via SSH. Um ponto interessante: ao instalar, \u00e9 melhor indicar que a instala\u00e7\u00e3o seja realizada por meio dos chamados parcelas<\/i>: pacotes especiais, cada um contendo todos os componentes necess\u00e1rios, configurados para trabalhar uns com os outros. Essencialmente, \u00e9 uma vers\u00e3o aprimorada do gerenciador de pacotes.<\/p>\n

Ap\u00f3s a instala\u00e7\u00e3o, obtemos um console de gerenciamento de cluster, onde \u00e9 poss\u00edvel visualizar a telemetria dos clusters, os servi\u00e7os instalados, al\u00e9m de poder adicionar\/remover recursos e editar a configura\u00e7\u00e3o do cluster. <\/p>\n

\"O
\n
\nComo resultado, voc\u00ea se depara com a se\u00e7\u00e3o da nave que o levar\u00e1 para o futuro brilhante do Big Data. Mas antes de dizer \u201cvamos l\u00e1\u201d, vamos dar uma olhada sob o cap\u00f4.<\/p>\n

Requisitos de hardware<\/h2>\n

\nEm seu site, a Cloudera menciona diferentes configura\u00e7\u00f5es poss\u00edveis. Os princ\u00edpios gerais que orientam sua constru\u00e7\u00e3o s\u00e3o apresentados na ilustra\u00e7\u00e3o:<\/p>\n

\"O
\nEsta vis\u00e3o otimista pode ser ofuscada pelo MapReduce. Se olharmos novamente para o diagrama da se\u00e7\u00e3o anterior, fica claro que, na maioria dos casos, uma tarefa MapReduce pode enfrentar um 'gargalo' ao ler dados do disco ou da rede. Isso tamb\u00e9m \u00e9 mencionado no blog da Cloudera. Como resultado, para c\u00e1lculos r\u00e1pidos, incluindo aqueles feitos via Spark, que \u00e9 frequentemente utilizado para c\u00e1lculos em tempo real, a velocidade de entrada\/sa\u00edda \u00e9 crucial. Portanto, ao utilizar o Hadoop, \u00e9 de extrema import\u00e2ncia que o cluster tenha m\u00e1quinas balanceadas e r\u00e1pidas, o que, para ser gentil, nem sempre \u00e9 garantido na infraestrutura em nuvem.<\/p>\n

O balanceamento na distribui\u00e7\u00e3o de cargas \u00e9 alcan\u00e7ado pelo uso de virtualiza\u00e7\u00e3o OpenStack em servidores com poderosos CPUs multin\u00facleo. Os n\u00f3s de dados recebem seus pr\u00f3prios recursos de processamento e discos espec\u00edficos. Em nossa solu\u00e7\u00e3o Atos Codex Data Lake Engine<\/i> \u00e9 alcan\u00e7ada ampla virtualiza\u00e7\u00e3o, o que nos beneficia tanto em termos de desempenho (minimizando o impacto da infraestrutura de rede) quanto em TCO (eliminando servidores f\u00edsicos desnecess\u00e1rios).<\/p>\n

\"O
\nNo caso do uso de servidores BullSequana S200, obtemos uma carga bastante uniforme, livre de alguns gargalos. A configura\u00e7\u00e3o m\u00ednima inclui 3 servidores BullSequana S200, cada um com dois JBOD, al\u00e9m de S200 adicionais que podem ser conectados, cada um contendo quatro n\u00f3s de dados. Aqui est\u00e1 um exemplo de carga no teste TeraGen:<\/p>\n

\"O
\n
\nOs testes com diferentes volumes de dados e valores de replica\u00e7\u00e3o mostram resultados consistentes em termos de distribui\u00e7\u00e3o de carga entre os n\u00f3s do cluster. Abaixo est\u00e1 um gr\u00e1fico de distribui\u00e7\u00e3o de acesso a disco nos testes de desempenho.<\/p>\n

\"O
\n
\nOs c\u00e1lculos foram realizados com base em uma configura\u00e7\u00e3o m\u00ednima de 3 servidores BullSequana S200. Isso inclui 9 n\u00f3s de dados e 3 n\u00f3s principais, al\u00e9m de m\u00e1quinas virtuais reservadas para implanta\u00e7\u00e3o de prote\u00e7\u00e3o baseada em Virtualiza\u00e7\u00e3o OpenStack. Resultado do teste TeraSort: tamanho do bloco de 512 MB com um fator de replica\u00e7\u00e3o de tr\u00eas e criptografia levou 23,1 minutos.<\/p>\n

Como pode-se expandir o sistema? Para o Data Lake Engine est\u00e3o dispon\u00edveis diferentes tipos de expans\u00f5es:<\/p>\n