Implementación de un almacén de datos dimensional con Databricks SQL: Parte 2

A medida que las organizaciones consolidan las cargas de trabajo de análisis en Databricks, a menudo necesitan adaptar las técnicas tradicionales de almacenamiento de datos. Esta serie explora cómo implementar el modelado dimensional, específicamente esquemas en estrella, en Databricks. El primer blog se centró en el diseño del esquema. Este blog detalla los pipelines de ETL para tablas de dimensiones, incluidos los patrones de Dimensiones de Cambio Lento (SCD) Tipo-1 y Tipo-2. La Parte 3 le muestra cómo crear pipelines de ETL para tablas de hechos.

Dimensiones de Cambio Lento (SCD)

En el blog anterior, definimos nuestro esquema en estrella, incluyendo una tabla de hechos y sus dimensiones relacionadas. Destacamos una tabla de dimensiones en particular, DimCustomer, como se muestra aquí (con algunos atributos eliminados para ahorrar espacio):

Los últimos tres campos de esta tabla, es decir, StartDate, EndDate y IsLateArriving, representan metadatos que nos ayudan con la versión de los registros. A medida que cambian los ingresos, el estado civil, la propiedad de la vivienda, el número de hijos en casa u otras características de un cliente determinado, querremos crear nuevos registros para ese cliente para que los hechos, como nuestras transacciones de ventas en línea en FactInternetSales, se asocien con la representación correcta de ese cliente. La clave natural (también conocida como clave de negocio), CustomerAlternateKey, será la misma en todos estos registros, pero los metadatos diferirán, lo que nos permitirá saber el período para el cual esa versión del cliente fue válida, al igual que la clave sustituta, CustomerKey, lo que permitirá que nuestros hechos se vinculen a la versión correcta.

NOTA: Debido a que la clave sustituta se usa comúnmente para vincular hechos y dimensiones, las tablas de dimensiones a menudo se agrupan según esta clave. A diferencia de las bases de datos relacionales tradicionales que utilizan índices b-tree en registros ordenados, Databricks implementa un método de agrupación único conocido como agrupación líquida. Si bien los detalles de la agrupación líquida están fuera del alcance de este blog, utilizamos consistentemente la cláusula CLUSTER BY en la clave sustituta de nuestras tablas de dimensiones durante su definición para aprovechar esta característica de manera efectiva.

Este patrón de versión de registros de dimensiones a medida que cambian los atributos se conoce como el patrón de Dimensión de Cambio Lento Tipo-2 (o simplemente SCD Tipo-2). El patrón SCD Tipo-2 se prefiere para registrar datos de dimensiones en la metodología dimensional clásica. Sin embargo, hay otras formas de tratar los cambios en los registros de dimensiones.

Una de las formas más comunes de tratar los valores cambiantes de las dimensiones es actualizar los registros existentes en su lugar. Solo se crea una versión del registro, de modo que la clave de negocio siga siendo el identificador único del registro. Por varias razones, entre ellas el rendimiento y la consistencia, todavía implementamos una clave sustituta y vinculamos nuestros registros de hechos a estas dimensiones en esas claves. Sin embargo, los campos de metadatos StartDate y EndDate que describen los intervalos de tiempo durante los cuales se considera activo un registro de dimensión determinado no son necesarios. Esto se conoce como el patrón SCD Tipo-1. La dimensión Promotion en nuestro esquema en estrella proporciona un buen ejemplo de una implementación de tabla de dimensión Tipo-1:

Pero, ¿qué pasa con el campo de metadatos IsLateArriving visto en la dimensión de Cliente Tipo-2 pero ausente en la dimensión de Promoción Tipo-1? Este campo se utiliza para marcar los registros como de llegada tardía. Un registro de llegada tardía es aquel para el cual la clave de negocio aparece durante un ciclo de ETL de hechos, pero no se encuentra ningún registro para esa clave durante el procesamiento previo de la dimensión. En el caso de los SCD Tipo-2, este campo se utiliza para indicar que cuando se observan por primera vez los datos de un registro de llegada tardía en un ciclo de ETL de dimensión, el registro debe actualizarse en su lugar (al igual que en un patrón SCD Tipo-1) y luego versionarse a partir de ese momento. En el caso de los SCD Tipo-1, este campo no es necesario porque el registro se actualizará en su lugar independientemente.

NOTA: The Kimball Group reconoce patrones SCD adicionales, la mayoría de los cuales son variaciones y combinaciones de los patrones Tipo-1 y Tipo-2. Dado que los SCD de Tipo-1 y Tipo-2 son los más implementados de estos patrones y las técnicas utilizadas con los otros están estrechamente relacionadas con lo que se emplea con estos, limitamos este blog solo a estos dos tipos de dimensiones. Para obtener más información sobre los ocho tipos de SCD reconocidos por el Kimball Group, consulte la sección Técnicas de Dimensión de Cambio Lento de este documento.

Implementación del Patrón SCD Tipo-1

Con los datos actualizados en su lugar, el patrón de flujo de trabajo SCD Tipo-1 es el más sencillo de los patrones ETL bidimensionales. Para admitir estos tipos de dimensiones, simplemente:

1. Extraer los datos requeridos de nuestros sistemas operativos
2. Realizar las operaciones de limpieza de datos requeridas
3. Comparar nuestros registros entrantes con los que ya están en la tabla de dimensiones
4. Actualizar los registros existentes donde los atributos entrantes difieren de lo que ya está registrado
5. Insertar los registros entrantes que no tienen un registro correspondiente en la tabla de dimensiones

Para ilustrar una implementación SCD Tipo-1, definiremos el ETL para la población continua de la tabla DimPromotion.

Paso 1: Extraer datos de un sistema operativo

Nuestro primer paso es extraer los datos de nuestro sistema operativo. Como nuestro data warehouse sigue el patrón de la base de datos de ejemplo AdventureWorksDW proporcionada por Microsoft, estamos utilizando la base de datos de ejemplo estrechamente asociada AdventureWorks (OLTP) como nuestra fuente. Esta base de datos se ha implementado en una instancia de Azure SQL Database y se ha hecho accesible dentro de nuestro entorno Databricks a través de una consulta federada. La extracción se facilita luego con una consulta simple (con algunos campos redactados para ahorrar espacio), con los resultados de la consulta persistidos en una tabla en nuestro esquema staging (que solo es accesible para los ingenieros de datos en nuestro entorno a través de configuraciones de permisos que no se muestran aquí). Esta es solo una de las muchas formas en que podemos acceder a los datos del sistema de origen en este entorno:

Paso 2: Comparar registros entrantes con los de la tabla

Suponiendo que no tenemos pasos adicionales de limpieza de datos que realizar (que podríamos implementar con una UPDATE o con otra instrucción CREATE TABLE AS), podemos abordar nuestras operaciones de actualización/inserción de datos de dimensión en un solo paso utilizando una instrucción MERGE, haciendo coincidir nuestros datos preparados y los datos de la dimensión con la clave comercial:

Algo importante a tener en cuenta sobre la instrucción, tal como está escrita aquí, es que actualizamos cualquier registro existente cuando se encuentra una coincidencia entre los datos preparados y los datos publicados de la tabla de dimensiones. Podríamos agregar criterios adicionales a la cláusula WHEN MATCHED para limitar las actualizaciones a aquellas instancias en que un registro en staging tiene información diferente de lo que se encuentra en la tabla de dimensiones, pero dado el número relativamente pequeño de registros en esta tabla en particular, hemos optado por emplear la lógica relativamente más delgada que se muestra aquí. (Usaremos la lógica adicional WHEN MATCHED con DimCustomer, que contiene muchos más datos).

El patrón SCD Tipo-2

El patrón SCD Tipo-2 es un poco más complejo. Para admitir estos tipos de dimensiones, debemos:

1. Extraer los datos requeridos de nuestros sistemas operativos
2. Realizar las operaciones de limpieza de datos requeridas
3. Actualizar los registros de miembros que llegan tarde en la tabla de destino
4. Expirar los registros existentes en la tabla de destino para los cuales se encuentran nuevas versiones en staging
5. Insertar registros nuevos (o nuevas versiones) en la tabla de destino

Paso 1: Extraer y limpiar datos de un sistema de origen

Al igual que en el patrón SCD Tipo-1, nuestros primeros pasos son extraer y limpiar datos del sistema de origen. Utilizando el mismo enfoque que el anterior, emitimos una consulta federada y persistimos los datos extraídos en una tabla en nuestro esquema staging:

Paso 2: Comparar con una tabla de dimensiones

Con estos datos cargados, ahora podemos compararlos con nuestra tabla de dimensiones para realizar las modificaciones de datos necesarias.  La primera de ellas es actualizar en el lugar cualquier registro marcado como llegado tarde de procesos ETL anteriores de la tabla de hechos.  Tenga en cuenta que estas actualizaciones se limitan a aquellos registros marcados como llegados tarde y el indicador IsLateArriving se restablece con la actualización para que estos registros se comporten como SCDs de Tipo 2 normales en el futuro:

Paso 3: Expirar registros versionados

El siguiente conjunto de modificaciones de datos es expirar cualquier registro que necesite ser versionado.  Es importante que el valor EndDate que establecemos para estos coincida con la StartDate del nuevo registro que implementaremos en el siguiente paso.  Por esa razón, estableceremos una variable de marca de tiempo para ser utilizada entre estos dos pasos:

NOTA: Dependiendo de los datos disponibles para usted, puede optar por emplear un valor EndDate originario del sistema de origen, momento en el cual no necesariamente declararía una variable como se muestra aquí.

Tenga en cuenta los criterios adicionales utilizados en la cláusula WHEN MATCHED.  Debido a que solo estamos realizando una operación con esta declaración, sería posible mover esta lógica a la cláusula ON, pero la mantuvimos separada de la lógica de coincidencia principal, donde estamos coincidiendo con la versión actual del registro de dimensión para mayor claridad y mantenibilidad.

Como parte de esta lógica, estamos haciendo un uso intensivo de la función equal_null().  Esta función devuelve TRUE cuando los primeros y segundos valores son iguales o ambos NULL; de lo contrario, devuelve FALSE.  Esto proporciona una forma eficiente de buscar cambios columna por columna.  Para obtener más detalles sobre cómo Databricks admite la semántica NULL, consulte este documento.

En esta etapa, cualquier versión anterior de registros en la tabla de dimensiones que haya expirado ha sido marcada con fecha de fin.  

Paso 4: Insertar nuevos registros

Ahora podemos insertar nuevos registros, tanto verdaderamente nuevos como recién versionados:

Como antes, esto podría haberse implementado usando una declaración INSERT, pero el resultado es el mismo.  Con esta declaración, hemos identificado cualquier registro en la tabla de staging que no tiene un registro correspondiente no expirado en las tablas de dimensiones. Estos registros simplemente se insertan con un valor StartDate consistente con cualquier registro expirado que pueda existir en esta tabla.

Próximos pasos: implementación del ETL de la tabla de hechos

Con las dimensiones implementadas y pobladas con datos, ahora podemos centrarnos en las tablas de hechos. En la Parte 3, demostraremos cómo se puede implementar el ETL para estas tablas.

Para obtener más información sobre Databricks SQL, visite nuestro sitio web o lea la documentación. También puede consultar el recorrido por el producto para Databricks SQL. Suponga que desea migrar su almacén de datos existente a un almacén de datos sin servidor de alto rendimiento con una excelente experiencia de usuario y un menor costo total. En ese caso, Databricks SQL es la solución: pruébelo gratis.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original