El mercado de computación distribuida y big data, según , está creciendo a un 18-19% por año. Esto significa que la cuestión de elegir software para estos fines sigue siendo relevante. En esta publicación, comenzaremos explicando por qué necesitamos computación distribuida, profundizaremos en la elección del software, hablaremos sobre el uso de Hadoop con Cloudera y, finalmente, hablaremos sobre la elección del hardware y cómo afecta el rendimiento. En maneras diferentes.
¿Por qué necesitamos computación distribuida en los negocios ordinarios? Todo es simple y complicado al mismo tiempo. Simple: porque en la mayoría de los casos realizamos cálculos relativamente simples por unidad de información. Difícil, porque hay mucha información de este tipo. Tantos. En consecuencia, uno tiene que . Por lo tanto, los casos de uso son bastante universales: los cálculos se pueden aplicar donde sea necesario para tener en cuenta una gran cantidad de métricas en una matriz de datos aún mayor.
Un ejemplo reciente: Dodo Pizza basado en un análisis de la base de pedidos de los clientes, que al elegir una pizza con ingredientes arbitrarios, los usuarios generalmente operan con solo seis conjuntos básicos de ingredientes más un par de ingredientes aleatorios. En consecuencia, la pizzería ajustó las compras. Además, pudo recomendar mejor los productos adicionales ofrecidos en la etapa de pedido a los usuarios, lo que incrementó las ganancias.
Otro ejemplo: Merchandising permitió a H&M reducir el surtido en tiendas individuales en un 40%, manteniendo el nivel de ventas. Esto se logró excluyendo las posiciones de venta deficientes y se tuvo en cuenta la estacionalidad en los cálculos.
Selección de herramienta
El estándar de la industria para este tipo de computación es Hadoop. ¿Por qué? Porque Hadoop es un marco excelente y bien documentado (el mismo Habr da muchos artículos detallados sobre este tema), que se acompaña de todo un conjunto de utilidades y bibliotecas. Puede enviar grandes conjuntos de datos estructurados y no estructurados como entrada, y el propio sistema los distribuirá entre la potencia informática. Además, estas mismas capacidades se pueden aumentar o desactivar en cualquier momento: esa misma escalabilidad horizontal en acción.
En 2017, la influyente consultora Gartner que Hadoop pronto quedará obsoleto. La razón es bastante banal: los analistas creen que las empresas migrarán masivamente a la nube, ya que allí podrán pagar en función del uso de la potencia informática. El segundo factor importante supuestamente capaz de "enterrar" a Hadoop es la velocidad de trabajo. Porque opciones como Apache Spark o Google Cloud DataFlow son más rápidas que el Hadoop subyacente de MapReduce.
Hadoop se apoya en varios pilares, los más destacables son las tecnologías MapReduce (un sistema de distribución de datos para los cálculos entre servidores) y el sistema de archivos HDFS. Este último está diseñado específicamente para almacenar información distribuida entre los nodos del clúster: cada bloque de un tamaño fijo se puede colocar en varios nodos y, gracias a la replicación, el sistema es resistente a las fallas de los nodos individuales. En lugar de una tabla de archivos, se utiliza un servidor especial llamado NameNode.
La siguiente ilustración muestra cómo funciona MapReduce. En la primera etapa, los datos se dividen de acuerdo con un determinado atributo, en la segunda etapa se distribuyen por potencia de cálculo, en la tercera etapa se realiza el cálculo.
MapReduce fue creado originalmente por Google para las necesidades de su búsqueda. Entonces MapReduce entró en código libre y Apache se hizo cargo del proyecto. Bueno, Google migró gradualmente a otras soluciones. Un matiz interesante: por el momento, Google tiene un proyecto llamado Google Cloud Dataflow, posicionado como el siguiente paso después de Hadoop, como su reemplazo rápido.
Una mirada más cercana muestra que Google Cloud Dataflow se basa en una variación de Apache Beam, mientras que Apache Beam incluye el marco Apache Spark bien documentado, lo que nos permite hablar de casi la misma velocidad de ejecución de la solución. Bueno, Apache Spark funciona bien en el sistema de archivos HDFS, lo que le permite implementarlo en servidores Hadoop.
Agregue aquí el volumen de documentación y soluciones preparadas para Hadoop y Spark contra Google Cloud Dataflow, y la elección de la herramienta se vuelve obvia. Además, los ingenieros pueden decidir por sí mismos qué código, bajo Hadoop o Spark, ejecutarán, centrándose en la tarea, la experiencia y las calificaciones.
Servidor local o en la nube
La tendencia hacia la transición general a la nube ha dado lugar incluso a un término tan interesante como Hadoop-as-a-service. En tal escenario, la administración de los servidores conectados se ha vuelto muy importante. Porque, por desgracia, a pesar de su popularidad, Hadoop puro es una herramienta bastante difícil de configurar, ya que hay que hacer mucho a mano. Por ejemplo, puede configurar servidores individualmente, monitorear su rendimiento y ajustar muchos parámetros. En general, si trabajas para un aficionado, existe una gran posibilidad de equivocarte en alguna parte o perderte algo.
Por lo tanto, varias distribuciones se han vuelto muy populares, que inicialmente están equipadas con herramientas convenientes de implementación y administración. Una de las distribuciones más populares que admite Spark y facilita las cosas es Cloudera. Tiene versiones pagas y gratuitas, y en esta última, todas las funciones principales están disponibles y sin limitar la cantidad de nodos.
Durante la configuración, Cloudera Manager se conectará mediante SSH a sus servidores. Un punto interesante: al instalar, es mejor especificar que lo lleve a cabo el llamado paquetes: paquetes especiales, cada uno de los cuales contiene todos los componentes necesarios configurados para trabajar entre sí. De hecho, esta es una versión tan mejorada del administrador de paquetes.
Después de la instalación, obtenemos una consola de administración de clústeres, donde puede ver la telemetría de los clústeres, los servicios instalados, además puede agregar/eliminar recursos y editar la configuración del clúster.
Como resultado, el corte de ese cohete aparece frente a ti, lo que te llevará al brillante futuro de BigData. Pero antes de decir "vamos", avancemos rápidamente bajo el capó.
Requisitos de hardware
En su sitio web, Cloudera menciona diferentes configuraciones posibles. Los principios generales por los que se construyen se muestran en la ilustración:
MapReduce puede desdibujar esta imagen optimista. Mirando de nuevo el diagrama de la sección anterior, queda claro que en casi todos los casos, un trabajo de MapReduce puede encontrar un cuello de botella al leer datos del disco o de la red. Esto también se indica en el blog de Cloudera. Como resultado, para cualquier cálculo rápido, incluso a través de Spark, que a menudo se usa para cálculos en tiempo real, la velocidad de E/S es muy importante. Por lo tanto, al usar Hadoop, es muy importante que las máquinas equilibradas y rápidas entren en el clúster, lo que, por decirlo suavemente, no siempre se proporciona en la infraestructura de la nube.
El equilibrio en la distribución de la carga se logra mediante el uso de la virtualización Openstack en servidores con potentes CPU multinúcleo. A los nodos de datos se les asignan sus propios recursos de procesador y ciertos discos. En nuestra decisión Motor de lago de datos Codex de Atos Se logra una amplia virtualización, por lo que ganamos tanto en rendimiento (se minimiza el impacto de la infraestructura de red) como en TCO (se eliminan servidores físicos adicionales).
En el caso de utilizar servidores BullSequana S200, conseguimos una carga muy uniforme, desprovista de algunos de los cuellos de botella. La configuración mínima incluye 3 servidores BullSequana S200, cada uno con dos JBOD, además de S200 adicionales que contienen cuatro nodos de datos conectados opcionalmente. Aquí hay un ejemplo de carga en una prueba de TeraGen:
Las pruebas con diferentes volúmenes de datos y valores de replicación muestran los mismos resultados en términos de distribución de carga entre los nodos del clúster. A continuación se muestra un gráfico de la distribución del acceso al disco por pruebas de rendimiento.
Los cálculos se basan en una configuración mínima de 3 servidores BullSequana S200. Incluye 9 nodos de datos y 3 nodos maestros, así como máquinas virtuales reservadas en caso de despliegue de protección basada en OpenStack Virtualization. Resultado de la prueba de TeraSort: el tamaño de bloque de 512 MB de un factor de replicación de tres con cifrado es de 23,1 minutos.
¿Cómo se puede ampliar el sistema? Hay varios tipos de extensiones disponibles para Data Lake Engine:
- Nodos de datos: por cada 40 TB de espacio utilizable
- Nodos analíticos con la capacidad de instalar una GPU
- Otras opciones según las necesidades del negocio (por ejemplo, si necesita Kafka y similares)
El complejo Atos Codex Data Lake Engine incluye tanto los propios servidores como el software preinstalado, incluido el kit Cloudera con licencia; Hadoop mismo, OpenStack con máquinas virtuales basadas en el kernel de RedHat Enterprise Linux, replicación de datos y sistemas de copia de seguridad (incluido el uso de un nodo de copia de seguridad y Cloudera BDR - Copia de seguridad y recuperación ante desastres). Atos Codex Data Lake Engine es la primera solución de virtualización certificada .
Si está interesado en los detalles, estaremos encantados de responder a nuestras preguntas en los comentarios.
Fuente: habr.com