Consideraciones sobre el almacenamiento de datos: ¿cuándo y por qué?

Question

Un poco de fondo aquí:

Sé what a data warehouse is, más o menos. He leído varias docenas de guías sobre almacenamiento de datos, he jugado con SSAS, sé lo que es un esquema de estrella, una tabla de dimensiones y una tabla de hechos, sé lo que es ETL y cómo hacerlo. Esta no es una pregunta de "cómo" o una solicitud de tutoriales.

Mi problema es que todo el material que he leído sobre el almacenamiento de datos parece pasar por alto el razón de ser para construir un depósito de datos. Todos ellos, en sentido figurado, o en algunos casos, literalmente comienzan con la frase "por lo que ha decidido construir un almacén de datos ..." Excepto que aún no tomé esa decisión.

Así que espero que los miembros SO puedan indicarme o ayudarme a llegar a algún tipo de prueba semi-objetiva. Algo que puedo adaptar a un sistema en particular y terminar con "sí, necesitamos un almacén de datos" o "no, la recompensa de hoy sería demasiado pequeña". Creo que las preguntas específicas que deben ser capaces de responder son:

1. ¿En qué momento es la construcción de un almacén de datos de una opción digna de consideración? En otras palabras, ¿qué indicadores reveladores, métricas u otros criterios debería buscar, que podrían indicar que un entorno transaccional estándar ya no es suficiente?

2. ¿Cuáles son las alternativas a un almacén de datos completo? La desnormalización en la base de datos transaccional y el "servidor de informes" duplicado estándar del pantano son dos que vienen a la mente; ¿Hay otros que deba explorar antes de comprometerme con el DW?

3. ¿Por qué es un almacén de datos mejor que dichas alternativas? Si la respuesta es "depende", ¿de qué depende?

4. Cuando no debería intento construir un almacén de datos? Soy escéptico de cualquier cosa declarada como una "mejor práctica" independientemente del contexto. Seguramente debe haber algunos escenarios en los que un DW es la opción equivocada - ¿qué son?

5. ¿Hay ejemplos prácticos de que podría consultar en los sistemas que se mejoraron mediante la introducción de un almacén de datos? Algo que me explique, de principio a fin, qué tipo de decisiones o análisis necesitaban para el almacén, cómo decidieron qué poner en él, y cómo el almacén terminó encajando en el entorno más amplio. No quiero un artificio "vamos a hacer un cubo de la base de datos de AdventureWorks" - la implementación es irrelevante para mí, estoy interesado en las especificaciones y los diseños y proceso de pensamiento que participaron.

por lo general tratan de no hacer multi-parters pero creo que estos son todos muy estrechamente relacionados. Estoy dispuesto a aceptar cualquier respuesta que aborde al menos las primeras 4 preguntas, aunque la última realmente ayudaría a cristalizar esto en mi mente. Los enlaces están bien si alguien ya ha escrito sobre esto, siempre que sean razonablemente concisos y específicos (enlace a la página de inicio de Ralph Kimball = no útil).

Espero que haya aclarado la pregunta, gracias de antemano por sus respuestas!

Answer 1

A ver si puedo hacer mi mejor esfuerzo para responder a sus preguntas de manera sucinta.

1. ¿En qué punto la construcción de un almacén de datos es una opción que vale la pena considerar? En otras palabras, ¿qué signos reveladores, métricas, u otros criterios que deben ser mirando hacia fuera para que pudiera indicar que una norma entorno transaccional ya no es suficiente?

a. Si observa que la generación de informes y el monitoreo están perjudicando el rendimiento de su sistema de producción y/o un almacén de datos fuera de línea.

b. Si encuentra que obtener respuestas a las preguntas de su negocio requiere construir una gran cantidad de SQL complejos cada vez.

c. Si descubre que cada vez que realiza un cambio en su esquema transaccional, debe volver atrás y volver a procesar todas sus consultas de informes.

d. Si desea reunir datos de múltiples fuentes.

2. ¿Cuáles son las alternativas a un almacén de datos completo? La desnormalización en la base de datos transaccional y el estándar de pantano replicado "servidor de informes" son dos que vienen a la mente; ¿Hay algún más que deba explorar antes de comprometerse con el DW?

3.¿Por qué un almacén de datos es mejor que dichas alternativas? Si la respuesta es "depende", entonces ¿en qué depende ?

Voy a responder a esto juntos. No pensaría en un almacén de datos como una empresa de todo o nada. Es simplemente una frase concisa que significa "almacenar sus datos de una manera que le permite responder preguntas de negocios de manera más fácil y rápida".

Las bases de datos transaccionales están diseñadas para interactuar eficientemente con las aplicaciones. Los almacenes de datos, los mercados de datos, los almacenes de datos operativos y las tablas de informes están diseñados para interactuar eficientemente con las personas, si eso tiene sentido.

4. ¿Cuándo no debería intentar construir un depósito de datos? Soy escéptico de cualquier cosa declarada como una "mejor práctica" independientemente del contexto. Seguramente no debe haber algunos escenarios donde un DW es la elección incorrecta - ¿qué son?

Buena pregunta. Si su sistema transaccional le proporciona suficiente información sobre su negocio, es probable que no tenga necesidad de almacenamiento.

Si solo tiene una fuente de datos y el rendimiento no es un problema, probablemente pueda obtener información a partir de la creación de tablas de informes simples.

¿5.Are Hay ejemplos prácticos yo pude ver que eran de los sistemas mejorado mediante la introducción de un dato almacén? Algo que explicar a mí, de extremo a extremo, lo que ordena de decisiones o análisis que necesitaban el deposito para que, como decidieron qué poner en ella, y cómo el almacén terminaron encajando en la más grande ¿ambiente? No quiero un artificial "vamos a hacer un cubo de la base de datos AdventureWorks" - la aplicación es irrelevante para mí, estoy interesado en las especificaciones y diseños y proceso general de pensamiento que estuvieron involucrados.

Esa es una gran pregunta que tomaría mucho más espacio de lo que me asignan aquí.

En este caso, puedo indicarle algunos lugares que podrían brindarle la información que busca.

• "Implementing A Data Warehouse: Una metodología que funcionó" de Bruce Ullrey es un libro que documenta el camino de un hombre hacia la construcción de un depósito de datos. No está muy pulido, lo que le da más realismo. Se lee como un diario con muchos modelos y otras imágenes que ilustran bastante bien sus esfuerzos.
• "Business Intelligence Roadmap" por Larissa Moss. Tarifa estándar. Le muestra el proceso de construir una práctica de BI en un nivel alto.
• "El impacto de los beneficios de la inteligencia empresarial" de Steve Williams ofrece una serie de estudios de casos que muestran el valor de la construcción de data warehouses.

Answer 2

¿En qué punto es la construcción de un almacén de datos una opción que vale la pena considerar? En otras palabras, ¿qué indicadores reveladores, métricas u otros criterios debería buscar, que podrían indicar que un entorno transaccional estándar ya no es suficiente?

Recomendaría un almacén de datos cuando observara que realizar actividades de informes y análisis en el almacén de datos transaccionales era dañino para ambos.

¿Cuáles son las alternativas a un almacén de datos completo? La desnormalización en la base de datos transaccional y el "servidor de informes" duplicado estándar del pantano son dos que vienen a la mente; ¿Hay otros que deba explorar antes de comprometerme con el DW?

No tengo nada que ofrecer aquí. Diría que mantener las bases de datos transaccionales y de informes me parece sensato, independientemente de si lo llaman almacén o no. La minería de datos puede ser una actividad muy intensiva de la CPU.

¿Por qué es un almacén de datos mejor que dichas alternativas? Si la respuesta es "depende", ¿de qué depende?

No tengo nada que ofrecer aquí.

¿Cuándo no debería intentar construir un depósito de datos? Soy escéptico de cualquier cosa declarada como una "mejor práctica" independientemente del contexto. Seguramente debe haber algunos escenarios en los que un DW sea la elección incorrecta, ¿qué son?

Yo diría que si no es necesario para mantener larga historia, no están haciendo análisis intensivo de los datos, y sus necesidades de información se limita a una consulta ad hoc de vez en cuando, entonces tal vez un almacén de datos no es necesario.

¿Hay algún ejemplo práctico que pueda ver de los sistemas que se mejoraron mediante la introducción de un almacén de datos? Algo que me explique, de principio a fin, qué tipo de decisiones o análisis necesitaban para el almacén, cómo decidieron qué poner en él, y cómo el almacén terminó encajando en el entorno más amplio. No quiero una idea artificial de "hagamos un cubo de la base de datos de AdventureWorks": la implementación es irrelevante para mí, estoy interesado en las especificaciones, los diseños y el proceso de reflexión general que se produjo.

Mis empleadores tienen todos los almacenes de datos utilizados desde hace muchos años antes de mi llegada, por lo que no puedo hablar de cómo eran las cosas antes de llegar.

Answer 3

Según mi experiencia, el primer signo para comenzar a pensar en el almacenamiento de datos es cuando tiene (o está desarrollando) una base de datos transaccional y los usuarios comienzan a agregar muchos informes y requisitos de historial de datos. Que es más o menos siempre. Siempre es más fácil tener un almacén de datos o una base de datos de informes independientes que tratar de diseñar un sistema transaccional que maneje las necesidades de informes que los usuarios finales siempre tienen. Almacenar el historial (para entidades comerciales) en un sistema transaccional agrega complejidad e hincha una base de datos que debe ser tan receptiva como sea posible.

Por otro lado, he estado en grandes empresas donde muchos grupos crearon almacenes de datos porque los datos de interés se extendieron a través de muchos sistemas y, por lo tanto, era difícil de consultar.El problema era que cada grupo creaba su propio depósito de datos porque todos los almacenes existentes en la empresa no tenían el subconjunto adecuado de información, o tenían un modelo de datos que se consideraba no óptimo o incorrecto. Esto empeoró la situación al crear sistemas de datos aún más dispares que eran difíciles de comparar.

Answer 4

1. Usted debe considerar la construcción de un almacén de datos, cuando dos de los siguientes criterios de partido:

   • cantidad enorme de datos
   • Muchos selecciona complejos grandes (posiblemente compararon a pocos inserciones, actualizaciones y eliminaciones) que solo lleva mucho tiempo para ejecutarse (y se completan para escribir)
   • Datos de diferentes sistemas deben combinarse

2. Realmente es la pregunta de lo que usted considera un almacén de datos. En muchos casos, puede pasar gradualmente de los sistemas OLTP con algunos informes a un datawarehouse completo, siempre que pueda apegarse a un sistema de administración de bases de datos relacionales. Primero podría ser construir una primera tabla de hechos, y seguir usando las tablas normalizadas para la dimensión. Luego agregue más datos, más tablas de hechos o tablas de dimensiones dedicadas al juego. Primero en la misma base de datos (o en una de las bases de datos de los sistemas involucrados), posiblemente moviéndose posteriormente a una base de datos separada.

3. Un datawarehouse completo (base de datos separada, esquema de estrella) ofrece las mejores opciones para sintonizar declaraciones seleccionadas, además de ir a un sistema especializado. También está claramente desacoplado de los sistemas oLTP. Piensa en el diseño de esquemas, pero también en recursos como CPU, E/S, memoria y organización, como la programación de nuevas versiones. Por supuesto, es mucho trabajo que posiblemente no necesite.

4. Está en las respuestas anteriores: simplemente porque tiene un puñado de consultas complejas, no significa que deba construir un DWH, lo mismo ocurre con los otros criterios, si se presentan de forma aislada.

5. No se puede ofrecer mucho aquí, pero el consejo es: agile. Los requisitos para un DWH dependen extremadamente de las posibilidades que ven los usuarios. Es probable que los requisitos cambien. Automatizar las pruebas con bases de datos es una molestia, pero perder el tiempo en un sistema de producción sin pruebas adecuadas es peor.

Answer 5

1. El propósito principal de un DW es para acelerar la presentación de informes y analítica (simplificar). Permite dividir y dividir los datos de cualquier forma que un usuario de negocios pueda pensar.

2. Para un primer paso DW, simplemente puede implementar un esquema de estrella Kimball y ejecutar consultas SQL en su contra. Si esto resulta demasiado lento, comience a pensar en agregaciones precalculadas (cubos).

3. El corte y recorte de información contra un DW es mucho más simple que contra un DB normalizado. El servidor de informes replicados mejorará el rendimiento, pero no simplificará el corte y el corte. También tenga en cuenta que el DW pertenece a los usuarios comerciales, por lo que les corresponde a ellos crear varias ideas de segmentación/dados en cualquier momento: las personas de TI deberían simplemente proporcionar un entorno en el que algo como esto sea posible.

4. Si solo ejecuta algunos informes de vez en cuando en su sistema operativo y está satisfecho con el rendimiento, no hay necesidad de DW.

5. Toda mi experiencia es con sistemas en los que los usuarios comerciales se quejan de informes lentos e incapacidad de escribir "consultas complicadas", mientras que los productores se quejan de que la base de datos se empantana debido a los informes. En todos los casos, una estrella simple de Kimball y un servidor de informes con memoria caché e instantáneas eran lo suficientemente buenos.

Answer 6

"Creo que ¿por qué algunos proyectos fallan?"

Hay cinco razones principales:

• falta de colaboración entre el departamento de TI y los usuarios de negocios;
• arquitectura de almacén de datos incorrecta;
• personas con poca experiencia;
• planificación inadecuada, como no utilizar una metodología probada y un plan para garantizar que no se omitan los detalles;
• y dependiendo de la tecnología de vanguardia.

Answer 7

DW podría considerarse si, uno está utilizando un 'Sistema transaccional' de un período prolongado. Más tarde, se dan cuenta de que necesitan realizar una minería de datos para determinar los diferentes patrones de datos del negocio. Y finalmente, con la ayuda de los patrones de datos determinados, se quiere ayudar a la alta dirección a tomar más decisiones en beneficio de la empresa.

Los siguientes pasos tiene que ser tomado para la construcción de una casa de las mercancías de datos:

1. Una plataforma ETL y la base de datos tiene que ser decidido por la base de datos.
2. Se debe elegir una herramienta de informe como SSRS, Tableau, etc. para la visualización.
3. Se puede optar por el lenguaje de análisis de datos como R, para un uso posterior.
4. Finalmente, todo esto ayudará a desarrollar la casa de almacenamiento de datos y la herramienta de informes.