• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Arquitecura de bodega de datos
 

Arquitecura de bodega de datos

on

  • 1,400 views

Durante mi presentación, buscaré aclarar los conceptos básicos de bodegas de datos, las tecnologías Microsoft involucradas así como los errores más comunes en este tipo de proyectos. ...

Durante mi presentación, buscaré aclarar los conceptos básicos de bodegas de datos, las tecnologías Microsoft involucradas así como los errores más comunes en este tipo de proyectos.

Para registrarse en mi sesión deben visitar el siguiente link: http://bit.ly/1h5WCMy

Statistics

Views

Total Views
1,400
Views on SlideShare
1,345
Embed Views
55

Actions

Likes
8
Downloads
1
Comments
1

1 Embed 55

http://190.25.234.142 55

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Excelente trabajo....
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Arquitecura de bodega de datos Arquitecura de bodega de datos Presentation Transcript

    • BODEGAS DE DATOS: PLANEANDO UNA ARQUITECTURA CORRECTA Dr. Eduardo Castro, MSc ecastro@simsasys.com http://ecastrom.blogspot.com http://comunidadwindows.org http://tiny.cc / comwindows Facebook: ecastrom Twitter: edocastro
    • FUENTE DE PRESENTACIÓN Almacenamiento de datos moderno, Minería y Visualización: Core Conceptos por George M. Marakas Data Warehousing Diez Común Los errores de Jon C. Choe http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • Qué es la inteligencia de negocios? • Un almacén de datos es generalmente un componente de una solución global de Business Intelligence • Personas de TI pueden tener la tentación de pensar en términos de productos y tecnologías PERO ...
    • Objetivo general • El objetivo general de la inteligencia empresarial es proporcionar la información necesaria para gestionar un negocio • Esto significa que el suministro de información en apoyo de la toma de decisiones de gestión, por lo que BI también se llama "Decision Support"
    • BI se trata de "extracción de datos" Etapas (4) sabiduría conocimiento información datos • El público de un almacén de datos normalmente considera subconjuntos más altos de abstracción de datos pirámide • El nivel más bajo de la pirámide es demasiado detallado y difícil de manejar
    • No es la tecnología • Business Intelligence es sobre la entrega de valor de negocio • proporcionar un beneficio tangible al responder preguntas importantes que pueden ayudar a la empresa a alcanzar su objetivo estratégico • Mejorar la rentabilidad • ¿Quiénes son nuestros cinco clientes más rentables? • ¿Cuáles son los productos menos rentables? • La reducción de costes • ¿Quiénes son nuestros proveedores de menor costo? • ¿Qué materiales se incurren costos más altos de deterioro? • Mejorar la satisfacción del cliente • ¿Qué factores pueden conducir a la pérdida de clientes?
    • Requisitos Arquitectura BI • Debe reconocer el cambio como una constante • Tomar enfoque de desarrollo incremental • Aplicaciones existentes deben seguir trabajando • Necesario permitir que se añadan más datos y nuevos tipos de datos
    • Aceptación del usuario • comprensibilidad • comprensibilidad está en los ojos del espectador • querer ocultar la complejidad • tratar de hacerlo: • intuitiva, obvia • visible, memorable
    • Aceptación del usuario • Rendimiento • no quieren interrumpir el proceso de pensamiento • proporcionar un solo clic, acceso instantáneo • almacén debe estar disponible, el sistema de "producción"
    • ¿Qué son las bodegas de datos? • Definido de muchas maneras diferentes, pero no rigurosamente. • Una base de datos de soporte de decisiones que se mantiene por separado de la base de datos operativa de la organización • Apoyar procesamiento de la información al proporcionar una plataforma sólida de datos históricos consolidados, para su análisis. • "Un almacén de datos es orientada hacia un tema, integrado,variante en el tiempo,y no volátil recogida de datos en apoyo de los procesos de toma de decisiones de la administración. "-W. H. Inmon • Almacenamiento de datos: • El proceso de construcción y utilización de almacenes de datos
    • Bodegas de datos • Organizada en torno a grandes temas, como la clientes, productos, ventas • Centrándose en el modelado y análisis de datos para la toma de decisiones, y no en las operaciones diarias o procesamiento de transacciones • Proporcionar una forma sencilla y concisa ver alrededor de determinadas cuestiones sometidas por exclusión de los datos que no son útiles en el proceso de ayuda a la decisión
    • 12 Necesidad de Data Warehousing • Integrado, en toda la empresa con vista de información de alta calidad (de diferentes bases de datos) • Separación de los sistemas operacionales (para mejorar el rendimiento)
    • Data Mart Definición • Mercado de datos es un subconjunto completo del almacén de datos global • un único proceso de negocio o • un grupo de relacionados los procesos de negocio • Pensar en un mercado de datos como una colección de tablas de hechos relacionados con el intercambio de dimensiones compatibles, también conocido como una 'constelación de hecho "
    • Integración en bodegas de datos • Construido por la integración de múltiples fuentes de datos heterogéneas • bases de datos relacionales, archivos planos, registros de transacciones en línea • Se aplican técnicas de integración de datos y de limpieza de datos. • Garantizar la coherencia de las convenciones de nomenclatura, la codificación de estructuras, medidas de atributos, etc entre las diferentes fuentes de datos • Por ejemplo, el Hotel precio: moneda, impuestos, desayuno cubierto, etc • Cuando los datos se mueven a la bodega, se convierte.
    • Variante en el tiempo • El horizonte de tiempo para el almacén de datos es significativamente más larga que la de los sistemas operacionales • Base de datos operativa: datos del valor actual • Datos de bodega de datos: proporcionar información desde una perspectiva histórica (por ejemplo, 5 a 10 años pasados) • Cada estructura clave en el data warehouse • Contiene un elemento de tiempo, de manera explícita o implícita • Pero la clave de los datos operativos puede o puede no contener "elemento de tiempo"
    • Plan del proyecto Data Warehouse En primer lugar en la agenda es una evaluación de la preparación. Readiness tiene cinco factores clave: 1. Fuerte respaldo administrativo - Quizás el factor más importante 2. Obligar motivación empresarial - el valor de un DW es lo que hace para el negocio 3. Calidad de la asociación es-business - El grupo está tiene que ser una parte central de la empresa http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • La Data Warehouse Plan del proyecto (cont.) En primer lugar en la agenda es una evaluación de la preparación. Readiness tiene cinco factores clave: 4. Cultura de la organización - la organización debe poner un alto valor a la información y el análisis 5. DW viabilidad - son los datos actuales exacta y suficientemente estandarizada para que la integración sea posible? http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • Estrategias de diseño • Diseño DW Top-down - el diseño de almacenes de datos se basa en el modelo de la empresa en sí. Implica una perspectiva estratégica, en lugar de funcionamiento, de los datos. • Bottom-up de diseño DW - se centra más en hacer uso de los datos disponibles en el sistema actual. Esto es menos esfuerzo que el enfoque de arriba hacia abajo, pero puede terminar con un almacén de datos que no satisface todas las necesidades de información de la organización. http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • Especificación el análisis y Diseño Instrumentos • Si bien se podría utilizar un enfoque de modelado entidad-relación del diseño de base de datos relacional, el enfoque de modelado dimensional al diseño lógico se utiliza más a menudo para un almacén de datos. • Una de las razones es que la ERM a nivel de empresa sería demasiado complejo de entender. • Hay tres elementos básicos en el modelo dimensional (1) una mesa central llamada tabla de hechos, (2) dos o más tablas más pequeñas llamadas al tablas de dimensiones, Y (3) y un conjunto de relaciones llamado combinación en estrella. http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • Diseño de Data Warehouse: Un Marco de Análisis de Negocio • Cuatro puntos de vista sobre el diseño de un almacén de datos • Vista desde arriba hacia abajo • permite la selección de la información relevante necesaria para el almacenamiento de datos • Vista de origen de datos • Expone que se capturó la información, almacenada y gestionada por los sistemas operativos • Vista de almacén de datos • consta de tablas de hechos y tablas de dimensiones • Vista de consulta de negocios • ve las perspectivas de los datos en el almacén de la vista del usuario final
    • ARQUITECTURA DE BODEGAS DE DATOS MEJORES PRÁCTICAS
    • El desarrollo de una Arquitectura • Un arquitectura documento de requisitos que el primer sobre. Al lado de cada requisito de negocio se enumeran las implicaciones arquitectónicas. • El desarrollo de una arquitectura de DW es una tarea difícil y debe ser enfrentado con el enfoque adecuado. http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • El desarrollo de una arquitectura técnica DW (cont.) • Allí son numerosas recetas para esto, pero un proceso de cuatro capa simple es a menudo suficiente: 1. 2. 3. 4. requerimientos del negocio arquitectura técnica definición de estándares el desarrollo de productos de aplicación. http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • Datos Almacén Proyecto Factores de éxito La construcción de un DW es muy similar a la construcción de cualquier otro sistema de información compleja en términos de lo que hace que sea un éxito. Algunas pautas para el éxito del proyecto son:  Tienen un fuerte promotor del proyecto  Generar usuario buy-in  Identificar las necesidades del negocio  Comience con un alcance limitado  Comprender la cultura de la organización  Crear documentos de requisitos claros  Definir los requisitos de información y comunicación  Prototype menudo http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • Arquitecturas de Data Warehouse • Arquitectura de dos niveles • Data Mart Independiente • Data Mart dependiente y operacional almacén de datos • Logical Data Mart y Almacén • Arquitectura de tres capas Todas implican algún tipo de extracción,transformación y carga (ETL)
    • Tres modelos de almacén de datos • Almacén empresarial • recoge toda la información sobre temas que abarcan toda la organización • Data Mart • Un subconjunto de datos en toda la empresa que es de valor para un grupo específico de usuarios. Su ámbito de aplicación se limita a determinados grupos específicos, tales como la comercialización del mercado de datos • Independiente vs dependiente (directamente desde el almacén) data mart • Almacén virtual • Un conjunto de puntos de vista sobre bases de datos operacionales • Sólo algunas de las posibles vistas de resumen se puede materializarse
    • Data Warehouse: Una arquitectura de varios niveles Otro fuentes Operacional DBs Metadatos Extraer Transformar Cargar Refrescar Controlar Y Integrador Datos Almacén OLAP Server Servir Análisis Pregunta Informes La minería de datos Data Marts Fuentes de datos Almacenamiento de Datos OLAP Engine Herramientas de aplicaciones para usuario
    • Desarrollo de Data Warehouse: Un enfoque recomendado Distribuido Data Marts Data Mart Data Mart Almacén de datos Multi-Tier Enterprise Data Warehouse Modelo refinamiento Modelo refinamiento Definir un modelo de datos corporativo de alto nivel
    • Dos niveles de arquitectura de almacenamiento de datos genéricos L T Uno de ellos, de toda la compañía almacén E Extracción periódica  datos no es completamente actual en almacén
    • 69 Data mart arquitectura de almacenamiento de datos independiente Mini-almacenes, limitada en su alcance L T E ETL separada para cada data mart independiente Datos de acceso debido a la complejidad de múltiple data marts
    • 70 Mercado de datos dependiente de almacén de datos operativos: una arquitectura de tres niveles ODS proporciona opción para la obtención corriente datos L T E De acceso a datos sencilla ETL único para la empresa de almacenamiento de Data Marts dependientes datos cargados desde EDW (EDW)
    • Lógica de datos mart y la arquitectura de almacén en tiempo real ODS y almacén de datos son una L T E ETL en tiempo real para los Data Warehouse Data Marts no son bases de datos separadas, pero lógica vistas del almacén de datos  más fácil de crear nuevos mercados de datos
    • Depósito de datos back-end de herramientas y utilidades • Extracción de los datos • obtener datos de múltiples, heterogéneos y fuentes • • • • externas Limpieza de datos • detectar errores en los datos y rectificarlos cuando sea posible Transformación de datos • convertir los datos de la herencia o de acogida un formato a otro almacén Cargar • Ordena, resumir, consolidar, calcular puntos de vista, comprobar la integridad y construir ındices y particiones Refrescar • propagar los cambios en las fuentes de datos para el almacén
    • Arquitecturas OLAP Server • OLAP relacional (ROLAP) • Utilice relacional o relacional ampliada DBMS para almacenar y gestionar datos de almacenes y OLAP media de consumo • Incluya optimización de DBMS backend, la implementación de la lógica de navegación agregación y herramientas y servicios adicionales • Mayor escalabilidad • OLAP multidimensional (MOLAP) • Escaso motor de almacenamiento multidimensional basada en arreglos • Indexación rápida a los datos resumidos previamente calculados • OLAP híbrido (HOLAP) (Por ejemplo, Microsoft SQL Server) • La flexibilidad, por ejemplo, el bajo nivel: relacional de alto nivel: array • Servidores SQL Especializada (Por ejemplo, Redbricks) • Soporte especializado para consultas SQL más esquemas en estrella / copo de nieve
    • Uso de almacenamiento de datos • Tres tipos de aplicaciones de almacenamiento de datos • Tratamiento de la información • apoya la consulta, el análisis estadístico básico, y la presentación de informes con tablas de referencias cruzadas, tablas, cuadros y gráficos • Procesamiento analítico • análisis multidimensional de datos de almacenamiento de datos • apoya las operaciones básicas de OLAP, rebanadadados, perforación, pivotantes • La minería de datos • descubrimiento de conocimiento a partir de patrones ocultos • apoya las asociaciones, la construcción de modelos analíticos, realizar la clasificación y predicción, y la presentación de los resultados de minería de datos utilizando herramientas de visualización
    • Modelo Dimensional para una Ventas al por menor Pronóstico http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • Diseño de una tabla de hechos DW En general, hay cuatro pasos básicos: 1. 2. 3. 4. La elección de un DW de datos para el pequeño grupo de usuarios finales que tratamos. Tabla de hechos granularidad (El nivel mínimo definido de los datos en la tabla) se determina. Dimensiones se seleccionan. Determinar los hechos para la tabla. En la mayoría de los casos, la granularidad es en el nivel de transacción, por lo que el hecho de es la cantidad. http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • Almacén Arquitectura Especificación y Desarrollo La siguiente fase es el diseño de la arquitectura técnica. Ciertos elementos deben ser incluidos: • Las fuentes más comunes: un mercado de datos necesita ser almacenado en una ubicación central para que otros puedan utilizarlo. • Dimensiones comunes: estos pueden ser compartidos también. • Normas comunes de negocios: el equipo de DW tiene que identificar el mayor número posible de esta opción. http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • Almacén Arquitectura Especificación y Desarrollo (cont.) La siguiente fase es el diseño de la arquitectura técnica. Ciertos elementos deben ser incluidos: • Semántica comunes: debe haber en toda la empresa la definición de términos. • Sistema de medición común: las cosas deben medirse de la misma manera en toda la empresa. http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • DW Arquitectura Áreas Componente Clave • Arquitectura de datos - cada área en un negocio se basa en diferentes dimensiones. Donde se cruzan que es necesario definir el mismo (el cliente que compra es el mismo proyecto de ley que). • Arquitectura Infraestructura - cuestiones de tamaño, la escalabilidad y la capacidad deben ser direcciones. • Arquitectura técnica - Este es impulsado por el catálogo de metadatos. Los servicios deben elaborar los parámetros de las tablas, no codificar ellos. http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • El proceso de clasificación de datos Una parte importante de la arquitectura técnica es el proceso de clasificación de datos, que cubre cinco áreas principales: 1. 2. 3. 4. 5. Extracción de datos de múltiples fuentes Transformación y la limpieza Carga los datos, a menudo a varios destinos Seguridad Las políticas de acceso y cifrado Control de trabajos, Que incluye la programación, el seguimiento y la notificación. http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • Arquitectura de Alto Nivel • Recordemos los diferentes "mundos" • procesamiento de transacciones en línea (OLTP) • sistemas de inteligencia de negocios (BIS) • Los usuarios son diferentes • Contenido de los datos es diferente • Estructuras de datos son diferentes • Arquitectura y metodología deben ser diferentes
    • Dos Mundos • On-Line Transaction Processing • Entidad Modelo Relacional de Datos • creada en 1960 para hacer frente a los problemas de • • • • rendimiento con las implementaciones de bases de datos relacionales normalizada de manera más eficiente obtener datos de divide los datos en muchas entidades discretas muchas relaciones entre estas entidades este enfoque fue documentado por C.J. fecha en Una introducción a los sistemas de bases de datos
    • Dos Mundos • Business Intelligence Sistemas • Modelo Dimensional • También llamado esquema en estrella • Diseñado para facilidad conseguir información • Menor número de relaciones que ERD, la única mesa con varias combinaciones de conectar con otras tablas es la mesa central • Desarrollado en 1960 por los proveedores de servicios de datos, formalizada por Ralph Kimball en El kit de herramientas Data Warehouse
    • Ventajas modelo dimensional • Sencillez • Los seres humanos pueden navegar y recordar • Software puede navegar determinista • Procesos de negocio separadas de manera explícita (Data Mart)
    • Best Practice # 1 Usar un modelo de datos que se ha optimizado para la recuperación de la información • Modelo tridimensional • Sin normalizar • Enfoque híbrido
    • Procesos de Adquisición de Datos • Extraer Transform Load (ETL) • El proceso de descarga o copia de datos de los sistemas de origen, transformándolo en el formato y el modelo de datos necesario en el entorno de BI, y lo carga a la DW • Una herramienta de desarrollo de software para la creación de procesos ETL (una herramienta ETL) • Muchas base de datos datos de producción utilizan COBOL u otros lenguajes de programación de propósito general para la aplicación de ETL
    • Aseguramiento de la Calidad de Datos • Limpieza de datos • El proceso de validación y el enriquecimiento de los datos tal como se publica en la DW • También, una herramienta de desarrollo de software para la construcción de los procesos de limpieza de datos (una herramienta de limpieza de datos) • Muchas bases de datos de producción tienen los procesos de garantía de calidad de datos sólo es muy rudimentarias
    • Recogida de datos y limpieza • La obtención de datos cargados de manera eficiente y correctamente es crítico para el éxito de su DW • Implementación de los procesos de adquisición y limpieza de datos representa de 50 a 80% de esfuerzo en proyectos típicos DW • Contenido de los datos inexactos puede ser "el beso de la muerte” para la aceptación del usuario
    • Best Practice # 2 Diseñar cuidadosamente la adquisición de datos y procesos de limpieza para su DW • Asegurar los datos se procesan de manera eficiente y precisa • Considere la adquisición de ETL y herramientas de limpieza de datos • Úsalos bien!
    • Modelo de Datos • Ya se ha examinado los beneficios de un modelo multidimensional • No importa si se utiliza modelado multidimensional o cualquier otro enfoque de diseño, el modelo de datos debe ser documentada
    • Documentar el modelo de datos • Lo más recomendable es utilizar algún tipo de herramienta de modelado de datos • CA ERwin • Sybase PowerDesigner • Oracle Designer • IBM Rational Rose • Etcétera • Diferentes herramientas soportan diferentes notaciones de modelado, pero son más o menos equivalentes de todos modos • La mayoría de las herramientas permiten el intercambio de los metadatos de una herramienta ETL
    • Modelo de Datos de Metadatos • Definiciones de negocios deben registrarse para cada campo (a menos que sean sólo los campos técnicos) • Dominio de los datos debe ser registrado • Los valores de muestras deben ser incluidos • A medida que más metadatos se completa automáticamente en la herramienta de modelado se hace cada vez más importante para poder compartir estos datos a través de ETL y herramientas de acceso a datos
    • Arquitectura Metadatos • La estrategia para el modelo de intercambio de datos y otros metadatos debe ser formalizado y documentado • Herramientas de gestión de metadatos deben ser considerados y la arquitectura general de los metadatos deben ser cuidadosamente planeadas
    • Best Practice # 3 Diseñar una arquitectura de metadatos que permite el intercambio de metadatos entre los componentes de su DW • Considerar los estándares de metadatos como Metamodel depósito común de OMG (CWM)
    • Arquitectura Enfoques Alternativos • Bill Inmon: "Información sobre la fábrica de las empresas" • Hub and Spoke filosofía • "JBOC" - sólo un montón de cubos • Deje que evolucione naturalmente
    • Lo que queremos (Principal Architectural) • En la mayoría de los casos, de negocios y de TI de acuerdo en que el almacén de datos debe proporcionar una "única versión de la verdad" • Cualquier enfoque que puede resultar en datamarts o cubos de datos dispares es indeseable • Esto se conoce como silos de datos
    • DW Arquitectura • Cómo diseñar un almacén de datos de la empresa y garantizar una "única versión de la verdad"? • De acuerdo con Kimball: • comenzar con una fase general de la arquitectura de datos • utilizar el diseño "Data Warehouse Bus" para integrar múltiples data marts • utilizar enfoque incremental mediante la construcción de un mercado de datos a la vez
    • Data Warehouse Bus Architecture • Llamado así por el autobús en un ordenador • interfaz estándar que permite conectar en CDROM, disco duro, etc • estos periféricos trabajan juntos sin problemas • Establece el marco para mercados de datos que encajan • Permite a los mercados de datos separados que sean implementadas por los diferentes grupos, incluso en diferentes momentos
    • Diseñar El Bus DW • Determinar qué dimensiones serán compartidos a través de múltiples data marts • Conformar las dimensiones compartidas • producir una suite principal de dimensiones compartidas • Determinar qué hechos serán compartidos a través de mercados de datos • Conformar los hechos • estandarizar las definiciones de los hechos
    • Granularidad de las dimensiones • Dimensiones compatibles serán generalmente granular • hace que sea fácil de integrar con varias tablas de hechos a nivel de base • fácil de extender tabla de hechos mediante la adición de nuevos hechos • no hay necesidad de colocar o volver a cargar tablas de hechos, y hay claves que ser cambiado
    • Consolidación de Datos • Una tendencia actual en BI / DW es "la consolidación de datos ' • Desde una perspectiva de proveedor de software, se tiene la tentación de simplificar esto: • 'Podemos mantener todas las tablas para todas sus aplicaciones dispares en una base de datos física'
    • Integración de Datos • Para lograr realmente "una única versión de la verdad", debe hacer algo más que la consolidación de las bases de aplicación • Debe integrar los modelos de datos y establecer los términos de referencia comunes
    • Best Practice # 4 Adoptar un enfoque que consolida los datos en "una sola versión de la verdad" • Data Warehouse Bus • Dimensiones y Hechos
    • Operational Data Store (ODS) • un único punto de integración para los sistemas operativos dispares • contiene los datos integrados en el nivel más detallado (transaccional) • puede ser cargado en 'tiempo real' o periódicamente • se puede utilizar para la notificación de operaciones centralizado
    • ODS en DW Arquitectura • En el caso en que un ODS es un componente necesario de la DW en general, debe ser cuidadosamente integrado en la arquitectura global • También se puede utilizar para: • Área de ensayo • Maestro / gestión de datos de referencia • Etc ...
    • ODS Data Model • No está claro si alguno enfoque de diseño de un modelo de datos ODS se ha convertido en una práctica • normalizada • dimensional • desnormalizado / híbrido
    • Best Practice # 5 Considere la posibilidad de la aplicación de un ODS sólo cuando los requisitos de recuperación de información están cerca de la parte inferior de la pirámide de la abstracción de datos y / o cuando hay múltiples fuentes operativas que necesitan ser visitada • Debe asegurarse de que el modelo de datos está integrada, no sólo consolidada • Se puede considerar modelo de datos 3NF • Evite a toda costa un "volcado de datos de tierra '
    • Planificación de la capacidad • Cargas de trabajo de DW son típicamente muy exigentes, sobre todo de la capacidad de E / S • Implementaciones exitosas tienden a crecer muy rápidamente, tanto en número de usuarios y el volumen de datos • Reglas generales sí existen para el dimensionamiento de la plataforma de hardware para ofrecer un rendimiento inicial adecuada • normalmente sobre la base de estimados tamaño de los datos "en bruto" de la propuesta de base de datos de ejemplo 100-150 Gb por CPU moderna
    • Escala SMP • Rendimiento de escala dentro de un único servidor SMP se conoce como "escala up” • Puntos de referencia de base de datos sugieren escalabilidad de Windows
    • Best Practice # 6 Crear un plan de capacidad para su aplicación BI y monitorear cuidadosamente Considere la posibilidad de futuras demandas adicionales de rendimiento • Establecer consultas de referencia de rendimiento estándar y ejecutar regularmente los • Implementar herramientas de control de capacidad • Construir escalabilidad en su arquitectura • Puede ser necesario para permitir escalar hacia arriba y hacia fuera!
    • DW Appliance • Aparatos DW, que consisten en paquetes de soluciones que proporcionan todo el software y hardware necesario, están empezando a ofrecer el precio / rendimiento muy prometedor • Experiencia en la producción se limita hasta el momento
    • Unas palabras sobre Metadatos • En la secuencia de pasos de especificar el modelo de almacén, para su aplicación, para su uso en consultas, algunos pasos en realidad se refieren a datos "reales". Todo lo demás implica metadatos. • Para la definición de arquitectura, los principales elementos del catálogo de metadatos deben incluir reglas de negocio, información de la transformación, la información de las operaciones y herramientas específicas de información. http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
    • 82 El proceso de ETL • Captura / Extracto • Frote o limpieza de datos • Transformar • Carga y el índice ETL = extracción, transformación y carga
    • 83 Captura / Extracto ... obtener una instantánea de un subconjunto seleccionado de los datos de origen para la carga en el almacén de datos Pasos en la conciliación de datos Extracto estático = Capturar una instantánea de los datos de origen a un punto en el tiempo Extracto Incremental = Captura de los cambios que se han producido desde el último extracto de estática
    • Scrub / Cleanse ... utiliza técnicas de reconocimiento de patrones y la IA para mejorar la calidad de los datos Pasos en la conciliación de datos (Cont.) Solución de errores: faltas de ortografía, fechas erróneas, uso de campo incorrecto, las direcciones no coinciden, los datos que faltan, datos duplicados, inconsistencias También: decodificación, formato, fecha y hora, la conversión, la generación de claves, la fusión, la detección de errores / registro, la localización de los datos faltantes
    • Pasos en la conciliación de datos (Cont.) Transformar = convertir datos de un formato de sistema operativo al formato de almacenamiento de datos A nivel de registro: Selección Partición-data Unión-Datos combinando Agregación-Datos de resumen Nivel de campo: -solo campo-De un campo a un campo varios campos-De muchos campos a uno, o un campo a muchos
    • Carga / index = lugar transforma los datos en el almacén y crear índices Pasos en la conciliación de datos (Cont.) Modo de Actualización: mayor reescritura de datos del blanco, a intervalos periódicos Modo de actualización: sólo los cambios en los datos de origen se escriben en almacenamiento de datos
    • Componentes de un esquema en estrella 88 Las tablas de hechos contener datos objetivos y cuantitativos Relación 1: N entre tablas de dimensiones y tablas de hechos Las tablas de dimensiones se desnormalizar para maximizar el rendimiento Las tablas de dimensiones contiene descripciones sobre los temas de la empresa Excelente para las consultas ad-hoc, pero malo para el procesamiento de transacciones en línea
    • Ejemplo de esquema de estrella Tabla de hechos proporciona estadísticas de ventas desglosadas por productos, de época y tienda de dimensiones
    • Esquema estrella con datos de ejemplo
    • DATA WAREHOUSE Diez errores comunes http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Diez errores communes - 01 1. Comienzo con mal patrocinadores a. b. c. Data Manager Warehousing Patrocinador ejecutivo con gran cantidad de dinero Proyecto piloto "" a. b. c. Ya se ha ganado el respeto de los otros ejecutivos Tiene un sano escepticismo acerca de la tecnología Es decisivo, pero flexible http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Diez errores communes - 02 Establecimiento de expectativas poco realistas que no se pueden cumplir a. El almacenamiento de datos tiene dos fases: Fase Venta - persuadir a la gente Lucha de eliminación de cumplir con el expectativa b. Frustra a los ejecutivos de la hora de la verdad http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Diez errores communes - 03 Promover el valor incorrecto de sus datos Almacén a. Participación en el comportamiento políticamente ingenuo b. Ayudan a los gerentes a tomar mejores decisiones c. Perder partidarios potenciales http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Diez errores communes - 04 Carga de depósito de datos con información innecesaria a. envía una lista de elementos de la tabla y los datos para el usuario final b. volver largas listas de información innecesaria c. disminuye la capacidad de respuesta y aumentar los requerimientos de almacenamiento de almacenamiento de datos http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Diez errores communes - 05 Data Warehouse Design Database vs Base de datos transaccional Diseño a. Procesamiento de transacciones: - Un programador desarrolla una consulta que se utiliza muchas veces - Por lo general contiene sólo la básica datos b. Almacenamiento de datos: - Un usuario final desarrolla la consulta y puede usarlo sólo una vez - Esperar encontrar agregados - sumas, promedios, tendencias, La información de series de tiempo ya calculado para ellos y listo para inmediata mostrar http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Diez errores comunes - 06 Data Warehousing Manager: orientada a la tecnología en lugar de Orientado a los usuarios a. usuario administrador del proyecto pone hostil proyecto entero en peligro de ser desguazado b. Almacenamiento de datos es una empresa de servicios y no un negocio de almacenamiento. c. No hacer que los clientes se enojen! http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Diez errores communes - 07 Demasiado énfasis en orientado a registro interno tradicional datos a. altos ejecutivos ven almacenes de datos como irrelevantes b. la posibilidad de incluir imágenes, gráficos, audio o video, etc ... http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Diez errores comunes - 08 La entrega de los datos con la superposición y confusión definiciones a. Gerente de Finanzas - ventas significa neto de ingresos menos devoluciones b. La gente de distribución - ventas significa que tiene que ser entregado c. Persona de ventas - ventas de medios monto comprometido por los clientes http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Diez errores communes - 09 Rendimiento, capacidad y escalabilidad a. dentro de 4 meses, la compra de al menos un procesador adicional igual o más grande que el equipo actual. b. presupuesto adicional hardware c. presupuesto de dificultades imprevistas d. sobrecargas de la red son muy comunes http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Diez errores comunes - 10 Convencidos de que una vez que el depósito de datos está en funcionamiento, sus problemas han acabado a. equipo de proyecto de almacenamiento de datos necesita para mantener una alta energía durante largos períodos de tiempo. b. El almacenamiento de datos es un viaje, no un destino http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Factores críticos de éxito • Proyecto líder debe ser experimentado • Cuidadoso Recopilación y análisis de necesidades de los usuarios, incluidos los informes existentes es crucial • Conseguir unsencia de cómo los usuarios van a utilizar la nueva herramienta • Hacer un proyecto piloto • Hacer el usuario feliz http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
    • Top 10 Mejores prácticas para la construcción de una gran escala de almacenamiento de datos relacional • La construcción de un almacén de datos relacional a gran escala es una tarea compleja. • En esta sección se describe algunas técnicas de diseño que pueden ayudar en la arquitectura de un almacén de datos relacional a gran escala eficiente con SQL Server. • Más almacenes de datos a gran escala usan mesa y particiones de índice, y por lo tanto, muchas de las recomendaciones aquí implican partición. • Más de estos consejos se basan en las experiencias de construcción de grandes almacenes de datos en SQL Server Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Considere la posibilidad de dividir las grandes tablas de hechos • Considere la posibilidad de particionar tablas de hechos que son de 50 a 100 GB o más grande. • Partición puede proporcionar ventajas de rendimiento y capacidad de administración a menudo. • Mantenimiento de índices más rápido, más granular. • Más flexibles de copia de seguridad / restauración de opciones. • Datos más rápidos de carga y eliminar • Búsquedas más rápidas cuando se limita a una sola partición .. • Normalmente partición la tabla de hechos en la fecha clave. • Permite la ventana deslizante. • Permite la eliminación de particiones. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Construir índice agrupado en la fecha clave de la tabla de hechos • Esto apoya las consultas eficientes para llenar cubos o recuperar un segmento de datos histórica. • Si carga los datos en un lote ventana para el índice agrupado en el hecho de tabla a continuación, utilice las opciones ALLOW_ROW_LOCKS = OFF y ALLOW_PAGE_LOCKS = OFF • Este ayuda a acelerar las operaciones de exploración de mesa durante el tiempo de consulta y ayuda a evitar el exceso de actividad de bloqueo durante grandes cambios. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Construir índice agrupado en la fecha clave de la tabla de hechos • Construir no agrupado índices de cada clave externa. • Este ayuda a "identificar las consultas de los que extraer filas sobre la base de una dimensión determinante selectiva. • Utilizar grupos de archivos para las necesidades de gestión, tales como copia de seguridad / restauración, la disponibilidad de bases de datos parciales, etc Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Elija granos partición cuidadosamente • La mayoría de los clientes utilizan mes, trimestre o año. • Para borra eficientes, debe eliminar una partición completa a la vez. • Es más rápido para cargar una partición completa en un momento. • Particiones diarias para cargas diarias pueden ser una opción atractiva. • Sin embargo, tenga en cuenta que una tabla puede tener un máximo de 1.000 particiones. • Grano partición afecta paralelismo consulta. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Elija granos partición cuidadosamente • Para SQL Server 2005: • Consultas tocar una sola partición pueden paralelizar hasta MAXDOP (máximo grado de paralelismo). • Consultas tocar varias particiones utilizan un hilo por partición hasta MAXDOP. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Elija granos partición cuidadosamente • Para SQL Server 2008: • Paralelo hilos hasta MAXDOP se distribuyen proporcionalmente a escanear las particiones y múltiples hilos por partición se pueden utilizar incluso cuando varias particiones deben ser escaneados. • Evitar un diseño de partición en la que sólo 2 o 3 particiones son tocados por las preguntas frecuentes, si usted necesita MAXDOP paralelismo (suponiendo MAXDOP = 4 o superior). Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Tablas de dimensiones diseño apropiado • Utilizar claves suplentes enteros para todas las dimensiones, excepto los de la dimensión Date. • Utilizar el número entero más pequeño posible para las claves suplentes dimensión. Esto ayuda a mantener la tabla de hechos estrecha. • Utilizar una clave significativa fecha de tipo entero derivable del tipo de datos DATETIME (por ejemplo: 20060215). • No haga utilizar una clave sustituta para la dimensión Date Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Tablas de dimensiones diseño apropiado • Construir un índice agrupado en la clave sustituta para cada dimensión tabla • Construir un índice no agrupado en la clave de negocio (posiblemente combinado con una fila fecha de vigencia) para apoyar a las búsquedas principales sustitutos durante cargas. • Construir no agrupado índices en otras columnas de dimensión buscados de manera frecuente. • Evite dividir tablas de dimensiones. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Tablas de dimensiones diseño apropiado • Evitar aplicar relaciones de clave externa entre el hecho y las tablas de dimensiones, para permitir que las cargas de datos más rápidas. • Usted puede crear restricciones de clave externa con NOCHECK para documentar las relaciones, pero no cumplir. • Asegurar integridad de los datos, aunque Transform búsquedas, o llevar a cabo las comprobaciones de integridad de datos en la fuente de los datos. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Escribir consultas efectivas para la eliminación de particiones • Cuando es posible, coloque un predicado de la consulta (condición WHERE) directamente en la clave de particionamiento (tecla de dimensión Date) de la tabla de hechos. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Utilice una técnica de ventana deslizante para mantener los datos • Mantener una ventana de tiempo de laminación para el acceso en línea a las tablas de hechos. Cargar los datos más recientes, descargar los datos más antiguos. • • Siempre mantener particiones vacías en ambos extremos de la gama de particiones para garantizar que la división de particiones (antes de cargar nuevos datos) y la partición de combinación (después de la descarga de datos antiguos) no incurren en ningún movimiento de datos. • Evitar dividir o fusionar particiones pobladas. La división o la fusión de particiones pobladas puede ser muy ineficiente, ya que esto puede causar hasta 4 veces más de generación de registro, así como producir un bloqueo severo. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Utilice una técnica de ventana deslizante para mantener los datos • Crear la tabla de ensayo de carga de la misma grupo de archivos como la partición que va a cargar. • Crear la descarga de la tabla de etapas en el mismo grupo de archivos como la partición que está deleteing. • Lo es más rápido para cargar más reciente partición completa de una sola vez, pero sólo es posible cuando el tamaño de la partición es igual a la frecuencia de carga de datos (por ejemplo, si tiene una partición por día, y cargar los datos de una vez al día). Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Utilice una técnica de ventana deslizante para mantener los datos • Si el tamaño de la partición no coincide con la frecuencia de carga de datos, incrementalmente cargar la última partición. • Vario opciones para la carga de datos en masa en una tabla con particiones se discuten en el documento técnico • http:/ / Www.microsoft.com / technet / prodtechnol / sql / BestPractice / loading_bulk_data_partitioned_table.mspx. • Siempre descargar una partición a la vez. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Eficiente cargar los datos iniciales • Utilizar Modelo de recuperación SIMPLE LOGGED oa granel durante la carga inicial de datos. • Crear la tabla de hechos se repartió con el índice agrupado. • Crear tablas no indexadas de estadificación para cada partición y los archivos de datos de origen separadas para poblar cada partición. • Poblar las tablas de importación en paralelo. • Utilizar múltiple BULK INSERT, BCP o SSIS tareas. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Eficiente cargar los datos iniciales • Crear como muchos guiones de carga para que se ejecuten en paralelo, ya que hay CPU, si no hay un cuello de botella IO. Si el ancho de banda IO es limitado, usar menos scripts en paralelo. • Utilizar 0 Tamaño de lote de la carga. Utilizar 0 comprometen tamaño de la carga. • Utilizar TABLOCK. • Utilizar BULK INSERT si las fuentes son archivos planos en el mismo servidor. Utilice BCP o SSIS si los datos está siendo empujado desde máquinas remotas. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Eficiente cargar los datos iniciales • Construir un índice agrupado en cada tabla de ensayo, a continuación, cree adecuadas las restricciones CHECK. • CAMBIAR todas las particiones en la tabla de particiones. • Construir no agrupado los índices de la tabla con particiones. • Posible para cargar 1 TB en menos de una hora en un servidor de 64 CPU con una SAN capaz de 14 GB / s de velocidad (tabla no indizada). Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Eficiente eliminar datos antiguos • Utilizar partición cambiar siempre que sea posible. • A eliminar millones de filas desde sin particiones, Tablas indizadas • Evitar DELETE FROM ... WHERE ... • Enorme bloqueo y problemas de registro • Largo rollback si la eliminación es cancelado • Por lo general, más rápido • Insertar los registros para mantener a una tabla no indizada • Crear un índice (es) Sobre la mesa • Cambiar el nombre de la nueva tabla para reemplazar el original Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Eficiente eliminar datos antiguos • Como una alternativa, elimina 'goteo' usando el siguiente repetidamente en un bucle BORRAR TOP (1000) ... ; COMMIT • Otra alternativa es actualizar la fila para marcar como eliminado, a continuación, eliminar tarde fuera del horario crítico. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Gestione estadísticas manualmente • Las estadísticas sobre las tablas con particiones se mantienen para la tabla en su conjunto. • Actualización manual de estadísticas sobre grandes tablas de hechos después de cargar nuevos datos. • Actualice manualmente las estadísticas después de la reconstrucción de índice en una partición. • Si se actualiza periódicamente estadísticas después de cargas periódicas, puede desactivar autostats en esa mesa. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Gestione estadísticas manualmente • Esto es importante para la optimización de las consultas que puedan necesitar para leer sólo los datos más recientes. • Actualización de las estadísticas sobre las pequeñas tablas de dimensiones después de cargas incrementales también pueden mejorar el rendimiento. • Utilizar Opción FULLSCAN de estadísticas de actualización de las tablas de dimensiones para los planes de consulta más precisos. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Considere las estrategias de copia de seguridad eficaces • Copia de seguridad de toda la base de datos puede tomar bastante tiempo para una base de datos muy grande. • Para ejemplo, copias de seguridad de una base de datos de 2 TB a un 10-husillo RAID-5 discos en una SAN puede tomar de 2 horas (a la tasa de 275 MB / seg). • Instantánea copia de seguridad con la tecnología SAN es una muy buena opción. • Reducir el volumen de los datos de copia de seguridad regularmente. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Considere las estrategias de copia de seguridad eficaces • La grupos de archivos para las particiones históricos pueden ser marcados como de sólo lectura. • Realizar una grupo de archivos copia de seguridad de una vez cuando un grupo de archivos pasa a ser de sólo lectura. • Realice copias de seguridad periódicas sólo en la lectura / escritura grupos de archivos. • Tenga en cuenta que restaura de sólo lectura del grupos de archivos no se puede realizar en paralelo. Fuente. Top 10 Mejores prácticas para la construcción a gran escala de almacenamiento de datos relacional SQL
    • Conclusión • Proyectos de bodegas de datos son diferentes de diseño relacional tradicional. • No supongamos que un desarrollador tradicional experto será capaz de liderar un proyecto de bodegas de datos • Reunir requisitos de usuario antes de la construcción del almacén de datos http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt