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.

Particionamiento de tablas para reducir el tiempo de las consultas

 

Una solución analítica se caracteriza por la necesidad de acceder a un gran volumen de datos. Sin embargo, lo habitual es acceder solamente a una parte de éstos, y no a su totalidad.

Para poder gestionar de manera más eficiente el acceso a la información, algunas bases de datos han implementado el concepto de particionamiento de tablas.

El diseño lógico de tablas con particionamiento de tablas proporciona grandes beneficios tanto en la gestión de datos como en las consultas realizadas sobre éstos.

Particionamiento de tablas

El particionamiento de tablas consiste en el almacenamiento de los datos de una tabla en contenedores separados, en función de los valores de cada registro, según una función específica determinada en

Por ejemplo, las ventas de una empresa pueden particionarse por el año de la venta, por unidad de negocio, etc.

Al particionar por el año de venta, cada contenedor con registros de las ventas contiene la información de un año. De esta manera, las consultas sobre el año actual accederán tan solo al contenedor del año en curso. Lo mismo sucede si accedemos a información del año pasado o el anterior, por ejemplo, accediendo al contenedor específico de ese año.

Gestión de datos

El particionamiento a nivel tabla en una base de datos es transparente para el desarrollador, y aún más para el usuario final.

La base de datos es capaz de insertar los datos en el contenedor correspondiente a cada registro al aplicar la función de particionamiento sobre los datos de cada uno de éstos. Por ejemplo, al insertar una venta actual, el registro se almacenará físicamente en el contenedor del año en curso, mientras que si insertamos una venta del año pasado, éste se almacenará en el contenedor para ese año.

Lo mismo sucede con las modificaciones que afecten a las columnas de la función de particionamiento. Al producirse un cambio en los valores, el registro puede cambiar de partición (o sea, de contenedor).

Por último, cabe destacar el hecho de que, al disponer de todos los datos de una partición juntos, se facilita la gestión de los datos (movimiento de disco, copias de seguridad, etc.) en tareas de mantenimiento.

Mayor eficiencia en las consultas

Aparte de los beneficios en la gestión de datos para el personal de Sistemas en las citadas tareas de mantenimiento, el gran beneficio del particionamiento de datos reside en el acceso a los datos en las consultas.

Las consultas de usuario suelen contener filtros sobre los datos. Si ciertos filtros son habituales, puede ser efectivo particionar las tablas por esas columnas presentes en esos filtros de datos.

En el caso del particionamiento por el año de venta (un filtro habitual en la gran mayoría de empresas), conseguiremos acceder únicamente a las ventas del año en curso en lugar de a todo el histórico de ventas para resolver la consulta. Esto supone una gran reducción del volumen de registros a consultar (y posiblemente a agregar), lo cual supone un gran beneficio en términos de rendimiento.

Cierto es que el indexado de tablas puede proporcionar también un gran beneficio a la hora de acceder únicamente a los registros requeridos por las consultas, pero el acceso por índice para grandes volúmenes de datos nunca será tan efectivo como el acceso secuencial a una partición de datos donde todos los registros deben ser consultados.

Además, es posible que existan otros filtros que activen otros índices que tengamos disponibles. En este caso, cada partición tiene sus propios índices sobre esas columnas, separados de los índices sobre las mismas columnas existentes en otras particiones. Por tanto, los índices son más pequeños y más eficientes.

Conclusión

El particionamiento de tablas es una técnica de diseño de bases de datos que permite organizar los datos físicamente en contenedores de datos separados en función de los valores del cada registro.

Al disponer de tablas particionadas, las consultas que utilizan filtros pueden beneficiarse de esta técnica de diseño al acceder únicamente a subconjuntos de datos con la información necesaria para la resolución de la consulta.

Esto supone un menor volumen de datos a acceder y por tanto una mayor eficiencia en las consultas.

La elección de la función de particionamiento es clave para obtener una mayor o menor eficiencia en las consultas. Pero a la vez, elegir una función de particionamiento errónea puede suponer una penalización respecto a una solución sin esta técnica de diseño. Por eso, recomiendo usar el particionamiento, pero siempre con la seguridad que proporciona contar con la opinión de un experto en este tema.

Optimización de consultas con agregados

 

Analizar datos implica, generalmente, el acceso a una gran cantidad de datos. Por otra parte, para poder obtener una visión analítica completa es necesario disponer de datos a nivel de detalle. Esto permite tanto el análisis a alto nivel como la navegación a niveles inferiores de los datos (drill down) para identificar información que requiere una especial atención a nivel operacional.

Sin embargo, disponer de datos a nivel de detalle penaliza en gran manera el rendimiento de las consultas. Cuando tenemos grandes volúmenes de datos las consultas pueden tardar tanto que la obtención de resultados puede ser inviable dentro de los plazos requeridos por el usuario.

En estas situaciones, es necesario trabajar con datos agregados.

Agregación de datos

Los datos agregados son una visión a alto nivel de los datos disponibles a nivel de detalle. La información agregada debe corresponder exactamente al resultado de una consulta agregada sobre a los datos de detalle. La violación de este requerimiento da como resultado incoherencias en la información obtenida, y por tanto invalida la validez de esos datos agregados.

Disponer de agregaciones de datos permite formular las consultas a partir de dichas agregaciones en lugar de a partir de las tablas de detalle. Al tratarse de tablas con un volumen de registros menor, el tiempo de acceso a las tablas es menor. Además, al incluir los resultados de funciones de agregación, éstas no son necesarias en tiempo de ejecución de las consultas. Todo ello conlleva una mejora del rendimiento de las consultas al utilizar tablas agregadas respecto al uso de tablas de detalle.

Gestor de agregados

Al disponer de tablas agregadas, es necesario identificar la tabla de datos a incluir en la consulta. Esta función es la que debe realizar el «Gestor de agregados».

El gestor de agregados es un elemento que tiene como función principal decidir la(s) tabla(s) a utilizar en la creación de una consulta para acceder a los datos requeridos por el usuario. Este elemento puede ser llevado a cabo por tres diferentes entidades:

  • Usuario: La existencia de diferentes modelos de datos (e.g. Detalle, Agregado por mes, Agregado por cliente, etc.) permite al usuario decidir sobre qué tablas físicas ejecutar la consulta. En este caso, la decisión queda a expensas del conocimiento técnico del usuario, lo cual no es una buena opción.
  • Herramienta de explotación de datos: Una herramienta de Business Intelligence (BI), donde se crea un modelo de negocio que mapea el modelo físico del repositorio de datos, puede asociar cierto elemento de datos con diferentes orígenes físicos en el repositorio. No todas las herramientas de BI permiten definir múltiples orígenes de datos para el mismo objeto de la capa de presentación. Pero aquellas que sí que lo permiten, disponen de un gran elemento diferenciador respecto al resto de tecnologías. En este caso, la consulta se crea dinámicamente en función de las columnas de la consulta de usuario y la disponibilidad de agregados.
  • Base de datos: Existen bases de datos que permiten la reescritura de las consultas a partir de las consultas de usuario y de la disponibilidad de tablas agregadas. En este caso, el beneficio se generaliza a todas las herramientas de explotación de datos que accedan a la base de datos, sin necesidad de replicar la lógica de decisión del agregado en todas las herramientas de BI utilizadas.

A la hora de decidir la política de agregados, es muy importante tener claro quién va a asumir el rol del gestor de agregados. La tecnología a utilizar puede depender de ello.

Mantenimiento de agregados

El uso de agregados requiere una revisión periódica, algo que no ocurre en sistemas de información asociados a aplicativos.

El conjunto de agregados en un sistema analítico debe estar alineado con los requerimientos de acceso a la información por parte de los usuarios. Si los requerimientos cambian (e.g. Inicialmente los informes agrupaban la información por año, pero a posteriori éstos son necesarios a nivel de mes), es muy posible que las tablas agregadas no proporcionen los beneficios para los nuevos requerimientos (en el ejemplo anterior, una tabla agregada a nivel de año quedaría invalidada para dar respuesta a las consultas por mes, y la consulta tendría que realizarse a partir de las tablas de detalle).

Por tanto, es necesario hacer un seguimiento de los requerimientos de acceso a la información por parte de los usuarios. Al detectar cambios, deberemos identificar posibles cambios en el conjunto de agregados e implementar esos cambios para que no haya un impacto en el usuario.

Conclusión

El uso de agregados permite mejorar dramáticamente el rendimiento de las consultas en un sistema analítico. De hecho, puede suponer la diferencia entre el éxito y el fracaso de una solución analítica.

El gestor de agregados es el componente inteligente que determina el acceso a los datos (bien sea a tablas agregadas o a las tablas de detalle). La lógica puede definirse a varios niveles: Usuario, herramienta de BI y base de datos. Cada una de ellas tiene sus pros y sus contras. Determinar la opción adecuada en cada solución es una tarea clave para el éxito de la solución analítica.

Los agregados son parte de una solución dinámica. Es decir, puede cambiar con el tiempo. Es necesario realizar un seguimiento de los requerimientos y del histórico de consultas para determinar cambios en éstas, para así poder redefinir los agregados en el caso que esto sea necesario.

Todo diseño de una solución analítica debe incluir un módulo de agregados. De no ser así, existe un gran riesgo de fracaso del proyecto. Si ya dispones de una solución de BI, asegúrate de disponer de la documentación del módulo de agregados. En el futuro puede ser que la necesites.