Analytics: Un juego de niños

Posted on by moon

 

A menudo me encuentro con personas en las empresas que dicen no tener datos suficientes para iniciar un proyecto de Data Analytics para la mejora de la toma de decisiones.

(… Sin comentarios)

Hoy os quiero presentar un caso basado en mi propia experiencia, para ilustrar como hasta los niños son capaces de obtener datos para así analizar sus actos y poder mejorar su rendimiento.

Escenario

El baloncesto, como cualquier otro deporte, nos da la oportunidad de capturar muchos datos. En las ligas profesionales, existe todo un ejército de personas dedicadas a la captura de estos datos, bien a través de tecnología sofisticada (como el posicionamiento de los jugadores y el balón a través de cámaras), bien manualmente (otorgar una asistencia a un jugador depende en cierto modo del criterio de una persona).

Durante un par de años tuve el privilegio de poder ejercer de entrenador asistente en equipos de categorías inferiores. Al asumir ese cargo, brotó en mí una idea: ¿Y si pudiéramos mejorar el rendimiento del equipo a partir del análisis de los datos obtenidos durante los partidos?

Desde el punto de vista de recolección de datos, solamente estaba yo para poder realizar esa tarea. Y lo cierto es que durante los partidos, un entrenador asistente tiene que estar atento a un sinfín de cosas para poder ayudar al entrenador principal. Por tanto, mi gozo en un pozo. Sin embargo, en algunos partidos sí que pude obtener algunos datos. Datos que terminaron convirtiéndose en información muy valiosa.

De los datos a la toma de decisión

La sensación es que el equipo tenía un gran problema: Perdíamos muchos balones. Pero, ¿realmente perdíamos tantos balones? Decidí hacer un estudio en base a los cuatro siguientes partidos.

Los datos que capturé durante esos partidos fueron:

  • Número de posesiones
  • Número de balones perdidos

De esta manera, pude obtener un porcentaje de balones perdidos.

El método de recolección de datos fue realmente «alta tecnología». Utilicé el método clásico de papel, lápiz y palitos.

Hay que tener en cuenta que, dependiendo del ritmo del partido, podíamos oscilar entre 70 y 100 posesiones por partido. Por tanto, el número de pérdidas era susceptible de una gran variabilidad.

Los resultados arrojaron un dato demoledor: El equipo perdía el balón en el 68% de las posesiones.

El trabajo que se hizo con esta información fue doble:

  • A nivel de entrenamientos se tomó la decisión de trabajar tanto la técnica como la táctica para minimizar las pérdidas.
  • A nivel de cada jugador, hubo una concienciación del problema con los balones perdidos, lo cual supuso un aumento de la concentración y la responsabilidad de los jugadores para minimizar ese número (esa fue la toma de decisión que los propios jugadores decidieron llevar a cabo).

Los resultados de los tres próximos partidos fueron demoledores. Por citar los dos más importantes:

  • Las pérdidas se redujeron al 47% de las posesiones.
  • El porcentaje de pérdidas en cada uno de esos tres partidos fue significativamente inferior al porcentaje de pérdidas mínimo de los cuatro partidos de la muestra inicial.

Querer es poder

Si un equipo de baloncesto integrado por niños es capaz de tomar decisiones para cambiar sus procesos a partir de cuatro palitos mal puestos en una hoja de papel, ¿qué puede llegar a hacer una organización en pleno siglo XXI?

Lo más importante a la hora de embarcarse en un proyecto de Data Analytics no es disponer de datos. La experiencia me dice que lo más importante es la actitud. El deseo de obtener datos y poderlos convertir en conocimiento para mejorar la toma de decisiones es lo que permite a las organizaciones avanzar en su camino hacia la toma inteligente de decisiones.

Es por eso que es tan importante que las personas que toman decisiones, los verdaderos sponsors del proyecto, estén convencidas de la necesidad de dar ese paso. Solamente de esta manera podrán generar un cambio en la cultura de la organización para la aceptación de este nuevo modelo de toma de decisiones.

Conclusión

Toda actividad es medible.

La recolección de datos siempre es posible… si hay voluntad para ello.

Cualquier persona de cualquier edad (incluidos niños de un equipo de baloncesto de nivel muy bajo) puede tomar decisiones de manera inteligente a partir de datos que aporten valor.

La existencia de sponsors fuertes convencidos de la necesidad de un cambio en la cultura de las organizaciones es clave para el éxito de los proyectos de Data Analytics.

Customización vs. Mantenibilidad

Posted on by moon

 

Toda solución analítica tiene como objetivo satisfacer los requerimientos de obtención de información de los usuarios para la toma de decisiones. Sin embargo, este no es el único objetivo a tener en cuenta. Existen otras cuestiones que debemos tener en cuenta y que son tan o más importantes que el mero hecho de satisfacer los requerimientos de los usuarios.

Uno de ellos es la mantenibilidad de la solución tecnológica, tal y como se indica en el artículo «Calidad en un sistema de BI – Un beneficio para todo«. En este artículo se plantea el conflicto entre estos dos objetivos.

 

Satisfacción del usuario

La importancia de satisfacer al usuario va más allá del mero hecho de que la solución tecnológica cumpla con los requerimientos.

Un proyecto que no dé al usuario aquello que necesita, es un proyecto que no será utilizado por el usuario. Y por tanto, un fracaso rotundo. De ahí la importancia de satisfacer los requerimientos de usuario.

No obstante, debemos plantearnos siempre la necesidad real de ese requerimiento si no queremos estar altamente condicionados por los requerimientos. Es decir, el mero hecho de que un usuario indique que algo es importante no significa que realmente lo sea. Una lista de deseos del usuario no es motivo suficiente para hipotecar otros objetivos de un proyecto que pueden ser tan o más importantes que los requerimientos de usuario.

En el caso de una solución analítica genérica, podemos aplicar customizaciones para satisfacer algunos requerimientos de usuario concretos. Pero, ¿cómo afectaría esto al proyecto en el futuro?

Mantenibilidad

Un proyecto tecnológico no se acaba en el momento en que éste se entrega. Después de poner el proyecto a disponibilidad de los usuarios, empieza la fase de mantenimiento.

En esta fase, hay que realizar tareas correctivas y evolutivas que requieren la modificación de la solución tecnológica. Estas modificaciones tienen un coste que se cuantifica en términos de mano de obra y a la postre en un coste económico.

La mantenibilidad indica el grado de facilidad del mantenimiento de una solución. A mayor grado de mantenibilidad, menor coste de mantenimiento. Por tanto, es muy importante mantener un grado de mantenibilidad alto. De esta manera, conseguimos reducir el coste de las tareas de mantenimiento, tanto correctivo como evolutivo. Y debemos tener en cuenta que esta fase acaba siendo la que se dilata más en el tiempo, por muy largo que haya sido el periodo de desarrollo de un proyecto.

Conflicto entre objetivos

La mantenibilidad está reñida con otros objetivos de todo proyecto informático como pueden ser la eficiencia y la satisfacción completa de los requerimientos de usuario.

Un ejemplo clásico de requerimiento de usuario en una solución analítica es el de la construcción de un informe que obtenga una información concreta en el mínimo tiempo posible.

Ante este requerimiento es importante plantearse un par de cuestiones:

  • ¿Es posible reducir el tiempo de ejecución de una consulta concreta creada por una solución analítica genérica? Las consultas creadas a partir de soluciones genéricas suelen no ofrecer el mejor rendimiento posible, ya que una solución a medida estará más ajustada. Por tanto, sí es posible reducir el tiempo de consulta.
  • ¿Cuál es el tiempo máximo que un usuario puede esperar para tener la información que obtiene de la consulta, que le permitirá tomar una decisión con valor para su organización? Esta respuesta la tiene que proporcionar el usuario. Lo que sucede a menudo es que el tiempo máximo que pide el usuario no es para la toma de decisiones sin pérdida de la oportunidad de la información, sino que responde al tiempo máximo que el usuario quiere esperar delante de la pantalla a obtener los resultados.

Ante estas dos cuestiones, debemos valorar qué es más importante: Ofrecer una respuesta rápida al usuario (reduciendo el grado de mantenibilidad de la solución analítica) o mantener un grado de mantenibilidad alto en nuestra solución (aunque ello implique la no satisfacción del usuario).

Mi opinión es que, dentro de lo que sea posible, se debe hacer un esfuerzo por mantener el grado de mantenibilidad de una solución analítica, intentando minimizar las customizaciones. Para ello es muy importante comunicar correctamente los objetivos tanto a los usuarios como a los sponsors del proyecto (para buscar su apoyo en la mediación con los usuarios). De esta manera conseguiremos contener el coste de mantenimiento de la solución analítica, que no deja de ser otro objetivo clave.

Conclusión

La satisfacción de los requerimientos de usuario es uno de los objetivos primordiales en todo proyecto de creación de una solución analítica, aunque no el único.

Mantener un grado de mantenibilidad alto permite reducir los costes en la fase de mantenimiento de un proyecto. Y reducir los costes es un objetivo de vital importancia.

Existen conflictos entre objetivos, como puede ser entre la satisfacción de los requerimientos de usuario y la mantenibilidad de una solución.

La comunicación efectiva de los objetivos a sponsors y usuarios nos permite negociar las posibles situaciones de conflictos entre objetivos.

Visualización efectiva de información

Posted on by moon

 

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

Posted on by moon

 

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

Posted on by moon

 

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

Posted on by moon

 

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

Posted on by moon

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

Posted on by moon

 

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

Posted on by moon

 

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

Posted on by moon

 

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.