ventajas que español desventajas caracteristicas database database-design data-warehouse

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



mongodb español (7)

Un pequeño trasfondo aquí:

Sé lo que es un almacén de datos , 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 almacenamiento de datos parece ignorar los motivos para construir un almacén 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 de 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 debería poder responder son:

  1. ¿En qué punto construir un almacén de datos es 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?

  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. ¿Cuándo no debería intentar 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 sea la elección incorrecta , ¿qué son?

  5. ¿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.

Por lo general, trato de no preguntar a los multipartes, pero creo que todos están muy 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 haber aclarado la pregunta, gracias de antemano por sus respuestas.

¿En qué punto construir un almacén de datos es 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 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 sea la elección incorrecta, ¿qué son?

Yo diría que si no necesita mantener una larga historia, no está haciendo un análisis intensivo de los datos, y sus necesidades de informes se limitan 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 han usado almacenes de datos durante muchos años antes de mi llegada, por lo que no puedo hablar sobre cómo eran las cosas antes de llegar.

  1. Debería considerar construir un datawarehouse, cuando dos de los siguientes criterios coinciden:

    • Gran cantidad de datos
    • Muchas selecciones de grandes complejos (posiblemente en comparación con algunas inserciones, actualizaciones y eliminaciones) que solo tardan en ejecutarse (y se completan para su escritura)
    • Los datos de diferentes sistemas deben combinarse

  2. Realmente es la pregunta 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 en 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: solo porque tenga un puñado de consultas complejas, no significa que deba construir un DWH, lo mismo ocurre con los otros criterios, si se presentan aislados.

  5. No puedo ofrecer mucho aquí, pero el consejo es: agil. 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.

  1. El objetivo principal de un DW es acelerar (simplificar) los informes y analíticos. 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. Cortar y cortar en trozos 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 donde los usuarios de negocios se quejan interminablemente de informes lentos y la incapacidad de escribir "consultas complicadas", mientras que la gente de producción se queja de que la base de datos se atasca 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.

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

Hay cinco razones principales:

  • falta de asociación entre el departamento de TI y los usuarios comerciales;
  • arquitectura incorrecta del almacén de datos;
  • no hay suficientes personas con 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 punta.

DW podría considerarse si, uno está usando un ''Sistema transaccional'' de un período largo. 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.

Se deben seguir los siguientes pasos para construir una casa de almacenamiento de datos:

  1. Se debe decidir una plataforma ETL y una base de datos para 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.

Desde mi experiencia, el primer signo para comenzar a pensar en el almacenamiento de datos es cuando tienes (o estás desarrollando) una base de datos transaccional y los usuarios comienzan a agregar muchos requisitos de informes y 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 compañías donde muchos grupos crearon data warehouses porque los datos de interés se extendieron a través de muchos sistemas y, por lo tanto, era difícil consultarlos. El problema era que cada grupo creaba su propio almacén de datos porque todos los almacenes existentes en la empresa no tenían el subconjunto correcto 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.

Veré si puedo hacer mi mejor esfuerzo para responder 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é indicadores reveladores, métricas u otros criterios debería buscar, que podrían indicar que un entorno transaccional estándar 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.

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

do. 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.

re. 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 "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?

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 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 sea 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. ¿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.

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

En este caso, puedo indicarle algunos lugares que podrían proporcionarle 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 almacén 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.
  • "The Profit Impact of Business Intelligence" de Steve Williams ofrece una serie de estudios de casos que muestran el valor de la construcción de data warehouses.