Big Data – Un arma de doble filo

Como consultor del Máster de BI de la UOC, es mi responsabilidad definir los trabajos que los estudiantes deben realizar en las asignaturas que imparto. Dentro de esta definición de trabajos, me gusta dar libertad a los estudiantes para que ellos mismos definan el escenario sobre el que basarse. De esta manera suprimimos la complejidad inicial de comprender un escenario desconocido para ellos. Este enfoque funciona muy bien pero a la vez acarrea un problema: Es el escenario de partida válido?

A lo largo de los semestres he podido constatar algo que ya había visto en mi vida profesional: Plantear soluciones mediante el uso de Big Data en escenarios que pueden resolverse mediante técnicas de BI tradicional es un error que se produce con demasiada asiduidad.

Big Data es un camino, no una finalidad

Big Data. Qué bien suena… Estas dos palabras están de moda. Quien implementa una solución con Big Data crece profesionalmente. Y las organizaciones adquieren un status de modernidad al ejecutar proyectos con esta tecnología.

Quizá sea esto lo que esté provocando que las organizaciones se estén lanzando a implementar soluciones de Big Data con tanto fervor. Pero, nos hemos parado a pensar si se trata de lo mejor para esa organización y en ese escenario concreto?

Es indudable que Big Data está mitificado. Se ha producido una corriente a nivel mundial que está constantemente alimentando este término. Eso está causando que se inicien proyectos de Big Data sin ser realmente necesarios.

Un proyecto de BI se inicia a partir de una necesidad de negocio. En la fase de obtención de requerimientos se identifican las fuentes de datos y la información a extraer de cada una de ellas. Y finalmente, después del análisis de dichos requerimientos, es cuando se diseña la solución que más convenga en cada escenario. Esta solución puede que implique el uso de Big Data, pero puede que no.

El planteamiento erróneo es el que define la tecnología sin tener en cuenta los requerimientos. He aquí un ejemplo:

Cuando se quiere analizar la información de Social Media de una organización, la gran mayoría de personas piensan inmediatamente en Big Data. Tengamos en cuenta este requerimiento de negocio:

  • Una organización quiere analizar el número de comentarios recibidos en su página de Facebook en función de la fecha y el país de origen de los comentarios.
  • Esta información será analizada semanalmente y utilizada para definir la línea a seguir en las siguientes semanas en Social Media.
  • El número de posts diarios es de cinco como máximo.
  • El número de comentarios recibidos no ha excedido nunca los 10.000 semanales.

La información requerida está disponible a partir del análisis básico de los campos proporcionados por Facebook. Es pues necesario implementar Big Data? La respuesta es “no”. Por volumen, velocidad de generación y estructura de datos, la información necesaria para el análisis puede ser obtenida mediante herramientas de BI tradicionales. En este caso, no es necesario embarcarse en un proyecto de Big Data, ya que el coste y el riesgo son elevados.
 

Big Data, “Big Risk”

Big Data significa el uso de una nueva tecnología, de un paradigma de diseño distinto a los utilizados en el BI tradicional, y de formación nueva y especializada para los equipos de proyecto.

Big Data usa una tecnología aún en fase de crecimiento, una tecnología no lo suficientemente madura, donde los cambios y las mejoras se suceden constantemente. Esto significa que los componentes usados en un proyecto pueden quedar anticuados en un periodo corto de tiempo debido a esa constante evolución.

Así pues, podemos resumir los riesgos introducidos hoy en día al implementar un proyecto de Big Data en:

  • Tecnología no consolidada
  • Necesidad de formación y de cambio de mentalidad del equipo de proyecto

Con estos riesgos, cabe pues plantearse si el uso de Big Data en un proyecto es realmente necesario cuando es posible obtener las mismas respuestas mediante técnicas de BI tradicionales.

 

Resumen

  • Big Data nos permite poder analizar datos que en el pasado eran descartados para el análisis.
  • El uso de Big Data en un proyecto debe responder a necesidades de acceso y tratamiento de la información.
  • Si los requerimientos de negocio pueden satisfacerse mediante la implementación de una solución de BI tradicional, la elección de Big Data supondría un riesgo añadido en el proyecto.
  • Tratándose de una nueva tecnología aún en evolución, hay un elevado riesgo de que ésta quede obsoleto en un plazo relativamente corto.
  • Los equipos implicados en el diseño y desarrollo de una solución de BI con Big Data, deben adaptarse a un nuevo paradigma de programación, lo que constituye de por sí un importante riesgo.

Si quieres conocer más acerca de Big Data, no lo dudes y ponte en contacto conmigo.

Business Intelligence en tiempo real

Una solución de Business Intelligence (BI) debe permitir el análisis de datos para la extracción de conocimiento que aporte valor añadido para así poder mejorar los diferentes procesos de una organización.

Históricamente el BI se ha basado en cargas diarias de datos que se acumulan en un almacén de datos (data warehouse). Esto significa que los datos del data warehouse son estáticos e invariables hasta la ejecución de una nueva carga. Sin embargo, desde hace unos años, ha surgido una nueva tendencia en el análisis de datos: el BI en tiempo real.

En este artículo quiero invitaros a reflexionar sobre los siguientes temas:

  • Requerimientos de negocio: Es necesario analizar datos en tiempo real?
  • Arquitectura de un sistema de BI en tiempo real
  • Herramienta de BI y federación de datos

Todos ellos son, a mi entender, aspectos muy importantes a tener en cuenta al abordar un proyecto de BI con datos en tiempo real, y que suelen obviarse cuando se carece de experiencia en este tipo de proyectos.

Requerimientos de negocio: Es necesario analizar datos en tiempo real?

Al iniciar el proyecto de BI debemos obtener los requerimientos de negocio. Durante esta fase es muy importante identificar el retardo máximo (la latencia máxima) con la que los datos deben estar disponibles para su análisis. Ello nos indicará si bien los datos pueden incorporarse al data warehouse de manera diaria, deben ser cargados varias veces durante el día, o bien si deben estar disponibles en el mismo momento en que son introducidos en la fuente de datos.

La identificación de la latencia máxima debe hacerse en base a criterios de negocio y teniendo en cuenta el tipo de análisis a realizar. De ella dependerá cómo los datos se van a incorporar al data warehouse. Veamos un par de ejemplos:

Latencia máxima menor que 24 horas

Las ventas de una compañía multinacional se realizan a través de su página web. Cada día se ofertan una serie de productos que se venden a un ritmo de miles de ventas por minuto en todo el mundo. Negocio desea poder detectar posibles caídas bruscas del número de ventas, que deberán ser investigadas y resueltas de manera urgente. Se determina la latencia máxima para la ejecución del informe de tipo operacional en 2′.

En este caso, los criterios de negocio indican una necesidad de información en un periodo corto (2′). Con una carga diaria, los datos no estarían disponibles hasta el día siguiente, lo que no permitiría reaccionar en un periodo de tiempo corto para así solucionar el problema.

Latencia máxima mayor o igual que 24 horas

Tomando como punto de partida la compañía del escenario anterior y dentro del entorno de ventas, éstas deben ser analizadas para ver su progresión respecto a los objetivos marcados a nivel anual. En este caso, las ventas realizadas durante el último día no afectarán en gran manera a los resultados del análisis, por lo que se no son estrictamente necesarias.

En este escenario, los criterios de negocio no indican una necesidad de información durante el día en curso. Con una carga diaria es suficiente para poder mostrar el análisis deseado el día siguiente. Si bien disponer de datos más actualizados mostraría una información más ajustada a la realidad, la variación se considera mínima, con lo que una latencia máxima inferior a 24 horas no es un requerimiento de negocio.

Arquitectura de un sistema de BI en tiempo real

La necesidad de incorporar datos al data warehouse en tiempo real o casi real implica cambios en la arquitectura de los procesos de carga del data warehouse y de las estructuras de datos de éste. Cada uno de los casos tiene sus particularidades.

BI en tiempo real

El BI en tiempo real requiere que los datos estén disponibles un instante después de ser incorporados a la fuente de datos. Esta necesidad se traduce en la ausencia de cargas de datos al data warehouse. En su lugar, el acceso a los datos se realiza directamente sobre la fuente de datos o una réplica de ésta. En este último caso hay que tener en cuenta que habrá que disponer una tecnología capaz de replicar los datos originales en tiempo real.

BI en tiempo casi real

El BI en tiempo casi real, por su parte, nos permite cierto retraso a la hora de disponer de esos datos. Ese retraso puede ser de segundos, minutos y hasta de varias horas. En este caso sí que podremos ejecutar cargas de datos al data warehouse. Sin embargo, el tipo de carga a realizar, la cantidad de información a incorporar, la tecnología utilizada y el destino de los datos dependerá de la frecuencia de las cargas y la duración de éstas. Cabe notar que en el caso de una frecuencia alta de cargas, es muy posible que los datos no puedan integrarse en el data warehouse y deban almacenarse en una área alternativa, también llamada partición de tiempo real del data warehouse.

Herramienta de BI y federación de datos

En una solución de BI en tiempo real y probablemente también en una solución de BI en tiempo casi real, los datos estarán almacenados en una área diferente a la de los datos del data warehouse. Para poder analizar la totalidad de los datos y tratarlos como una sola fuente de información, es necesario mapear las diferentes estructuras de datos (data warehouse, partición de tiempo real, y fuente de datos) a un modelo lógico común basado en el modelo de negocio. Esta integración de distintas estructuras de datos en un modelo lógico único recibe el nombre de federación de datos.

Es muy importante tener en cuenta la necesidad de federar datos a la hora de elegir la herramienta de BI, puesto que la federación de datos es una capacidad que no está disponible en todas las herramientas de BI del mercado. Por tanto, la elección de la herramienta a utilizar debería realizarse una vez los requerimientos hayan sido obtenidos y analizados. Tan solo así nos aseguraremos de disponer de una solución de BI que se adapte a las necesidades de negocio.

Resumen

  • La identificación de la latencia máxima en el acceso a la información en un sistema de BI es una tarea clave en la obtención de los requerimientos de negocio de un proyecto de BI.
  • La necesidad de disponer de datos en tiempo real o casi real determinará la arquitectura, el software y el sistema de comunicaciones en un sistema de BI.
  • La inclusión en un mismo análisis de datos históricos y datos actuales requiere la combinación de ambos subconjuntos de datos bajo el mismo prisma de negocio. Esto es lo que se llama federación de datos.
  • La elección de la herramienta de BI a utilizar dependerá, entre otros muchos factores, de la necesidad del usuario de acceder a datos federados, ya que no todas las herramientas del mercado disponen de esta capacidad.
Si quieres conocer más acerca del BI en tiempo real, no lo dudes, contacta conmigo.