Inicio > Business Analytics > Agregar, Agregar, Agregar (o cómo acelerar un sistema de BI)

Agregar, Agregar, Agregar (o cómo acelerar un sistema de BI)

La rapidez (o lentitud) de un sistema de Business Intelligence está condicionada por diversos factores entre los que destacan el hardware disponible, el volumen de datos a analizar y el correcto diseño del data.
Supongamos (y no es poco) que hayamos conseguido la configuración óptima (!!!) de estos factores acorde a nuestro presupuesto, pero que aún así, el rendimiento del sistema no es satisfactorio.
¿Significa esto que hemos agotado nuestras posibilidades y que ha fracasado nuestro proyecto de Business Intelligence?
No. Cuando no es posible mover los datos más rápido, la mejora del rendimiento de un sistema pasa por mover menos datos.

Para reducir el tiempo de acceso a los datos, introduciremos una optimización de diseño: la creación de tablas agregadas (tablas que resumen los datos de las tablas de hechos de un datawarehouse/datamart con menor nivel de detalle, por lo que tienen menor volumen). Aunque mínimamente, estas tablas deberán ser consideradas y mantenidas tanto en las herramientas de diseño, como en la documentación y el desarrollo de los procesos de ETL, etc.

Para que este esfuerzo adicional resulte en una optimización efectiva del sistema de BI, es preciso que éste sea lo suficientemente inteligente como para que, basándose únicamente en los hechos, métricas y agregaciones utilizados por cualquier análisis, sepa escoger de manera totalmente automática y transparente al usuario, el conjunto de tablas que pueda responder de manera más eficiente a la petición.  En cualquier otro caso, habrá que dar formación y soporte a los usuarios para transmitirles el conocimiento necesario sobre el modelo de datos para que sepan escoger las tablas agregadas más adecuadas a cada análisis que pretendan realizar, compromentiendo la viabilidad de la mejora.

La tecnología Oracle puede ayudarnos en la realización de la mayoría de tareas relacionadas con la construcción, mantenimiento y utilización de tablas agregadas; desde la identificación de las consultas más habituales (propósito para la que dispone de varias herramientas), pasando por los agregados que conviene crear, la sintaxis para la creación de las vistas materializadas que hayamos decidido, hasta llegar a asumir la compleja y delicada responsabilidad de elegir las tablas agregadas que pueden responder de manera más eficientemente a las consultas de análisis de los usuarios.
Vamos a centrarnos en los diferentes mecanismos que Oracle pone a nuestra disposición para sacar provecho de la agregación como recurso para acelerar la ejecución de consultas:

Agregar (durante el ETL)

Aunque sería un paso previo a la situación descrita hasta el momento, las herramientas ETL de Oracle como Data Integrator, nos pueden ayudar a agregar los datos que van a poblar el data, siempre conservando una granularidad ajustada a las necesidades de la organización, pero con menor nivel de detalle que en el sistema origen (podríamos por ejemplo, resumir todos los pedidos diarios de un cliente y un producto en el sistema transaccional, como un único registro en el data).

Agregar (al construir la consulta)

El segundo nivel de agregación puede formar parte del diseño de nuestro data desde el principio, o puede incorporarse como optimización en el momento en que sea necesario (como en nuestro supuesto) sin mayor incidencia sobre el desarrollo existente. Si proveemos a nuestro datawarehouse/datamart de tablas con diferentes niveles de agregación sobre los hechos (por ejemplo diaria, mensual, anual, …), el motor de acceso a datos OBI Server es capaz de decidir en el momento de generar las consultas que enviará a la BD, qué tablas interrogar, eligiendo entre las diferentes tablas disponibles, según su nivel de detalle o incluso de elegir entre diferentes agregadas a un mismo nivel y entre varias dimensiones (por ejemplo mensual x región, mensual x gama de producto, …).
Para utilizarlo deberemos informar adecuadamente en el repositorio la existencia de dichas agregaciones y asociarlas al nivel apropiado de la jerarquía correspondiente a la dimensión sobre la que hemos agregado (temporal, geográfica, producto, …).

Agregar (reescribiendo consultas)

El tercer nivel de agregación estaría en la base de datos, convenientemente configurada, con la opción QUERY_REWRITE habilitada. Para poder usar esta funcionalidad, en el momento de la creación de las vistas materializadas que utilizamos para la agregación, deberemos informar a la BD de que son elegibles para query-rewrite y nos aseguraremos de que su definición cumple las restricciones necesarias para su utilización (existe alguna restricción, aunque son mayoritariamente lógicas, no técnicas). Esta característica de la base de datos realizará una traducción al vuelo de la consulta recibida sobre una tabla de la que existan agregaciones en forma de vista materializada elegible para query-rewrite, y la convertirá en otra consulta diferente que responderá a la solicitud con el mismo resultado, pero obteniendo los datos de su agregada (de menor volumen) más rápidamente.

Al ser ésta una funcionalidad de BD, su aplicación es independiente de las consultas que OBI (o cualquier otra herramienta) pueda lanzar, por lo que su efecto podría llegar a “acumularse” con la característica descrita en “Agregar (al construir la consulta)”.
Espero que tengáis ocasión de sacar provecho de alguno de los recursos presentados … o de todos!

  1. Aún no hay comentarios.
  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: