Sobre Data Warehouse Lifecycle Management (DWLM)

Hay veces que nos olvidamos que en la base de cualquier sistema de Business Intelligence existe un data warehouse. ¡Hombre, qué exagerado me dirás! Pero es que al final de lo único de lo que tienen constancia nuestros usuarios es de la parte final. Traducción: del reporting, de los cuadros de mando, de los mapas geográficos, del análisis OLAP, del balanced Scorecard,…

A veces incluso podemos caer en el craso error que un sistema Business Intelligence es un simple proyecto cerrado que una vez terminado se queda en un lugar sin sufrir ningún cambio. Y sin embargo, ¿no es cierto que nuestra organización evoluciona? Entonces, tal cual debe pasar con nuestro sistema BI para que refleje nuestra organización. Deberíamos tener un Business Intelligence Lifecycle Management (BILM). Sin duda, es un aspecto a tener en cuenta.

Ah, atención no penséis que loa acrónimos son en balde. La economía del lenguaje es importante una vez introducidos los conceptos.

Pero vayamos en la dirección de lo que quería hablar. Me gustaría centrarme en el corazón de un sistema BI: en el data warehouse.
A este nivel, estaremos hablando de Data Warehouse Lifecycle Management (DWLM).

Pongámonos en contexto. Hemos ya terminado nuestro primer proyecto de BI en nuestra organización. Ello se ha traducido en que una de nuestra áreas se realiza una explotación correcta y beneficiosa de la información. El éxito de este primer hito nos impulsa con brío y como CIO decidimos continuar con una siguiente fase mucho más ambiciosa. Queremos que un tanto por ciento importante de las áreas de nuestra organización entre en el segundo proyecto y que toda la información este conformada y conforme con la evolución de nuestra organización.

Llegados hasta este punto debemos mirar atrás un momento. Tenemos un data mart que evolucionará a un data warehouse. ¿Cómo continuará ofreciéndonos el rendimiento actual? ¿Cómo se podrá conseguir cruzar la información? ¿Cómo se debe plantear la evolución de sistema existente?

Estamos hablando sin duda alguna de:

* Cuál debe ser la arquitectura del data warehouse: por ejemplo, es necesario tener un DW central y un data mart por cada departamento.
* Si es necesario o no el uso de tablas agregadas: hemos detectado unas consultas más lentas de lo normal, hemos identificado las consultas típicas.
* Si es necesario el uso de Raid

Uhm, quedémonos un momento en el uso de RAID en DW.

El rendimiento a nivel I/O es uno de los aspectos importantes en el diseño de un data warehouse. Esto contrasta con lo que sucede para los sistemas OLTP donde el cuello de botella potencial depende de los patrones de acceso y la carga de trabajo del usuario. Por definición:

* Cuando un sistema presenta restricciones a nivel I/O, se dice que está limitado o tiene un cuello de botella I/O.
* Cuando un sistema presenta restricciones a nivel de CPU, se dice que está limitado o tiene un cuello de botella CPU.

Los arquitectos de bases de datos frecuentemente usan sistemas RAID (Redundant Arrays of Inexpensive Disks) para evitar cuellos de botella I/O y proporcionar una mayor disponibilidad de datos. Existen múltiples implementaciones RAID algunas de ellas consistentes a nivel de mejoras por parte de fabricantes para superar defectos propios de diseño.

En definitiva existen muchos aspectos que debe tenerse en cuenta. ¿Los tenemos?