El desarrollo del almacenamiento es un negocio largo y serio.
Gran parte de la vida de un proyecto depende de qué tan bien se hayan pensado al principio el modelo de objeto y la estructura base.
El enfoque generalmente aceptado ha sido y sigue siendo varias combinaciones del esquema en estrella con la tercera forma normal. Como regla, según el principio: datos iniciales - 3NF, vitrinas - una estrella. Este enfoque, probado en el tiempo y respaldado por una gran cantidad de investigaciones, es lo primero (y, a veces, lo único) que le viene a la mente a un especialista en DWH con experiencia cuando piensa en cómo debería ser un repositorio analítico.
Por otro lado, los negocios en general y los requisitos de los clientes en particular tienden a cambiar rápidamente, mientras que los datos crecen tanto "en profundidad" como "en amplitud". Y aquí aparece el principal inconveniente de la estrella: limitado flexibilidad.
Y si en tu vida tranquila y cómoda como desarrollador DWH de repente:
- surgió la tarea de “hacer al menos algo rápido, y luego ya veremos”;
- apareció un proyecto en rápido desarrollo, con la conexión de nuevas fuentes y la alteración del modelo de negocio al menos una vez por semana;
- apareció un cliente que no tiene idea de cómo debería verse el sistema y qué funciones debería realizar al final, pero está listo para los experimentos y el refinamiento constante del resultado deseado con un enfoque consistente;
- el gerente del proyecto miró con buenas noticias: "¡Y ahora tenemos ágil!".
O si solo está interesado en saber de qué otra manera puede construir almacenamiento, ¡bienvenido al gato!
¿Qué significa "flexibilidad"?
Para empezar, definamos qué propiedades debe tener un sistema para ser llamado “flexible”.
Por separado, vale la pena mencionar que las propiedades descritas deben referirse específicamente a sistemano a proceso su desarrollo Por tanto, si querías leer sobre Agile como metodología de desarrollo, es mejor que leas otros artículos. Por ejemplo, ahí mismo, en Habré, hay muchos materiales interesantes (como и Y ).
Esto no significa que el proceso de desarrollo y la estructura del almacén de datos no tengan ninguna relación. En general, el desarrollo ágil de un almacenamiento ágil debería ser mucho más fácil. Sin embargo, en la práctica, hay más opciones con el desarrollo ágil de DWH clásico según Kimbal y DataVault, según cascada, que felices coincidencias de flexibilidad en sus dos formas en un proyecto.
Entonces, ¿qué características debe tener el almacenamiento flexible? Hay tres puntos aquí:
- Entrega anticipada y finalización rápida - esto significa que, idealmente, el primer resultado comercial (por ejemplo, los primeros informes de trabajo) debe obtenerse lo antes posible, es decir, incluso antes de que se diseñe e implemente todo el sistema. Al mismo tiempo, cada revisión posterior también debería tomar el menor tiempo posible.
- refinamiento iterativo - esto significa que cada revisión posterior, idealmente, no debería afectar la funcionalidad que ya funciona. Es este momento el que a menudo se convierte en la mayor pesadilla en proyectos grandes: tarde o temprano, los objetos individuales comienzan a adquirir tantas relaciones que se vuelve más fácil repetir completamente la lógica en una copia al lado del otro que agregar un campo a una tabla existente. Y si le sorprende que el análisis del impacto de las mejoras en los objetos existentes pueda llevar más tiempo que la propia revisión, lo más probable es que no haya trabajado con grandes almacenes de datos en la banca o las telecomunicaciones.
- Adaptación constante a los requisitos comerciales cambiantes - la estructura del objeto general debe diseñarse no solo teniendo en cuenta la posible expansión, sino con la expectativa de que la dirección de esta próxima expansión ni siquiera se podría soñar en la etapa de diseño.
Y sí, el cumplimiento de todos estos requisitos en un solo sistema es posible (por supuesto, en determinados casos y con algunas reservas).
A continuación, revisaré dos de las metodologías de diseño ágil más populares para HD: modelo de ancla и Bóveda de datos. Fuera de los corchetes hay trucos tan excelentes como, por ejemplo, EAV, 6NF (en su forma pura) y todo lo relacionado con las soluciones NoSQL, no porque sean peores de alguna manera, y ni siquiera porque en este caso el artículo amenazaría con adquirir el volumen. de un disertante promedio. Es solo que todo esto se refiere a soluciones de una clase ligeramente diferente, ya sea a técnicas que puede aplicar en casos específicos, independientemente de la arquitectura general de su proyecto (como EAV), o a paradigmas de almacenamiento de información globalmente diferentes (como bases de datos de gráficos y otras opciones). NoSQL).
Problemas del enfoque “clásico” y sus soluciones en metodologías flexibles
Por el enfoque "clásico" me refiero a la buena vieja estrella (independientemente de la implementación específica de las capas subyacentes, perdónenme los seguidores de Kimball, Inmon y CDM).
1. Cardinalidad rígida de conexiones
Este modelo se basa en una división clara de los datos en medidas (Dimensión) и hechos (Hecho). Y esto, maldita sea, es lógico: después de todo, el análisis de datos en la gran mayoría de los casos se reduce al análisis de ciertos indicadores numéricos (hechos) en ciertas secciones (dimensiones).
Al mismo tiempo, los enlaces entre objetos se establecen en forma de enlaces entre tablas mediante una clave externa. Esto parece bastante natural, pero inmediatamente conduce a la primera limitación de flexibilidad: definición estricta de la cardinalidad de las relaciones.
Esto significa que en la etapa de diseño de las tablas, debe especificar para cada par de objetos relacionados si se pueden relacionar muchos a muchos o solo 1 a muchos, y "en qué dirección". Depende directamente de cuál de las tablas tendrá una clave principal y cuál tendrá una clave externa. Cambiar esta proporción cuando se reciban nuevos requisitos probablemente conducirá a una reelaboración de la base.
Por ejemplo, al diseñar el objeto "recibo de efectivo", usted, confiando en las garantías juradas del departamento de ventas, estableció la posibilidad de acción una promoción para varias posiciones de cheques (pero no al revés):
Y después de un tiempo, los colegas introdujeron una nueva estrategia de marketing en la que varias promociones al mismo tiempo. Y ahora necesita finalizar las tablas resaltando la relación en un objeto separado.
(Todos los objetos derivados, en los que se une el cheque de promoción, ahora también deben mejorarse).
Vínculos en Data Vault y Anchor Model
Resultó ser bastante simple evitar tal situación: no tienes que confiar en el departamento de ventas, es suficiente todas las relaciones se almacenan inicialmente en tablas separadas y procesar como muchos a muchos.
Este enfoque ha sido propuesto dan linstedt como parte del paradigma Bóveda de datos y totalmente respaldado Lars Rönnbäck в Modelo de ancla.
Como resultado, obtenemos el primer rasgo distintivo de las metodologías flexibles:
Las relaciones entre objetos no se almacenan en los atributos de las entidades principales, sino que son un tipo de objeto separado.
В Bóveda de datos tales tablas se llaman Enlace, Y en Modelo de ancla - Corbata. A simple vista son muy similares, aunque sus diferencias no se agotan en el nombre (que se comentará más adelante). En ambas arquitecturas, las tablas de enlace pueden enlazar cualquier número de entidades (no necesariamente 2).
Esta redundancia a primera vista proporciona una flexibilidad esencial en las terminaciones. Tal estructura se vuelve tolerante no solo para cambiar las cardinalidades de los enlaces existentes, sino también para agregar otros nuevos: si ahora una posición de cheque también tiene un enlace con el cajero que lo rompió, la apariencia de dicho enlace será simplemente una superestructura. sobre las tablas existentes sin afectar a los objetos y procesos existentes.
2. Duplicación de datos
El segundo problema que resuelven las arquitecturas flexibles es menos obvio e inherente en primer lugar. medidas tipo SCD2 (cambiando lentamente las medidas del segundo tipo), aunque no solo ellas.
En el almacenamiento clásico, una dimensión suele ser una tabla que contiene una clave sustituta (como PK) y un conjunto de claves y atributos comerciales en columnas separadas.
Si la dimensión admite el control de versiones, los límites de tiempo de la versión se agregan al conjunto estándar de campos y aparecen múltiples versiones en el repositorio por fila en la fuente (una para cada cambio en los atributos con versión).
Si una dimensión contiene al menos un atributo versionado que cambia con frecuencia, la cantidad de versiones de dicha dimensión será impresionante (incluso si los otros atributos no están versionados o nunca cambian), y si hay varios atributos de este tipo, la cantidad de versiones puede crecer exponencialmente a partir de su número. Tal dimensión puede ocupar una cantidad significativa de espacio en disco, aunque la mayoría de los datos almacenados en ella son simplemente duplicados de valores de atributos inmutables de otras filas.
Al mismo tiempo, también se usa a menudo desnormalización - algunos de los atributos se almacenan intencionalmente como un valor y no como una referencia a un libro de referencia u otra dimensión. Este enfoque acelera el acceso a los datos al reducir el número de uniones al acceder a una dimensión.
Típicamente, esto resulta en la misma información se almacena simultáneamente en varios lugares. Por ejemplo, la información sobre la región de residencia y la pertenencia a la categoría de cliente se puede almacenar simultáneamente en las dimensiones "Cliente" y los hechos "Compra", "Entrega" y "Contactos con el centro de llamadas", así como en el tabla de enlace “Cliente - Gestor de clientes”.
En general, lo anterior se aplica a las mediciones regulares (no versionadas), pero en las versionadas pueden tener una escala diferente: la aparición de una nueva versión de un objeto (especialmente en retrospectiva) lleva no solo a actualizar todas las tablas relacionadas, sino a una aparición en cascada de nuevas versiones de objetos relacionados, cuando la Tabla 1 se usa para construir la Tabla 2, y la Tabla 2 se usa para construir la Tabla 3, y así sucesivamente. Incluso si ni un solo atributo de la Tabla 1 está involucrado en la construcción de la Tabla 3 (y otros atributos de la Tabla 2 obtenidos de otras fuentes están involucrados), el control de versiones de esta construcción al menos conducirá a una sobrecarga adicional y, como máximo, a una carga adicional. versiones en la Tabla 3, que generalmente es "nada que ver con eso" y más abajo en la cadena.
3. Complejidad no lineal de refinamiento
Al mismo tiempo, cada nuevo escaparate que se construye encima de otro aumenta la cantidad de lugares donde los datos pueden "divergir" cuando se realizan cambios en el ETL. Esto, a su vez, conduce a un aumento en la complejidad (y duración) de cada revisión posterior.
Si lo anterior se aplica a sistemas con procesos ETL raramente modificados, puede vivir en ese paradigma; solo asegúrese de que las nuevas mejoras se realicen correctamente en todos los objetos relacionados. Si las revisiones ocurren con frecuencia, la probabilidad de "perder" accidentalmente varios enlaces aumenta significativamente.
Si, además, tenemos en cuenta que el ETL “versionado” es mucho más complicado que el “no versionado”, se vuelve bastante difícil evitar errores durante el frecuente refinamiento de toda esta economía.
Almacenamiento de objetos y atributos en Data Vault y Anchor Model
El enfoque propuesto por los autores de arquitecturas flexibles se puede formular de la siguiente manera:
Es necesario separar lo que cambia de lo que permanece invariable. Eso es almacenar claves por separado de los atributos.
Sin embargo, no confundas no versionado atributo con sin alterar: el primero no almacena el historial de su cambio, pero puede cambiar (por ejemplo, al corregir un error de entrada o recibir nuevos datos), el segundo nunca cambia.
Los puntos de vista sobre qué se puede considerar exactamente sin cambios en el Data Vault y el modelo Anchor difieren.
En términos de arquitectura Bóveda de datos, se puede considerar sin cambios todo el juego de llaves — natural (TIN de la organización, código de producto en el sistema fuente, etc.) y sustituto. A su vez, el resto de atributos se pueden dividir en grupos según la fuente y/o frecuencia de cambios y mantener una mesa separada para cada grupo con un conjunto independiente de versiones.
En el mismo paradigma Modelo de ancla considerado sin cambios solo clave sustituta entidades. Todo lo demás (incluidas las claves naturales) es solo un caso especial de sus atributos. Donde todos los atributos son independientes entre sí por defecto, por lo que para cada atributo se debe crear mesa separada.
В Bóveda de datos las tablas que contienen claves de entidad se llaman Hubami (Centro). Los concentradores siempre contienen un conjunto fijo de campos:
- Claves de entidades naturales
- Clave sustituta
- Enlace a la fuente
- Tiempo de grabación
Entradas en concentradores nunca cambiar y no tener versiones. Aparentemente, los concentradores son muy similares a las tablas de mapas de ID que se usan en algunos sistemas para generar sustitutos; sin embargo, se recomienda no usar una secuencia de enteros, sino un hash de un conjunto de claves comerciales como sustitutos en Data Vault. Este enfoque simplifica la carga de enlaces y atributos de las fuentes (no es necesario unirse al concentrador para obtener un sustituto, solo calcule el hash de la clave natural), pero puede causar otros problemas (por ejemplo, con colisiones, mayúsculas y minúsculas). imprimir caracteres en claves de cadena, etc. .p.), por lo que generalmente no se acepta.
Todos los demás atributos de entidad se almacenan en tablas especiales llamadas Satélites (Satélite). Un concentrador puede tener varios satélites que almacenan diferentes conjuntos de atributos.
La distribución de atributos entre los satélites se produce según el principio cambio conjunto - en un satélite, se pueden almacenar atributos no versionados (por ejemplo, fecha de nacimiento y SNILS para un individuo), en el otro - raramente cambiando versionado (por ejemplo, apellido y número de pasaporte), en el tercero - cambiando con frecuencia (por ejemplo, dirección de entrega, categoría, fecha del último pedido, etc.). El versionado en este caso se realiza a nivel de satélites individuales y no de la entidad como un todo, por lo que es recomendable distribuir los atributos de tal manera que la intersección de versiones dentro de un satélite sea mínima (lo que reduce el número total de versiones almacenadas).
Además, para optimizar el proceso de carga de datos, los atributos obtenidos de varias fuentes a menudo se colocan en satélites separados.
Los satélites se comunican con el Hub por clave externa (que corresponde a la cardinalidad de 1 a muchos). Esto significa que esta arquitectura "predeterminada" admite varios valores de atributo (por ejemplo, varios números de teléfono de contacto para el mismo cliente).
В Modelo de ancla las tablas que almacenan claves se llaman anclas. Y mantienen:
- Solo llaves sustitutas
- Enlace a la fuente
- Tiempo de grabación
Se consideran claves naturales desde el punto de vista del Anchor Model atributos ordinarios. Esta opción puede parecer más difícil de entender, pero da mucho más alcance para identificar un objeto.
Por ejemplo, si los datos sobre la misma entidad pueden provenir de diferentes sistemas, cada uno de los cuales usa su propia clave natural. En la Bóveda de datos, esto puede conducir a construcciones bastante engorrosas de varios concentradores (uno por fuente + versión maestra fusionada), mientras que en el modelo Anchor, la clave natural de cada fuente cae en su propio atributo y se puede usar cuando se carga independientemente de todos los otros.
Pero aquí yace un momento insidioso: si los atributos de diferentes sistemas se combinan en una sola entidad, lo más probable es que haya algunos reglas de pegamento, por lo que el sistema debe entender que los registros de diferentes fuentes corresponden a una instancia de la entidad.
В Bóveda de datos es probable que estas reglas determinen la formación “hub sustituto” de la entidad maestra y en ningún caso afectará a los Hubs que almacenan las claves naturales de las fuentes y sus atributos originales. Si en algún momento las reglas para la fusión cambian (o los atributos que se utilizan para la fusión se actualizan), será suficiente para volver a formar los centros sustitutos.
В modelo de ancla tal entidad es probable que se almacene en ancla única. Esto significa que todos los atributos, sin importar de qué fuente se obtengan, estarán vinculados al mismo sustituto. La separación de registros combinados erróneamente y, en general, el seguimiento de la relevancia de la combinación en dicho sistema puede ser mucho más difícil, especialmente si las reglas son bastante complejas y cambian con frecuencia, y el mismo atributo se puede obtener de diferentes fuentes (aunque definitivamente es posible, porque cada versión del atributo conserva una referencia a su origen).
En cualquier caso, si se supone que su sistema debe implementar la funcionalidad deduplicación, combinación de registros y otros elementos de MDM, debe leer con especial atención los aspectos del almacenamiento de claves naturales en metodologías flexibles. Tal vez el diseño más difícil de manejar de la Bóveda de datos sea repentinamente más seguro en términos de errores de fusión.
modelo de ancla también proporciona un tipo de objeto adicional llamado Nudo de hecho es un especial tipo degenerado de ancla, que solo puede contener un atributo. Se supone que los nodos se utilizan para almacenar directorios planos (por ejemplo, género, estado civil, categoría de servicio al cliente, etc.). A diferencia del ancla, el nudo no tiene tablas de atributos asociadas, y su único atributo (nombre) siempre se almacena en la misma tabla con la clave. Los nodos se conectan a las tablas Anchors by Tie de la misma manera que los anclajes se conectan entre sí.
No existe una opinión inequívoca sobre el uso de Nodes. Por ejemplo, , que promueve activamente el uso del Modelo Ancla en Rusia, cree (con razón) que es imposible decir de un solo libro de referencia que él siempre será estático y de un solo nivel, por lo que es mejor usar un ancla completa para todos los objetos a la vez.
Otra diferencia importante entre Data Vault y Anchor Model es la presencia atributos para enlaces:
В Bóveda de datos Los enlaces son los mismos objetos completos que los concentradores y pueden tener atributos propios. En modelo de ancla Los enlaces solo se utilizan para conectar anclas y no puede tener sus propios atributos. Esta diferencia conduce a enfoques de modelado significativamente diferentes. de hechos, de la que se hablará a continuación.
Almacenamiento de datos
Hasta ahora, hemos hablado principalmente de medidas de modelado. Los hechos son un poco menos claros.
В Bóveda de datos un objeto típico para almacenar hechos − Enlace, en cuyos satélites se añaden indicadores reales.
Este enfoque parece ser intuitivo. Proporciona un fácil acceso a los indicadores analizados y, en general, es similar a una tabla de hechos tradicional (solo que los indicadores no se almacenan en la tabla en sí, sino en la "tabla adyacente"). Pero también hay escollos: uno de los refinamientos típicos del modelo, la expansión de la clave de hechos, hace que sea necesario agregando una nueva clave externa al enlace. Y esto, a su vez, “rompe” la modularidad y potencialmente provoca la necesidad de mejoras en otros objetos.
В modelo de ancla Un enlace no puede tener sus propios atributos, por lo que este enfoque no funcionará: absolutamente todos los atributos e indicadores deben estar vinculados a un ancla específica. La conclusión de esto es simple: cada hecho también necesita su propio ancla. Para algunos de los que estamos acostumbrados a percibir como hechos, esto puede parecer natural; por ejemplo, el hecho de una compra se reduce perfectamente al objeto "pedido" o "recibo", la visita a un sitio se reduce a una sesión, etc. Pero también hay hechos para los que no es tan fácil encontrar un "objeto portador" tan natural, por ejemplo, el saldo de mercancías en los almacenes al comienzo de cada día.
En consecuencia, no hay problemas con la modularidad cuando se expande la clave de hechos en el Modelo de Ancla (basta con agregar una nueva Relación al Ancla correspondiente), pero diseñar el modelo para mostrar hechos es menos sencillo, pueden aparecer Anclas "artificiales". que reflejan el modelo de objetos del negocio no es obvio.
Cómo se logra la flexibilidad
La construcción resultante en ambos casos contiene significativamente más mesasque la medición tradicional. pero puede tomar significativamente menos espacio en disco con el mismo conjunto de atributos versionados que la dimensión tradicional. Naturalmente, no hay magia aquí, se trata de normalización. Al distribuir atributos entre satélites (en la bóveda de datos) o tablas individuales (modelo de anclaje), reducimos (o eliminamos por completo) duplicar los valores de algunos atributos al cambiar otros.
para Bóveda de datos la ganancia dependerá de la distribución de atributos entre los Satélites, y por modelo de ancla — es casi directamente proporcional al número promedio de versiones por objeto de medición.
Sin embargo, ocupar espacio es una ventaja importante, pero no la principal, de almacenar atributos por separado. Junto con el almacenamiento separado de enlaces, este enfoque hace que el almacenamiento diseño modular. Esto significa que agregar atributos individuales y áreas temáticas completamente nuevas en dicho modelo parece superestructura sobre un conjunto existente de objetos sin cambiarlos. Y esto es exactamente lo que hace que las metodologías descritas sean flexibles.
También se asemeja a la transición de la producción por piezas a la producción en masa: si en el enfoque tradicional cada mesa modelo es única y requiere atención por separado, en las metodologías flexibles ya es un conjunto de "detalles" típicos. Por un lado, hay más tablas, los procesos de carga y obtención de datos deberían parecer más complicados. Por otra parte, se convierten típico. Esto significa que puede haber automatizado y gestionado por metadatos. La pregunta “¿cómo lo vamos a poner?”, cuya respuesta podría ocupar una parte importante del trabajo en el diseño de mejoras, ahora simplemente no vale la pena (al igual que la pregunta sobre el impacto del cambio de modelo en procesos de trabajo).
Esto no significa que los analistas en un sistema de este tipo no sean necesarios en absoluto: alguien todavía tiene que trabajar en un conjunto de objetos con atributos y averiguar dónde y cómo cargarlo todo. Pero la cantidad de trabajo, así como la probabilidad y el costo de un error, se reducen significativamente. Tanto en la etapa de análisis como durante el desarrollo de ETL, que en una parte importante puede reducirse a la edición de metadatos.
Lado oscuro
Todo lo anterior hace que ambos enfoques sean realmente flexibles, fabricables y adecuados para el refinamiento iterativo. Por supuesto, también hay un “barril de alquitrán”, que creo que ya conoces.
La descomposición de datos que subyace a la modularidad de las arquitecturas flexibles conduce a un aumento en el número de tablas y, en consecuencia, gastos generales para uniones al buscar. Para obtener simplemente todos los atributos de una dimensión, una sola selección es suficiente en el almacenamiento clásico, y una arquitectura flexible requerirá varias uniones. Además, si para los informes todas estas uniones se pueden escribir por adelantado, los analistas que están acostumbrados a escribir SQL a mano sufrirán doblemente.
Hay varios hechos que facilitan esta situación:
Cuando se trabaja con grandes dimensiones, casi todos sus atributos casi nunca se usan simultáneamente. Esto significa que puede haber menos uniones de lo que parece a primera vista en el modelo. En Data Vault, también puede tener en cuenta la frecuencia esperada de uso compartido al asignar atributos a los satélites. Al mismo tiempo, los Hubs o Anchors se necesitan principalmente para generar y mapear sustitutos en la etapa de carga y rara vez se usan en consultas (esto es especialmente cierto para Anchors).
Todas las uniones son por clave. Además, una forma más "comprimida" de almacenar datos reduce la sobrecarga del análisis de tablas donde se necesita (por ejemplo, al filtrar por un valor de atributo). Esto puede conducir al hecho de que obtener de una base de datos normalizada con un montón de uniones será incluso más rápido que escanear una dimensión pesada con muchas versiones por fila.
Por ejemplo, aquí en artículo hay una prueba de rendimiento comparativa detallada del modelo Anchor con una selección de una tabla.
Mucho depende del motor. Muchas plataformas modernas tienen mecanismos internos para optimizar las uniones. Por ejemplo, MS SQL y Oracle pueden "omitir" uniones a tablas si sus datos no se usan en ninguna parte excepto para otras uniones y no afectan la selección final (eliminación de tablas/uniones), mientras que MPP Vertica , demostró ser un motor excelente para el modelo de anclaje, con alguna optimización manual del plan de consulta. Por otro lado, almacenar el Anchor Model, por ejemplo, en Click House, que tiene un soporte limitado para unirse, no parece una buena idea todavía.
Además, para ambas arquitecturas existen trucos especiales, que facilitan el acceso a los datos (tanto en términos de rendimiento de consultas como para los usuarios finales). Por ejemplo, Tablas de momentos puntuales en Bóveda de datos o funciones especiales de tabla en el modelo de anclaje.
En total
La esencia principal de las arquitecturas flexibles consideradas es la modularidad de su "diseño".
Esta propiedad permite:
- Después de una preparación inicial relacionada con la implementación de metadatos y la escritura de algoritmos ETL básicos, proporcionar rápidamente al cliente el primer resultado en forma de un par de informes que contienen datos de unos pocos objetos de origen. No es necesario pensar completamente (incluso en el nivel superior) todo el modelo de objetos para esto.
- Un modelo de datos puede comenzar a funcionar (y ser útil) con solo 2 o 3 objetos, y luego crecer gradualmente (sobre el modelo Anchor Nikolay hermosa comparación con el micelio).
- La mayoría de las mejoras, incluida la ampliación del área temática y la adición de nuevas fuentes no afecta la funcionalidad existente y no causa el peligro de romper algo que ya está funcionando.
- Gracias a la descomposición en elementos estándar, los procesos ETL en dichos sistemas tienen el mismo aspecto, su escritura se presta a la algoritmización y, en última instancia, a automatización.
El precio de esta flexibilidad es производительность. Esto no significa que sea imposible lograr un rendimiento aceptable en dichos modelos. La mayoría de las veces, es posible que necesite más esfuerzo y atención a los detalles para lograr las métricas deseadas.
Aplicaciones
Tipos de entidad Bóveda de datos
Más sobre la bóveda de datos:
Tipos de entidad Modelo de ancla
Más sobre el modelo de ancla:
Cuadro resumen con características comunes y diferencias entre los enfoques considerados:
Fuente: habr.com