Desarrollo de un proyecto
¿Porque Construir Bloques de Data Warehouse?
Para ampliar un negocio, se necesita que la información sea comprensible. Para muchas compañías, esto significa un gran data warehouse que muestre, junto a los datos no filtrados y dispersos, nuevas formas creativas de presentación.
Las herramientas para capturar y explorar los datos al detalle evolucionan, así como nuestra capacidad para encontrar las formas de explotar los datos recolectados.
En los últimos 10 años se han combinado dos factores para ayudar a la difusión de los data warehouses. Ellos son:
- Se ha reconocido los beneficios del procesamiento analítico en línea (On Line Analytical Processing - OLAP), más allá de las áreas tradicionales de marketing y finanzas.
Las organizaciones saben que los conocimientos inmersos en las masas de datos que rutinariamente recogen sobre sus clientes, productos, operaciones y actividades comerciales, contribuyen a reducir los costos de operación y aumentar las rentas, por no mencionar que es más fácil la toma de decisiones estratégicas.
- El crecimiento de la computación cliente/servidor, ha creado servidores de hardware y software más poderosos y sofisticados que nunca. Los servidores de hoy compiten con las mainframes de ayer y ofrecen arquitecturas de memoria tecnológicamente superiores, procesadores de alta velocidad y capacidades de almacenamiento masivas.
Al mismo tiempo, los Sistemas de Gestión de Base de Datos (Data Base Management Systems - DBMS(s)) modernos, proporcionan mayor soporte para las estructuras de datos complejas.
De esta renovación de hardware y software surgen los data warehouses multiterabyte que ahora se ve en ambientes de cliente/servidor.
Consideraciones Previas al Desarrollo de un Data Warehouse
Hay muchas maneras para desarrollar data warehouses como tantas organizaciones existen. Sin embargo, hay un número de dimensiones diferentes que necesitan ser consideradas:
- Alcance de un data warehouse
- Redundancia de datos
- Tipo de usuario final
La Figura N° 15 muestra un esquema bidimensional para analizar las opciones básicas. La dimensión horizontal indica el alcance del depósito y la vertical muestra la cantidad de datos redundantes que deben almacenarse y mantenerse.
Alcance de un Data Warehouse
El alcance de un data warehouse puede ser tan amplio como toda la información estratégica de la empresa desde su inicio, o puede ser tan limitado como un data warehouse personal para un solo gerente durante un año.
En la práctica, en la amplitud del alcance, el mayor valor del data warehouse es para la empresa y lo más caro y consumidor de tiempo es crear y mantenerlo. Como consecuencia de ello, la mayoría de las organizaciones comienzan con data warehouses funcionales, departamentales o divisionales y luego los expanden como usuarios que proveen retroalimentación.
Redundancia de Datos
Hay tres niveles esenciales de redundancia de datos que las empresas deberían considerar en sus opciones de data warehouse:
- Data warehouses "virtual" o "Point to Point"
- Data warehouses "centrales"
- Data warehouses "distribuidos"
No se puede pensar en un único enfoque. Cada opción adapta un conjunto específico de requerimientos y una buena estrategia de almacenamiento de datos, lo constituye la inclusión de las tres opciones.
- Data Warehouses "Virtual" o "Point to Point"
-
Una estrategia de data warehouses virtual, significa que los usuarios finales pueden acceder a bases de datos operacionales directamente, usando cualquier herramienta que posibilite "la red de acceso de datos".
Este enfoque provee flexibilidad así como también la cantidad mínima de datos redundantes que deben cargarse y mantenerse. Además, se pueden colocar las cargas de consulta no planificadas más grandes, sobre sistemas operacionales.
Como se verá, el almacenamiento virtual es, frecuentemente, una estrategia inicial, en organizaciones donde hay una amplia (pero en su mayor parte indefinida) necesidad de conseguir la data operacional, desde una clase relativamente grande de usuarios finales y donde la frecuencia probable de pedidos es baja.
Los depósitos virtuales de datos proveen un punto de partida para que las organizaciones determinen qué usuarios finales están buscando realmente.
- Data Warehouses "Centrales"
-
El concepto de data warehouses centrales es el concepto inicial que se tiene del data warehouse. Es una única base de datos física, que contiene todos los datos para un área funcional específica, departamento, división o empresa.
Los data warehouses centrales se seleccionan por lo general donde hay una necesidad común de los datos informáticos y un número grande de usuarios finales ya conectados a una red o computadora central. Pueden contener datos para cualquier período específico de tiempo. Comúnmente, contienen datos de sistemas operacionales múltiples.
Los data warehouses centrales son reales. Los datos almacenados en el data warehouse son accesibles desde un lugar y deben cargarse y mantenerse sobre una base regular. Normalmente se construyen alrededor de RDBMS avanzados o, en alguna forma, de servidor de base de datos informático multidimensional.
- Data Warehouses Distribuidos
-
Los data warehouses distribuidos son aquellos en los cuales ciertos componentes del depósito se distribuyen a través de un número de bases de datos físicas diferentes.
Cada vez más, las organizaciones grandes están tomando decisiones a niveles más inferiores de la organización y a la vez, llevando los datos que se necesitan para la toma de decisiones a la red de área local (Local Area Network - LAN) o computadora local que sirve al que toma decisiones.
Los data warehouses distribuidos comúnmente involucran la mayoría de los datos redundantes y como consecuencia de ello, se tienen procesos de actualización y carga más complejos.
Tipo de Usuario Final
De la misma forma que hay una gran cantidad de maneras para organizar un data warehouse, es importante notar que también hay una gama cada vez más amplia de usuarios finales.
En general, se puede considerar tres grandes categorías:
- Ejecutivos y gerentes
- "Power users" o "Buzo de Información" (analistas financieros y de negocios, ingenieros, etc.)
- Usuarios de soporte (de oficina, administrativos, etc.).
Cada una de estas categorías diferentes de usuario tienen su propio conjunto de requerimientos para los datos, acceso, flexibilidad y facilidad de uso.
Elementos Claves para el Desarrollo de un Data Warehouse
Los data warehouses exitosos comienzan cuando se escogen e integran satisfactoriamente tres elementos claves.
Un data warehouse está integrado por un servidor de hardware y los DBMS que conforman el depósito. Del lado del hardware, se debe combinar la configuración de plataformas de los servidores, mientras se decide cómo aprovechar los saltos casi constantes de la potencia del procesador. Del lado del software, la complejidad y el alto costo de los DBMSes fuerzan a tomar decisiones drásticas y balances comparativos inevitables, con respecto a la integración, requerimientos de soporte, desempeño, eficiencia y confiabilidad.
Si se escoge incorrectamente, el data warehouse se convierte en una gran empresa con problemas difíciles de trabajar en su entorno, costoso para arreglar y difícil de justificar.
Para conseguir que la implementación del depósito tenga un inicio exitoso, se necesita enfocar hacia tres bloques claves de construcción:
- Arquitectura total del depósito
- Arquitecturas del servidor
- Sistemas de Gestión de Base de Datos
A continuación se presentan algunas recomendaciones para tomar las correctas elecciones para su empresa.
Diseño de la Arquitectura
Arquitectura del Depósito
El desarrollo del data warehouse comienza con la estructura lógica y física de la base de datos del depósito más los servicios requeridos para operar y mantenerlo. Esta elección conduce a la selección de otros dos ítems fundamentales: el servidor de hardware y el DBMS.
La plataforma física puede centralizarse en una sola ubicación o distribuirse regional, nacional o internacionalmente. A continuación se dan las siguientes alternativas de arquitectura:
- Un plan para almacenar los datos de su compañía, que podría obtenerse desde fuentes múltiples internas y externas, es consolidar la base de datos en un data warehouse integrado. El enfoque consolidado proporciona eficiencia tanto en la potencia de procesamiento como en los costos de soporte. (Ver Figura N° 16).
- La arquitectura global distribuye información por función, con datos financieros sobre un servidor en un sitio, los datos de comercialización en otro y los datos de fabricación en un tercer lugar. (Ver Figura N° 17)
- Una arquitectura por niveles almacena datos altamente resumidos sobre una estación de trabajo del usuario, con resúmenes más detallados en un segundo servidor y la información más detallada en un tercero.
La estación de trabajo del primer nivel maneja la mayoría de los pedidos para los datos, con pocos pedidos que pasan sucesivamente a los niveles 2 y 3 para la resolución.
Las computadoras en el primer nivel pueden optimizarse para usuarios de carga pesada y volumen bajo de datos, mientras que los servidores de los otros niveles son más adecuados para procesar los volúmenes pesados de datos, pero cargas más livianas de usuario. (Ver figura N° 18).
Arquitectura del servidor
Al decidir sobre una estructura de depósito distribuida o centralizada, también se necesita considerar los servidores que retendrán y entregarán los datos. El tamaño de su implementación (y las necesidades de su empresa para escalabilidad, disponibilidad y gestión de sistemas) influirá en la elección de la arquitectura del servidor.
- Servidores de un solo procesador
Los servidores de un sólo procesador son los más fáciles de administrar, pero ofrecen limitada potencia de procesamiento y escalabilidad. Además, un servidor sólo presenta un único punto de falla, limitando la disponibilidad garantizada del depósito.
Se puede ampliar un solo servidor de redes mediante arquitecturas distribuidas que hacen uso de subproductos, tales como Ambientes de Computación Distribuida (Distributed Computing Environment - DCE) o Arquitectura Broker de Objeto Común (Common Objects Request Broker Architecture - CORBA), para distribuir el tráfico a través de servidores múltiples.
Estas arquitecturas aumentan también la disponibilidad, debido a que las operaciones pueden cambiarse al servidor de copia de seguridad si un servidor falla, pero la gestión de sistemas es más compleja.
- Multiprocesamiento simétrico
Las máquinas de multiprocesamiento simétrico (Symmetric MultiProcessing - SMP) aumentan mediante la adición de procesadores que comparten la memoria interna de los servidores y los dispositivos de almacenamiento de disco.
Se puede adquirir la mayoría de SMP en configuraciones mínimas (es decir, con dos procesadores) y levantar cuando es necesario, justificando el crecimiento con las necesidades de procesamiento. La escalabilidad de una máquina SMP alcanza su límite en el número máximo de procesadores soportados por los mecanismos de conexión (es decir, el backplane y bus compartido).
- Procesamiento en paralelo masivo
Una máquina de procesamiento en paralelo masivo (Massively Parallel Processing - MPP), conecta un conjunto de procesadores por medio de un enlace de banda ancha y de alta velocidad. Cada nodo es un servidor, completo con su propio procesador (posiblemente SMP) y memoria interna. Para optimizar una arquitectura MPP, las aplicaciones deben ser "paralelizadas" es decir, diseñadas para operar por separado, en partes paralelas.
Esta arquitectura es ideal para la búsqueda de grandes bases de datos. Sin embargo, el DBMS que se selecciona debe ser uno que ofrezca una versión paralela. Y aún entonces, se requiere un diseño y afinamiento esenciales para obtener una óptima distribución de los datos y prevenir "hot spots" o "data skew" (donde una cantidad desproporcionada del procesamiento es cambiada a un nodo de procesamiento, debido a la partición de los datos bajo su control).
- Acceso de memoria no uniforme
La dificultad de mover aplicaciones y los DBMS a agrupaciones o ambientes realmente paralelos ha conducido a nuevas y recientes arquitecturas, tales como el acceso de memoria no uniforme (Non Uniform Memory Access - NUMA).
NUMA crea una sola gran máquina SMP al conectar múltiples nodos SMP en un solo (aunque físicamente distribuida) banco de memoria y un ejemplo único de OS. NUMA facilita el enfoque SMP para obtener los beneficios de performance de las grandes máquinas MPP (con 32 o más procesadores), mientras se mantiene las ventajas de gestión y simplicidad de un ambiente SMP estándar.
Lo más importante de todo, es que existen DBMS y aplicaciones que pueden moverse desde un solo procesador o plataforma SMP a NUMA, sin modificaciones.
Sistemas de Gestión de Bases de Datos
Los data warehouses (conjuntamente con los sistemas de soporte de decisión [Decision Support Systems - DSS] y las aplicaciones cliente/servidor), fueron los primeros éxitos para el DBMS relacional (Relational Data Base Management Systems - RDBMS).
Mientras la gran parte de los sistemas operacionales fueron resultados de aplicaciones basadas en antiguas estructuras de datos, los depósitos y sistemas de soporte de decisiones aprovecharon el RDBMS por su flexibilidad y capacidad para efectuar consultas con un único objetivo concreto.
Los RDBMS son muy flexibles cuando se usan con una estructura de datos normalizada. En una base de datos normalizada, las estructuras de datos son no redundantes y representan las entidades básicas y las relaciones descritas por los datos (por ejemplo productos, comercio y transacción de ventas). Pero un procesamiento analítico en línea (OLAP) típico de consultas que involucra varias estructuras, requiere varias operaciones de unión para colocar los datos juntos.
La performance de los RDBMS tradicionales es mejor para consultas basadas en claves ("Encuentre cuenta de cliente #2014") que para consultas basadas en el contenido ("Encuentre a todos los clientes con un ingreso sobre $ 10,000 que hayan comprado un automóvil en los últimos seis meses").
Para el soporte de depósitos a gran escala y para mejorar el interés hacia las aplicaciones OLAP, los proveedores han añadido nuevas características al RDBMS tradicional. Estas, también llamadas características super relacionales, incluyen el soporte para hardware de base de datos especializada, tales como la máquina de base de datos Teradata.
Los modelos super relacionales también soportan extensiones para almacenar formatos y operaciones relacionales (ofrecidas por proveedores como REDBRICK) y diagramas de indexación especializados, tales como aquellos usados por SYBASE IQ. Estas técnicas pueden mejorar el rendimiento para las recuperaciones basadas en el contenido, al pre juntar tablas usando índices o mediante el uso de listas de índice totalmente invertidos.
Muchas de las herramientas de acceso a los data warehouses explotan la naturaleza multidimensional del data warehouse. Por ejemplo, los analistas de marketing necesitan buscar en los volúmenes de ventas por producto, por mercado, por período de tiempo, por promociones y niveles anunciados y por combinaciones de estos diferentes aspectos.
La estructura de los datos en una base de datos relacional tradicional, facilita consultas y análisis a lo largo de dimensiones diferentes que han llegado a ser comunes. Estos esquemas podrían usar tablas múltiples e indicadores para simular una estructura multidimensional. Algunos productos DBMS, tales como ESSBASE y GENTIUM, implementan técnicas de almacenamiento y operadores que soportan estructuras de datos multidimensionales.
Mientras las bases de datos multidimensionales (MultiDimensional Databases - MDDBs) ayudan directamente a manipular los objetos de datos multidimensionales (por ejemplo, la rotación fácil de los datos para verlos entre dimensiones diferentes, o las operaciones de drill down que sucesivamente exponen los niveles de datos más detallados), se debe identificar estas dimensiones cuando se construya la estructura de la base de datos. Así, agregar una nueva dimensión o cambiar las vistas deseadas, puede ser engorroso y costoso. Algunos MDDBS requieren un recargue completo de la base de datos cuando ocurre una reestructuración.
Nuevas Dimensiones
Una limitación de un RDBMS y un MDDB, es la carencia de soporte para tipos de datos no tradicionales como imágenes, documentos y clips de vídeo / audio. Si usted necesita estos tipos de objetos en su data warehouse, busque un DBMS relacional - objeto (Ejemplo: ILLUSTRA de INFORMIX).
Por su enfoque en los valores de datos codificados, la mayor parte de los sistemas de base de datos pueden acomodar estos tipos de datos, sólo con extensiones basadas en cierta referencias, tales como indicadores de archivos que contienen los objetos. Muchos RDBMS almacenan los datos complejos como objetos grandes binarios (Binary Large Objects - BLOBs). En este formato, los objetos no pueden ser indexados, clasificados, o buscados por el servidor.
Los DBMS relacional - objeto, de otro lado, almacenan los datos complejos como objetos nativos y pueden soportar las grandes estructuras de datos encontradas en un ambiente orientado a objetos. Estos sistemas de base de datos naturalmente acomodan no sólo tipos de datos especiales sino también los métodos de procesamiento que son únicos para cada uno de ellos.
Pero una desventaja del enfoque relacional - objeto, es que la encapsulación de los datos dentro de los tipos especiales de datos (una serie de precios de stock a través del tiempo en cada registro de una tabla de stock, por ejemplo), requiere de operadores especializados para que hagan búsquedas simples previamente (por ejemplo, "Encontrar todas las existencias que han mostrado una disminución en el precio de Abril a Mayo 1996").
La selección del DBMS está también sujeta al servidor de hardware que se usa. Algunos RDBMS, como el DB2 Paralelo, INFORMIX XPS y el ORACLE Paralelo, ofrecen versiones que soportan operaciones paralelas. El software paralelo divide consultas, uniones a través de procesadores múltiples y corre estas operaciones simultáneamente para mejorar la performance.
Se requiere el paralelismo para el mejor desempeño en los servidores MPP grandes y SMP agrupados. No es aún una opción con MDDBS o DBMS relacional - objeto.
En la tabla "Cómo comparar DBMS" se resume los pro y los contra de los diferentes tipos de DBMS para operaciones de data warehouse.
La tabla "Matriz de Decisión del Data Warehouse" contiene algunos ejemplos de cómo afectan estos criterios de decisión en la elección de una arquitectura de servidor/ data warehouse.
¿Cómo comparar DBMSES?
| Características / Función |
Relacional |
Super Relacional |
Multidimensional (Lógico) |
Multidimensional (Físico) |
Objeto Relacional |
| Estructuras Normalizadas |
| | | | |
| Tipos de datos abstractos |
| | | | |
| Paralelismo |
| | | | |
| Estructuras Multidimensionales |
| | | | |
| Drill-Down |
| | | | |
| Rotación |
| | | | |
| Operaciones dependientes de datos |
| | | | |
Matriz de Decisión para el Data Warehouse
| Para estos ambientes... |
|
|
Elija... |
|
|
| Requerimientos comerciales |
Usuarios |
Soporte de Sistemas |
Arquitectura |
Servidor |
DBMS |
| Alcance: departamental | | Usos: análisis de datos |
|
Pequeña - ubicación única |
Local mínimo - central promedio |
Consolidado - paquete |
Procesador único o SMP |
MDDB |
| Alcance: departamental | | Usos: análisis más informático |
|
Grandes Analistas en una sola ubicación; usuarios informáticos dispersos |
Local mínimo - central promedio |
Seccionado - detalle en central - resumen en local |
Grupos de SMP para central; SP o SMP para local |
RDBMS para central - MDDB para local |
| Alcance: empresa | | Usos: análisis más informático |
|
Grande; geográficamente disperso |
Central fuerte |
Centralizado |
Grupos de SMP |
Objeto-relacional- soporte Web |
| Alcance: departamental | | Usos: investigación |
|
Pequeña - pocas ubicaciones |
Central fuerte |
Centralizado |
MPP |
RDBMS con soporte paralelo |
Combinacion de la Arquitectura con el Sistema de Gestion de Bases de Datos
Para seleccionar la combinación correcta de la arquitectura del servidor y el DBMS, primero es necesario comprender los requerimientos comerciales de su compañía, su población de usuarios y las habilidades del personal de soporte.
Las implementaciones de los data warehouses varían apreciablemente de acuerdo al área. Algunos son diseñados para soportar las necesidades de análisis específico para un solo departamento o área funcional de una organización, tales como finanzas, ventas o marketing. Las otras implementaciones reúnen datos a través de toda la empresa para soportar una variedad de grupos de usuarios y funciones. Por regla general, a mayor área del depósito, se requiere mayor potencia y funcionalidad del servidor y el DBMS.
Los modelos de uso de los data warehouses son también un factor. Las consultas y vistas de reportes preestructuradas frecuentemente satisfacen a los usuarios informáticos, mientras que hay menos demandas sobre el DBMS y la potencia de procesamiento del servidor. El análisis complejo, que es típico de los ambientes de decisión - soporte, requiere más poder y flexibilidad de todos los componentes del servidor. Las búsquedas masivas de grandes data warehouses favorecen el paralelismo en el DBMS y el servidor.
Los ambientes dinámicos, con sus requerimientos siempre cambiantes, se adaptan mejor a una arquitectura de datos simple, fácilmente cambiable (por ejemplo, una estructura relacional altamente normalizada), antes que una estructura intrincada que requiere una reconstrucción después de cada cambio (por ejemplo, una estructura multidimensional).
El valor de la data fresca requerida indica cuán importante es para el data warehouse renovar y cambiar los datos. Los grandes volúmenes de datos que se refrescan a intervalos frecuentes, favorecen una arquitectura físicamente centralizada para soportar una captura de datos eficiente y minimizar el tiempo de transporte de los datos.
Un perfil de usuario debería identificar quiénes son los usuarios de su data warehouse, dónde se ubican y cuántos necesita soportar. La información sobre cómo cada grupo espera usar los data warehouses, ayudará a analizar los diversos estilos de uso.
Conocer la ubicación física de sus usuarios ayudará a determinar cómo y a qué área necesita distribuir el data warehouse. Una arquitectura por niveles podría usar servidores en el lugar de las redes de área local. O puede necesitar un enfoque centralizado para soportar a los trabajadores que se movilizan y que trabajan en el depósito desde sus laptops.
El número total de usuarios y sus modelos de conexión determinan el tamaño de sus servidores de depósito. Los tamaños de memoria y los canales de I/O deben soportar el número previsto de usuarios concurrentes bajo condiciones normales, así como también en las horas punta de su organización.
Finalmente, se debe factorizar la sofisticación del personal de soporte. Los recursos de los sistemas de información (Information System - IS) que están disponibles dentro de su organización, pueden limitar la complejidad o sofisticación de la arquitectura del servidor. Sin el personal especializado interno o consultores externos, es difícil de crear y mantener satisfactoriamente una arquitectura que requiere paralelismo en la plataforma del servidor (MPP o SMP agrupado, por ejemplo).
Planes de Expansion
Como su depósito evoluciona y los datos que contiene llegan a ser más accesible, los empleados externos al depósito podrían descubrir también el valor de sus datos. Al enlazar su data warehouse a otros sistemas (tanto internos como externos a la organización), se puede compartir información con otras entidades comerciales con poco o sin desarrollo. Los mensajes de correo electrónico, servidores WEB y conexiones Intranet/Internet, pueden entregar listas por niveles a sus proveedores o según su condición, a sus socios de negocio.
Como los data warehouses continúan creciendo en sofisticación y uso, los datos acumulados dentro de una empresa llegarán a ser más organizados, más interconectados, más accesibles y, en general, más disponibles a más empleados.
El resultado será la obtención de mejores decisiones en el negocio, más oportunidades y más claridad de trabajo.
Confiabilidad de los Datos
La data "sucia" es peligrosa. Las herramientas de limpieza especializadas y las formas de programar de los clientes proporcionan redes de seguridad.
No importa cómo esté diseñado un programa o cuán hábilmente se use. Si se alimenta mala información, se obtendrá resultados incorrectos o falsos. Desafortunadamente, los datos que se usan satisfactoriamente en las aplicaciones de línea comercial operacionales pueden ser basura en lo que concierne a la aplicación data warehousing.
Los datos "sucios" pueden presentarse al ingresar información en una entrada de datos (por ejemplo, "Sistemas S. A." en lugar de "Sistemas S. A.") o de otras causas. Cualquiera que sea, la data sucia daña la credibilidad de la implementación del depósito completo. A continuación, en la Figura N° 19 se muestra un ejemplo de formato de ventas en el que se pueden presentar errores.
Afortunadamente, las herramientas de limpieza de datos pueden ser de gran ayuda. En algunos casos, puede crearse un programa de limpieza efectivo. En el caso de bases de datos grandes, imprecisas e inconsistentes, el uso de las herramientas comerciales puede ser casi obligatorio.
Decidir qué herramienta usar es importante y no solamente para la integridad de los datos. Si se equivoca, se podría malgastar semanas en recursos de programación o cientos de miles de dólares en costos de herramientas.
La limpieza de una data "sucia" es un proceso multifacético y complejo. Los pasos a seguir son los siguientes:
- Analizar sus datos corporativos para descubrir inexactitudes, anomalías y otros problemas.
- Transformar los datos para asegurar que sean precisos y coherentes.
- Asegurar la integridad referencial, que es la capacidad del data warehouse, para identificar correctamente al instante cada objeto del negocio, tales como un producto, un cliente o un empleado.
- Validar los datos que usa la aplicación del data warehouse
Tutoriales
