Mostrando entradas con la etiqueta Componentes construir Data Warehouse. Mostrar todas las entradas
Mostrando entradas con la etiqueta Componentes construir Data Warehouse. Mostrar todas las entradas

lunes, 9 de febrero de 2009

Data Warehouse en profundidad

Empieza el primer tema hablando de los Data Warehouses, los almacenes de datos.
Los sistemas tradicionales empezaron a tener problemas para satisfacer las necesidades de los usuarios y de esta problematica, surgen los Data Warehouse como sistemas de apoyo a la toma de decisiones, en que los datos de una organización se transforman en información estratégica. Ayudan a su vez a disponer de un acceso sencillo e inmediato a determinada información de negocio estructurada y de calidad.

Acceder a los datos directamente en sistemas operacionales (del dia a dia, no DWH) suponía algunos problemas:
  • Conocer lenguajes como SQL
  • Rendimiento
  • Los datos no están preparados para las consultas necesarias.
  • No suelen tener un horizonte histórico como para detectar tendencias o realizar seguimientos.

Data Warehousing versus Data Warehouse
Data Warehousing es el proceso de crear y mantener un almacén central de datos, es decir un Data Warehouse.

Características de un DWH
  • Orientado a temas: en contra de la orientación a procesos de los sistemas operacionales, facilitando su acceso y entendimiento.
  • Integrado: Los datos de un DWH son íntegros en unidades de medida, nombres, codificación, etc...
  • Variante en el tiempo: Se guardan datos históricos (del orden de años) que facilitan la evaluación e identificación de tendencias.
  • No volátil: Los valores permanecen en el DWH sin modificación.

Diferencias entre un DWH y una BD Operacional
La principal diferencia entre un Data Warehouse y una BD operacional es su objetivo, el primero esta orientado a las operaciones del día a día y el segundo al análisis y la toma de decisiones. Por tanto podemos preveer que uno recibe multitud de transacciones repetitivas y conocidas y el DWH consultas masivas, puntuales y no conocidas. También como diferencia encontramos el rendimiento, la volatilidad, los usuarios (más expertos), estructura (relacional versus multidimensional), alcance histórico, detalle de los datos y por último el volumen, mucho mayor en un DWH.

Arquitectura de un DWH

Cuando hablamos de la arquitectura, nos referimos a la manera de representar la estructura global de los datos, los procesos y las interfaces de usuario. Las bases de esta arquitectura son:
  • Mezclar los datos de la BD operacional con otras fuentes de datos, incluidas las externas.
  • Información fácil y transparente
  • Proveer al usuario de un acceso universal a los datos (apoyado en lenguaje SQL)
  • Metadatos: De donde proviene un dato, que formato tenía, significado, como se ha calculado, etc...
  • Construir y mantener el directorio de datos.
  • Gestión de copia y de replicación: todos los procesos necesarios para asegurar la calidad de los datos.

Estructura del DWH
¿Qué nivel de detalle tienen los datos? Normalmente difiere de los sistemas de producción por contener agregaciones y por guardar al detalle los datos de otros años.
Dentro del DWH también encontramos los famosos Metadatos, que los podríamos definir como un directorio para ayudar a ubicar los contenidos, una guía de donde provienen los datos y una descripción de los algoritmos utilizados para calcular las agregaciones pertinentes.

Data Mart
Un Data Mart cumple los mismos principios que un Data Warehouse, pero difiere principalmente en el alcance del mismo, que seria de un departamento o grupo de personas y no de toda la organización. De Data Marts podemos encontrar de dos tipos: dependientes e independientes según si los datos son extraidos del DWH o directamente de los sistemas operacionales (a la larga un desastre).

Explotar un Data Warehouse
El reto es sacar datos y convertirlo en información, que se dice pronto... y encima querer crear una ventaja empresarial. Este reto va des de la edición de informes hasta una minería de datos avanzada, con análisis multidimensional. Por tanto, un DWH es un medio, no un fin en si mismo. Ningún proyecto debería tener como finalidad construir un DWH, sino obtener información... si bien, cabe decir que el construirlo debe suponer una gran meta.
Para la explotación encontramos tres técnicas principalmente: Query and reporting, OLAP (análisis multidimensional) y Minería de datos . La primera consiste en realizar informes y generar consultas flexibles, con una interfaz gráfica, permitiendo también escribir total o parcialmente la consula en SQL (o similar). La segunda (OLAP) consiste en realizar análisis desde un conjunto de perspectivas o dimensiones. Muy adecuada para grandes volúmenes de datos.
La tercera consiste en el descubrimiento de conocimiento no accesible de manera directa... si no que se encuentra oculto, por ejemplo, buscar patrones de información en los datos.


Fuente: http://estudiandobi.blogspot.com/2007/11/data-warehouse-en-profundidad.html

jueves, 22 de enero de 2009

Componentes a tener en cuenta a la hora de construir un Data Warehouse

Un componente fundamental a la hora de poder contar con un Data Warehouse que responda a las necesidades analíticas avanzadas de los usuarios, es el poder contar con una infraestructura hardware que la soporte.

En este sentido son críticas, a la hora de evaluar uno u otro hardware, dos características principales:

Por un lado, a este tipo de sistemas suelen acceder pocos usuarios con unas necesidades muy grandes de información, a diferencia de los sistemas operacionales, con muchos usuarios y necesidades puntuales de información. Debido a la flexibilidad requerida a la hora de hacer consultas complejas e imprevistas, y al gran tamaño de información manejada, son necesarias unas altas prestaciones de la máquina.

Por otro lado, debido a que estos sistemas suelen comenzar con una funcionalidad limitada, que se va expandiendo con el tiempo (situación por cierto aconsejada), es necesario que los sistemas sean escalables para dar soporte a las necesidades crecientes de equipamiento. En este sentido, será conveniente el optar por una arquitectura abierta, que nos permita aprovechar lo mejor de cada fabricante.

En el mercado se han desarrollado tecnologías basadas en tecnología de procesamiento paralelo, dan el soporte necesario a las necesidades de altas prestaciones y escalabilidad de los Data Warehouse. Estas tecnologías son de dos tipos:

  • SMP (Symmetric multiprocessing, o Multiprocesadores Simétricos): Los sistemas tienen múltiples procesadores que comparten un único bus y una gran memoria, repartiéndose los procesos que genera el sistema, siendo el sistema operativo el que gestiona esta distribución de tareas. Estos sistemas se conocen como arquitecturas de "casi todo compartido". El aspecto más crítico de este tipo de sistemas es el grado de rendimiento relativo respecto al número de procesadores presentes, debido a su creciente no lineal.
  • MPP (Massively parallel processing, o Multiprocesadores Masivamente Paralelos): Es una tecnología que compite contra la SMP, en la que los sistemas suelen ser casi independientes comunicados por intercambiadores de alta velocidad que permiten gestionarlos como un único sistema. Se conocen por ello como arquitecturas de "nada compartido". Su escalabilidad es mayor que la de los SMP.

Según Meta Group, las tendencias de mercado indican que las arquitecturas SMP aportan normalmente suficientes características de escalabilidad, con una mayor oferta y un menor riesgo tecnológico. Sin embargo, cuando las condiciones de escalabilidad sean extremas, se puede plantear la opción MPP.

No obstante, se están produciendo avances significativos en arquitecturas SMP, que han logrado máquinas con un crecimiento lineal de rendimiento hasta un número de 64 procesadores.

Recomendamos desde estas páginas, la visita a la dirección Internet:

http://www.tpc.org/bench.results.html

en donde la Transaction Processing Council (de la que son miembros ALR, Amdahl, Bull, Compaq, Data General, Dell, Digital, Fujitsu, HP, IBM, Intergraph, NCR , Siemens-Nixdorf, Sun o Unisys), realiza una comparativa entre las máquinas de sus miembros, proporcionando para diferentes modelos y diferentes configuraciones de Sistemas Operativos y Software de Base de Datos, un análisis de rendimiento (throughput), y un resumen de características (precio, número de procesadores, arquitectura y futuras versiones y fecha de disponibilidad).

Software de almacenamiento (SGBD)

Como hemos comentado, el sistema que gestione el almacenamiento de la información (Sistema de Gestión de Base de Datos o SGBD), es otro elemento clave en un Data Warehouse. Independientemente de que la información almacenada en el Data Warehouse se pueda analizar mediante visualización multidimensional, el SGBD puede estar realizado utilizando tecnología de Bases de Datos Relacionales o Multidimensionales.

Las bases de datos relacionales, se han popularizado en los sistemas operacionales, pero se han visto incapaces de enfrentarse a las necesidades de información de los entornos Data Warehouse. Por ello, y puesto que, como hemos comentado, las necesidades de información suelen atender a consultas multidimensionales, parece que unas Bases de Datos multidimensionales, parten con ventaja. En este sentido son de aplicación los comentarios que realizamos en el apartado de hardware, por requerimientos de prestaciones, escalabilidad y consolidación tecnológica.

Al igual que en el hardware, nuevos diseños de las bases de datos relacionales, las bases de datos post-relacionales, abren un mayor abanico de elección. Estas bases de datos post-relacionales, parten de una tecnología consolidada y dan respuesta al agotamiento de las posibilidades de los sistemas de gestión de bases de datos relacionales, ofreciendo las mismas prestaciones aunque implantadas en una arquitectura diseñada de forma más eficiente.

Esta mayor eficiencia se consigue instaurando relaciones lógicas en vez de físicas, lo que hace que ya no sea necesario destinar más hardware a una solución para conseguir la ejecución de las funciones requeridas. El resultado es que la misma aplicación implantada en una BD post-relacional requiere menos hardware, puede dar servicio a un mayor número de usuarios y utilizar mecanismos intensivos de acceso a los datos más complejos. Asimismo, esta tecnología permite combinar las ventajas de las bases de datos jerárquicas y las relacionales con un coste más reducido. Ambos sistemas aportan como ventaja que no resulta necesario disponer de servidores omnipotentes, sin que puede partirse de un nivel de hardware modesto y ampliarlo a medida que crecen las necesidades de información de la compañía y el uso efectivo del sistema.

Dejamos fuera del ámbito de esta guía el detallar cómo los proveedores de bases de datos han optimizado los accesos a los índices, o las nuevas posibilidades que ofrece la compresión de datos (menos espacio para la misma información lo que implica, entre otras ventajas, que más información se puede tener en caché), para lo que remitimos a la prensa especializada o a las publicaciones de los fabricantes.

Software de extracción y manipulación de datos

En este apartado analizaremos un componente esencial a la hora de implantar un Data Warehouse, la extracción y manipulación. Para esta labor, que entra dentro del ámbito de los profesionales de tecnologías de la información, es crítico el poder contar con herramientas que permitan controlar y automatizar los continuos "mimos" y necesidades de actualización del Data Warehouse.

Estas herramientas deberán proporcionar las siguientes funcionalidades:

  • Control de la extracción de los datos y su automatización, disminuyendo el tiempo empleado en el descubrimiento de procesos no documentados, minimizando el margen de error y permitiendo mayor flexibilidad.
  • Acceso a diferentes tecnologías, haciendo un uso efectivo del hardware, software, datos y recursos humanos existentes.
  • Proporcionar la gestión integrada del Data Warehouse y los Data Marts existentes, integrando la extracción, transformación y carga para la construcción del Data Warehouse corporativo y de los Data Marts.
  • Uso de la arquitectura de metadatos, facilitando la definición de los objetos de negocio y las reglas de consolidación.
  • Acceso a una gran variedad de fuentes de datos diferentes.
  • Manejo de excepciones.
  • Planificación, logs, interfaces a schedulers de terceros.
  • Interfaz independiente de hardware.
  • Soporte en la explotación del Data Warehouse.

A veces, no se suele prestar la suficiente atención a esta fase de la gestión del Data Warehouse, aun cuando supone una gran parte del esfuerzo en la construcción de un Data Warehouse. Existen multitud de herramientas disponibles en el mercado que automatizan parte del trabajo, para lo cual recomendamos la visita a la página Internet:

http://pwp.starnetinc.com/larryg/clean.html

en la que se proporciona una lista de mas de 100 herramientas de extracción y manipulación de datos, con links a sus páginas Internet, y una somera descripción de la funcionalidad cubierta por cada herramienta.

Herramientas Middleware

Como herramientas de soporte a la fase de gestión de un Data Warehouse, analizaremos a continuación dos tipos de herramientas:

  • Por un lado herramientas Middleware, que provean conectividad entre entornos diferentes, para ayudar en la gestión del Data Warehouse.
  • Por otro, analizadores y aceleradores de consultas, que permitan optimizar tiempos de respuestas en las necesidades analíticas, o de carga de los diferentes datos desde los sistemas operacionales hasta el Data Warehouse.

Las herramientas Middleware deben ser escalables siendo capaces de crecer conforme crece el Data Warehouse, sin problemas de volúmenes. Tambien deben ser flexibles y robustas, sin olvidarse de proporcionar un rendimiento adecuado. Estarán abiertas a todo tipos de entornos de almacenamiento de datos, tanto mediante estándares de facto (OLE, ODBC, etc.), como a los tipos de mercado más populares (DB2, Access, etc.). La conectividad, al menos en estándares de transporte (SNA LU6.2, DECnet, etc.) debe estar tambien asegurada.

Con el uso de estas herramientas de Middleware lograremos:

  • Maximizar los recursos ejecutando las aplicaciones en la plataforma más adecuada.
  • Integrar los datos y aplicaciones existentes en una plataforma distribuida.
  • Automatizar la distribución de datos y aplicaciones desde un sistema centralizado.
  • Reducir tráfico en la red, balanceando los niveles de cliente servidor (mas o menos datos en local, mas o menos proceso en local).
  • Explotar las capacidades de sistemas remotos sin tener que aprender multiples entornos operativos.
  • Asegurar la escalabilidad del sistema.
  • Desarrollar aplicaciones en local y explotarlas en el servidor.

Los analizadores y aceleradores de querys trabajan volcando sobre un fichero de log las consultas ejecutadas y datos asociados a las mismas (tiempo de respuesta, tablas accedidas, método de acceso, etc). Este log se analiza, bien automáticamente o mediante la supervisión del administrador de datos, para mejorar los tiempos de accesos.

Estos sistemas de monitorización se pueden implementar en un entorno separado de pruebas, o en el entorno real. Si se ejecutan sobre un entorno de pruebas, el rendimiento del entorno real no se vé afectado. Sin embargo, no es posible optimizar los esfuerzos, puesto que los análisis efectuados pueden realizarse sobre consultas no críticas o no frecuentemente realizadas por los usuarios.

El implantar un sistema analizador de consultas, en el entorno real tiene además una serie de ventajas tales como:

  • Se pueden monitorizar los tiempos de respuesta del entorno real.
  • Se pueden implantar mecanismos de optimización de las consultas, reduciendo la carga del sistema.
  • Se puede imputar costes a los usuarios por el coste del Data Warehouse.
  • Se pueden implantar mecanismos de bloqueo para las consultas que vayan a implicar un tiempo de respuesta excesivo.
Fuente : DataPrix