BODEGAS DE DATOS:
PLANEANDO UNA
ARQUITECTURA
CORRECTA
Dr. Eduardo Castro, MSc
ecastro@simsasys.com
http://ecastrom.blogspo...
FUENTE DE PRESENTACIÓN

Almacenamiento de datos moderno, Minería y
Visualización: Core Conceptos por George M. Marakas
Dat...
Qué es la inteligencia de negocios?
• Un almacén de datos es generalmente un

componente de una solución global de
Busines...
Objetivo general
• El objetivo general de la

inteligencia empresarial es
proporcionar la información
necesaria para gesti...
BI se trata de "extracción de datos"
Etapas
(4)

sabiduría
conocimiento
información
datos

• El público de un almacén de d...
No es la tecnología
• Business Intelligence es sobre la entrega de

valor de negocio

• proporcionar un beneficio tangible...
Requisitos Arquitectura BI
• Debe reconocer el cambio como una

constante
• Tomar enfoque de desarrollo
incremental
• Apli...
Aceptación del usuario
• comprensibilidad
• comprensibilidad está en los ojos del espectador
• querer ocultar la complejid...
Aceptación del usuario
• Rendimiento
• no quieren interrumpir el proceso de
pensamiento
• proporcionar un solo clic, acces...
¿Qué son las bodegas de datos?
• Definido de muchas maneras diferentes, pero no rigurosamente.
• Una base de datos de sopo...
Bodegas de datos
• Organizada en torno a grandes temas, como la

clientes, productos, ventas
• Centrándose en el modelado ...
12

Necesidad de Data Warehousing
• Integrado, en toda la empresa con vista de

información de alta calidad (de diferentes...
Data Mart Definición
• Mercado de datos es un subconjunto completo

del almacén de datos global
• un único proceso de nego...
Integración en bodegas de datos
• Construido por la integración de múltiples fuentes de

datos heterogéneas
• bases de dat...
Variante en el tiempo
• El horizonte de tiempo para el almacén de datos es

significativamente más larga que la de los sis...
Plan del proyecto Data Warehouse
En primer lugar en la agenda es una evaluación de la
preparación.
Readiness tiene cinco f...
La Data Warehouse Plan del proyecto
(cont.)
En primer lugar en la agenda es una evaluación de la
preparación.
Readiness ti...
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í. Im...
Especificación el análisis y Diseño
Instrumentos

• Si bien se podría utilizar un enfoque de modelado

entidad-relación de...
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...
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 requisit...
El desarrollo de una arquitectura
técnica DW (cont.)
•

Allí son numerosas recetas para esto, pero un
proceso de cuatro ca...
Datos Almacén Proyecto Factores de
éxito
La construcción de un DW es muy similar a la
construcción de cualquier otro siste...
Arquitecturas de Data Warehouse
• Arquitectura de dos niveles
• Data Mart Independiente
• Data Mart dependiente y operacio...
Tres modelos de almacén de datos
• Almacén empresarial
• recoge toda la información sobre temas que abarcan toda la

organ...
Data Warehouse: Una arquitectura de varios
niveles
Otro
fuentes
Operacional
DBs

Metadatos

Extraer
Transformar
Cargar
Ref...
Desarrollo de Data Warehouse:
Un enfoque recomendado
Distribuido
Data Marts

Data
Mart

Data
Mart

Almacén de
datos Multi-...
Dos niveles de arquitectura de almacenamiento de datos genéricos

L

T

Uno de
ellos, de
toda la
compañía
almacén

E
Extra...
69

Data mart arquitectura de almacenamiento
de datos independiente

Mini-almacenes, limitada en su
alcance

L

T
E
ETL se...
70

Mercado de datos dependiente de almacén de datos operativos:
una arquitectura de tres niveles

ODS proporciona opción
...
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 re...
Depósito de datos back-end de herramientas y
utilidades
• Extracción de los datos
• obtener datos de múltiples, heterogéne...
Arquitecturas OLAP Server
• OLAP relacional (ROLAP)
• Utilice relacional o relacional ampliada DBMS para almacenar y

gest...
Uso de almacenamiento de datos
• Tres tipos de aplicaciones de almacenamiento de datos
• Tratamiento de la informació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...
Almacén Arquitectura Especificación y
Desarrollo
La siguiente fase es el diseño de la arquitectura técnica.
Ciertos elemen...
Almacén Arquitectura Especificación y
Desarrollo (cont.)
La siguiente fase es el diseño de la arquitectura
técnica. Cierto...
DW Arquitectura Áreas Componente
Clave
• Arquitectura de datos - cada área en un negocio se basa

en diferentes dimensione...
El proceso de clasificación de datos
Una parte importante de la arquitectura técnica es el
proceso de clasificación de dat...
Arquitectura de Alto Nivel
• Recordemos los diferentes "mundos"
• procesamiento de transacciones en línea (OLTP)
• sistema...
Dos Mundos
• On-Line Transaction Processing
• Entidad Modelo Relacional de Datos
• creada en 1960 para hacer frente a los ...
Dos Mundos
• Business Intelligence Sistemas
• Modelo Dimensional
• También llamado esquema en estrella
• Diseñado para fac...
Ventajas modelo dimensional
• Sencillez
• Los seres humanos pueden navegar y

recordar
• Software puede navegar determinis...
Best Practice # 1
Usar un modelo de datos que se ha optimizado para la

recuperación de la información
• Modelo tridimens...
Procesos de Adquisición de Datos
• Extraer Transform Load (ETL)
• El proceso de descarga o copia de datos de los
sistemas ...
Aseguramiento de la Calidad de Datos
• Limpieza de datos

• El proceso de validación y el enriquecimiento de

los datos ta...
Recogida de datos y limpieza
• La obtención de datos cargados de manera eficiente y

correctamente es crítico para el éxit...
Best Practice # 2
Diseñar cuidadosamente la adquisición de datos y

procesos de limpieza para su DW
• Asegurar los datos ...
Modelo de Datos
• Ya se ha examinado los beneficios de un modelo

multidimensional
• No importa si se utiliza modelado mul...
Documentar el modelo de datos
• Lo más recomendable es utilizar algún tipo de herramienta de

modelado de datos
• CA ERwin...
Modelo de Datos de Metadatos
• Definiciones de negocios deben registrarse para

cada campo (a menos que sean sólo los
camp...
Arquitectura Metadatos
• La estrategia para el modelo de intercambio de datos y

otros metadatos debe ser formalizado y do...
Best Practice # 3
Diseñar una arquitectura de metadatos que permite el

intercambio de metadatos entre los componentes de...
Arquitectura Enfoques Alternativos
• Bill Inmon: "Información sobre la fábrica de las empresas"
• Hub and Spoke filosofía
...
Lo que queremos
(Principal Architectural)
• En la mayoría de los casos, de negocios y de TI de

acuerdo en que el almacén ...
DW Arquitectura
• Cómo diseñar un almacén de datos de la empresa

y garantizar una "única versión de la verdad"?
• De acue...
Data Warehouse Bus Architecture
• Llamado así por el autobús en un ordenador
• interfaz estándar que permite conectar en C...
Diseñar El Bus DW
• Determinar qué dimensiones serán compartidos

a través de múltiples data marts
• Conformar las dimensi...
Granularidad de las dimensiones
• Dimensiones compatibles serán generalmente granular
• hace que sea fácil de integrar con...
Consolidación de Datos
• Una tendencia actual en BI / DW es "la consolidación de

datos '
• Desde una perspectiva de prove...
Integración de Datos
• Para lograr realmente "una única versión de

la verdad", debe hacer algo más que la
consolidación d...
Best Practice # 4
Adoptar un enfoque que consolida los datos en "una sola

versión de la verdad"
• Data Warehouse Bus
• D...
Operational Data Store (ODS)
• un único punto de integración para los sistemas

operativos dispares
• contiene los datos i...
ODS en DW Arquitectura
• En el caso en que un ODS es un

componente necesario de la DW en
general, debe ser cuidadosamente...
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
• n...
Best Practice # 5
Considere la posibilidad de la aplicación de un

ODS sólo cuando los requisitos de recuperación
de info...
Planificación de la capacidad
• Cargas de trabajo de DW son típicamente muy

exigentes, sobre todo de la capacidad de E / ...
Escala SMP
• Rendimiento de escala dentro de un único

servidor SMP se conoce como "escala up”

• Puntos de referencia de ...
Best Practice # 6
Crear un plan de capacidad para su aplicación

BI y monitorear cuidadosamente
Considere la posibilidad...
DW Appliance
• Aparatos DW, que consisten en paquetes de

soluciones que proporcionan todo el
software y hardware necesari...
Unas palabras sobre Metadatos
• En la secuencia de pasos de especificar el modelo de

almacén, para su aplicación, para su...
82

El proceso de ETL
• Captura / Extracto
• Frote o limpieza de datos
• Transformar
• Carga y el índice

ETL = extracción...
83

Captura / Extracto ... obtener una instantánea de un subconjunto
seleccionado de los datos de origen para la carga en ...
Scrub / Cleanse ... utiliza técnicas de reconocimiento de
patrones y la IA para mejorar la calidad de los datos

Pasos en ...
Pasos en la
conciliación de
datos
(Cont.)

Transformar = convertir datos de un formato de
sistema operativo al formato de ...
Carga / index = lugar transforma los
datos en el almacén y crear índices
Pasos en la
conciliación de
datos
(Cont.)

Modo d...
Componentes de un esquema en estrella

88

Las tablas de hechos

contener datos objetivos y
cuantitativos

Relación 1: N e...
Ejemplo de esquema de estrella
Tabla de hechos proporciona

estadísticas de ventas
desglosadas por productos, de
época y t...
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 c...
Diez errores communes - 02
Establecimiento de expectativas poco realistas que no se
pueden cumplir
a. El almacenamiento de...
Diez errores communes - 03
Promover el valor incorrecto de sus datos Almacén
a. Participación en el comportamiento polític...
Diez errores communes - 04
Carga de depósito de datos con información innecesaria
a. envía una lista de elementos de la ta...
Diez errores communes - 05
Data Warehouse Design Database vs Base de datos
transaccional Diseño
a. Procesamiento de transa...
Diez errores comunes - 06
Data Warehousing Manager: orientada a la tecnología en
lugar de Orientado a los usuarios
a. usua...
Diez errores communes - 07
Demasiado énfasis en orientado a registro interno
tradicional datos
a. altos ejecutivos ven alm...
Diez errores comunes - 08
La entrega de los datos con la superposición y confusión
definiciones
a. Gerente de Finanzas - v...
Diez errores communes - 09
Rendimiento, capacidad y escalabilidad
a. dentro de 4 meses, la compra de al menos un
procesado...
Diez errores comunes - 10
Convencidos de que una vez que el depósito de datos
está en funcionamiento, sus problemas han ac...
Factores críticos de éxito
• Proyecto líder debe ser experimentado
• Cuidadoso Recopilación y análisis de necesidades de l...
Top 10 Mejores prácticas para la construcción de una
gran escala de almacenamiento de datos relacional
• La construcción d...
Considere la posibilidad de dividir las
grandes tablas de hechos
• Considere la posibilidad de particionar tablas de hecho...
Construir índice agrupado en la fecha
clave de la tabla de hechos
• Esto apoya las consultas eficientes para llenar cubos ...
Construir índice agrupado en la fecha
clave de la tabla de hechos
• Construir no agrupado índices de cada clave externa.
•...
Elija granos partición cuidadosamente
• La mayoría de los clientes utilizan mes, trimestre o año.
• Para borra eficientes,...
Elija granos partición cuidadosamente
• Para SQL Server 2005:
• Consultas tocar una sola partición pueden paralelizar hast...
Elija granos partición cuidadosamente
• Para SQL Server 2008:
• Paralelo hilos hasta MAXDOP se distribuyen proporcionalmen...
Tablas de dimensiones diseño apropiado
• Utilizar claves suplentes enteros para todas las

dimensiones, excepto los de la ...
Tablas de dimensiones diseño apropiado
• Construir un índice agrupado en la clave sustituta para

cada dimensión tabla
• C...
Tablas de dimensiones diseño apropiado
• Evitar aplicar relaciones de clave externa entre el hecho y

las tablas de dimens...
Escribir consultas efectivas para la
eliminación de particiones
• Cuando es posible, coloque un predicado de la consulta

...
Utilice una técnica de ventana deslizante
para mantener los datos
• Mantener una ventana de tiempo de laminación para el a...
Utilice una técnica de ventana deslizante
para mantener los datos
• Crear la tabla de ensayo de carga de la misma grupo de...
Utilice una técnica de ventana deslizante
para mantener los datos
• Si el tamaño de la partición no coincide con la frecue...
Eficiente cargar los datos iniciales
• Utilizar Modelo de recuperación SIMPLE LOGGED oa granel

durante la carga inicial d...
Eficiente cargar los datos iniciales
• Crear como muchos guiones de carga para que se

ejecuten en paralelo, ya que hay CP...
Eficiente cargar los datos iniciales
• Construir un índice agrupado en cada tabla de ensayo, a

continuación, cree adecuad...
Eficiente eliminar datos antiguos
• Utilizar partición cambiar siempre que sea posible.
• A eliminar millones de filas des...
Eficiente eliminar datos antiguos
• Como una alternativa, elimina 'goteo' usando el siguiente

repetidamente en un bucle

...
Gestione estadísticas manualmente
• Las estadísticas sobre las tablas con particiones se

mantienen para la tabla en su co...
Gestione estadísticas manualmente
• Esto es importante para la optimización de las consultas

que puedan necesitar para le...
Considere las estrategias de copia de
seguridad eficaces
• Copia de seguridad de toda la base de datos puede

tomar bastan...
Considere las estrategias de copia de
seguridad eficaces
• La grupos de archivos para las particiones históricos

pueden s...
Conclusión
• Proyectos de bodegas de datos son diferentes de diseño

relacional tradicional.
• No supongamos que un desarr...
Arquitecura de bodega de datos
Upcoming SlideShare
Loading in...5
×

Arquitecura de bodega de datos

2,696

Published on

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

1 Comment
10 Likes
Statistics
Notes
  • Excelente trabajo....
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,696
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
1
Likes
10
Embeds 0
No embeds

No notes for slide

Arquitecura de bodega de datos

  1. 1. 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
  2. 2. 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
  3. 3. 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 ...
  4. 4. 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"
  5. 5. 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
  6. 6. 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?
  7. 7. 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
  8. 8. Aceptación del usuario • comprensibilidad • comprensibilidad está en los ojos del espectador • querer ocultar la complejidad • tratar de hacerlo: • intuitiva, obvia • visible, memorable
  9. 9. 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"
  10. 10. ¿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
  11. 11. 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. 12. 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)
  13. 13. 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 "
  14. 14. 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.
  15. 15. 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"
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. ARQUITECTURA DE BODEGAS DE DATOS MEJORES PRÁCTICAS
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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)
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 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)
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. Modelo Dimensional para una Ventas al por menor Pronóstico http://courseware.finntrack.eu/it/data/marakas_dw_ch6.ppt
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. 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)
  46. 46. 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
  47. 47. 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
  48. 48. 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
  49. 49. 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
  50. 50. 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!
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. 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)
  56. 56. 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
  57. 57. 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
  58. 58. 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
  59. 59. 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
  60. 60. 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
  61. 61. 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
  62. 62. 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'
  63. 63. 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
  64. 64. Best Practice # 4 Adoptar un enfoque que consolida los datos en "una sola versión de la verdad" • Data Warehouse Bus • Dimensiones y Hechos
  65. 65. 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
  66. 66. 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 ...
  67. 67. 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
  68. 68. 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 '
  69. 69. 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
  70. 70. 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
  71. 71. 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!
  72. 72. 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
  73. 73. 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
  74. 74. 82 El proceso de ETL • Captura / Extracto • Frote o limpieza de datos • Transformar • Carga y el índice ETL = extracción, transformación y carga
  75. 75. 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
  76. 76. 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
  77. 77. 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
  78. 78. 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
  79. 79. 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
  80. 80. Ejemplo de esquema de estrella Tabla de hechos proporciona estadísticas de ventas desglosadas por productos, de época y tienda de dimensiones
  81. 81. Esquema estrella con datos de ejemplo
  82. 82. DATA WAREHOUSE Diez errores comunes http://msit.cp.su.ac.th/msit3/PPT/Data% 20warehouse% 20Design.ppt
  83. 83. 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
  84. 84. 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
  85. 85. 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
  86. 86. 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
  87. 87. 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
  88. 88. 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
  89. 89. 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
  90. 90. 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
  91. 91. 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
  92. 92. 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
  93. 93. 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
  94. 94. 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
  95. 95. 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
  96. 96. 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
  97. 97. 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
  98. 98. 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
  99. 99. 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
  100. 100. 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
  101. 101. 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
  102. 102. 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
  103. 103. 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
  104. 104. 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
  105. 105. 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
  106. 106. 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
  107. 107. 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
  108. 108. 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
  109. 109. 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
  110. 110. 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
  111. 111. 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
  112. 112. 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
  113. 113. 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
  114. 114. 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
  115. 115. 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
  116. 116. 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
  117. 117. 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

×