Capa Silver en Fabric: Guía de Limpieza, Deduplicación y Conformación
En cualquier implementación seria de Microsoft Fabric, la capa Silver representa el punto de inflexión donde los datos dejan de ser ruido para convertirse en información. Mientras que la capa Bronze se limita a persistir el dato en su estado original (el «qué nos ha llegado»), la capa Silver es la encargada de responder al «cómo debe ser el dato». Si fallas aquí, estarás construyendo tus modelos de Power BI sobre arenas movedizas.
Como consultor, me encuentro habitualmente con proyectos que intentan saltar directamente de la ingesta bruta al modelado en estrella. El resultado es siempre el mismo: medidas DAX extremadamente complejas para gestionar nulos, inconsistencias en los nombres de los clientes y un rendimiento pobre debido a la falta de optimización en los archivos Delta subyacentes. La capa Silver no es un lujo; es el control de calidad obligatorio de tu arquitectura.
En este artículo analizamos cómo ejecutar este proceso de conformación utilizando Spark, centrándonos en la validación, la deduplicación y la integración mediante operaciones atómicas de combinación.
El propósito real de la capa Silver: Calidad y Estándar
La capa Silver es un componente crítico de la arquitectura medallón en Fabric. Su objetivo principal es ofrecer una versión «limpia» y enriquecida de los datos de negocio, pero sin llegar todavía a la estructura de dimensiones y hechos que veremos en Gold. Aquí el dato sigue estando, por lo general, orientado a la entidad de origen (ej. Clientes, Ventas), pero con reglas de integridad aplicadas.
Antes de escribir una sola línea de código en un Notebook de Spark, debemos definir qué constituye un «dato de calidad» para el proyecto. Esto suele implicar:
- Tipado de datos estricto: Convertir las cadenas de texto de Bronze en tipos
Date,DecimaloIntegerreales. - Tratamiento de nulos: Decidir si un nulo en un campo de importe debe ser 0 o si la fila debe descartarse por falta de integridad.
- Normalización de cadenas: Eliminar espacios en blanco, estandarizar mayúsculas y corregir codificaciones de caracteres erróneas.
- Enriquecimiento técnico: Añadir columnas de auditoría como
_SourceFile,_LoadTimestampy_IsDeleted.
Estrategias de Deduplicación y Manejo de Versiones
Uno de los mayores retos en la transición a Silver es la gestión de duplicados. En sistemas de retail o industria, es común recibir múltiples versiones de un mismo pedido debido a actualizaciones en el sistema origen o errores en la ingesta incremental.
Para manejar esto en Spark, la técnica más eficiente no es un simple dropDuplicates(), sino el uso de funciones de ventana para quedarnos con la versión más reciente basada en una marca de tiempo de modificación. Esto asegura que si un registro de venta cambió en el origen, nuestra capa Silver refleje el estado más actual.
from pyspark.sql import Window
from pyspark.sql.functions import col, row_number
# Definimos la ventana: particionamos por la clave de negocio y ordenamos por fecha de actualización
windowSpec = Window.partitionBy("ID_Venta").orderBy(col("Fecha_Modificacion").desc())
# Aplicamos el filtro para quedarnos con la fila 1 (la más reciente)
df_silver = df_bronze.withColumn("row_num", row_number().over(windowSpec)) \
.filter(col("row_num") == 1) \
.drop("row_num")
# Validación de negocio: El importe no puede ser negativo en este contexto
df_silver = df_silver.filter(col("Importe") >= 0)Este enfoque permite que la capa Silver sea determinista. Si volvemos a procesar los mismos datos de Bronze, el resultado en Silver debe ser idéntico. Es fundamental mantener esta idempotencia para facilitar la recuperación ante desastres o errores de lógica.
Operaciones MERGE: El motor de la actualización incremental
A diferencia de la capa Bronze, donde solemos realizar operaciones de append (añadir), la capa Silver requiere frecuentemente actualizaciones de registros existentes. Aquí es donde Delta Lake brilla en Microsoft Fabric. En lugar de sobrescribir tablas enteras —lo cual es ineficiente y costoso—, utilizamos la sentencia MERGE.
El MERGE compara los datos entrantes con los existentes basándose en una clave primaria y decide si insertar un nuevo registro o actualizar uno actual. Esto es vital para mantener el rendimiento y evitar el crecimiento descontrolado de metadatos. Sin embargo, recuerda que el uso intensivo de MERGE genera múltiples versiones de archivos. Para mantener el Lakehouse optimizado, es obligatorio programar tareas de limpieza de versiones antiguas con VACUUM.
from delta.tables import DeltaTable
target_table = DeltaTable.forPath(spark, "Tables/Silver_Ventas")
# Realizamos el Upsert (Update + Insert)
target_table.alias("target").merge(
df_silver.alias("source"),
"target.ID_Venta = source.ID_Venta"
).whenMatchedUpdateAll() \
.whenNotMatchedInsertAll() \
.execute()Al aplicar esta lógica, reducimos drásticamente el volumen de datos que los procesos posteriores (capa Gold o Power BI) deben escanear. Además, al usar Delta Lake, nos beneficiamos de los checkpoints de Delta para mejorar la velocidad de lectura en procesos de BI complejos.
Comparativa: Bronze vs. Silver
Para entender los trade-offs de diseño, la siguiente tabla resume las diferencias fundamentales en el tratamiento de los datos dentro de un Lakehouse en Fabric:
| Característica | Capa Bronze (Raw) | Capa Silver (Cleansed) |
|---|---|---|
| Esquema | Flexible (Schema-on-read) | Estricto (Schema-on-write) |
| Formato | Parquet / Delta / JSON / CSV | Delta Lake (Obligatorio) |
| Limpieza | Ninguna (Copia fiel del origen) | Deduplicación y normalización |
| Granularidad | Transaccional original | Transaccional o levemente agregada |
| Acceso | Solo ingenieros de datos | Ingenieros y Analistas avanzados |
Errores comunes en la implementación de Silver
A lo largo de diversos proyectos en sectores como el energético o retail, he identificado patrones de error que degradan la calidad del dato antes de llegar a los informes:
- No validar tipos de fecha: Dejar las fechas como strings en Silver obliga a Power Query a realizar transformaciones pesadas en cada refresco del informe.
- Ignorar la conformación de dimensiones: Si tienes dos sistemas de origen para «Clientes», la capa Silver debe intentar unificarlos bajo un esquema común antes de pasar a Gold.
- Falta de trazabilidad: No incluir la columna de la fuente original. Cuando un dato parece incorrecto en Power BI, lo primero que preguntará el usuario es de dónde viene. Sin trazabilidad en Silver, la depuración es una pesadilla.
- Exceso de lógica de negocio: No intentes calcular márgenes complejos o KPIs de rentabilidad en Silver. Esa lógica pertenece a Gold. Silver debe ser una representación fiel y limpia de los hechos.
Desde el punto de vista del rendimiento, es recomendable evaluar si necesitas un Lakehouse o un Warehouse para estas transformaciones. Si tu equipo domina T-SQL, el Warehouse ofrece capacidades excelentes, pero si buscas escalabilidad masiva y procesamiento de archivos no estructurados, el Lakehouse con Spark es la opción ganadora. Puedes profundizar en esta elección en nuestra guía de selección entre Lakehouse y Data Warehouse.
Garantizando la integridad para el futuro
La capa Silver no solo alimenta a Power BI. En el ecosistema actual, estos datos limpios son la base para modelos de Machine Learning y asistentes de IA. Un dato mal curado en Silver resultará en alucinaciones o predicciones sesgadas. Por ello, es fundamental integrar el gobierno de datos y la trazabilidad desde las primeras fases de la transformación.
Asegúrate de que cada Notebook de Spark que procese la capa Silver incluya logs detallados sobre cuántas filas se leyeron de Bronze, cuántas fueron descartadas por errores de validación y cuántas se insertaron/actualizaron finalmente.
Checklist de validación para tu capa Silver
- ¿Se han eliminado todos los registros duplicados utilizando una lógica de marca de tiempo?
- ¿Todos los campos numéricos y de fecha tienen el tipo de dato correcto en el esquema Delta?
- ¿Se han aplicado reglas de normalización (trim, upper/lower case) en campos clave de búsqueda?
- ¿Existe una columna de auditoría que identifique cuándo se cargó o modificó cada fila?
- ¿Se ha ejecutado un proceso de OPTIMIZE y VACUUM tras las cargas masivas iniciales?
Preguntas frecuentes
¿Es obligatorio usar Spark para la capa Silver?
No es obligatorio, pero sí muy recomendable por su escalabilidad y soporte nativo para operaciones MERGE complejas. En Microsoft Fabric también puedes usar Dataflows Gen2, aunque para volúmenes de datos medios-altos, los Notebooks de Spark ofrecen un control mucho más granular y un mejor rendimiento de costes.
¿Debo normalizar las tablas en Silver (3FN)?
No necesariamente. La capa Silver suele mantener una estructura similar al origen pero limpia. El objetivo no es crear un modelo relacional perfecto, sino un repositorio de datos de alta calidad. La desnormalización o el esquema en estrella se reserva habitualmente para la capa Gold.
¿Cómo gestiono los errores de validación en Silver?
La mejor práctica es implementar una «tabla de cuarentena». Los registros que no cumplen las reglas de calidad (ej. un importe de venta nulo) se desvían a esta tabla en lugar de bloquear el proceso. Esto permite que el resto de los datos sigan fluyendo mientras alguien del equipo de negocio revisa la cuarentena.
¿Cuándo debería usar SCD Tipo 2 en Silver?
Normalmente, la capa Silver es un reflejo de la situación actual (SCD Tipo 1). Si necesitas mantener el historial de cambios de un atributo (como el cambio de dirección de un cliente), esa lógica suele implementarse en la capa Gold al construir las dimensiones, aunque puedes preparar los datos en Silver identificando las versiones temporales.
