Definición de Variedad en Big Data

 

Las 3 V’s de Big Data son Volumen, Velocidad y Variedad. Si bien es fácil comprender qué significan Volumen y Velocidad, el término Variedad crea cierta confusión.

¿A qué nos referimos al hablar de Variedad? ¿Cuál es la Variedad que nos lleva a la utilización de Big Data por la imposibilidad de obtener respuestas analíticas con una solución tradicional?

 

¿Variedad de qué?

Para determinar si existe Variedad es importante saber el ámbito al que nos referimos.

Durante años he tenido largos debates sobre este tema, siempre con un par de interpretaciones enfrentadas. Durante mis años de docente, he encontrado también estas dos versiones en los foros, causando cierta confusión y hasta desconcierto en algunos alumnos.

Las dos opciones son:

  • Variedad de fuentes de datos
  • Variedad de tipos de datos

Variedad de fuentes de datos

La Variedad de fuentes de datos es la obtención de datos de una gran variedad de fuentes.

Lo que no me convence de esta definición es la poca concreción de ésta. ¿Qué significa «gran variedad»? ¿A partir de qué momento pasamos simplemente de «variedad» a «gran variedad»?

Una solución analítica obtiene datos de uno o más fuentes de datos. La mayoría de las soluciones de Business Intelligence tradicional, obtienen los datos únicamente de una fuente inicialmente. Sin embargo, éstas pueden ampliar ese número con el tiempo a medida que el sistema va creciendo e incorporando datos que complementan al conjunto de datos inicial.

Siendo así, ¿es plausible pensar que un sistema de Business Intelligence tradicional puede pasar a ser un sistema que necesite el uso de Big Data después de cierto número de evolutivos solamente por el hecho de incorporar nuevas fuentes de datos?

Como podéis observar, esta no es una definición que me convenza.

Variedad de tipos de datos

Existe Variedad de tipos de datos cuando la solución analítica requiere del uso de información con tipos de datos diferentes de los que pueden ser tratados y consultados por bases de datos tradicionales (es decir, relacionales).

Los tipos de datos gestionados eficientemente por estas bases de datos son:

  • Numérico
  • Texto
  • Fecha
  • Booleano

Cuando nos encontramos con tipos de datos fuera de este conjunto, una solución de Business Intelligence tradicional no puede aportar lo que se espera de ella.

Algunos de estos tipos de datos fuera del conjunto tradicional son:

  • Audio
  • Imágenes
  • Vídeo
  • Geolocalización (podemos almacenar la geolocalización como un par de coordenadas numéricas, pero los cálculos necesarios para obtener respuestas a partir del análisis de este tipo de datos son más eficientes con un software especializado que con una base de datos relacional)
  • Texto libre (la necesidad de, por ejemplo, extraer un análisis de sentimiento de un texto, es una tarea poco eficiente si la realizamos a partir de datos almacenados en una base de datos relacional, mientras que con otros sistemas de almacenamiento disponibles en Big Data, esta tarea puede ser mucho más eficiente)

En este caso, la definición es clara y no deja lugar a dudas.

Cierto es que hay cierto margen para trabajar con datos numéricos y texto aún almacenándolo en una base de datos relacional, lo que hace que la frontera no esté marcada claramente. Sin embargo, personalmente, creo que la línea está suficientemente bien definida.

Conclusión

La definición de Variedad como característica de un sistema analítico para el uso o no de Big Data, es algo que causa cierta confusión.

Las dos opciones más comunes de Variedad son las de variedad de fuentes de datos y la de variedad de tipos de datos.

En mi opinión, la variedad de fuentes de datos no es un motivo suficiente para el uso de Big Data.

Por otra parte, la variedad entendida como el uso de tipos de datos no simples sí que determina una limitación en los sistemas analíticos tradicionales. Esa es la Variedad que nos lleva a la implementación de soluciones analíticas con Big Data.

Federación de datos

 

Una de las características de un sistema analítico de calidad, es que nos permita analizar datos provenientes de diferentes sistemas de información y consultarlos como si se tratara de una sola fuente de información.

La solución más usada para solventar este escenario es el de la creación de una carga de datos (ETL). Mediante un proceso ETL, podemos obtener datos de diferentes orígenes y guardarlos en un único repositorio de datos. Y éste, a su vez, es fácilmente accesible por cualquier herramienta que permita la creación de consultas analíticas.

Sin embargo, hay ocasiones en las que la creación de una ETL no es posible, por distintas causas. En ese caso, la solución pasa por la federación de datos.

Federación de datos

La federación de datos consiste en la combinación de datos de diferentes orígenes y con diferentes modelos de datos, en un solo modelo de datos de tipo lógico. Este modelo de datos común es el que se denomina modelo de datos federado.

Hay que tener en cuenta que la federación es una capa lógica. Por tanto carece de un espacio de almacenamiento de datos que actúe como un repositorio único de la información (ese modelo de diseño es el que tenemos en el caso de tener una ETL).

La federación de datos requiere de una correspondencia entre los datos en origen y el modelo de datos federado. Es decir, desde una mera traducción de columnas en el caso más simple, hasta una fórmula que incluya un transformación de los datos en el caso más complejo.

Este nuevo modelo de datos federado es el que será utilizado por las herramientas analíticas para acceder a los datos de los distintos orígenes.

Por ejemplo, si el objetivo del sistema federado de información es obtener las ventas unificadas de dos sistemas de información distintos, al lanzar una consulta sobre el sistema federado, ésta se transformará en dos consultas independientes sobre cada uno de los sistemas origen.

Éstos devolverán dos conjuntos de datos (data sets) con los datos almacenados en cada uno de ellos. En este punto, los dos data sets deben ser combinados para devolver a la herramienta analítica un único data set.

Existen herramientas analíticas que incluyen la federación de datos. Esto les permite estar un paso por delante del resto de competidores.

Beneficios

La federación de datos permite la combinación de diferentes fuentes de datos sin la necesidad de implementar una ETL. En situaciones en las que una ETL no es posible, es la alternativa a seguir.

En escenarios de acceso a datos con una latencia muy baja (casos cercanos a tiempo real), la federación de datos permite la combinación de datos almacenados en un Data Warehouse (cargados diariamente, por ejemplo), y datos del día en curso (esta consulta tendría un filtro sobre datos no cargados en la última ETL). De esta manera, la visión global de los datos es posible sin afectar al rendimiento del sistema operacional (datos del día en curso).

Otro caso típico es el de la existencia de diferentes aplicativos con diferentes modelos de datos. En este caso, sin una ETL, la federación permite la consulta de la información como si se tratase de un único sistema origen.

La federación de datos, al generar múltiples consultas, obtiene los datos en paralelo. Es decir, las consultas se ejecutan al mismo tiempo en los diferentes sistemas origen, para devolver los resultados de cada una de las consultas al sistema de federación de datos. Este paralelismo supone una reducción del tiempo de obtención de los resultados parciales.

Inconvenientes

La federación de datos añade un post-proceso de los datos: la combinación de los data sets.

Este proceso tiene un coste que hay que añadir al de la obtención de los data sets. Si el resultado final requiere la ordenación o agregación de los resultados parciales obtenidos de los diferentes orígenes de datos, este post-proceso debe ser realizado por el sistema de federación de datos.

El coste de este post-proceso dependerá del tamaño de los data sets y de los recursos disponibles en el sistema de federación de datos. Por lo general, una base de datos dispone de más recursos y mejores algoritmos para la ejecución de este tipo de operaciones, pero la elección de la herramienta adecuada y una buena configuración pueden obtener los datos finales con un buen rendimiento.

Otro inconveniente es que la transformación de los datos de los sistemas origen al sistema federado debe realizarse en cada consulta. Si se compara con una ETL, en ésta los datos son transformados una sola vez y almacenados en un modelo de datos optimizado para la consulta de datos. Pero esa transformación solamente se realiza una vez. Por tanto, hay que añadir un retraso en la obtención de los datos en el caso de la federación, si lo comparamos con los datos de un Data Warehouse cargados mediante una ETL.

Conclusión

La federación de datos permite combinar datos de diferentes orígenes a partir de un modelo lógico común y las transformaciones de los datos iniciales.

Esta opción es una alternativa a las cargas de datos, en especial cuando existen limitaciones para la existencia de una ETL.

Las herramientas analíticas que incluyen la federación de datos, permiten un diseño de soluciones analíticas con una flexibilidad más alta que el resto de herramientas, ya que no dependen de la existencia de cargas de datos que unifiquen el modelo de datos, ni de herramientas específicas para la federación de datos.

La federación de datos es una muy buena opción para la creación de pruebas de concepto. De esta manera, es posible obtener una visión de los resultados combinados sin la necesidad de crear una ETL (con un alto coste) en la fase previa al inicio de un proyecto.