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.

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.

Top 3 errores en el diseño del modelo de datos de un Data Warehouse

 

El componente principal de una solución de Business Intelligence es el Data Warehouse, el almacén de datos donde guardamos toda la información que vamos a analizar. ¿Cómo saber si el diseño del modelo de datos de tu Data Warehouse, y por extensión de tu solución de Business Intelligence es de calidad o no? ¿Cómo puedes saber si el dinero que has invertido en esta tarea ha revertido en una solución de calidad?

En este artículo te presento los 3 errores más comunes en el diseño de modelos de datos de un Data Warehouse. Esta lista ha sido elaborada a partir de mi experiencia a lo largo de más de 17 años diseñando soluciones de Business intelligence. Es posible que haya otros errores de gran calado que se repitan en otras implementaciones de soluciones de Business Intelligence. Pero yo os hablaré de las que me he encontrado más a menudo a lo largo de mi carrera como consultor.

#1 Un elevado número de joins

Una solución de Business Intelligence tiene como objeto analizar un gran número de datos de manera eficiente. La operación más costosa en el acceso a las tablas donde se encuentran los datos es la join entre dos tablas (lo que se conoce como «cruzar» la información de dos tablas). Por tanto, minimizar el número de joins es vital para obtener un gran rendimiento en las consultas.

Para ello existe el modelo dimensional. Al utilizar esta técnica de diseño del modelo datos, minimizamos el número de joins aumentando así el rendimiento de las consultas respecto al diseño de datos transaccional. En contraposición, una solución de Business Intelligence que trabaje directamente sobre el modelo transaccional (con un elevado número de joins), implicará un alto coste en el acceso a los datos.

En varias ocasiones me he encontrado con aparentes diseños dimensionales basados en realidad en vistas y no en tablas. Es decir, sobre el papel el modelo era dimensional. Pero, sin embargo, en vez de tablas se estaban utilizando vistas. Por tanto, las consultas acababan accediendo a una gran cantidad de tablas, realizando a la vez una gran cantidad de operaciones de join. En este caso, el rendimiento de las consultas es, evidentemente, muy bajo.

#2 Diseñar las tablas a partir de los informes finales

Cuando diseñamos el modelo de datos es importante tener en cuenta las necesidades de acceso a la información de los usuarios. Al hacer esto, somos capaces de identificar las métricas e indicadores por una parte, y las dimensiones necesarias para el modelo de negocio que vamos a diseñar. Sin embargo, basar nuestro diseño únicamente en los informes, suele acarrear errores de diseño.

Por una parte nos alejamos de la metodología de diseño que nos proporcionará esas dimensiones y esas tablas de hechos sobre las cuales basamos el modelo dimensional. Por otra estaremos ligando nuestro modelo de datos a una visión particular de los datos (la de los usuarios). Y en el momento en que los usuarios quieran modificar esa visión de los datos, la tabla que habremos creado sobre unos informes específicos, deberá ser modificada para poder incluir la nueva información que el usuario quiera visualizar.

El mero hecho de añadir una columna a un informe puede conllevar la modificación de una tabla, y por tanto de la carga de datos. Y el coste de realizar ese cambio será muy elevado.

Cierto es que el hecho de disponer de tablas con toda la información necesaria para un informe nos permite acceder a esa información sin necesidad de hacer ninguna join. Sin embargo, diseñar un modelo de datos en base a este sistema de trabajo, no permite reaprovechar las distintas tablas del Data Warehouse, ya sean de dimensiones o de hechos. De esta manera, el modelo de negocio que vamos a diseñar en nuestras herramienta de Business Intelligence, estará ligado no a un modelo de datos genérico sino a los diferentes informes de usuario.

#3 No usar claves sinteticas (surrogate keys)

Es común que las diferentes tablas de nuestros sistemas transaccionales dispongan de claves primarias (claves que identifican unívocamente los diferentes registros de la tabla y que a la vez no pueden ser nulos).

Los diseñadores inexpertos suelen cometer un grave error confiando en estas claves primarias para ejercer como claves primarias del Data Warehouse. Sin embargo, hay varias razones por las cuales utilizar estas claves primarias de los sistemas transaccionales no está recomendado a la hora de diseñar un Data Warehouse.

Estas claves primarias transaccionales pueden variar con el tiempo. Situaciones como migraciones y cargas masivas de datos de otros sistemas informáticos, pueden modificar los valores de esas claves primarias o producir duplicados. Esto puede ser algo relativamente sencillo de corregir en las tablas dimensiones. Pero adaptar esos nuevos valores en las diferentes tablas de hechos (cabe recordar que son las tablas con más volumen de registros en un Data Warehouse), supone un gran esfuerzo, que a menudo resulta demasiado grande.

Además, esas claves primarias transaccionales pueden contener valores alfanuméricos. Este hecho penaliza el rendimiento del sistema ya que la longitud del registro de las tablas de hechos se ve incrementado y por tanto el throughput (número de registros por unidad de espacio en disco) de acceso a los datos disminuye.

El uso de claves sinteticas con valores numéricos (de tamaño mucho menor que las claves alfanuméricas) permite optimizar el acceso a las tablas de hechos mejorando así al rendimiento de las consultas.

Conclusión

El diseño del modelo de datos de un sistema analítico es esencial para obtener un buen rendimiento en las consultas. Un elevado número de joins, un diseño orientado a los informes finales, y el uso de las claves primarias del sistema transaccional son tres grandes errores evitar en nuestra solución de Business Intelligence.

Para evitar caer en estos errores es primordial contar con un equipo de expertos con una amplia experiencia en el diseño de soluciones de Business Intelligence. Si una solución existente no ofrece el rendimiento esperado y es difícil de mantener, es posible que contenga alguno de estos errores.

Si una solución de Business Intelligence incluye alguno de estos diseños erróneos, estos deberán estar debidamente justificados. De no ser así, sabremos que se trata de un error de diseño.

¿Realmente sabes cómo está diseñada tú solución de Business Intelligence por dentro? Si tu respuesta es «No», una auditoría puede ayudarte. Y si estás pensando en crear una nueva solución de Business Intelligence, te recomiendo que acudas a un experto que pueda verificar los diseños generados por tu proveedor de servicios. Una segunda opinión, una verificación de los diseños antes de que sea demasiado tarde, te puede salvar de males mayores en el futuro.

¿Porqué necesitas una estrategia de BI?

 

 

La gran mayoría de las empresas han oído hablar de Business Intelligence. Es un tema muy interesante y la vez atractivo, por el hecho de poder tomar decisiones basadas en información que a menudo puede escaparse de la percepción de quienes deben tomar esas decisiones.

Y eso hace que las empresas quieran innovar dentro de este campo.

 

Palos de ciego

Sin embargo, la mayoría de empresas carecen del personal y la experiencia necesaria para desarrollar proyectos de Business Intelligence. Y por tanto, su enfoque suele ser el de empezar con un proyecto piloto para ver los beneficios que un proyecto de estas características puede beneficiar a su organización. No es un mal enforque inicial. Lo malo es que después de este primer proyecto, aparecen nuevas necesidades abordadas directamente, sin una visión de futuro, sin un objetivo a medio o largo plazo en mente.

Esa visión a medio y largo plazo es la estrategia de Business Intelligence.

A menudo me encuentro en situaciones en las que tengo que exponer a mis clientes que esa manera de abordar proyectos de Business Intelligence no es la que les va a aportar más beneficios a medio y largo plazo.

Buscando un símil

En estos casos, siempre les planteo un par o tres de situaciones para que vean el sinsentido de su enfoque.

Por ejemplo, ¿qué sucede cuando queremos decorar nuestra sala de estar y no tenemos una idea clara del estilo a seguir?

El resultado puede ser que acabemos con una mezcla de estilos, siendo ésta más perjudicial que beneficiosa. Podemos acabar con una mesa de madera de teka, un mueble de estilo rococó, unas lámparas de estilo minimalista y un sofá digna de una película de los años 50. A la vista está que una sala de estar con esta decoración carece de sentido. Es posible que haya satisfecho esos deseos individuales por lo que se refiere a cada uno de los elementos decorativos. Sin embargo, el conjunto no nos proporcionará una experiencia consistente que realce sus cualidades y que aporte un alto valor visual.

Beneficios de tener una estrategia

Definir una estrategia de Business Intelligence que permita que todos los desarrollos realizados aporten un alto valor añadido a una parte y a todo el conjunto de la organización es esencial para el buen gobierno de la información de ésta

Una estrategia de Business Intelligence permite identificar las prioridades a nivel de análisis de información en una organización, organizar esos requerimientos en proyectos y finalmente priorizarloos en función de la necesidad y los recursos disponibles.

Las organizaciones que disponen de una estrategia de Business Intelligence consiguen una mayor eficiencia en el desarrollo de sus proyectos a la vez que minimizan los cambios en los diferentes componentes analíticos debido a su previa planificación.

Carecer de una estrategia de Business Intelligence suele implicar, en la mayoría de los casos, un sobrecoste en el desarrollo de soluciones. Además, supone un aumento del riesgo respecto a la eficacia de la solución como respuesta a los requerimientos analíticos de toda la organización.

Conclusión

La definición y adopción de una estrategia de Business Intelligence en las organizaciones no solamente responde al gusto por el seguimiento de un enfoque organizado y premeditado. Supone un beneficio para la organización en términos económicos y funcionales.

Optar por un enfoque sin una estrategia de Business Intelligence es claramente un error que puede tener graves consecuencias económicas.

Las pruebas de concepto y proyectos piloto son una muy buena opción para determinar la viabilidad de un proyecto y los beneficios aportados por éste. Sin embargo, continuar con el desarrollo de proyectos sobre prueba de concepto, y evolucionar una plataforma de manera no planificada, es una mala decisión estratégica.

La decisión de que pertenece a las organizaciones. Como consultor y asesor en el área del Business Intelligence, mi labor es el de comunicar a mis clientes los beneficios e inconvenientes de ambos enfoques. Y cuando se me pregunta por una recomendación, lo tengo claro. Es esencial tener una estrategia de Business Intelligence.

Infoxicación

Disponer de un gran volumen de datos de diferente naturaleza es la base para un buen análisis que nos permita una toma de decisiones inteligente.

Sin embargo, una gran cantidad y variedad de datos puede derivar en dificultades a la hora de tratar toda esa información. Es lo que se denomina infoxicación.

Definición

La infoxicación es la imposibilidad de poder procesar y analizar los datos que alimentan un repositorio de información.

Esta situación puede producirse por dos causas:

  • La existencia de grandes volúmenes de datos
  • La generación de información a una velocidad superior a la de proceso y análisis

Cuando una solución tecnológica no es capaz de procesar todos los datos respetando los requerimientos de urgencia de los usuarios, ésta no puede aportar todo el valor necesario. En esta situación, hablamos de infoxicación.

Causas

La imposibilidad de procesar todos los datos a tiempo puede producirse por la existencia de grandes volúmenes de datos y por una velocidad de generación de datos muy elevada.

Los datos de un repositorio analítico deben ser procesados para su posterior análisis. Estas son las dos fases sobre las que actúa la infoxicación.

Si bien el proceso de los datos (entendido como la captación de éstos) cuando hay grandes volúmenes de datos no implica grandes dificultades, sí que podemos encontrarlas a la hora de refinar esos datos en las tareas de análisis. Cruzar (hacer una join, un lookup) datos relacionados tiene un coste que augmenta de manera logarítmica con el número de registros a tratar. Como es de imaginar, con volúmenes masivos de datos, el coste puede llegar a ser muy elevado. Y puede serlo tanto que el sistema sea incapaz de finalizar esta tarea antes del siguiente proceso por lotes analítico (e.g. la siguiente carga de datos).

En el caso de la generación de datos a una gran velocidad, el problema aparece en el procesado de los datos. Cuando éstos llegan al sistema, deben ser consumidos a una velocidad igual o superior a la de generación. En caso contrario, los datos se acumularán a la espera de ser procesados. Y esa acumulación puede ir incrementándose hasta el punto en que podemos llegar a perder datos.

En cualquiera de estas situaciones, el riesgo está en la imposibilidad de producir información a partir de unos datos de entrada, o de generar esa información demasiado tarde, con lo cual el usuario no obtiene valor para una toma de decisiones inteligente.

Solución

Ante una situación así, es necesario diseñar un sistema de proceso y análisis del dato que permita subsanar las dificultades de cada escenario.

Utilizar una solución técnica basada en la tecnología Big Data nos permite resolver los problemas derivados de las carencias en el proceso y análisis en estas situaciones.

La escalabilidad de un cluster de Big Data y la computación distribuida inherente a este tipo de arquitecturas, proporcionan la capacidad de tratar grandes volúmenes de datos generados a una gran velocidad.

Conclusión

La infoxicación es la imposibilidad de tratar datos y ofrecer al usuario información de valor para la toma de decisiones, debido al gran volumen o la alta velocidad en la generación de los datos.

Las consecuencias de la infoxicación son la pérdida de datos y la tardía generación de información. Ante esas situaciones, la información bien no existe bien carece de valor.

El uso de una solución basada en Big Data permite resolver estas limitaciones, permitiendo a los usuarios disponer de la información requerida dentro de los términos útiles para la toma de decisiones.

Definición de requerimientos en un proyecto de Business Intelligence

 

En todo proyecto de Business Intelligence existe una fase inicial que proporciona la base sobre la que debe definirse el proyecto: La definición de requerimientos.

Se trata de la fase más importante de todo el proyecto. Una mala definición de requerimientos tendrá implicaciones negativas en el resto del proyecto. Y para eso, es crucial disponer de los conocimientos y la experiencia necesaria para abordar esta fase.

Hay que tener en cuenta que los proyectos de Business Intelligence tienen grandes peculiaridades que los hacen especiales, difíciles de gestionar. Es por eso que la gestión de proyectos llevada a cabo por personas sin experiencia previa en la gestión de proyectos de Business Intelligence conlleva un alto riesgo. Todo ello provoca que el índice de éxito de este tipo de proyectos sea, en comparación con proyectos de desarrollo de software, mucho menor.

Requerimientos genéricos y acordados

Obtener los requerimientos a partir de documentos generados por los usuarios puede, a primera vista, verse como algo altamente positivo, ya que permitiría cerrar la fase de obtención de requerimientos de manera simple. Sin embargo, utilizar esta metodología conlleva un gran riesgo: Obtener requerimientos demasiado específicos.

La obtención de requerimientos se debe realizar a partir de reuniones con los distintos usuarios del sistema. Durante estas reuniones, los usuarios deben exponer sus necesidades mientras que el encargado de obtener los requerimientos deberá interponer preguntas cuestionando estos requerimientos y dirigiendo a los usuarios a un punto de convergencia, a un acuerdo donde sus necesidades se vean cubiertas por los diferentes requerimientos definidos.

La documentación de los requerimientos por parte de los usuarios, previa a estas reuniones, es de gran ayuda para que los usuarios tengan claro qué necesitan de la solución de Business Intelligence. Sin embargo, esa información no debería pasar directamente a la lista de requerimientos del proyecto sin antes efectuar esta serie de reuniones con el objetivo de refinar y acordar esos requerimientos, para así amoldarlos a todos los usuarios.

A continuación se presentan un par de ejemplos sobre especificidad de requerimientos como muestra del riesgo que esto supone.

Sobrecoste del proyecto

El primer ejemplo trata del aumento de coste del proyecto a partir de una mala toma de requerimientos.

Imaginemos un usuario qué necesita disponer de un informe de ventas para el mes en curso para así poder monitorizar posibles desviaciones respecto a los objetivos definidos. El fin de este informe es el de poder disponer nuevas medidas para reconducir la situación en caso de desviaciones negativas.

Ahora imaginemos otro usuario que necesita información de las ventas del mes anterior para poder hacer el informe mensual de cierre de ventas.

La obtención de requerimientos directamente de los usuarios sin la posibilidad de modificación de aquellos, supone la definición de dos informes diferentes:

  • Ventas del mes actual
  • Ventas del mes anterior

Sin embargo, podría ser que estos dos informes pudieran ser fusionados en uno solo. En el caso en que ambos informes necesitaran diferentes columnas, es muy probable que podamos llegar a un acuerdo para fusionar ambos informes y generar uno solo con la fusión de ambos conjuntos de columnas. De esta manera, un solo informe sería suficiente para poder dar servicio a ambos usuarios. Esto significaría una reducción en la carga de trabajo en la fase de diseño y desarrollo, en la gestión del proyecto, en las pruebas y en la puesta en marcha del proyecto. Asimismo, también reduciría el coste de mantenimiento del proyecto una vez éste estuviera en producción.

El uso de personal con experiencia en proyectos de Business Intelligence durante la toma de requerimientos permitiría detectar escenarios como éste.

Mi experiencia personal me remite a casos en los que, a partir de una lista original de más de 200 informes, se pudo reducir el número de informes final a poco más del 50 (una reducción del 75%).

Gracias a esto se pudo llevar a cabo el proyecto. Si hubiésemos tenido que hacer una valoración del proyecto a partir de los requerimientos iniciales, se habría superado el presupuesto y por tanto el proyecto no se habría llevado a cabo.

Definición incompleta de dimensiones

El segundo ejemplo trata de la definición de dimensiones a partir de los informes específicos requeridos por los usuarios.

La definición de los informes basados en las necesidades de un usuario suele ser muy específica. Es decir, el usuario se concentra en las columnas necesarias únicamente para su informe. Por tanto, los requerimientos obtenidos a partir de informes de usuario suelen ser pobres, limitantes y poco generalistas.

El diseño de una solución a partir de estas especificidades supone tener una visión incompleta del ámbito global del sistema. Lo cual significa que definir los requerimientos de un sistema de Business Intelligence a partir de los informes de usuario o de la visión que los usuarios pueden tener de la solución a partir de los informes que necesitan, es un enfoque erróneo.

Volviendo al ejemplo de las ventas por mes, la toma de requerimientos realizada por una persona inexperta podría limitar la dimensión temporal a una granularidad a nivel de mes (y, otorgándole un voto de confianza, con agregaciones a nivel de trimestre, semestre y año).

Esta definición de la dimensión temporal es claramente limitante y erróneo, puesto que las transacciones de venta están definidas a un nivel más bajo (por supuesto a nivel de día, o quizá a nivel de hora, minuto y segundo).

Lo mismo puede suceder con cualquier otra dimensión asociada a una tabla de hechos. Si basamos los requerimientos en los informes o en lo que los usuarios creen que necesita el nuevo sistema de Business Intelligence, podemos caer en el error de definir dimensiones con una granularidad superior a la real, y podemos obviar información útil que podría proporcionar un análisis con un alto valor añadido en el futuro.

Conclusión

La obtención de requerimientos en un proyecto de Business Intelligence es una tarea clave para el éxito del proyecto.

Su ejecución requiere un alto nivel de experiencia en proyectos de Business Intelligence para poder llevarla a cabo con las máximas garantías de éxito. En caso contrario, estaremos poniendo trabas al proyecto, incrementando las posibilidades de fracaso.

El sobrecoste del proyecto y la definición errónea de dimensiones son dos de las consecuencias de una mala definición de los requerimientos. La primera puede ser la causa de cancelación del proyecto. La segunda supone un sobrecoste en las tareas de mantenimiento evolutivo y la pérdida de confianza en la solución de Business Intelligence.

A la hora de definir un proyecto de Business Intelligence y definir los requerimientos de éste, vale la pena invertir en experiencia. En caso contrario, este error puede salir muy caro.