Tipado en bronze: ¿todo como string?

Puntos clave

Publica los tipos definitivos en bronze (o en la primera vista limpia estable).
Prohíbe el CAST ritual sobre columnas físicas sin cambios en silver y gold.
Permite los casts de alineación de UNION solo cuando están junto al UNION.
Gold es responsable de los literales tipados de las filas unknown que coinciden con los tipos de las relaciones.
Revisa con lint el ruido de CAST en la CI; solo hay excepciones con una razón escrita.
Rematerializa los objetos dependientes cuando cambia el contrato de tipos.

Volver a hacer CAST de la misma columna física en cada capa medallion parece prudente. Normalmente es así como se multiplica la deriva. Bronze convierte a decimal. Silver vuelve a convertir "por si acaso". Gold convierte una tercera vez e inventa un literal unknown con otro tipo distinto. Los consumidores heredan un juego de adivinanzas.

Tipa cada columna publicada una sola vez, tan pronto como te atrevas (normalmente en bronze, a veces en la primera vista limpia estable). Silver y gold se quedan solo con alias, cálculos de negocio y literales tipados para las filas unknown. Los casts de alineación de UNION son la excepción, no el estilo de vida. El resto, pásalo por el lint.

Modelo con nombre: tipar una vez y pronto

Publicar en bronze: tipos definitivos en la primera frontera de publicación estable, una vez entendido el contrato del origen.
Calcular en silver: granularidad, alias y reglas de negocio sobre los tipos heredados. Nada de volver a hacer CAST ritual del mismo campo físico.
Dar forma en gold: hechos, dimensiones y miembros unknown tipados que coinciden con los tipos de las relaciones.
Excepciones: los casts de alineación de UNION siguen siendo explícitos y locales; las columnas derivadas pueden hacer CAST; rematerializa cuando cambia el contrato.
Contrato: las capas posteriores consumen los tipos. No los renegocian.

Modelo con nombre: bronze publica los tipos una vez; silver calcula; gold da forma a los hechos y a los unknown tipados

Figura 1. Tipa cada columna una sola vez, tan pronto como te atrevas. Las capas posteriores heredan el contrato. No reinventan el CAST para la misma columna física.

Contexto y restricción

Un patrón habitual es un SQL de silver que dedica más líneas a redeclarar tipos que a expresar reglas de negocio. El lakehouse parecía disciplinado. Aun así, los tipos no coincidían con el modelo semántico porque gold tenía su propio folclore de CAST. Tener que rematerializar medio linaje después de un cambio de tipo dejó el coste a la vista.

El CAST ritual en silver y gold crea verdades paralelas: float aquí, decimal allá, fechas como cadenas en un tercer notebook. Los miembros unknown necesitan literales tipados explícitos en gold, no nulos accidentales que rompen relaciones. Cuando cambia el contrato, rematerializa a propósito el linaje dependiente. Con un refresco a medias, los tipos de ayer persiguen a las medidas de mañana.

La figura 2 es la superficie de Learn donde aparecen la asignación y el tipado en un pipeline. El producto te deja hacer cast. La plataforma sigue necesitando una regla sobre dónde vive el contrato.

Configurar la asignación en un pipeline de copia de datos

Figura 2. Las decisiones de asignación y de tipos aparecen pronto en la ruta de ingesta. Pon el contrato duradero en la primera frontera de publicación estable, no en cada SELECT posterior. Fuente: Microsoft Learn: actividad de copia de datos.

Diseño

1. Elige la primera frontera de tipado estable

Prefiere bronze (o la vista limpia ligera sobre shortcuts de confianza) una vez entendido el contrato del origen. Tipar en la zona de aterrizaje en bruto antes de que el origen se estabilice solo congela la inestabilidad. Tipar solo en gold empuja la ambigüedad a través de todos los consumidores anteriores. Elige la capa en la que la columna se publica para reutilizarse y declara los tipos ahí. La figura 1 muestra esa frontera como tres tareas.

2. Prohíbe el CAST ritual en silver y gold

Silver transforma la granularidad y aplica reglas de negocio. Gold da forma a hechos y dimensiones para su consumo. Ninguna de las dos debería repetir CAST(x AS DECIMAL(18,2)) porque alguien estaba nervioso. Los nervios van en pruebas contra el contrato de bronze. Si silver tiene que hacer CAST, debe ser porque crea una columna derivada nueva, no porque desconfíe de bronze. La figura 3 compara el fallo de la manta de seguridad con el camino preferido.

Antipatrón de CAST en cada capa frente a tipar una vez en bronze y que silver y gold hereden

Figura 3. El CAST ritual multiplica la deriva. Tipa una vez en bronze. Calcula después. Deja los casts de alineación de UNION junto al UNION y pasa el resto por el lint.

3. Permite los casts de alineación de UNION como excepciones con nombre

Las ramas de UNION y UNION ALL necesitan tipos alineados. Esos casts son ingeniería real. Nómbralos en comentarios o helpers, mantenlos junto al UNION y no los copies en cada lista de select "por coherencia". La coherencia sin UNION es ruido.

4. Gold es responsable de las filas unknown tipadas, no de renegociar tipos

Los miembros unknown y not applicable necesitan claves y literales que coincidan con los tipos de las relaciones. Eso es trabajo de gold. Inventar un string 'unknown' junto a una clave int64 es como aparecen después los visuales vacíos. Mantén el tipado de las filas unknown en el mismo contrato que la granularidad del hecho. La figura 4 compara el unknown seguro para las relaciones con la rotura silenciosa.

Un string UNK junto a una clave BIGINT rompe las relaciones; una clave unknown tipada en la dimensión mantiene honesto el modelo

Figura 4. En los miembros unknown se nota la disciplina de tipado. Haz que coincidan los tipos de clave. Documenta la convención junto a la granularidad. Rematerializa cuando cambie el contrato.

5. Pasa el lint al ruido de CAST

SQLFluff o reglas equivalentes deberían fallar con patrones de CAST ruidosos en silver y gold, salvo en los archivos de la allowlist (helpers de UNION). El lint gana al folclore de la revisión de código. Si el equipo puede explicar por qué hace falta un CAST, ponlo en la allowlist con su motivo. Si no puede, bórralo.

6. Rematerializa después de cambiar el contrato de tipos

Cambiar tipos en bronze sin reconstruir los dependientes deja generaciones mezcladas en el lake. Planifica la rematerialización como parte del cambio de tipo, no como un incidente sorpresa. Documenta qué MLV y tablas tienen que reconstruirse y en qué orden. La figura 4 incluye esa cláusula a propósito: un refresco a medias es un bug de tipos con retraso.

Cómo introducir la prohibición sin una guerra santa

Empieza con un informe de densidad de CAST por capa. Elige los objetos de gold más ruidosos y borra los casts redundantes mientras demuestras que los resultados no cambian. Añade el lint en modo aviso y después en modo error para los cambios nuevos. No reescribas todos los modelos en un solo PR. El objetivo es un trinquete: el CAST ritual nuevo deja de entrar y el antiguo muere durante los cambios normales. Acompaña el trinquete de un ADR breve para que los revisores puedan citar algo más que el gusto.

En los miembros unknown se nota la disciplina de tipado

Los equipos que prohíben el CAST ritual siguen tropezando con las filas unknown: un hecho hace un left outer join con una dimensión, alguien rellena con coalesce una clave que falta con el string "UNK" y la relación muere. Decide los tipos de las claves unknown con la misma seriedad que los tipos numéricos. Pon el miembro unknown en la dimensión con una clave tipada. Referencia esa clave desde los hechos. Documenta la regla junto a la definición de la granularidad para que un notebook futuro no invente una segunda convención de unknown para la misma entidad.

Errores comunes

El CAST como manta de seguridad. Cada capa "arregla" los tipos; ninguna es responsable de ellos. La figura 3 muestra ese fallo.

Claves como cadenas en una capa. Las relaciones y los joins pasan a funcionar por temporadas.

Literales unknown con tipos accidentales. Los modelos semánticos fallan en silencio. La figura 4 muestra la rotura y la solución.

Refresco a medias tras cambiar tipos. En la práctica, los archivos parquet antiguos conservan los tipos antiguos.

Lint opcional. Los revisores se cansan; el ritual del CAST vuelve.

Tipar sobre datos en bruto inestables. Conviertes el caos del volcado del origen en verdad de la plataforma.

Úsalo tal cual o adáptalo

Úsalo tal cual

Las columnas publicadas reciben sus tipos definitivos en bronze (o en la primera capa estable documentada).
El CAST ritual sobre columnas físicas sin cambios en silver/gold está prohibido.
Los casts de alineación de UNION están permitidos y son locales.
Los literales de las filas unknown de gold tienen que coincidir con los tipos de las relaciones.
El lint de la CI falla con el ruido de CAST fuera de las allowlists.
Los cambios en el contrato de tipos incluyen un plan explícito de rematerialización.

Adáptalo antes de usarlo

Tipar pronto te ata antes a entender el origen. Tipar tarde ata a cada consumidor a la ambigüedad durante más tiempo. Los falsos positivos del lint necesitan un proceso de allowlist o la gente se salta la CI. Rematerializar cuesta capacidad; saltárselo cuesta incidentes. Las columnas derivadas seguirán haciendo CAST. La regla trata del retipado ritual del mismo campo físico, no de prohibir SQL.

Referencias principales: la documentación de tipos de datos de Spark SQL y la guía medallion del lakehouse de Fabric en Microsoft Learn. Acompáñalas de un conjunto de reglas de lint en el repo para que el contrato se pueda hacer cumplir.

Cierre

Si cada capa vuelve a tipar la misma columna, no tienes un sistema de tipos. Tienes una costumbre.

Tipa una vez y pronto. Calcula después. Elimina el ritual con el lint. Rematerializa cuando cambie el contrato. La plataforma se vuelve más tranquila, y los visuales vacíos también.

Relacionado

Puertas de CI: ¿qué bloqueas de verdad en los pipelines de Azure DevSecOps? (hacer que las reglas de lint hagan fallar el build en la CI)