El automatizado, Sin código Pila de datos
Aprende cómo Astera Data Stack puede simplificar y agilizar la gestión de datos de su empresa.
Cargar datos en hechos y dimensiones: ¿pan comido?
KimballEl modelado dimensional de estilo ha sido la arquitectura de referencia para la mayoría de los desarrolladores de almacenes de datos durante las últimas dos décadas. La naturaleza desnormalizada de estos esquemas, junto con la optimización para el mantenimiento del historial, hace que el modelo dimensional sea una herramienta ideal para el arsenal de almacenamiento de datos, especialmente para generar informes a través de inteligencia empresarial (BI) herramientas.
A primera vista, la idea es simple: las tablas de hechos contienen información transaccional y las dimensiones brindan contexto a estos hechos a través de relaciones de clave externa. Las preguntas que surgen, sin embargo, son las siguientes: ¿Qué tan fácil es cargar y mantener datos en tablas de hechos y dimensiones? ¿Y vale la pena el esfuerzo?
Tomemos un escenario en el que ha configurado una arquitectura para su almacenamiento de datos — un esquema de estrella simple que consta de información de ventas en la tabla de hechos, rodeada de algunas dimensiones, como clientes, proveedores, etc. Los datos de origen que inicialmente provienen de sistemas dispares se han cargado en una capa de preparación unificada.
El objetivo es configurar un proceso de carga y mantenimiento para sus tablas de dimensiones y hechos. Cargar datos en tablas de dimensiones puede ser simple, dado que no busca mantener el historial. En tal caso, solo querrá actualizar los registros de destino, lo que se puede realizar a través de Cambiando lentamente las dimensiones Tipo 1 (SCD1). Aquí hay un fragmento de cómo se vería esa consulta:
Sin embargo, es poco probable que esto sea suficiente en un escenario comercial práctico. Es importante mantener al menos algo de historial en un almacén de datos para identificar tendencias y patrones. Ahí es donde entran en juego otros tipos de SCD más complicados, como SCD 2, 3 y 6.
Si tiene la intención de usar SCD 2 o 6 en ciertos campos, la tabla también debe contener identificadores de registro para reconocer la fila activa para cada registro. Esto podría ser un indicador de verdadero/falso, un rango de fechas de vencimiento efectivo o simplemente un número de versión para cada registro, por nombrar algunos ejemplos.
En caso de que desee utilizar SCD 3 o 6, necesitará un campo adicional para almacenar el valor anterior del campo en cuestión.
Así es como se vería una parte de la consulta si usara SCD 2 o 6 para mantener el historial:
¿Está empezando a parecer un poco complicado? Solo hemos tocado la punta del iceberg.
Es probable que requiera diferentes niveles de historial para diferentes campos. Supongamos, por ejemplo, que tiene una dimensión de empleado que contiene información sobre el salario y el número de teléfono de los empleados. Aquí, es posible que desee realizar un seguimiento de cómo cambia el salario de un empleado, pero solo actualice el número de teléfono.
Para casos como este, usaría varios tipos de SCD; SCD 1 para los campos que simplemente requieren actualizaciones y SCD 2, 3 o 6 para aquellos campos que requieren un cierto nivel de historial para mantenerse. ¡Con tantas cosas a tener en cuenta, puede imaginar lo compleja que sería la consulta!
Hasta ahora, nos hemos centrado en la población y el mantenimiento de las tablas de dimensiones. Estas dimensiones proporcionan contexto a la información almacenada en las tablas de hechos. Por lo tanto, cada cambio en una tabla de dimensiones también se propaga a la tabla de hechos; garantizar que esta propagación se realice con precisión puede ser un desafío.
Parte de la información que necesita cargar en la tabla de hechos no está disponible en la fuente. Las claves sustitutas que se utilizan para establecer relaciones entre las tablas de dimensiones y de hechos no existen en la capa de preparación; se crearon como claves generadas por el sistema en cada dimensión.
Por lo tanto, debe diseñar un mecanismo que utilice búsquedas de dimensión para tomar cada clave empresarial (natural) entrante de la capa de ensayo a la dimensión relevante y obtener la clave sustituta activa para ese registro. Además, las complejidades de obtener estas claves sustitutas variarían según el tipo de SCD utilizado para cada campo y el identificador de fila presente en la tabla de dimensiones.
Como si ese proceso no fuera lo suficientemente complejo, aquí hay otra curva para usted: ¿Qué pasa si faltan algunas entradas en la tabla de hechos que no requieren la clave sustituta más actualizada? Podría usar una clave de fecha de transacción para determinar la clave sustituta activa, dado que ha usado un identificador de fila activo específico de marca de tiempo, como el rango de fechas de vencimiento efectivo.
La situación también podría ser al revés: es posible que tenga algunas entradas en la tabla de hechos que se refieran a un registro de dimensión que aún no se ha agregado a la tabla de dimensión. Este es un enigma común del almacenamiento de datos: dimensiones que llegan tarde y hechos que llegan temprano. Para solucionar este problema, puede crear un registro ficticio en la tabla de dimensiones en tiempo de ejecución.
Este registro eventualmente sería reemplazado por el registro de dimensión apropiado (retrasado) proveniente de la fuente. Pero al menos permitiría que la búsqueda de dimensiones se realice en el momento adecuado sin contratiempos innecesarios.
En general, cargar datos en la tabla de hechos puede ser un proceso tedioso y propenso a errores. Si no se abordan los problemas destacados anteriormente. Por ejemplo, sus tuberías podrían fallar o su almacén podría terminar conteniendo datos inexactos.
Aquí hay una consulta de muestra que podría cargar datos en una tabla de hechos:
Digamos que haces todo. Ha escrito con éxito todas las consultas necesarias y son perfectas. Tu trabajo todavía no está del todo completo. Un proceso de almacenamiento de datos nunca está completamente terminado porque el mantenimiento del ecosistema es tan importante como diseñarlo en primer lugar. Para maximizar el rendimiento, debe asegurarse de que los datos se carguen de forma incremental, lo que requiere la implementación del mecanismo de captura de datos modificados (CDC).
Además, estas consultas complejas necesitarían actualizaciones frecuentes, según las necesidades del negocio. Es posible que deba agregar o eliminar campos, cambiar ciertos tipos de datos, modificar el tipo de SCD aplicado a un campo, etc. Hacer estos cambios en las consultas no solo lleva mucho tiempo sino que también es extremadamente propenso a errores. Antes de que te des cuenta, es posible que hayas estropeado una canalización existente al implementar un cambio menor en el mecanismo de carga.
A pesar de estos posibles problemas de mantenimiento, aún sentirá que la mayor parte del trabajo duro está hecho. Sin embargo, las empresas buscan constantemente modernizar y mejorar sus procesos de datos. Puede llegar el día en que su empresa decida cambiar de plataforma de almacenamiento de datos. Supongamos que han decidido pasar de SQL Server local a una plataforma en la nube como Copo de nieve or Desplazamiento al rojo de Amazon.
¿Te das cuenta de lo que eso requeriría? Primero, debe crear una nueva arquitectura en la nueva plataforma. Luego, reescriba todas las consultas para configurar canalizaciones nativas a las nuevas tablas de destino. Básicamente, tendría que realizar todo el proceso nuevamente, ¡desde cero! Entonces, según todo lo que hemos desarrollado, es seguro concluir que cargar datos en tablas de hechos y dimensiones es NO un pedazo de la torta. El nivel de complejidad involucrado puede llegar a ser demasiado alto, incluso para los usuarios técnicos.
Pero, ¿y si te dijera que hay una manera mucho más fácil de lograr el mismo resultado?
Con Astera Generador de almacenamiento de datos, puede construir una arquitectura para su modelo dimensional utilizando el diseñador intuitivo de modelos de datos. Además, la interfaz de hacer clic y señalar le permite asignar funciones, como tipos de SCD, identificadores de filas activas, claves de fecha de transacción, etc., a los campos de hecho y tablas de dimensiones.
Lo que es más importante, puede aprovechar la información dentro de sus modelos en el componente ETL/ELT basado en arrastrar y soltar de la herramienta para automatizar las tareas tediosas y lentas involucradas en la carga de tablas de hechos y dimensiones, que van desde mantener SCD en dimensiones hasta realizar búsquedas de dimensiones en tablas de hechos. El código complicado que vimos anteriormente es generado automáticamente por la herramienta.
¿Por qué perder tanto tiempo y esfuerzo escribiendo consultas enormes cuando puede lograr el mismo resultado utilizando una interfaz visual simple? Aunque cargar datos en hechos y dimensiones normalmente no es pan comido, con Astera Data Warehouse Builder, ¡puede ser!
Si desea explorar la forma ágil de construir su almacén de datos, contáctenos en [email protected] hoy o descargar un prueba gratuita de 14 días..
