Partiendo de los objetivos principales de reducir la complejidad de los sistemas y de ser más “tolerantes” (ser capaz de recuperarse mejor, en definitiva) a los fallos humanos, uno de los principios básicos de la Arquitectura Lambda es diseñar el sistema de datos siguiendo la aproximación de “datos inmutables”: al no tener que preocuparnos tanto por el crecimiento de la base de datos (gracias a los sistemas Big Data), podemos prescindir de tener que modificar los datos almacenados a medida que se generan nuevos y apostar simplemente por almacenar todos los datos “en crudo” a medida que se generan. Usando el ejemplo del conteo de visitas a las páginas de un sitio web, estaríamos simplemente añadiendo nuevos datos que reflejan una nueva visita, pero no estaríamos modificando (incrementando) ninguna cuenta de visitas acumuladas. Esto nos permite simplificar el sistema y de hecho tolerar mejor los fallos, ya que tener guardados todos los datos “básicos” facilita la regeneración de los datos elaborados ante un error.
Dado que recorrer todos esos datos en crudo cada vez que queramos hacer una consulta sería demasiado costoso, la capa batch (batch layer) de la arquitectura es la que se encarga de ir precalculando en diferido aquellas operaciones que generan datos elaborados (batch views). Por ejemplo, una herramienta como Apache Hadoop sería un candidato adecuado para esta labor. De esa manera se irán generando y actualizando periódicamente diferentes “vistas batch”, cada una de ellas diseñada para responder a diferentes necesidades de consulta. Sobre esta capa, la capa de servicio (serving layer) consistiría en la base de datos distribuida encargada de hacer accesibles de manera eficiente esas vistas batch generadas previamente en la capa batch, de manera que las consultas a esas vistas se puedan resolver con tiempos bajos de respuesta.
El único cabo suelto que nos queda por atar es que, con las capas anteriores, conseguimos un tiempo bajo de respuesta pero no de actualización de los datos para poder responder con información “en tiempo real”, ya que los datos se van actualizando en bloque a medida que la capa batch completa sus procesados periódicos. Aquí es donde la capa de velocidad (speed layer) entra en juego para no perder las actualizaciones que se han ido generando en tiempo real mientras se estaban preparando nuevas vistas batch. La capa de velocidad realiza un procesamiento incremental de los datos que va recibiendo en tiempo real (pero sólo de los más recientes, y únicamente en tanto en cuanto no hayan sido ya incorporados en las vistas batch). De esa manera obtendremos un resultado completo combinando (a) la respuesta de la capa de servicio con las vistas batch (que se habrán generado con todos los datos recibidos en el sistema desde su inicio hasta el momento X en el que la capa batch terminó su último procesado) y (b) la respuesta de las vistas en tiempo real suministradas por la capa de velocidad (generadas de manera incremental con los datos recibidos desde dicho momento X hasta el momento actual).
Dado que recorrer todos esos datos en crudo cada vez que queramos hacer una consulta sería demasiado costoso, la capa batch (batch layer) de la arquitectura es la que se encarga de ir precalculando en diferido aquellas operaciones que generan datos elaborados (batch views). Por ejemplo, una herramienta como Apache Hadoop sería un candidato adecuado para esta labor. De esa manera se irán generando y actualizando periódicamente diferentes “vistas batch”, cada una de ellas diseñada para responder a diferentes necesidades de consulta. Sobre esta capa, la capa de servicio (serving layer) consistiría en la base de datos distribuida encargada de hacer accesibles de manera eficiente esas vistas batch generadas previamente en la capa batch, de manera que las consultas a esas vistas se puedan resolver con tiempos bajos de respuesta.
El único cabo suelto que nos queda por atar es que, con las capas anteriores, conseguimos un tiempo bajo de respuesta pero no de actualización de los datos para poder responder con información “en tiempo real”, ya que los datos se van actualizando en bloque a medida que la capa batch completa sus procesados periódicos. Aquí es donde la capa de velocidad (speed layer) entra en juego para no perder las actualizaciones que se han ido generando en tiempo real mientras se estaban preparando nuevas vistas batch. La capa de velocidad realiza un procesamiento incremental de los datos que va recibiendo en tiempo real (pero sólo de los más recientes, y únicamente en tanto en cuanto no hayan sido ya incorporados en las vistas batch). De esa manera obtendremos un resultado completo combinando (a) la respuesta de la capa de servicio con las vistas batch (que se habrán generado con todos los datos recibidos en el sistema desde su inicio hasta el momento X en el que la capa batch terminó su último procesado) y (b) la respuesta de las vistas en tiempo real suministradas por la capa de velocidad (generadas de manera incremental con los datos recibidos desde dicho momento X hasta el momento actual).
No hay comentarios:
Publicar un comentario