Particionamiento de tablas para reducir el tiempo de las consultas

 

Una solución analítica se caracteriza por la necesidad de acceder a un gran volumen de datos. Sin embargo, lo habitual es acceder solamente a una parte de éstos, y no a su totalidad.

Para poder gestionar de manera más eficiente el acceso a la información, algunas bases de datos han implementado el concepto de particionamiento de tablas.

El diseño lógico de tablas con particionamiento de tablas proporciona grandes beneficios tanto en la gestión de datos como en las consultas realizadas sobre éstos.

Particionamiento de tablas

El particionamiento de tablas consiste en el almacenamiento de los datos de una tabla en contenedores separados, en función de los valores de cada registro, según una función específica determinada en

Por ejemplo, las ventas de una empresa pueden particionarse por el año de la venta, por unidad de negocio, etc.

Al particionar por el año de venta, cada contenedor con registros de las ventas contiene la información de un año. De esta manera, las consultas sobre el año actual accederán tan solo al contenedor del año en curso. Lo mismo sucede si accedemos a información del año pasado o el anterior, por ejemplo, accediendo al contenedor específico de ese año.

Gestión de datos

El particionamiento a nivel tabla en una base de datos es transparente para el desarrollador, y aún más para el usuario final.

La base de datos es capaz de insertar los datos en el contenedor correspondiente a cada registro al aplicar la función de particionamiento sobre los datos de cada uno de éstos. Por ejemplo, al insertar una venta actual, el registro se almacenará físicamente en el contenedor del año en curso, mientras que si insertamos una venta del año pasado, éste se almacenará en el contenedor para ese año.

Lo mismo sucede con las modificaciones que afecten a las columnas de la función de particionamiento. Al producirse un cambio en los valores, el registro puede cambiar de partición (o sea, de contenedor).

Por último, cabe destacar el hecho de que, al disponer de todos los datos de una partición juntos, se facilita la gestión de los datos (movimiento de disco, copias de seguridad, etc.) en tareas de mantenimiento.

Mayor eficiencia en las consultas

Aparte de los beneficios en la gestión de datos para el personal de Sistemas en las citadas tareas de mantenimiento, el gran beneficio del particionamiento de datos reside en el acceso a los datos en las consultas.

Las consultas de usuario suelen contener filtros sobre los datos. Si ciertos filtros son habituales, puede ser efectivo particionar las tablas por esas columnas presentes en esos filtros de datos.

En el caso del particionamiento por el año de venta (un filtro habitual en la gran mayoría de empresas), conseguiremos acceder únicamente a las ventas del año en curso en lugar de a todo el histórico de ventas para resolver la consulta. Esto supone una gran reducción del volumen de registros a consultar (y posiblemente a agregar), lo cual supone un gran beneficio en términos de rendimiento.

Cierto es que el indexado de tablas puede proporcionar también un gran beneficio a la hora de acceder únicamente a los registros requeridos por las consultas, pero el acceso por índice para grandes volúmenes de datos nunca será tan efectivo como el acceso secuencial a una partición de datos donde todos los registros deben ser consultados.

Además, es posible que existan otros filtros que activen otros índices que tengamos disponibles. En este caso, cada partición tiene sus propios índices sobre esas columnas, separados de los índices sobre las mismas columnas existentes en otras particiones. Por tanto, los índices son más pequeños y más eficientes.

Conclusión

El particionamiento de tablas es una técnica de diseño de bases de datos que permite organizar los datos físicamente en contenedores de datos separados en función de los valores del cada registro.

Al disponer de tablas particionadas, las consultas que utilizan filtros pueden beneficiarse de esta técnica de diseño al acceder únicamente a subconjuntos de datos con la información necesaria para la resolución de la consulta.

Esto supone un menor volumen de datos a acceder y por tanto una mayor eficiencia en las consultas.

La elección de la función de particionamiento es clave para obtener una mayor o menor eficiencia en las consultas. Pero a la vez, elegir una función de particionamiento errónea puede suponer una penalización respecto a una solución sin esta técnica de diseño. Por eso, recomiendo usar el particionamiento, pero siempre con la seguridad que proporciona contar con la opinión de un experto en este tema.

Optimización de consultas con agregados

 

Analizar datos implica, generalmente, el acceso a una gran cantidad de datos. Por otra parte, para poder obtener una visión analítica completa es necesario disponer de datos a nivel de detalle. Esto permite tanto el análisis a alto nivel como la navegación a niveles inferiores de los datos (drill down) para identificar información que requiere una especial atención a nivel operacional.

Sin embargo, disponer de datos a nivel de detalle penaliza en gran manera el rendimiento de las consultas. Cuando tenemos grandes volúmenes de datos las consultas pueden tardar tanto que la obtención de resultados puede ser inviable dentro de los plazos requeridos por el usuario.

En estas situaciones, es necesario trabajar con datos agregados.

Agregación de datos

Los datos agregados son una visión a alto nivel de los datos disponibles a nivel de detalle. La información agregada debe corresponder exactamente al resultado de una consulta agregada sobre a los datos de detalle. La violación de este requerimiento da como resultado incoherencias en la información obtenida, y por tanto invalida la validez de esos datos agregados.

Disponer de agregaciones de datos permite formular las consultas a partir de dichas agregaciones en lugar de a partir de las tablas de detalle. Al tratarse de tablas con un volumen de registros menor, el tiempo de acceso a las tablas es menor. Además, al incluir los resultados de funciones de agregación, éstas no son necesarias en tiempo de ejecución de las consultas. Todo ello conlleva una mejora del rendimiento de las consultas al utilizar tablas agregadas respecto al uso de tablas de detalle.

Gestor de agregados

Al disponer de tablas agregadas, es necesario identificar la tabla de datos a incluir en la consulta. Esta función es la que debe realizar el «Gestor de agregados».

El gestor de agregados es un elemento que tiene como función principal decidir la(s) tabla(s) a utilizar en la creación de una consulta para acceder a los datos requeridos por el usuario. Este elemento puede ser llevado a cabo por tres diferentes entidades:

  • Usuario: La existencia de diferentes modelos de datos (e.g. Detalle, Agregado por mes, Agregado por cliente, etc.) permite al usuario decidir sobre qué tablas físicas ejecutar la consulta. En este caso, la decisión queda a expensas del conocimiento técnico del usuario, lo cual no es una buena opción.
  • Herramienta de explotación de datos: Una herramienta de Business Intelligence (BI), donde se crea un modelo de negocio que mapea el modelo físico del repositorio de datos, puede asociar cierto elemento de datos con diferentes orígenes físicos en el repositorio. No todas las herramientas de BI permiten definir múltiples orígenes de datos para el mismo objeto de la capa de presentación. Pero aquellas que sí que lo permiten, disponen de un gran elemento diferenciador respecto al resto de tecnologías. En este caso, la consulta se crea dinámicamente en función de las columnas de la consulta de usuario y la disponibilidad de agregados.
  • Base de datos: Existen bases de datos que permiten la reescritura de las consultas a partir de las consultas de usuario y de la disponibilidad de tablas agregadas. En este caso, el beneficio se generaliza a todas las herramientas de explotación de datos que accedan a la base de datos, sin necesidad de replicar la lógica de decisión del agregado en todas las herramientas de BI utilizadas.

A la hora de decidir la política de agregados, es muy importante tener claro quién va a asumir el rol del gestor de agregados. La tecnología a utilizar puede depender de ello.

Mantenimiento de agregados

El uso de agregados requiere una revisión periódica, algo que no ocurre en sistemas de información asociados a aplicativos.

El conjunto de agregados en un sistema analítico debe estar alineado con los requerimientos de acceso a la información por parte de los usuarios. Si los requerimientos cambian (e.g. Inicialmente los informes agrupaban la información por año, pero a posteriori éstos son necesarios a nivel de mes), es muy posible que las tablas agregadas no proporcionen los beneficios para los nuevos requerimientos (en el ejemplo anterior, una tabla agregada a nivel de año quedaría invalidada para dar respuesta a las consultas por mes, y la consulta tendría que realizarse a partir de las tablas de detalle).

Por tanto, es necesario hacer un seguimiento de los requerimientos de acceso a la información por parte de los usuarios. Al detectar cambios, deberemos identificar posibles cambios en el conjunto de agregados e implementar esos cambios para que no haya un impacto en el usuario.

Conclusión

El uso de agregados permite mejorar dramáticamente el rendimiento de las consultas en un sistema analítico. De hecho, puede suponer la diferencia entre el éxito y el fracaso de una solución analítica.

El gestor de agregados es el componente inteligente que determina el acceso a los datos (bien sea a tablas agregadas o a las tablas de detalle). La lógica puede definirse a varios niveles: Usuario, herramienta de BI y base de datos. Cada una de ellas tiene sus pros y sus contras. Determinar la opción adecuada en cada solución es una tarea clave para el éxito de la solución analítica.

Los agregados son parte de una solución dinámica. Es decir, puede cambiar con el tiempo. Es necesario realizar un seguimiento de los requerimientos y del histórico de consultas para determinar cambios en éstas, para así poder redefinir los agregados en el caso que esto sea necesario.

Todo diseño de una solución analítica debe incluir un módulo de agregados. De no ser así, existe un gran riesgo de fracaso del proyecto. Si ya dispones de una solución de BI, asegúrate de disponer de la documentación del módulo de agregados. En el futuro puede ser que la necesites.

ETL y Late Arriving Dimensions

 

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

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

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

Late Arriving Dimension

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

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

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

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

Diseño complejo

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

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

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

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

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

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

Conclusión

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

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

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

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

Predecir el futuro es posible

 

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

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

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

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

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

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

Grandes volúmenes de datos

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

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

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

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

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

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

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

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

Grandes conjuntos de variables

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

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

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

Conclusión

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

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

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

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

Monetización de los datos

 

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

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

 

Ámbitos de aplicación de la información

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

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

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

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

Monetización de los datos

Empecemos con unas preguntas:

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

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

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

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

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

Aspectos éticos y legales

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

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

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

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

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

Conclusión

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

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

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

Efectividad de un proyecto de Business Intelligence

 

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

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

 

Factores de medida de éxito

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

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

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

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

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

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

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

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

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

Incremento de la efectividad en la toma de decisiones

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

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

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

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

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

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

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

Consideraciones

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

Conclusión

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

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

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.

Carga de datos en BI vs. Big Data

 

Uno de los componentes clave de todo sistema analítico es la carga de datos. Durante este proceso, los datos generados en los sistemas origen son cargados en el repositorio de datos analítico para su posterior análisis.

Existen grandes diferencias conceptuales entre como los sistemas de Business Intelligence (BI) y los basados en Big Data cargan los datos en el repositorio analítico. En este artículo veremos estas diferencias para tres tipos de arquitectura:

  • BI tradicional
  • Micro cargas (como componente de un sistema BI basado en una Arquitectura Lambda)
  • Big Data

Factores que afectan a la arquitectura de una solución analítica

La decisión sobre qué arquitectura debe ser utilizada en una solución analítica, depende de las 3 V’s de las que hablamos en este artículo.

Por tanto, el volumen de datos generados en los sistemas origen, la variedad de datos y la latencia máxima para la explotación efectiva por parte de los usuarios, son los factores clave para decidir la arquitectura de una solución analítica y, por tanto, de la carga de datos.

Teniendo en cuenta estas tres variables, obtenemos la siguiente tabla, que nos muestra la arquitectura a utilizar en función de las 3 V’s:

Proceso de los datos: Batch vs. Streaming

La carga de datos puede realizarse, por lo que se refiere a cómo se procesan los datos, de dos maneras diferentes:

  • Batch: Los datos se acumulan en el sistema origen. En el momento de iniciarse la carga, estos datos acumulados se procesan a la vez.
  • Streaming: A medida que los datos son generados por el sistema origen, éstos son enviados para su proceso. El volumen de datos procesados depende de la frecuencia de generación de éstos. Este método de proceso de datos permite detectar patrones en los datos en tiempo real. Un ejemplo es el de la detección de fraude en compras online.

Para las tres arquitecturas anteriores, los tipos de proceso de datos que encontramos son:

ETL vs. ELT

Una carga de datos no es únicamente un movimiento de datos. Ésta suele ir acompañada de una transformación de los datos, ya sea en el modelo de datos (cómo se almacenan), en el valor de éstos (los datos pueden cambiar debido a estandardizaciones de valores, por ejemplo), etc.

Esta transformación requiere del uso de recursos del sistema y de tiempo. El objetivo a la hora de diseñar una carga de datos es que tanto el uso de recursos del sistema como del tiempo no supere el máximo establecido en cada caso.

En el caso de disponer de una ventana de tiempo limitada para la ejecución de una carga de datos, lo lógico es minimizar esas transformaciones, para aligerar el trabajo a realizar durante el proceso de los datos. Esta situación es extensible al escenario en el cual debemos procesar grandes cantidades de datos, ya que podríamos alargar el proceso más allá de la ventana de tiempo disponible.

Existen dos tipos de cargas de datos en función de cuándo se realiza la transformación de los datos:

  • ETL (Extraction – Transformation – Load): La transformación de los datos se realiza antes de la carga en el repositorio de datos. En este caso, al acabar la carga, los datos están disponibles en su estado final, listos para ser explotados por los usuarios finales.
  • ELT (Extraction – Load – Transformation): No existe transformación de datos (o en todo caso es mínima) antes de la carga en el repositorio de datos. Posteriormente, los datos son transformados mediante procesos de refinamiento de éstos. En este caso, los datos precisan de esa transformación posterior para poder ser explotados por los usuarios finales.

Para las tres arquitecturas anteriores, los tipos de carga de datos que encontramos según en qué momento se realiza la transformación de los datos son:

Es decir, en una solución Big Data, la transformación de los datos se realizará una vez cargados los datos en bruto en el repositorio de datos. Esta transformación se llevará a cabo mediante procesos de refinamiento de los datos, que irán añadiendo valor a éstos. Estos procesos pueden ser de calidad de datos, de enriquecimiento, analíticos, etc.

Conclusión

Existen grandes diferencias entre las cargas de datos de los sistemas BI y Big Data.

La carga de datos de un sistema BI (ya sea tradicional o con arquitectura Lambda), procesa los datos en modo batch, mientras que un sistema basado en Big Data puede utilizar cargas batch o basadas en streaming.

Cuando las transformaciones se hacen durante la carga y antes de dejar los datos en las tablas finales del repositorio de datos, se denomina ETL. Este tipo de cargas es el usado en los sistemas BI.

Cuando las transformaciones se realizan posteriormente a la carga de datos en el repositorio, éstas dotan a los datos de calidad, los refinan, los enriquecen y les proporcionan un valor añadido, se denomina ELT. Big Data usa este tipo de cargas.

Elegir el tipo de carga correcto para cada escenario es clave para el éxito de una solución analítica. De ello se deriva poder disponer de los datos para la toma de decisiones de manera efectiva. El hecho de utilizar una carga de datos errónea puede suponer el fracaso del proyecto de creación de una solución analítica.