O mercado de computación distribuída e big data, segundo , está a medrar un 18-19% ao ano. Isto significa que a cuestión de escoller software para estes fins segue sendo relevante. Nesta publicación, comezaremos polo que se necesita a computación distribuída, entraremos en máis detalles sobre a elección do software, falaremos sobre o uso de Hadoop usando Cloudera e, finalmente, falaremos sobre a elección do hardware e como afecta o rendemento de diferentes xeitos.
Por que é necesaria a computación distribuída nos negocios habituais? Todo aquí é sinxelo e complicado ao mesmo tempo. Simple - porque na maioría dos casos realizamos cálculos relativamente sinxelos por unidade de información. É difícil porque hai moita información deste tipo. Moitos. Como consecuencia, é necesario . Así, os casos de uso son bastante universais: os cálculos pódense usar sempre que sexa necesario ter en conta un gran número de métricas nunha matriz aínda maior de datos.
Un dos exemplos recentes: a cadea de pizzerías Dodo Pizza baseándose nunha análise da base de datos de pedidos dos clientes, que ao elixir unha pizza cunha cobertura aleatoria, os usuarios adoitan operar con só seis conxuntos básicos de ingredientes máis un par de outros aleatorios. De acordo con isto, a pizzería axustou as súas compras. Ademais, puido recomendar mellor produtos adicionais ofrecidos aos usuarios durante a fase de pedido, o que aumentou os beneficios.
Un exemplo máis: Os artigos de produtos permitiron á tenda H&M reducir nun 40% a oferta en tendas individuais, mantendo os niveis de vendas. Isto conseguiuse excluíndo os artigos mal vendidos e tívose en conta a estacionalidade nos cálculos.
Selección de ferramentas
O estándar da industria para este tipo de computación é Hadoop. Por que? Porque Hadoop é un marco excelente e ben documentado (o mesmo Habr ofrece moitos artigos detallados sobre este tema), que vai acompañado de todo un conxunto de utilidades e bibliotecas. Podes introducir enormes conxuntos de datos estruturados e non estruturados, e o propio sistema distribuirao entre a potencia informática. Ademais, estas mesmas capacidades pódense aumentar ou desactivar en calquera momento, a mesma escalabilidade horizontal en acción.
En 2017, a influínte empresa de consultoría Gartner que Hadoop pronto quedará obsoleto. O motivo é bastante banal: os analistas cren que as empresas migrarán masivamente á nube, xa que alí poderán pagar a medida que utilicen a potencia informática. O segundo factor importante que supostamente pode "enterrar" a Hadoop é a súa velocidade. Porque opcións como Apache Spark ou Google Cloud DataFlow son máis rápidas que MapReduce, que subxace a Hadoop.
Hadoop descansa sobre varios piares, dos cales os máis salientables son as tecnoloxías MapReduce (un sistema de distribución de datos para os cálculos entre servidores) e o sistema de ficheiros HDFS. Este último está especialmente deseñado para almacenar información distribuída entre nodos do clúster: cada bloque dun tamaño fixo pódese colocar en varios nodos e, grazas á replicación, o sistema é resistente aos fallos dos nodos individuais. En lugar dunha táboa de ficheiros, úsase un servidor especial chamado NameNode.
A ilustración seguinte mostra como funciona MapReduce. Na primeira etapa, os datos divídense segundo un determinado criterio, na segunda etapa distribúense segundo a potencia de cálculo e na terceira etapa prodúcese o cálculo.
MapReduce foi orixinalmente creado por Google para as súas necesidades de busca. Logo MapReduce pasou a ser código gratuíto e Apache fíxose cargo do proxecto. Ben, Google migrou aos poucos a outras solucións. Un dato interesante: Google ten actualmente un proxecto chamado Google Cloud Dataflow, posicionado como o seguinte paso despois de Hadoop, como un substituto rápido do mesmo.
Unha ollada máis atenta mostra que Google Cloud Dataflow está baseado nunha variación de Apache Beam, mentres que Apache Beam inclúe o ben documentado framework Apache Spark, que nos permite falar case da mesma velocidade de execución das solucións. Pois ben, Apache Spark funciona perfectamente no sistema de ficheiros HDFS, o que permite que se despregue nos servidores Hadoop.
Engade aquí o volume de documentación e solucións preparadas para Hadoop e Spark fronte a Google Cloud Dataflow, e a elección da ferramenta faise obvia. Ademais, os enxeñeiros poden decidir por si mesmos que código -para Hadoop ou Spark- deben executar, centrándose na tarefa, experiencia e cualificacións.
Servidor local ou en nube
A tendencia cara a unha transición xeral á nube mesmo deu lugar a un termo tan interesante como Hadoop-as-a-service. Neste escenario, a administración dos servidores conectados volveu ser moi importante. Porque, por desgraza, a pesar da súa popularidade, Hadoop puro é unha ferramenta bastante difícil de configurar, xa que hai que facer moito manualmente. Por exemplo, configure os servidores individualmente, supervisa o seu rendemento e configure coidadosamente moitos parámetros. En xeral, o traballo é para un afeccionado e hai unha gran posibilidade de estropear algún lugar ou perder algo.
Polo tanto, varios kits de distribución, que inicialmente están equipados con ferramentas de implementación e administración convenientes, fixéronse moi populares. Unha das distribucións máis populares que admite Spark e facilita todo é Cloudera. Ten versións de pago e gratuítas, e nesta última están dispoñibles todas as funcións básicas, sen limitar o número de nós.
Durante a configuración, Cloudera Manager conectarase aos teus servidores mediante SSH. Un punto interesante: ao instalar, é mellor especificar que o realice o chamado pasteis: paquetes especiais, cada un dos cales contén todos os compoñentes necesarios configurados para funcionar entre si. Esencialmente, esta é unha versión mellorada do xestor de paquetes.
Despois da instalación, recibimos unha consola de xestión de clústeres, onde podes ver a telemetría do clúster, os servizos instalados, ademais de engadir/eliminar recursos e editar a configuración do clúster.
Como resultado, aparece diante de ti a cabina do foguete que te levará ao brillante futuro de BigData. Pero antes de dicir "imos", movémonos baixo o capó.
Requisitos de hardware
Na súa páxina web, Cloudera menciona diferentes configuracións posibles. Os principios xerais polos que se constrúen móstranse na ilustración:
MapReduce pode desenfocar esta imaxe optimista. Se miras de novo o diagrama da sección anterior, queda claro que en case todos os casos, un traballo de MapReduce pode atopar un pescozo de botella ao ler datos do disco ou da rede. Isto tamén se sinala no blog de Cloudera. Como resultado, para calquera cálculo rápido, incluso a través de Spark, que adoita usarse para cálculos en tempo real, a velocidade de E/S é moi importante. Polo tanto, cando se usa Hadoop, é moi importante que o clúster inclúa máquinas equilibradas e rápidas, o que, para dicir un pouco, non sempre está asegurado na infraestrutura da nube.
O equilibrio na distribución da carga conséguese mediante o uso da virtualización Openstack en servidores con potentes CPU multinúcleo. Aos nodos de datos asígnanse os seus propios recursos de procesador e discos específicos. Na nosa decisión Motor Atos Codex Data Lake Conséguese unha ampla virtualización, polo que nos beneficiamos tanto en rendemento (remítase ao mínimo o impacto da infraestrutura de rede) como en TCO (elimínanse os servidores físicos extra).
Cando usamos servidores BullSequana S200, obtemos unha carga moi uniforme, sen algúns embotellamentos. A configuración mínima inclúe 3 servidores BullSequana S200, cada un con dous JBOD, ademais de S200 adicionais que conteñen catro nodos de datos están conectados opcionalmente. Aquí tes un exemplo da carga na proba TeraGen:
As probas con diferentes volumes de datos e valores de replicación mostran os mesmos resultados en canto á distribución de carga entre os nodos do clúster. A continuación móstrase un gráfico da distribución do acceso ao disco por probas de rendemento.
Os cálculos realizáronse a partir dunha configuración mínima de 3 servidores BullSequana S200. Inclúe 9 nodos de datos e 3 nodos mestres, así como máquinas virtuais reservadas en caso de implantación de protección baseada en OpenStack Virtualization. Resultado da proba TeraSort: tamaño do bloque 512 MB factor de replicación igual a tres con cifrado é de 23,1 minutos.
Como se pode ampliar o sistema? Hai diferentes tipos de extensións dispoñibles para Data Lake Engine:
- Nodos de datos: por cada 40 TB de espazo utilizable
- Nodos analíticos con capacidade para instalar unha GPU
- Outras opcións dependendo das necesidades empresariais (por exemplo, se necesitas Kafka e similares)
O Atos Codex Data Lake Engine inclúe tanto os propios servidores como o software preinstalado, incluíndo un kit con licenza de Cloudera; O propio Hadoop, OpenStack con máquinas virtuais baseadas no núcleo RedHat Enterprise Linux, replicación de datos e sistemas de copia de seguridade (incluído o uso dun nodo de copia de seguridade e Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine converteuse na primeira solución de virtualización certificada .
Se estás interesado nos detalles, estaremos encantados de responder ás nosas preguntas nos comentarios.
Fonte: www.habr.com