Por qué Big Data necesita InfiniBand para seguir evolucionando - Calendae | Informática, Electrónica, CMS, Ciberseguridad

Por qué Big Data necesita InfiniBand para seguir evolucionando

Hola otra vez. Te escribe Simón Sánchez y esta vez vamos a hablar sobre Por qué Big Data necesita InfiniBand para seguir evolucionando

Es cada vez más un mundo de Big Data en el que vivimos. En caso de que haya vivido bajo una roca y necesite una prueba de ello, un minorista importante puede usar cantidades inimaginables de puntos de datos para predecir el embarazo de una adolescente fuera de Minneapolis antes de que tenga la oportunidad de decírselo a su familia. Este es solo un ejemplo, pero hay muchos otros que sugieren la idea de que la extracción de grandes volúmenes de datos puede descubrir pepitas de oro de proporciones utilizables (aunque a veces vuelven loca a la gente, por ejemplo, el padre de esa chica).

Todavía estamos en los albores de esta era de Big Data y, como está demostrando el mercado, el procesamiento de datos de talla única ya no es adecuado. Para dar el siguiente paso en esta evolución, el software especializado en big data puede mejorar no solo utilizando la computación en la nube, sino también utilizando una infraestructura de red especializada, InfiniBand, de la comunidad de supercomputadoras. Sin embargo, antes de comprender por qué, es necesario comprender la historia de cómo llegamos a este mundo de Big Data en primer lugar.

¿Cómo llegamos aquí? El nacimiento de la base de datos relacional

1970 no es solo el año de Unix Epoch, también es el año en que se escribió el abuelo de todos los documentos de bases de datos relacionales (RDB). El investigador de IBM EF Codd escribió «Un modelo relacional para grandes bases de datos compartidas«Para la revista ACM Communications en junio de ese año, y durante décadas se convirtió en el trabajo definitorio sobre diseños de datos. El modelo de Codd se perfeccionaría durante los próximos 40 años, pero lo que propuso se convirtió en un conjunto de herramientas genéricas para estructurar y manipular datos que se han utilizado para todo, desde la gestión de activos bancarios hasta el almacenamiento de recetas de alimentos.

Este software de análisis de datos de propósito general también funcionó excepcionalmente bien en hardware de procesamiento de propósito general. Los dos se llevaban muy bien, de hecho, ya que todo lo que realmente necesitabas era un disco lo suficientemente grande para manejar datos estructurados y suficiente CPU y RAM para ejecutar consultas. De hecho, algunos fabricantes de hardware como Hewlett-Packard regalarían software de base de datos al comprar el hardware para ejecutarlo. Especialmente para las empresas, la base de datos relacional fue la aplicación principal del negocio de hardware del centro de datos.

En este punto, todo el mundo estaba felizmente resolviendo problemas y ganando dinero. Entonces sucedió algo que lo cambió todo e interrumpió por completo este ecosistema para siempre. Se llamó Google.

Entonces pasó Google

Durante la administración de Nixon, copiar todo Internet no fue un problema difícil dado su pequeño tamaño. Pero ese no fue el caso a fines de la década de 1990, cuando la primera ola de motores de búsqueda como Lycos y Alta Vista supuestamente resolvió el problema de encontrar información Online. Poco después, sucedió Google y detuvo no solo la industria de búsqueda Online, sino también el procesamiento de datos.

Resulta que si siempre puede conservar una copia del Internet moderno, puede hacer cosas increíbles para determinar la relevancia y, por lo tanto, obtener mejores resultados de búsqueda. Sin embargo, un RDB tradicional no se puede utilizar para abordar este problema por varias razones. En primer lugar, para resolver este problema es necesario almacenar una gran cantidad de datos. Tanto es así que resulta poco práctico depender únicamente del escalado vertical al agregar más disco / CPU / RAM a un sistema y un RDB no escala muy bien horizontalmente. Agregar más máquinas a una RDB no mejora su rendimiento ni su capacidad para almacenar más datos. Ese matrimonio disco / CPU / RAM ha existido durante 40 años y no es fácil separarse.

Además, a medida que aumenta el tamaño del conjunto de datos en un RDB, la velocidad de las consultas generalmente disminuye. Para una empresa de servicios financieros que cuestiona las tendencias del precio de las acciones, esto puede ser aceptable, ya que esto afecta el tiempo de un puñado de analistas que pueden hacer otra cosa mientras el procesamiento está en progreso. Pero para una empresa de búsqueda en Internet que busca proporcionar respuestas de menos de 3 segundos a millones de clientes a la vez, simplemente no volará.

Finalmente, dados los grandes volúmenes de datos y la velocidad de consulta requerida para las búsquedas en Internet, la necesidad de redundancia de datos está implícita ya que los datos son necesarios en todo momento. Como tal, el modelo simple maestro-esclavo empleado por la mayoría de las distribuciones de RDB durante las últimas cuatro décadas es mucho menos a prueba de balas de lo que se necesita cuando se intenta copiar de manera consistente todo Internet. Un espejo grande simplemente no lo cortará.

Sistemas de archivos distribuidos y mapeo / reducción de cambios

Si el documento RDB fundamental de Codd tuviera nietos, serían un par de documentos publicados por Google que describen cómo resolvieron su problema de datos. Publicado en 2003, «El sistema de archivos de Google«Por Sanjay Ghermawat, Howard Gobioff y Shun-tak Leung describieron cómo una nueva forma de almacenar datos en muchas, muchas máquinas diferentes ha proporcionado un mecanismo para manejar grandes volúmenes de una manera mucho más barata que la RDB tradicional.

El documento de seguimiento de 2004 titulado «MapReduce: procesamiento de datos simplificado en grandes clústeresDi Ghermawat y Jeffrey Dean también revelaron que Google consulta su gran conjunto de datos distribuidos dividiendo el problema en partes más pequeñas, enviando esas partes más pequeñas a los nodos del sistema distribuido (el paso Mapa) y finalmente reuniendo los resultados de la solución. más pequeño (el paso Contraer) en un todo.

Juntos, estos dos documentos han creado un renacimiento en el procesamiento de datos. Aunque los RDB todavía tienen su lugar, ya no son la única solución a todos los problemas en el mundo del procesamiento de datos. Para problemas que involucran grandes volúmenes de datos en particular, las soluciones derivadas de estos dos documentos han surgido durante la última década para ofrecer a los desarrolladores y arquitectos muchas más opciones de las que tenían en el mundo exclusivo de RDB que existía anteriormente.

Hadoop democratiza Big Data; Ahora, ¿dónde lo vas a ejecutar?

El siguiente paso lógico en esta evolución hacia una era de programación de código abierto fue que alguien tomara las teorías establecidas en estos documentos de Google y las convirtiera en una realidad que todos pudieran usar. Esto es exactamente lo que hicieron Doug Cutting y Michael J. Cafarella, y llamaron al resultado Hadoop. Con Hadoop, ahora todos tenían el software para administrar grandes volúmenes de datos y realizar consultas sofisticadas. Sin embargo, lo que no todos podían permitirse era el hardware para ejecutarlo.

Ingrese a la computación en la nube, específicamente la infraestructura como servicio (IaaS). Inventado principalmente por Amazon con su oferta de servicios web de Amazon, cualquiera podía alquilar los 100, si no miles, de nodos de cómputo necesarios para ejecutar grandes trabajos de Hadoop en lugar de comprar las máquinas físicas necesarias para el trabajo. Combine esta idea con software de orquestación de personas como OpsCode o Puppet Labs y podrá automatizar la creación de su hardware virtualizado, la instalación y configuración del software Hadoop y la carga de grandes volúmenes de datos para minimizar los costos de ejecución. de estas consultas.

Una vez más, todos resuelven felizmente los problemas y ganan dinero. Pero no hemos terminado. Hay otro paso en esta evolución y está sucediendo ahora.

InfiniBand: haciendo que Hadoop sea más rápido y económico

El procesamiento de Hadoop y otras consultas de Big Data en IaaS produce resultados, pero lentamente. Esta combinación es elogiada por las respuestas que puede encontrar, pero a costa de reducir la velocidad. Hemos visto una revolución en el procesamiento de datos provocada por enfoques de software diferentes a los introducidos por primera vez en la década de 1970. Los clústeres de Hadoop con mejor rendimiento, con todo el tráfico de red que producen en los pases Map y Shrink, se pueden encontrar adoptando un enfoque similar con una infraestructura de red diferente.

Ethernet, la tecnología de infraestructura de red más utilizada en la actualidad, ha seguido un camino similar al de las RDB. Inventado en 1980, Ethernet utiliza una estructura jerárquica de subredes para unir computadoras en una red. Es tan común que, como hace 10 años, la mayoría de las personas no creen que puedan elegir algo diferente.

El problema de rendimiento con Ethernet radica en su estructura básica. Con las jerarquías de subred vinculadas al enrutador, los paquetes de red tienen exactamente una ruta que pueden atravesar entre dos puntos cualesquiera de la red. Puede aumentar ligeramente el tamaño de la tubería entre estos dos puntos, pero básicamente todavía tiene la única ruta.

InfiniBand, que nació en la comunidad de supercomputadoras durante el siglo XXI, utiliza en cambio un sistema de cuadrícula que permite múltiples rutas para que los paquetes de red atraviesen dos puntos. El enrutamiento inteligente que sabe qué parte de la red está ocupada actualmente, similar a los informes de tráfico de automóviles que se encuentran en las aplicaciones de mapas de teléfonos inteligentes, mantiene el flujo de tráfico en todo el sistema funcionando de manera óptima. Una red típica basada en Ethernet funciona a 1 Gigabit por segundo (Gb / s) y una rápida a 10 Gb / s. Una red InfiniBand de doble canal funciona a 80 Gb / s, lo que la convierte en un gran complemento para los pasos de mapeo / escalado en un clúster Hadoop.

Hemos visto cómo una revolución del software que nos permitió superar el uso exclusivo de RDB ha permitido una minería de datos que antes era inimaginable. El código abierto y la computación en la nube han hecho que los macrodatos sean accesibles a una audiencia más amplia. Se puede lograr una velocidad más rápida, que se traduce en tiempos de consulta más cortos y ahorros de tiempo necesarios para alquilar espacio IaaS, utilizando proveedores de nube pública que ofrecen InfiniBand. Este es el siguiente paso en la revolución del procesamiento de datos y la próxima generación de servicios de Cloud Computing (también conocido como Cloud Computing 2.0) trae InfiniBand a la nube pública. BeneficioLadrillos es el primer proveedor que ofrece un rendimiento similar al de una supercomputación a la nube pública a un precio asequible. Los datos se están democratizando y ahora también lo está la informática de alto rendimiento.

Recuerda compartir en tus redes sociales para que tus amigos lo disfruten

??? ? ? ???

Comparte