O mercado de computação distribuída e big data, de acordo com , está crescendo de 18 a 19% ao ano. Isso significa que a questão da escolha do software para esses fins permanece relevante. Nesta postagem, começaremos explicando por que precisamos de computação distribuída, abordaremos com mais detalhes a escolha do software, falaremos sobre o uso do Hadoop com Cloudera e, finalmente, falaremos sobre a escolha do hardware e como isso afeta o desempenho De maneiras diferentes.
Por que precisamos de computação distribuída em negócios comuns? Tudo é simples e complicado ao mesmo tempo. Simples - porque na maioria dos casos realizamos cálculos relativamente simples por unidade de informação. Difícil - porque há muitas dessas informações. Muitos. Como consequência, é preciso . Assim, os casos de uso são bastante universais: os cálculos podem ser aplicados sempre que necessário para levar em conta um grande número de métricas em uma matriz de dados ainda maior.
Um exemplo recente: Dodo Pizza com base em uma análise da base de pedidos do cliente, ao escolher uma pizza com coberturas arbitrárias, os usuários geralmente operam com apenas seis conjuntos básicos de ingredientes mais alguns aleatórios. Assim, a pizzaria ajustou as compras. Além disso, foi capaz de recomendar melhor produtos adicionais oferecidos na fase de pedido aos usuários, o que aumentou os lucros.
Outro exemplo: A mercadoria permitiu à H&M reduzir o sortimento em lojas individuais em 40%, mantendo o nível de vendas. Isso foi obtido excluindo as posições de venda fraca e a sazonalidade foi levada em consideração nos cálculos.
Seleção de ferramenta
O padrão da indústria para esse tipo de computação é o Hadoop. Por que? Porque o Hadoop é uma estrutura excelente e bem documentada (o mesmo Habr fornece muitos artigos detalhados sobre esse tópico), que é acompanhado por todo um conjunto de utilitários e bibliotecas. Você pode enviar grandes conjuntos de dados estruturados e não estruturados como entrada, e o próprio sistema os distribuirá entre o poder de computação. Além disso, essas mesmas capacidades podem ser aumentadas ou desativadas a qualquer momento - a mesma escalabilidade horizontal em ação.
Em 2017, a influente empresa de consultoria Gartner que o Hadoop logo se tornará obsoleto. O motivo é bastante banal: analistas acreditam que as empresas migrarão massivamente para a nuvem, já que lá poderão pagar com base no uso do poder computacional. O segundo fator importante supostamente capaz de "enterrar" o Hadoop é a velocidade de trabalho. Porque opções como Apache Spark ou Google Cloud DataFlow são mais rápidas que o MapReduce subjacente ao Hadoop.
O Hadoop se baseia em vários pilares, sendo os mais notáveis as tecnologias MapReduce (sistema de distribuição de dados para cálculos entre servidores) e o sistema de arquivos HDFS. Este último é projetado especificamente para armazenar informações distribuídas entre os nós do cluster: cada bloco de tamanho fixo pode ser colocado em vários nós e, graças à replicação, o sistema é resistente a falhas de nós individuais. Em vez de uma tabela de arquivos, um servidor especial chamado NameNode é usado.
A ilustração abaixo mostra como o MapReduce funciona. No primeiro estágio, os dados são divididos de acordo com um determinado atributo, no segundo estágio são distribuídos pelo poder de computação, no terceiro estágio ocorre o cálculo.
MapReduce foi originalmente criado pelo Google para as necessidades de sua busca. Em seguida, o MapReduce passou para o código livre e o Apache assumiu o projeto. Bem, o Google migrou gradualmente para outras soluções. Uma nuance interessante: no momento, o Google tem um projeto chamado Google Cloud Dataflow, posicionado como o próximo passo depois do Hadoop, como seu substituto rápido.
Um olhar mais atento mostra que o Google Cloud Dataflow é baseado em uma variação do Apache Beam, enquanto o Apache Beam inclui a bem documentada estrutura Apache Spark, que nos permite falar sobre quase a mesma velocidade de execução da solução. Bem, o Apache Spark funciona bem no sistema de arquivos HDFS, o que permite que você o implante em servidores Hadoop.
Adicione aqui o volume de documentação e soluções prontas para Hadoop e Spark em relação ao Google Cloud Dataflow, e a escolha da ferramenta se torna óbvia. Além disso, os engenheiros podem decidir por si mesmos qual código - no Hadoop ou Spark - eles executarão, com foco na tarefa, experiência e qualificações.
Nuvem ou servidor local
A tendência para a transição geral para a nuvem deu origem a um termo tão interessante como Hadoop-as-a-service. Nesse cenário, a administração de servidores conectados tornou-se muito importante. Porque, infelizmente, apesar de sua popularidade, o Hadoop puro é uma ferramenta bastante difícil de configurar, já que você tem que fazer muito manualmente. Por exemplo, você pode configurar servidores individualmente, monitorar seu desempenho e ajustar vários parâmetros. Em geral, trabalhe para um amador e há uma grande chance de estragar em algum lugar ou perder alguma coisa.
Portanto, várias distribuições se tornaram muito populares, inicialmente equipadas com ferramentas convenientes de implantação e administração. Uma das distribuições mais populares que suporta o Spark e facilita as coisas é a Cloudera. Possui versões pagas e gratuitas - sendo que nesta última está disponível toda a funcionalidade principal, e sem limitar o número de nós.
Durante a configuração, o Cloudera Manager se conectará via SSH aos seus servidores. Um ponto interessante: ao instalar, é melhor especificar que seja realizado pelo chamado parcelas: pacotes especiais, cada um dos quais contém todos os componentes necessários configurados para funcionar entre si. Na verdade, esta é uma versão aprimorada do gerenciador de pacotes.
Após a instalação, obtemos um console de gerenciamento de cluster, onde você pode ver a telemetria para clusters, serviços instalados, além de adicionar / remover recursos e editar a configuração do cluster.
Como resultado, surge à sua frente o corte daquele foguete, que o levará ao brilhante futuro do BigData. Mas antes de dizermos "vamos lá", vamos avançar rapidamente sob o capô.
requisitos de hardware
Em seu site, Cloudera menciona diferentes configurações possíveis. Os princípios gerais pelos quais eles são construídos são mostrados na ilustração:
MapReduce pode desfocar essa imagem otimista. Observando novamente o diagrama da seção anterior, fica claro que, em quase todos os casos, uma tarefa MapReduce pode atingir um gargalo ao ler dados do disco ou da rede. Isso também é observado no blog Cloudera. Como resultado, para qualquer cálculo rápido, inclusive por meio do Spark, que costuma ser usado para cálculos em tempo real, a velocidade de E/S é muito importante. Portanto, ao usar o Hadoop, é muito importante que máquinas balanceadas e rápidas entrem no cluster, o que, para dizer o mínimo, nem sempre é fornecido na infraestrutura de nuvem.
O equilíbrio na distribuição de carga é alcançado por meio do uso da virtualização Openstack em servidores com poderosas CPUs multi-core. Os nós de dados recebem seus próprios recursos de processador e determinados discos. Em nossa solução Mecanismo Atos Codex Data Lake uma ampla virtualização é alcançada, e é por isso que ganhamos tanto em termos de desempenho (o impacto da infraestrutura de rede é minimizado) quanto em TCO (os servidores físicos extras são eliminados).
No caso da utilização de servidores BullSequana S200, obtemos uma carga bastante uniforme, sem alguns gargalos. A configuração mínima inclui 3 servidores BullSequana S200, cada um com dois JBODs, além de S200s adicionais contendo quatro nós de dados conectados opcionalmente. Aqui está um exemplo de carga em um teste TeraGen:
Testes com diferentes volumes de dados e valores de replicação mostram os mesmos resultados em termos de distribuição de carga nos nós do cluster. Abaixo está um gráfico da distribuição de acesso ao disco por testes de desempenho.
Os cálculos são baseados em uma configuração mínima de 3 servidores BullSequana S200. Inclui 9 nós de dados e 3 nós mestres, bem como máquinas virtuais reservadas em caso de implantação de proteção baseada em OpenStack Virtualization. Resultado do teste TeraSort: tamanho de bloco de 512 MB de um fator de replicação de três com criptografia é de 23,1 minutos.
Como o sistema pode ser expandido? Vários tipos de extensões estão disponíveis para o Data Lake Engine:
- Nós de dados: para cada 40 TB de espaço utilizável
- Nós analíticos com a capacidade de instalar uma GPU
- Outras opções dependendo das necessidades de negócios (por exemplo, se você precisar de Kafka e similares)
O complexo Atos Codex Data Lake Engine inclui os próprios servidores e o software pré-instalado, incluindo o kit Cloudera com uma licença; Hadoop em si, OpenStack com máquinas virtuais baseadas no kernel RedHat Enterprise Linux, replicação de dados e sistemas de backup (incluindo o uso de um nó de backup e Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine é a primeira solução de virtualização a ser certificada .
Se você estiver interessado nos detalhes, teremos o maior prazer em responder nossas perguntas nos comentários.
Fonte: habr.com