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.

ETL y Late Arriving Dimensions

 

Las cargas de datos (ETL, de Extract-Tranformation-Load en inglés), permiten mover datos de un sistema informático a otro. Durante este proceso, es habitual realizar modificaciones tanto en los datos (limpieza, estandarización de formatos, etc.) como en el modelo de datos (paso de un modelo transaccional a uno dimensional).

El diseño e implementación de una ETL es una tarea compleja. Existen una gran cantidad de situaciones a tener en cuenta para que ésta sea robusta y eficiente, y proporcione el resultado deseado.

Una de estas situaciones a tener en cuenta es la de la que se produce al cargar datos en un Data Warehouse, cuando una dimensión no está disponible en el momento de procesar un registro de una tabla de hechos. Es lo que se conoce en inglés como Late Arriving Dimension.

Late Arriving Dimension

La ejecución de una ETL, a grandes rasgos, procesa inicialmente las dimensiones para finalizar con las tablas de hechos. De esta manera, al procesar éstos, disponemos de los registros de las dimensiones referenciados en éstos.

Hasta aquí, perfecto. Sin embargo, ¿qué sucede cuando un escenario no es perfecto?

Una ETL simple obtiene todos los datos de un mismo origen. En este caso, es lógico pensar que dimensiones y hechos pueden ser tratados como una única unidad de información atómica. Por tanto, o bien todos los datos se obtendrán en la fase de extracción, o ninguno de ellos. En este último caso, al producirse un error en la extracción de datos, no tendremos ni dimensiones ni hechos. Y ese caso se solucionará restaurando el acceso al sistema origen de los datos.

Sin embargo, en una ETL que obtenga datos de diferentes orígenes, puede darse la situación en que la extracción de uno de ellos no sea posible, mientras que no haya ningún problema con los otros. En este caso, si no hemos podido obtener una dimensión, es posible que los registros de hechos hagan referencia a registros de dimensión que no hayan sido procesados en el sistema. Por tanto, ese registro de hechos no podrá enlazar a la información correcta.

Diseño complejo

Ante una situación así, debemos plantearnos diferentes soluciones en función del escenario.

La primera cuestión a plantearse es: ¿Es necesario disponer de toda la información para poder cargar los datos?

Si éste es el caso, la ETL debería finalizar con error. El siguiente paso sería solucionar el acceso a los datos. Y finalizaríamos ejecutando la ETL nuevamente para así poder cargar todos los datos en el sistema destino.

En caso contrario, procederíamos a cargar el registro de la tabla de hechos, referenciando un registro de dimensión donde únicamente las claves primaria y natural estuviesen informadas con información real (el resto serían valores por defecto). En el futuro, al cargar el registro de dimensión, modificaríamos ese registro inicial.

Pero habría que tener en cuenta también si esa dimensión requiere cambios en el tiempo (Slowly Changing Dimension Type 2, según la metodología Kimball). En ese caso, el proceso de inserción de una nueva versión de la dimensión no debería producirse inicialmente, ya que esta situación dejaría los registros de hechos referenciando a una versión incompleta de la dimensión.

Otra situación especial ocurre cuando no existe un único origen de datos para la confección de una dimensión. Es decir, a pesar de disponer de un maestro para una dimensión, ésta es enriquecida con datos provenientes de otros sistemas origen. La situación es similar a la anteriormente citada con los registros de hechos, pero no es exactamente la misma.

Conclusión

Una ETL debe ser robusta y tiene que proporcionar información correcta y consistente.

En un mundo ideal, todo funcionará siempre a la perfección. Sin embargo, eso es una utopía. La realidad es que a lo largo del tiempo sucederán situaciones de riesgo que una ETL debe tener controladas.

La mitigación de estas situaciones de riesgo es responsabilidad del arquitecto de la ETL. Un buen diseño debe ser capaz de sobreponerse a situaciones no habituales (que no inesperadas), alineando el comportamiento de la ETL a los requerimientos de ésta.

El caso de las Late Arriving Dimensions es uno de estos riesgos a controlar en una ETL. De ello depende que los usuarios puedan disponer o no de información para tomar sus decisiones en el día a día.

Predecir el futuro es posible

 

La toma de decisiones es crucial para el éxito de una organización. Estas decisiones pueden estar basadas en la experiencia o en la observación y análisis de datos históricos.

En este último caso, la predicción analítica nos permite tomar decisiones con un nivel de confianza predeterminado, a partir del análisis de grandes cantidades de datos y variables. Algo que escapa a la mente humana, por mucha experiencia que alguien pueda tener.

La responsabilidad de las organizaciones es definir un marco de trabajo para que sus empleados (desde los directivos hasta los operarios) puedan tomar decisiones con fundamento.

¿Qué es la predicción analítica?

La predicción analítica es como una bola de cristal que nos permite saber, con cierto grado de probabilidad, qué va a suceder. Ésta se basa en el análisis de datos históricos y en la determinación de patrones que se repiten en esos datos (por decirlo de una manera muy simple). El objetivo es la creación de un modelo predictivo que tiene como finalidad asignar una probabilidad de que algo suceda.

Este modelo es creado a partir de diferentes técnicas, en función del escenario de negocio. Estas técnicas incluyen el uso de estadística avanzada y algoritmos de Inteligencia Artificial entre otras. Algunos de los métodos usados en predicción analítica son las regresiones, árboles de decisión, clustering y redes neuronales. Estadística predictiva, Machine Learning y Deep Learning, entre otros, son términos asociados con el análisis de grandes volúmenes de datos para la creación de modelos de predicción analítica.

Grandes volúmenes de datos

El análisis parte de un gran volumen de datos. Este volumen vendrá determinado por el número de registros. A mayor conjunto de datos, mejor predicción.

¿Tomaríamos una decisión basada en una experiencia prácticamente inexistente? Seguramente no. El motivo es que no dispondríamos de suficiente respaldo para esa decisión. Lo mismo sucede con la predicción analítica.

Es posible generar modelos predictivos a partir de conjuntos pequeños de datos. Sin embargo, estos modelos no proporcionan una confianza lo suficientemente alta.

Imaginad que lanzamos un dado 6 veces y obtenemos las siguientes puntuaciones:

PuntuaciónNúmero de tiradas
10
23
30
41
50
62

Un modelo predictivo basado en este conjunto de observaciones, nos diría que probabilidad de que salga un número par al lanzar este dado en particular es del 100% (contra un 0% de que salga un número impar).

En este caso, la toma de decisiones basada en este modelo sería muy arriesgada (por sentido común).

Sin embargo, ¿qué confianza nos daría un modelo con esas probabilidades si el número de observaciones fuera 100? ¿Y 1000? ¿Y 1.000.000? Obviamente, la confianza sería mucho más alta. Y en este caso, seguramente nos plantearíamos si el dado está trucado.

Grandes conjuntos de variables

El número de variables a analizar determina el modelo de predicción. Un número muy bajo de variables es lo que hace que la gente se atreva a predecir qué va a suceder. En este caso, el comportamiento humano tiende a simplificar escenarios prescindiendo de variables, obviar casos que no se ciñan a lo esperado, etc. Esto deriva en una predicción falseada que afecta a la toma de decisiones.

Al incrementar el número de variables de un escenario, ese análisis se complica. Es en ese momento en el cual es necesario utilizar técnicas complejas de análisis que permitan analizar todas las variables disponibles.

El uso de un gran número de variables no significa que el modelo de predicción se base en todas ellas. Existen correlaciones y dependencias entre variables, lo cual hace que algunas de ellas impliquen los valores de otras. Por tanto, es posible que algunas, o gran parte de ellas no aparezcan en el modelo predictivo.

Conclusión

La predicción analítica permite obtener respuestas a qué va a suceder en el futuro con una probabilidad concreta en cada caso. El umbral del índice de confianza designado por el usuario para ese modelo determinará la toma de decisión final.

Para obtener un modelo de predicción con un alto nivel de confianza, es necesario disponer de un gran volumen de datos.

El gran número de variables permite generar un modelo de predicción más ajustado, ya que no obviamos información que puede acabar de determinar esa probabilidad final en cada caso.

La creación de un modelo de predicción requiere el uso de estadística avanzada o algoritmos de Inteligencia Artificial. Por tanto, es necesario contar con expertos en alguna de estas áreas que dispongan de la experiencia necesaria para poder obtener un modelo válido que aporte valor y sea válido para la toma de decisiones en una organización.

Monetización de los datos

 

El análisis de datos es usado principalmente para la obtención de respuestas que permitan mejorar la toma de decisiones dentro de una organización.

Un aspecto muy importante a tener en cuenta sobre ese análisis es el de los diferentes usos que se pueden dar a esos datos, tanto dentro como fuera de esa organización. Y es ahí, en el uso de los datos por entidades externas a dicha organización, donde el término «monetización de datos» adquiere una gran relevancia.

 

Ámbitos de aplicación de la información

Podemos distinguir dos ámbitos de aplicación de la información:

  • Interno (dentro de una organización)
  • Externo (fuera de ésta)

En el ámbito interno, los datos disponibles en la organización deben ser tratados y analizados para obtener información valiosa para los diferentes actores de los procesos de negocio internos. Es muy conveniente exponer esos datos en bruto y esa información derivada de éstos de manera transversal, para que todas las áreas de negocio puedan disponer de ellos. De esta manera, democratizando el acceso a la información, poniéndola al abasto de todos los empleados, se dispone de más herramientas para encontrar respuestas a nuestras preguntas. Y esto permite una mejor toma de decisiones.

Sin embargo, no hay que descuidar el ámbito externo en la explotación de esa información. Es decir, el uso de esos datos por organizaciones externas.

Monetización de los datos

Empecemos con unas preguntas:

  • ¿Pueden ser esos datos en bruto o esa información (producto del refinamiento de los datos) útiles para alguna organización externa?
  • ¿Qué valor tienen esos datos para esas organizaciones?
  • ¿Puede la organización propietaria de los datos beneficiarse de la venta de esos datos a terceros?

La monetización de datos o información consiste en la venta de éstos a organizaciones, y es la respuesta a las preguntas anteriores.

Cuando se dispone información que puede ser útil para otras organizaciones, ésta debe ser considerada como un producto con valor propio, que puede ser comercializado. Por tanto, es importante realizar un ejercicio visionario para encontrar ese mercado para los datos.

Por ejemplo, un municipio que disponga de sensores en la calle que permitan calcular el número y flujo de peatones en las calles, podría vender esa información a empresas de publicidad estática para poder determinar las mejores ubicaciones para la instalación de paneles publicitarios.

Respecto a cómo comercializar la información, el modelo puede ser el de venta puntual (e.g. Venta de todos los datos de un año en concreto) o por suscripción (e.g. Mensualmente se distribuyen los nuevos datos al comprador). Eso dependerá de las necesidades de los nuevos clientes y de la disponibilidad de los datos.

Aspectos éticos y legales

La venta de información debe ceñirse tanto a la ética como a la legalidad.

La cesión de información personal a terceros está regulada por la ley (ver GDPR – General Data Protection Regulation), con lo cual, las transacciones de intercambio de información deben cumplir los requisitos establecidos.

Además, hay que tener también en cuenta los aspectos éticos de la cesión y venta de información. El individuo debe dar consentimiento para la cesión o comercialización de sus datos personales, y debe ser capaz de modificarlos en cualquier momento. En este punto, afloran cuestiones como el hecho de cómo repercute esto sobre los datos previamente comercializados.

Estas cuestiones quedan fuera del alcance de este artículo y debe ser consultados con un profesional del ámbito legal.

En cualquier caso, si los datos personales no son necesarios, lo mejor es eliminar esa información en la distribución de información o anonimizarla para evitar riesgos innecesarios.

Conclusión

Los datos aportan la capacidad de mejorar la toma de decisiones. Pero también tienen un valor económico.

La venta de datos e información supone en sí un nuevo producto que puede ser comercializado.

Es de vital importancia cumplir con las normas legales y éticas a la hora de comercializar los datos de que disponen las organizaciones. La violación de éstas puede suponer la imposición de sanciones económicas muy importantes.

Efectividad de un proyecto de Business Intelligence

 

El éxito de un proyecto de Business Intelligence (o de Big Data) es una puerta a la continuidad. Es la diferencia entre seguir evolucionando una plataforma analítica de acuerdo con una estrategia bien definida o la siembra de dudas respecto a la conveniencia de seguir con esa línea.

La situación en la que nos hallamos es la siguiente: Después de muchos esfuerzos, nuestro proyecto de Business Intelligence ha llegado a su fin. Los usuarios ya tienen acceso a todas las funcionalidades analíticas estipuladas en los requerimientos. Pero, ¿cómo saber si el proyecto ha sido un éxito?

 

Factores de medida de éxito

Tradicionalmente el éxito de un proyecto se mide en base a los siguientes factores:

  • Cumplimientos de fechas indicadas en la planificación
  • Cumplimiento de los requerimientos
  • Ajuste sobre el presupuesto inicial

Estos tres actores suelen ser la vara de medir utilizada para determinar el éxito de un proyecto.

Sin embargo hay un par de factores muy importantes que suelen ser obviados.

  • Adopción de la solución por parte de los usuarios
  • Incremento de la efectividad en la toma de decisiones

Adopción de la solución por parte de los usuarios

Si después de realizar un proyecto los usuarios no utilizan la solución proporcionada, el proyecto debe considerarse un fracaso.

La inversión realizada tanto económicamente cómo en recursos humanos bien merece dar su fruto. Sin un beneficio para la organización el proyecto se convierte en un foso donde se han arrojado horas y dinero. Y esto es cierto, independientemente de que se hayan cumplido todos los objetivos de negocio detallados en los requerimientos del proyecto.

En ese caso el retorno de inversión (ROI) del proyecto será nulo. Y por tanto, desde el punto de vista de gestión económica del proyecto, éste será un gran fiasco. Todo proyecto debe proporcionar un retorno. Y un proyecto que no sea usado por los usuarios no tendrá un retorno de la inversión.

Incremento de la efectividad en la toma de decisiones

Si el punto anterior mide de manera cuantitativa la introducción de la solución en la base de usuarios ahora no centraremos en un análisis cualitativo.

En este caso, queremos medir cómo afecta a la toma de decisiones y sus resultados la introducción de la nueva solución analítica.

Para poder realizar el análisis comparativo es necesario disponer de datos de efectividad en la toma de decisiones con el modelo antiguo (antes de la introducción de la nueva solución). Estos datos son necesarios porque los utilizaremos como grupo de control sobre el que podremos comparar los resultados.

Una vez la nueva solución esté en uso, deberemos obtener datos de eficiencia para así comparar el rendimiento de los empleados antes y después de la adopción de la nueva solución.

Sin embargo también es necesario realizar ese análisis con los usuarios que no hayan adoptado la nueva solución. ¿Por qué? Porque pueden darse situaciones ajenas a la nueva solución que afectan por igual a los grupos. Este análisis del grupo de control y del nuevo grupo nos permitirá identificar si las diferencias se deben única y exclusivamente a la nueva solución adoptada o a otros factores.

Si nuestro análisis muestra que el segundo grupo obtiene mejores resultados podremos deducir que éstos se deben a la adopción de la solución. En cambio si los resultados son peores que los del grupo de control, podremos deducir que la nueva solución está empeorando los resultados.

Además podremos cuantificar esa mejora o pérdida en función de la diferencia de los resultados antes y después de la adopción de la nueva solución en ambos grupos. Podría darse que ambos mejoraran su rendimiento. En este caso, el análisis porcentual de la mejora nos permitiría identificarla cuantitativamente.

Consideraciones

En la fase incial de la adopción de la nueva solución, es posible que los resultados obtenidos sean inferiores a los que puedan obtenerse a medio plazo. Este hecho deberá tenerse en cuenta a la hora de valorar el éxito del proyecto. Por eso es conveniente realizar estos análisis de manera periódica, y realizar un seguimiento y dar formación a los usuarios para que puedan obtener el mayor rendimiento de la solución. De esta manera, es posible conseguir mejorar los resultados obtenidos inicialmente.

Conclusión

El éxito de un proyecto de Business Intelligence es de vital importancia para la continuidad de proyectos en una organización. Y para poder determinar el éxito real del proyecto, es necesario utilizar los indicadores adecuados.

La adopción y la productividad son esenciales para medir el éxito de un proyecto de BI. Si los pasamos por alto, podríamos tener una percepción errónea de la realidad. Y eso sería un estrepitoso fracaso en lo que se refiere a gestión de proyectos.