Como ya he explicado en algún post de esta serie una de las limitaciones que han sufrido los analistas de datos en el pasado ha sido la de estar sujetos a la capacidad de procesamiento de sus máquinas. Ni siquiera la famosa ley de Moore ha sido capaz de resolver este problema. Por muy potente que sea el ordenador al que tengan acceso su capacidad de procesamiento siempre es limitada y su escalabilidad prácticamente nula.
En este artículo vamos a estar hablando continuamente del Backend y del Frontend, dos conceptos que nos llevan acompañando desde el comienzo de los tiempos de Internet. Consultando en la Red hay diversidad de opiniones y me atrevería a decir que cierta indefinición. Tal y como yo los entiendo el término Backend hace referencia al lado del servidor mientras que el término frontend se refiere al lado cliente, la parte con la que interactúa el usuario.
En el mundo web el backend sería todo lo que tiene que ver con monitorizar y gestionar el funcionamiento de los servidores, las actualizaciones del software , la gestión de las bases de datos… todo lo que el usuario no puede ver cuando navega internet desde su navegador. Precisamente todo lo que el usuario ve en la pantalla de su navegador, lo que define la experiencia del usuario, es el territorio del frontend. Antes de abordar el mundo de Hadoop creo que es interesante ir un paso anterior y dedicarle un post al mundo de los sistemas distribuidos, así que allá vamos.
Los Sistemas Distribuidos
La primera ocasión en la que escuche el concepto detrás de los sistemas distribuidos fue en los inicios de Internet a través del proyecto SETI@Home, una iniciativa de la californiana Universidad de Berkely. SETI@Home era un proyecto que utilizaba la capacidad ociosa de los ordenadores personales de aquellos usuarios que se ofrecieran como voluntarios para colaborar a un proyecto que buscaba vida inteligente fuera de nuestro planeta.
Al inicio del programa más de un millón de usuarios cedieron tiempo de sus procesadores a la búsqueda de patrones en los datos que SETI@Home obtenía de los radio telescopios, probablemente algo tendría que ver el éxito de la serie Expediente X que en aquel momento causaba sensación. La manera en que funcionaba SETI@Home era a través de descomponer los problemas en piezas más pequeñas que denominabas unidades de trabajo (work units) que envíaban a las computadoras de los voluntarios. Aunque hay diferencias sustanciales con los modelos distribuidos actuales este fue mi primer contacto con el concepto de un sistema distribuido y me pareció fascinante.
La filosofía principal de un sistema distribuido se basa en la capacidad de dividir el trabajo, por grande que sea, entre multitud de máquinas distintas. Y cuando hablamos de multitud es bastante habitual manejar cifras de miles e incluso cientos de miles de máquinas para dar servicio a millones de usuarios y ser capaces de procesar miles de millones de consultas a la vez.
Una sencilla analogía que ayuda a entender este concepto de manera intuitiva es la que me llevo a elegir la foto de este post. Supongamos que queremos averiguar en cuantas ocasiones se menciona a Dulcinea del Toboso en la obra maestra de Miguel de Cervantes. Una manera de afrontar esta tarea es empezar a leer el libro de la página uno a la 1.424 (si, lo he mirado, son 1.424 páginas exactamente en la edición que he consultado) e ir contando cada vez que vemos una mención a la señora por la que bebía los vientos Don Quijote. La otra sería coger a 10 personas, por ejemplo, y darle a cada uno de ellos 143 páginas. Cada uno sólo leería su parte y contaría las veces que aparece allí una mención. Es evidente que este método permitirá realizar la tarea de manera mucho más rápida que el primero simplemente distribuyendo la tarea entre más lectores.
Por lo tanto una de las primeras claves en un sistema distribuido es el tamaño. Si en lugar de contar con 10 personas contamos con 100 reducimos el tiempo de respuesta a una décima parte. Pero no podemos dejar de lado el rendimiento, la velocidad de respuesta, un concepto que se denomina latencia. No podemos hacer que cada uno de los lectores lea más rápido que su capacidad de lectura rápida pero si añadimos más personas reducimos proporcionalmente el tiempo que nos llevará realizar la tarea. Por cierto que la media de lectura de una persona normal está entre 200 y 300 palabras por minuto, si lees por encima de 400 eres un portento.
Cuando hablamos de un sistema que coordina las capacidades distribuidas de miles de máquinas ubicadas en diferentes data centers es fundamental que el sistema disponga de mecanismos de diagnóstico y control del estado de sus componentes. A la capacidad de examinar el estado interno de un sistema se le denomina introspección y es fundamental en la gestión de este tipo de infraestructuras.
Para realizar el proceso de introspección los sistemas distribuidos generan continuamente logs sobre lo que está pasando en el sistema. Generalmente estos logs se generan a dos niveles: a alto nivel (high-level) por ejemplo se guardaría un código de estado (ok/ko) cada vez que un usuario hace una compra. A más bajo nivel (low-level) se pueden almacenar parámetros específicos de cada llamada. Los logs del sistema normalmente se guardan en un repositorio centralizado desde el que se pueden realizar los procesos automáticos para la gestión del sistema y la distribución de las cargas de trabajo.
Composición de los Sistemas Distribuidos
Los sistemas distribuidos suelen estár compuestos de varios subsistemas más pequeños. Según he leído estas son las tres composiciones que se usan con más frecuencia:
Balanceador de carga con múltiples replicas del backend
En este caso las peticiones le llegarían al balanceador de carga, un servidor que se encarga de elegir a qué backend debe distribuir la carga. Una vez que el backend procesa la respuesta la devuelve al balanceador para que éste a su vez conteste al sistema que realizó la petición original.
Los backends son denominados réplicas sencillamente porque son clones unos del otros. Cualquier petición a uno de ellos debería devolver exactamente la misma respuesta.
Lógicamente el balanceador tiene que conocer el estado de los backends en cada momento para poder elegir cuál es el backend al que dirigir la petición. Hay varios métodos para distribuir la carga uno puede ser por simple rotación (round-robin) mientras que otros utilizan métodos más complejos y pueden distribuir la carga en función de la disponibilidad, el que mayor disponibilidad tenga recibirá la petición (least loaded)
Un servidor con múltiples Backends
En este caso cuando el servidor recibe la petición envías varias consultas a distintos backends, los backends procesan la consulta en paralelo y devuelven cada uno su respuesta al servidor. Cuando éste recibe las respuestas las combina para ofrecer una respuesta al sistema que originó la petición. Este es el método que utilizan los buscadores por ejemplo.
Al concepto de descomponer una consulta (query) en múltiples consultas, una para cada backend, se le denomina fan out.
Árbol de servidores
Varios servidores trabajan cooperativamente con uno que hace del tronco del árbol. Este patrón se usa especialmente en el caso de conjuntos de datos muy grandes o corpus. Cómo el corpus es demasiado grande para poder estar alojado en una sóla máquina, como en el caso del balanceador, cada hoja del árbol va a guardar una fracción del total.
En este caso una petición viaja por cada rama hasta llegar a las hojas, los servidores en los extremos del árbol, estos devuelven sus resultados a sus padres, el siguiente nivel en la jerarquía, que ordenan y filtran los resultados y envían sus respuestas al servidor troncal que combina todos los resultados para construir la respuesta final.
Un ejemplo podría ser como Google construye los resultados de una página en su modelo de Universal Search. Distintas ramas del árbol procesan las búsquedas de resultados para las imágenes, las noticias, los resultados orgánicos (enlaces a páginas) y los resultados de pago (anuncios de Adwords). Finalmente cada rama devuelve sus resultados al tronco que se las arregla para componer la página a mostrar al usuario. El sistema tiene capacidad de devolver un resultado incluso en el caso de que una de las ramas no fuese capaz de devolver su parte del trabajo.
Las actualizaciones de información y el Principio CAP
Cuando hablamos de un sistema distribuido siempre tenemos que afrontar el reto de las actualizaciones del sistema, es decir, cuando hay una actualización en uno de los nodos qué es lo que ocurre y como se propaga por el resto de los nodos. A este concepto de información que está en flujo en el sistema se le conoce con el término State. En una consulta a una base de datos siempre vamos a querer que nos devuelva una respuesta y, a ser posible, con la última información disponible. Para que eso ocurra hay tres principios que tenemos que tener en cuenta:
Consistencia
Se refiere a que todos los nodos pueden ver exactamente los mismos datos en el mismo momento. Esto significa que si hay una actualización de los datos ésta actualización debería estar disponible en cualquier punto del sistema desde cualquiera de las réplicas. Dicho de otra forma en cada consulta de los datos (lectura) siempre tendríamos que tener acceso a la última actualización de los datos (escritura).
Disponibilidad
Es la capacidad del sistema para ofrecer una respuesta a cada consulta en un tiempo razonable incluso aunque la respuesta sea un fallo, pero siempre debe proporcionar feedback.
Tolerancia a la Partición
Significa la capacidad del sistema para seguir operando en el caso de la perdida de un mensaje o el fallo de uno de los nodos que forman parte del sistema.
El Principio CAP
El principio CAP, convertido en teorema por Gilbert y Lynch en 2002, recibe su nombre precisamente de la combinación de estos tres elementos en su versión inglesa: Consistencia (Consistency), Disponibilidad (Availability) y tolerancia a la partición (Partition-tolerance). Lo que viene a decir el teorema es que sólo podemos conseguir dos de los tres elementos pero nunca los tres a la vez.
El siguiente gráfico muestra cual es la combinación en la que están situadas cada una de las soluciones más conocidas del mercado
Vaya!!! información muy valiosa la de este articulo, sin duda alguna el Big Data está presente en nuestro día a día e integrado actualmente, abarcando casi que desde las aplicaciones que utilizamos en nuestro Smartphone, hasta las herramientas utilizadas por muchas empresas para el desarrollo de su actividad, las aplicaciones del Big Data está transformando el mundo que conocemos a pasos agigantados y la forma de cambiar nuestra forma de vida, el Big Data en Marketing es fundamental hoy en día gracias a las ventajas y utilidad que ofrece para lograr el éxito en una estrategia de muchas agencias de marketing online. Incluso el uso del Big Data en Marketing para establecer los objetivos y alcanzar las metas, se ha convertido esencial en cualquier organización para el éxito, y esto es algo extraordinario para otras áreas de una empresa, como la productiva o la economía.