Arquitecturas Lambda

Posted on by moon

 

En un sistema analítico basado en un Business Intelligence (BI) tradicional, los datos suelen estar disponibles en el repositorio analítica con una latencia típicamente de 24 horas (aunque la frecuencia de las cargas de datos puede aumentarse de diaria a varias -pocas- veces por día).

Esto supone que los usuarios no disponen de los datos para su explotación en los sistemas analíticos hasta que la carga de datos ha finalizado.

Existen escenarios en los que los usuarios deben tomar decisiones con una latencia cercana a tiempo real. En estos casos, una carga de datos tradicional no es capaz de dar respuesta a los requerimientos de explotación de la información.

Carga de datos tipo ETL

Una carga de datos en un BI tradicional es del tipo ETL (Extract – Transformation – Load). Esto significa que las transformaciones de datos se realizan durante la carga de datos para finalmente dejar los resultados en las tablas que los usuarios utilizarán para la explotación de datos.

Las transformaciones a realizar incluyen, entre otras, las siguientes:

  • Control de calidad de datos (mediante reglas de dominio y de negocio)
  • Estandardización de valores y formatos
  • Cambio del modelo de datos
  • Enriquecimiento de datos
  • Creación de agregaciones

Toda transformación requiere una inversión de recursos y de tiempo. Este último factor (el tiempo de carga) es el más determinante a la hora de decidir el diseño de las cargas de datos.

Límite en la frecuencia de las cargas de datos

Una carga de datos tradicional tiene una frecuencia establecida. El escenario más habitual es el de la carga diaria.

En ocasiones, los usuarios requieren de información actualizada con una latencia inferior a las 24 horas que proporciona la carga diaria. En este caso, es posible que los usuarios pidan que los datos se carguen con una frecuencia mayor.

Sin embargo, esto no siempre es posible. Y si lo es, el aumento de la frecuencia tiene un límite.

Las cargas de datos requieren tiempo para su ejecución. Durante ese periodo de tiempo, los datos disponibles pueden tener algún periodo donde muestren inconsistencias (e.g. Entre datos de detalle y agregados), a no ser que las cargas hayan sido diseñadas con este objetivo desde su inicio. Por tanto, la ejecución de una carga de datos en un periodo en el cual los usuarios pueden estar usando el sistema, podría dar lugar a inconsistencias en los datos.

Por otra parte, el consumo de recursos del sistema durante la carga de datos, podría restar recursos a la explotación de datos por parte de los usuarios. En otras palabras, las consultas de los usuarios se podrían ver afectadas negativamente por el hecho de cargar datos en ese mismo instante, lo cual provocaría un retraso en la obtención de respuestas desde el sistema analítico.

Es por eso que, si una carga de datos no ha sido diseñada inicialmente con miras a su ejecución en un entorno de disponibilidad continua de los datos, es un riesgo ejecutarla mientras los usuarios están utilizando la solución analítica. Además, la duración de la carga define un periodo durante el cual no deberíamos volver a lanzar la misma carga de datos para no entrar en conflictos de bloqueo o sobrescritura de resultados.

Por tanto, si bien es cierto que podemos aumentar la frecuencia de la carga de datos, si ésta no ha sido diseñada a tal efecto, el aumento de la frecuencia implica un riesgo adicional. El límite en la frecuencia está en el riesgo máximo asumible.

Una posible solución es la de definir ventanas de inactividad durante el día, durante las cuales el repositorio de datos no está disponible para consultas. Otra solución es el rediseño total de la carga de datos. Una tercera alternativa es la creación de micro cargas de datos que se ejecuten en paralelo a la carga de datos. Es lo que se denomina, arquitecturas Lambda.

Micro cargas de datos

Ante la necesidad de dar respuesta a los requerimientos de los usuarios que necesitan disponer de datos actualizados con una frecuencia superior a la de las cargas de datos, una solución es la creación de micro cargas de datos.

Estas micro cargas se caracterizan por lo siguiente:

  • Frecuencia elevada de ejecución
  • Bajo volumen de datos
  • Acceso rápido a los datos en origen
  • Mínima o nula transformación de los datos

Esto permite cargar los datos con un rendimiento muy alto en el sistema analítico, donde los usuarios podrán acceder a ellos.

Las micro cargas tienen algunas particularidades que es importante tener en cuenta a la hora de diseñarlas. Además, la aparición de micro cargas puede implicar cambios en la carga de datos existente. He aquí algunas preguntas a tener en cuenta:

  • ¿Los datos se cargarán en las tablas finales (utilizadas en la carga de datos diaria, por poner una frecuencia estándar) o en unas tablas específicas para esta segunda carga?
  • ¿Será una carga incremental o incremental a partir de la última carga diaria en todas las ejecuciones?
  • ¿Qué sucede con los datos previamente cargados cuando ejecutemos la siguiente carga diaria? ¿Sobrescribimos los datos o no los cargamos porque ya lo hemos hecho en las micro cargas?

Foto final: Arquitectura Lambda

La existencia de micro cargas en paralelo a una carga de datos es lo que se conoce como Arquitectura Lambda.

Los sistemas que usan este tipo de arquitecturas tienen un flujo periódico de datos a partir de una carga diaria (por ejemplo), y otro flujo de datos con una latencia mucho menor proveniente de una micro carga.

Conclusión

Cuando los usuarios requieren disponer de datos actualizados, las cargas de datos tradicionales de frecuencia diaria no permiten satisfacer esa necesidad.

Las cargas de datos, si han sido diseñadas a tal efecto, pueden ver incrementada su frecuencia, pero siempre con un límite que es función de la duración de la carga de datos.

En todo caso, hay que tener en cuenta el impacto en el sistema de la ejecución de cargas durante periodos en los que los datos sean explotados por los usuarios.

La creación de micro cargas de corta ejecución es la solución para complementar las cargas de datos tradicionales.

El escenario donde conviven estas dos cargas se denomina: Arquitectura Lambda.

Carga de datos en BI vs. Big Data

Posted on by moon

 

Uno de los componentes clave de todo sistema analítico es la carga de datos. Durante este proceso, los datos generados en los sistemas origen son cargados en el repositorio de datos analítico para su posterior análisis.

Existen grandes diferencias conceptuales entre como los sistemas de Business Intelligence (BI) y los basados en Big Data cargan los datos en el repositorio analítico. En este artículo veremos estas diferencias para tres tipos de arquitectura:

  • BI tradicional
  • Micro cargas (como componente de un sistema BI basado en una Arquitectura Lambda)
  • Big Data

Factores que afectan a la arquitectura de una solución analítica

La decisión sobre qué arquitectura debe ser utilizada en una solución analítica, depende de las 3 V’s de las que hablamos en este artículo.

Por tanto, el volumen de datos generados en los sistemas origen, la variedad de datos y la latencia máxima para la explotación efectiva por parte de los usuarios, son los factores clave para decidir la arquitectura de una solución analítica y, por tanto, de la carga de datos.

Teniendo en cuenta estas tres variables, obtenemos la siguiente tabla, que nos muestra la arquitectura a utilizar en función de las 3 V’s:

Proceso de los datos: Batch vs. Streaming

La carga de datos puede realizarse, por lo que se refiere a cómo se procesan los datos, de dos maneras diferentes:

  • Batch: Los datos se acumulan en el sistema origen. En el momento de iniciarse la carga, estos datos acumulados se procesan a la vez.
  • Streaming: A medida que los datos son generados por el sistema origen, éstos son enviados para su proceso. El volumen de datos procesados depende de la frecuencia de generación de éstos. Este método de proceso de datos permite detectar patrones en los datos en tiempo real. Un ejemplo es el de la detección de fraude en compras online.

Para las tres arquitecturas anteriores, los tipos de proceso de datos que encontramos son:

ETL vs. ELT

Una carga de datos no es únicamente un movimiento de datos. Ésta suele ir acompañada de una transformación de los datos, ya sea en el modelo de datos (cómo se almacenan), en el valor de éstos (los datos pueden cambiar debido a estandardizaciones de valores, por ejemplo), etc.

Esta transformación requiere del uso de recursos del sistema y de tiempo. El objetivo a la hora de diseñar una carga de datos es que tanto el uso de recursos del sistema como del tiempo no supere el máximo establecido en cada caso.

En el caso de disponer de una ventana de tiempo limitada para la ejecución de una carga de datos, lo lógico es minimizar esas transformaciones, para aligerar el trabajo a realizar durante el proceso de los datos. Esta situación es extensible al escenario en el cual debemos procesar grandes cantidades de datos, ya que podríamos alargar el proceso más allá de la ventana de tiempo disponible.

Existen dos tipos de cargas de datos en función de cuándo se realiza la transformación de los datos:

  • ETL (Extraction – Transformation – Load): La transformación de los datos se realiza antes de la carga en el repositorio de datos. En este caso, al acabar la carga, los datos están disponibles en su estado final, listos para ser explotados por los usuarios finales.
  • ELT (Extraction – Load – Transformation): No existe transformación de datos (o en todo caso es mínima) antes de la carga en el repositorio de datos. Posteriormente, los datos son transformados mediante procesos de refinamiento de éstos. En este caso, los datos precisan de esa transformación posterior para poder ser explotados por los usuarios finales.

Para las tres arquitecturas anteriores, los tipos de carga de datos que encontramos según en qué momento se realiza la transformación de los datos son:

Es decir, en una solución Big Data, la transformación de los datos se realizará una vez cargados los datos en bruto en el repositorio de datos. Esta transformación se llevará a cabo mediante procesos de refinamiento de los datos, que irán añadiendo valor a éstos. Estos procesos pueden ser de calidad de datos, de enriquecimiento, analíticos, etc.

Conclusión

Existen grandes diferencias entre las cargas de datos de los sistemas BI y Big Data.

La carga de datos de un sistema BI (ya sea tradicional o con arquitectura Lambda), procesa los datos en modo batch, mientras que un sistema basado en Big Data puede utilizar cargas batch o basadas en streaming.

Cuando las transformaciones se hacen durante la carga y antes de dejar los datos en las tablas finales del repositorio de datos, se denomina ETL. Este tipo de cargas es el usado en los sistemas BI.

Cuando las transformaciones se realizan posteriormente a la carga de datos en el repositorio, éstas dotan a los datos de calidad, los refinan, los enriquecen y les proporcionan un valor añadido, se denomina ELT. Big Data usa este tipo de cargas.

Elegir el tipo de carga correcto para cada escenario es clave para el éxito de una solución analítica. De ello se deriva poder disponer de los datos para la toma de decisiones de manera efectiva. El hecho de utilizar una carga de datos errónea puede suponer el fracaso del proyecto de creación de una solución analítica.