Visualización efectiva de información

 

El objetivo de mostrar información es la fácil comprensión de ésta para poder realizar una toma de decisión.

La información puede presentarse en una gran variedad de formatos. Dar con el formato ideal es, en sí, una quimera (ya se sabe que para gustos, colores). Sin embargo, lo cierto es que la manera cómo se presenta la información puede facilitar en diferente grado la comprensión de ésta.

Es por esto que una visualización efectiva de la información es tan importante como el mismo tratamiento de los datos a la hora de diseñar una solución analítica.

Tablas: El A, B, C de la visualización

Los datos suelen ser tratados como una sucesión de información con una estructura concreta. Y su almacenados más habitual, al menos desde el punto de vista conceptual, es el de una matriz.

Esa matriz está compuesta de:

  • Filas: Cada uno de los sucesivos registros de información.
  • Columnas: Las diferentes unidades de información (datos) que componen ese registro.

Por tanto, la manera más simple e intuitiva de visualizar información es mediante su representación en una tabla.

A continuación se muestra un ejemplo:

Hasta aquí todo es fácil.

Sin embargo, esta tabla es un caso simple. Se trata de la visualización de una matriz de 2 filas por 3 columnas (6 celdas de información). Esta tabla es fácilmente interpretable debido a la poca cantidad de información a visualizar.

En muchos casos nos encontraremos con tablas con más registros de los que nos caben en pantalla, lo cual dificultará la visualización (scroll continuo para ver todos los registros o simplemente la línea de totales que podamos tener al final de ésta).

Si añadimos el mes a la tabla anterior, obtenemos la siguiente tabla:

Esta tabla ya no cabe en la mayoría de las pantallas.

Si la tabla fuera por año y semana en lugar de por año y mes, aún es más evidente (ahora podréis experimentar la agonía de tener que hacer scroll para poder seguir con el artículo):

Prosigamos.

Llegados a este punto, ¿crees que es fácil identificar el mes con más ingresos de 2018? Lo de la semana lo dejo para los que no tengáis nada más interesante que hacer.

En este caso, los datos están ordenados por año, lo cual facilita la búsqueda de la respuesta. Pero, ¿y si os pido el mes y año con un mayor objetivo? Ahora ya nos toca hacer un recorrido visual por toda la tabla.

Independientemente del número de filas de la tabla, nos encontramos con otra dificultad añadida. En este escenario, como en muchos otros, podemos necesitar la realización de cálculos para poder obtener un conocimiento que nos permita tomar decisiones.

En este escenario, queremos identificar los meses (dupla año, mes) donde el objetivo no se ha cumplido. Además queremos ver esa diferencia numérica.

Una solución fácil vendría a partir de la creación de una nueva columna con fórmula «= INGRESOS – OBJETIVO» nos daría esa diferencia. De esta manera podríamos identificar fácilmente los valores negativos, que son los que nos interesan. El uso de un filtro para eliminar los registros que no queremos visualizar permitiría reducir el número de filas, pero eso no siempre sería suficiente.

Queda claro que esta visualización no es efectiva.

Tablas dinámicas: Uso inteligente del espacio

El uso de una tabla dinámica nos permite tener valores de las dimensiones en las filas y las columnas. Esto supone una reducción del número de filas, lo que supone la posible supresión del scroll.

La siguiente visualización muestra la diferencia entre ingresos y objetivo por año y mes, a la cual se le ha añadido un formato condicional para identificar los meses que no han llegado al objetivo:

Hemos mejorado mucho, pero a la vez hemos perdido detalle. Al no disponer de los ingresos y los objetivos, no podemos cuantificar si estos números representan un desvío elevado respecto a los objetivos o no.

Podríamos usar porcentajes, pero éstos se ven altamente distorsionados cuando los valores son bajos.

Podríamos añadir las columnas «Ingresos» y «Objetivo», o únicamente una de ellas, pero esto implicaría añadir mucha información a la tabla dinámica, cosa que complicaría su comprensión.

Gráficos: Una imagen vale más que mil palabras

El uso de gráficos permite mostrar información en una imagen, de manera que ésta resalte aquello que queremos obtener del análisis.

En este caso, nos interesa identificar los meses en los cuales no se ha llegado a los objetivos, a la vez que queremos ver esos ingresos y objetivos.

El siguiente gráfico nos muestra exactamente eso:

En este gráfico podemos identificar fácilmente, mediante las barras verticales y su dirección, si la diferencia entre ingresos y objetivos es positiva o negativa.

Además, podemos ver también el valor numérico de estos dos valores, con lo cual tenemos una visión más completa de la realidad.

En esta imagen estamos mostrando un total de 108 valores (3 métricas x 3 años x 12 meses/año), todo concentrado en una sola pantalla.

Además, los gráficos de la mayoría de las herramientas analíticas nos permiten obtener más información de detalle al posicionarnos sobre un elemento del gráfico (normalmente en forma de ventana emergente).

Usuarios y organizaciones anclados en el pasado

Lo expuesto hasta aquí no es nada que quede fuera del conocimiento de la mayoría de los usuarios. De hecho, entra dentro de lo que se puede considerar «sentido común».

Siendo así, ¿porqué hay tantos usuarios en tantas organizaciones que continúan visualizando la información en forma de tablas? ¿Porqué estos usuarios pierden tanto tiempo interpretando los resultados cuando podrían ser más eficientes y obtener mejores respuestas con riesgo de error en sus interpretaciones mucho menor?

Es necesario que las organizaciones tomen el control del análisis de datos, formando a sus empleados y apoyándolos para que puedan obtener respuestas para la correcta toma de decisiones de la manera más simple y eficiente. Solamente de esta manera podrán modernizar sus procesos analíticos.

La creación de soluciones analíticas sin la correcta formación y soporte a los usuarios, es un error. Los usuarios son los que decidirán como usar las herramientas. Y si ellos deciden usarlas de la manera más ineficiente, la organización es incapaz de mejorar sus procesos internos de toma de decisión.

Conclusión

La visualización de información es clave para una toma de decisiones eficiente.

El uso de tablas como visualización por defecto genera grandes ineficiencias en las organizaciones, debido al alto coste temporal y al riesgo de errores en la interpretación de la información.

El uso de tablas dinámicas es una ligera mejora respecto al uso de tablas, pero arrastra ciertas limitaciones de éstas.

Los gráficos pueden ser una gran solución para la visualización de información. Existe una gran variedad de formatos, cada uno adecuado a resaltar cierto elemento de información. El hecho de no obligar a leer los resultados es una gran ventaja respecto a las tablas y tablas dinámicas.

Las organizaciones deben apostar en la visualización para poder facilitar la interpretación de la información por parte de sus empleados. De esta manera conseguirán una mayor eficiencia y un menor grado de error en la toma de decisiones.

Arquitecturas Lambda

 

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.

Pensar en «Big»… Data no es siempre la mejor opción

 

Las limitaciones del Business Intelligence (BI) al tratar grandes volúmenes de datos, permitir el análisis en tiempo real y analizar tipos de datos complejos, son el origen de Big Data. Con este nuevo conjunto de tecnologías y procesos, podemos analizar datos en estas situaciones donde un BI tradicional no nos ofrece soluciones válidas.

Sin embargo, la aparición de Big Data está suponiendo un cambio de mentalidad, una simplificación en los diseños de soluciones técnicas, para hacerlas encajar en el mundo de Big Data. Y eso puede ir en detrimento de los intereses de las organizaciones.

En este artículo os presento un ejemplo.

Un requerimiento concreto

Una empresa a la cual llamaré X, precisaba analizar los ficheros de log de su sitio web (llamados comúnmente weblogs), para así poder extraer una información concreta. En este caso, se trataba de saber el porcentaje de visitas por idioma (catalán, español o inglés) a su sitio web.

El escenario era el siguiente:

  • Cliente internacional con tráfico web 24×7
  • Generación de 1 GB de weblog por hora, archivados en ficheros horarios (lo que supone casi 9 TB de weblog por año)
  • Estacionalidad en el tráfico del sitio web (el tráfico depende de la época del año)

Alternativa Big Data

Debido a la estacionalidad en el tráfico, era necesario analizar los datos de un año. La estimación del tamaño de los weblogs en un año de actividad (cerca de 9 TB), hizo que el cliente se posicionara a favor de una solución basada en Big Data desde un buen principio.

Estaban tan convencidos de que éste era el camino, que pronto contactaron con proveedores para sopesar la opción de adquirir hardware que les permitiera levantar una solución de Big Data. También habían estado mirando diversas tecnologías software para implantar la solución. Únicamente les quedaba elegir la opción más adecuada dentro del escenario Big Data.

Todo era excitación en la empresa X. El Departamento de Tecnología estaba muy emocionado por poder implementar una nueva solución, tan moderna, tan de la última tendencia… Esta emoción se extendió por la empresa. Los jefes de departamento soñaban con un futuro analítico con Big Data. No sabían exactamente qué podrían hacer con eso, pero sonaba muy bien, muy potente y muy moderno. Palabras como Machine Learning sonaban por los pasillos y en las reuniones de departamento. Hasta en las reuniones de Dirección, Big Data era un tema a tratar.

Solamente les faltaba la aprobación de un consultor externo experto en Big Data para poder tirar adelante el proyecto.

Los requerimientos mandan

Al enfrentarme a este escenario, lo primero que vi es que el cliente tenía muy decidido el camino a seguir, con lo cual sería muy importante justificar otra opción, si finalmente Big Data no era la mejor alternativa. Como veis, nunca parto de una alternativa única, sino que me gusta plantearme diferentes opciones para así hacer un análisis de pros y contras. De esta manera puedo elegir la más conveniente en cada caso.

Primera norma del consultor: Obtener los requerimientos.

Analizando este escenario, vi que el requerimiento se refería únicamente a un análisis concreto y específico. Al obtener requerimientos analíticos futuros, la respuesta fue que no había una necesidad de análisis posteriores de la información de los weblogs. Tampoco había nadie en la empresa que hubiera mostrado interés por extraer más información de esa fuente de datos en el futuro.

En este caso, el cliente se había inclinado por una solución muy potente para obtener una respuesta muy concreta. Pero esa inversión inicial no tenía en ese momento ninguna visión de futuro, ninguna continuidad que proporcionara un retorno de la inversión (ROI). Es sería la justificación a usar al plantear otra opción.

Propuesta de solución

Dado que los requerimientos presentes y futuros no justificaban una inversión tan grande, me planteé la alternativa de una solución a medida para obtener la respuesta a los requerimientos.

Esta opción consistía en dar una solución a la necesidad del proyecto, sin tener en cuenta la construcción de una plataforma analítica para su uso en futuros proyectos. Se trataba, pues, de un Quick Win.

Las opciones tecnológicas que planteé para esta alternativa fueron:

  • Servidor único, con ejecución serializada de larga duración en un servidor propio o en el cloud.
  • Cluster de Big Data, con ejecución distribuida en el cloud (eliminando la opción de cluster de Big Data propio).

En el primer caso, si el cliente disponía de un servidor donde poder ejecutar el proceso, el coste de hardware y software sería nulo. Únicamente tendrían que tener en cuenta el tiempo de ejecución del proceso, presumiblemente de larga ejecución por la serialización de éste.

El segundo caso, fue planteado únicamente en el cloud para pagar por uso computacional y reducir los gastos si lo comparamos con una solución on premise.

En este caso, la opción propuesta fue la de ejecución serializada en un servidor único disponible en el cliente, puesto que el cliente disponía del hardware necesario para ello. La ejecución del proceso se demoraría durante pocos días, pero daría respuesta a los requerimientos planteados al inicio del proyecto.

Conclusión

Big Data nos permite obtener soluciones a situaciones a las que el BI tradicional no puede dar respuesta.

Una solución de Big Data supone una inversión tanto tecnológica como de recursos humanos importante. Antes de realizar dicha inversión, es conveniente hacer un análisis del ROI para ver la conveniencia o no del esfuerzo económico.

Cuando una organización no dispone de una estrategia analítica o unos requerimientos que justifiquen la inversión de introducir Big Data, es importante explorar otras alternativas.

El uso de Big Data es un caramelo para las organizaciones, pero no siempre es la mejor solución a las necesidades corporativas. Un análisis de los requerimientos a corto, medio y largo plazo permitirá dictaminar la mejor opción.

El Valor de la información

 

Es habitual encontrar definiciones de Big Data basadas en las V’s: Volumen, Velocidad, Variedad, Veracidad… Una V que a menudo aparece en estas definiciones es la de Valor.

Los datos en sí carecen de Valor. Al otorgarles un contexto, estos datos proporcionan información. Y al combinar distintas informaciones aparece el conocimiento, que es el que permite tomar decisiones de manera inteligente.

¿Dónde aparece el Valor? ¿A qué se refiere la gente que habla del Valor en Big Data?

El dato contextualizado como fuente de Valor

El dato contextualizado aporta información. Por ejemplo, un sensor de temperatura puede darnos un conjunto de temperaturas en varias mediciones sucesivas. El contexto incluye las unidades de medida (°C) y la dimensión temporal, entre otras. Solamente con esta versión reducida del contexto, podemos ver la evolución de la temperatura a lo largo de un periodo de tiempo.

Si estas mediciones corresponden al proceso de vitrificación de ovocitos (técnica para la conservación de óvulos a temperaturas inferiores a -196°C), la información de la velocidad de enfriamiento aporta un gran Valor, ya que un proceso demasiado lento podría significar la creación de cristales de hielo que podrían dañar el óvulo.

Por tanto, queda claro que la información (la existencia de datos contextualizados), aporta Valor.

El Valor está en todo sistema analítico

Todo sistema analítico obtiene datos y los contextualiza. Por tanto, la aparición de Valor es propia de todo sistema analítico.

Hablar de Big Data como herramienta indispensable para aportar Valor es negar la posibilidad de que un sistema analítico tradicional (Business Intelligence) aporte Valor.

Big Data, como solución técnica dentro de un sistema analítico, también permite la aparición de Valor. Sin embargo, no aporta Valor por sí mismo. Es la información la que aporta Valor.

¿Qué aporta Big Data?

Big Data no hace que los datos adquieran Valor. Sin embargo, nos permite analizar datos y transformarlos en información, en situaciones en las que un sistema analítico tradicional se ve limitado.

Es aquí donde se halla la «aportación» de Valor de Big Data. En la posibilidad de obtener información que de otra forma no podríamos obtener.

Por tanto, Big Data es una solución que nos permite expandir el Valor global de los datos, por el mero hecho de que puede obtener más información que un sistema analítico tradicional.

Conclusión

El Valor aparece al obtener información a partir de la contextualización de los datos.

Un sistema analítico nos permite obtener información a partir de los datos. Esto significa que todo sistema analítico permite obtener Valor.

Big Data, al superar los límites de un Business Intelligence tradicional, permite obtener más información. Eso supone obtener un Valor adicional. Por eso, el uso de Big Data para obtener la misma información que un Business Intelligence tradicional, no aporta ningún Valor añadido.

Definición de Volumen en Big Data

Las 3 V’s de Big Data son Volumen, Velocidad y Variedad. El concepto de Volumen es fácil de entender. Sin embargo, lo que es más complicado es definir el límite a partir del cual dejamos atrás el Business Intelligence (BI) tradicional para adentrarnos en territorio Big Data.

¿Existe un Volumen máximo para un proyecto de BI? ¿Cuál es Volumen que nos lleva a la utilización de Big Data por la imposibilidad de obtener respuestas analíticas con una solución tradicional dentro de los requerimientos funcionales definidos?

Volumen y tecnología

El Volumen puede medirse en número de registros (miles, millones, miles de millones…) o en tamaño en disco (Gigabytes, Terabytes, Petabytes…).

Suele ocurrir que cuando alguien está acostumbrado a trabajar con cierto volumen de datos, oir hablar de volúmenes superiores en un par de órdenes de magnitud, genera cierto asombro. Es como si ese volumen fuera ir más allá de los límites del universo conocido. De hecho, mi experiencia me ha mostrado que la gente inicialmente suele plantearse cómo poder trabajar con esos volúmenes con la tecnología con la cual trabajan normalmente, es decir, con tecnología dimensionada para volúmenes más pequeños. Y como es de esperar, el rendimiento suele ser bastante pobre, según cuentan los propios afectados.

Pero si incrementamos las especificaciones de las máquinas donde se producen el proceso, almacenamiento y análisis de los datos, vemos que esos volúmenes imposibles de gestionar, pueden ser tratados sin ningún problema. Es decir, la tecnología da soporte al tratamiento de los datos. A mayor volumen de datos, mayor deberá ser la tecnología para dar respuesta a las tareas necesarias para lidiar con los datos.

En una situación así, incrementar la memoria (RAM, cache, etc.), la velocidad de los discos duros donde se almacenan los datos, de las controladoras de discos, del bus que conecta los diferentes componentes tecnológicos de un ordenador, y la velocidad de transferencia de la red, permite incrementar el poder computacional de una solución de BI.

¿Dónde está el límite?

He aquí la pregunta del millón.

Para la gran mayoría de organizaciones que disponen de una solución BI, la ampliación del hardware es una solución de recorrido relativamente corto. El incremento de la capacidad tecnológica va ligado a un incremento del coste del hardware. Y para esta gran mayoría de organizaciones, la inversión tecnológica tiene unos límites (basados en los presupuestos) que no les permiten obtener máquinas de alta capacidad computacional y alto rendimiento.

Para este grupo de organizaciones, se suele decir que el límite de una solución de BI tradicional, con un Data Warehouse como repositorio central de información analítica, está en los pocos Terabytes.

Existen algunas organizaciones (grandes corporaciones y administraciones públicas), que sí que pueden permitirse este tipo de tecnología. En este caso, los volúmenes que pueden llegar a procesar pueden llegar a ser muy grandes, pero puede ser que incluso esta tecnología no sea suficiente para según qué escenarios analíticos.

Para estas organizaciones, si disponen de tecnología punta, el volumen puede superar los pocos Terabytes citados anteriormente, aunque no va mucho más allá si se requiere obtener un buen rendimiento. ¿Cuánto más allá? Dependerá del diseño de la solución analítica, las consultas, la carga del sistema… En fin, depende de tantos factores y tan complejos, que es imposible dar un número a ciencia cierta.

Big Data como solución

Cuando la tecnología no puede incrementarse y el sistema no proporciona un buen rendimiento a las consultas analíticas, es el momento de plantearse un cambio. En este escenario, una solución de BI tradicional no puede dar respuesta debido a la gran cantidad de datos, por lo que es necesario explorar más allá del BI basado en un Data Warehouse.

Big Data, basado en el paradigma tecnológico de la computación distribuida, ofrece una solución a las limitaciones por grandes volúmenes de un BI tradicional.

La tecnología usada por un sistema analítico basado en Big Data no precisa ser de altas especificaciones, sinó que permite trabajar con hardware más modesto. El gran poder computacional de Big Data se basa en el trabajo cooperativo de los diferentes nodos que forman el cluster de Big Data. Además, esta red de máquinas puede crecer de manera flexible, lo que permite ver incrementadas las especificaciones del cluster y por tanto su capacidad de proceso de datos y cálculo.

Conclusión

El límite del Volumen de un BI tradicional no viene dado por un número sinó por la tecnología usada. A la hora de buscar un número, el más habitual ronda los pocos Terabytes.

Incrementar el poder computacional permite a una solución de BI procesar más datos de manera más eficiente, pero siempre encontraremos un límite (bien por rendimiento, bien por presupuesto en una organización).

Big Data aporta la computación distribuida como signo de identidad diferencial respecto al BI tradicional. Esto permite tratar con volúmenes de datos muy superiores al BI tradicional a la vez que lo hace con un mejor rendimiento.

Definición de Velocidad en Big Data

 

Las 3 V’s de Big Data son Volumen, Velocidad y Variedad. El concepto de Velocidad es fácil de entender. Sin embargo, es importante tener muy claro a qué nos referimos exactamente en términos de Big Data.

¿De qué Velocidad hablamos en un entorno de Big Data? ¿Cuál es la Velocidad que nos lleva a la utilización de Big Data por la imposibilidad de obtener respuestas analíticas con una solución tradicional?

 

¿Velocidad de qué?

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

Existen dos conceptos de Velocidad que acompañan a la generación, proceso, almacenamiento y análisis de datos. Éstos son:

  • Velocidad en la generación de datos
  • Velocidad como urgencia del análisis de datos

Velocidad en la generación de datos

Los datos a analizar son generados por los sistemas origen. La manera cómo los datos son generados depende de la naturaleza del sistema origen.

Por ejemplo, si un sistema genera datos a partir de su introducción por parte de una persona mediante una interfaz, la velocidad de generación será relativamente lenta. En cambio, si los datos se generan automáticamente, mediante mediciones realizadas por sensores, por poner un ejemplo, la velocidad de generación de datos puede ser muy elevada.

En una solución de Business Intelligence (BI) tradicional, partimos de la base de que los datos se procesan mediante cargas de datos (batch). Estas cargas obtienen los datos acumulados desde la última carga y los procesan, almacenándolos en el repositorio de datos (típicamente un Data Warehouse).

La idea de que una generación de datos a una gran velocidad no puede ser procesada por un BI tradicional es cierta hasta cierto punto. Veamos un ejemplo.

Para un experimento científico, medimos la temperatura en el interior de un espacio cerrado mediante un sensor de temperatura. Este sensor es capaz de medir la temperatura cada microsegundo (μs). Es decir, es capaz de efectuar 1 millón de medidas por segundo. En nuestro caso, si el experimento se alarga durante 1 hora, el número de registros de temperatura generados será de 3.600 millones.

En este caso, la velocidad de generación de datos es elevada, así como el volumen de datos, debido a la larga duración del experimento.

En cambio, si el experimento dura tan solo 10 milisegundo (10 ms), el número de registros generados será tan solo de 10.000, un volumen que no puede considerarse elevado.

Y ahora la gran pregunta que debemos hacernos a la hora de evaluar Big Data como la solución a seguir en un proyecto analítico: ¿Puede una solución de BI tradicional tratar los datos generados en ese experimento?

La respuesta depende del análisis que vayamos a hacer con esos datos. Si los datos deben ser analizados a posteriori, un BI tradicional será capaz de procesar esos datos y proporcionar un análisis para la toma de decisiones. De hecho, incluso con un experimento de 1 hora, si los datos son analizados después del experimento, un BI tradicional podría procesar esos datos en una carga y almacenarlos en el repositorio.

Hasta en una generación constante de datos, los datos pueden cargarse en un repositorio para su análisis posterior. En ese caso, el problema que aparecería sería el del volumen, pero eso lo veremos en otro artículo.

Velocidad como urgencia del análisis de datos

¿Pero qué sucede cuando necesitamos analizar los datos en tiempo real?

En este caso, incluso con un volumen de datos pequeño, como los 10.000 registros del experimento de 10 ms, un BI tradicional no sería capaz de proporcionar una solución a este requerimiento.

Es posible que necesitemos analizar las medidas de temperatura de nuestro experimento para detectar patrones que puedan indicar un posible fallo en el sistema, y que éste implique el inmediato aborto del experimento para no dañar los componentes utilizados. En este caso, es necesario procesar los datos a medida que son generados para poder anticipar la toma de decisión tanto como sea posible.

La arquitectura de un BI tradicional, incluso con una arquitectura Lambda no es capaz de ofrecer análisis en tiempo real. Por tanto, es necesario el uso de tecnología Big Data para poder dar respuesta a esta necesidad.

Conclusión

La Velocidad puede entenderse como la rapidez en la generación de datos y como la urgencia en el análisis de la información.

Generar datos velozmente no es, en sí misma, una razón para el uso de Big Data en una solución analítica, aunque puede ser la causa de un gran volumen, que podría justificar el uso de Big Data.

En cambio, la velocidad entendida como la necesidad de procesar datos con urgencia, para su análisis en tiempo real (o casi real), sí que justifica el uso de Big Data, puesto que un BI tradicional no es capaz de procesar datos con esa velocidad.

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.