DP-700: cómo planificar e implementar schema mapping para ingestión en Fabric

João Barros 06 de November de 2026 6 min de lectura

En esta lección voy a enseñar la competencia de planificar e implementar schema mapping durante la ingestión de datos en Microsoft Fabric. Esta competencia es importante para el examen DP-700 porque garantiza que los datos recibidos son coherentes con los modelos analíticos; en la práctica evita errores de compatibilidad, pérdida de información y facilita pipelines resilientes. Una buena estrategia de schema mapping puede reducir rechazos de ingestión en 60–90% en un entorno con evolución frecuente de esquemas.

Qué necesitas saber

Schema mapping es el proceso de mapear columnas, tipos y estructuras de datos de una fuente de ingestión al esquema de destino usado en tablas del Fabric (por ejemplo en Tables dentro de Lakehouse/Delta o en una Synapse SQL pool). El objetivo es, entre otros, armonizar nombres, convertir tipos, tratar columnas faltantes/excedentes y garantizar que la ingestión soporta evoluciones del esquema sin interrumpir consumidores downstream.

Ejemplo simple: una fuente CSV tiene las columnas (id, name, created_at) donde created_at es texto ISO; el destino requiere (Id INT, Nome STRING, CreatedAt DATETIME). El schema mapping define que id -> Id con conversión a INT, name -> Nome (renombrar), created_at -> CreatedAt con parsing a DATETIME y reglas cuando el campo esté vacío. En escenarios reales ves tablas con 20–200 columnas; aplicar mapeado explícito para las 10–20 columnas críticas suele ser suficiente para proteger informes esenciales mientras se hace evolución gradual del resto.

Cómo funciona en la práctica

En Fabric puedes aplicar schema mapping en varios puntos del pipeline: en el proceso de lectura (Dataflows, Notebooks, Spark), durante la escritura a Delta/OneLake (usando DataFrame schemas o DDL) o en pipelines de Data Factory/Synapse. Las aproximaciones varían según uses Spark/Apache/Delta o componentes low-code como Dataflows. En ingestiones de alta velocidad (p.ej. 10k–100k registros/minuto) prefieres transformaciones en Spark por ser más eficientes; para cargas puntuales y transformación ligera, Dataflows dan visibilidad y control sin código.

Puntos clave prácticos:

Definir el esquema objetivo de forma explícita: evita la inferencia automática. En Spark/PySpark definimos un StructType/DDL; en los Dataflows creamos las columnas con el tipo pretendido. En entornos de producción, mantener un fichero de esquema (JSON/DDL) versionado facilita auditoría y despliegue.
Mapear nombres y tipos: renombrar columnas y transformar tipos (ej.: string -> timestamp). Documenta también columnas opcionales y obligatorias y cuantifica: p.ej. 15 columnas obligatorias, 25 opcionales. Ese inventario ayuda a priorizar validaciones.
Gestionar columnas desconocidas: elegir entre ignorar, almacenar en una columna JSON de anexo, o fallar la ingestión. Una práctica común es almacenar columnas no mapeadas en un campo auxiliar JSON para auditoría — reduce fallos sin perder datos.
Tratar cambios de esquema: aplicar versionado del esquema (p.ej. v1, v2), usar columnas permisivas (nullable) y pipelines idempotentes. Define SLAs: por ejemplo, exigir compatibilidad de lectura durante 2 semanas antes de descontinuar campos antiguos.

# Exemplo PySpark: definir schema e aplicar transformações antes de escrever para Delta
from pyspark.sql.types import StructType, StructField, IntegerType, StringType, TimestampType
from pyspark.sql.functions import to_timestamp, col, to_json, struct

schema = StructType([
    StructField("id", IntegerType(), nullable=False),
    StructField("Nome", StringType(), nullable=True),
    StructField("CreatedAt", TimestampType(), nullable=True)
])

# leitura com inferência (exemplo) e transformação para o schema alvo
df = spark.read.option("header", "true").csv("/mnt/bronze/myfile.csv")

df_transformed = (
    df.withColumn("id", col("id").cast("int"))
      .withColumnRenamed("name", "Nome")
      .withColumn("CreatedAt", to_timestamp(col("created_at"), "yyyy-MM-dd'T'HH:mm:ss"))
)

# validar: garantir que colunas obrigatórias não são nulas e registar linhas inválidas
invalid = df_transformed.filter(col("id").isNull())
valid = df_transformed.filter(col("id").isNotNull())

# opcional: guardar colunas adicionais num campo JSON para auditoria
known_cols = ["id","Nome","CreatedAt"]
extra = df.drop(*known_cols)
extra_json = df.withColumn("_extra", to_json(struct(*extra.columns)))

# escrever para Delta/OneLake
valid.write.format("delta").mode("append").save("/mnt/lakehouse/mytable")

Si usas Dataflows en Fabric puedes configurar los mapeos visualmente: importas la fuente, añades pasos de transformación (Rename, Derived column, Convert data type) y defines reglas de tratamiento de valores nulos o inválidos. Para flujos críticos implementa tests automáticos que verifiquen muestras del 1% al 5% de los ficheros diariamente para detectar regresiones de esquema.

Errores comunes

1) Confiar siempre en la inferencia automática de tipos: esto causa diferencias entre ejecuciones (p.ej. un campo numérico con valores mixtos puede ser inferido como string). Siempre que sea posible define el schema explícitamente e incluye checks que alerten cuando la inferencia cambia.

2) Ignorar columnas adicionales en la fuente: pueden surgir columnas nuevas que contienen información importante o que rompen operaciones downstream. Decide una estrategia (log, almacenar como JSON, o rechazar) y aplícala de forma consistente. En entornos de integración continua, 30–40% de los fallos iniciales de pipelines derivan de columnas inesperadas.

3) Fallar en la normalización de formatos de fecha/locale: fechas en formatos diferentes conducen a parsing inválido. Centraliza las reglas de parsing (p.ej. UTC vs time zone local) y prueba con muestras representativas — prueba al menos 1000 filas por formato para reducir falsos positivos.

Cómo practicar

Practica creando pequeños pipelines en Fabric: usa un Lakehouse/Delta o un workspace con Spark, crea fuentes con variaciones de esquema (CSV/JSON) e implementa mapeos en PySpark y en Dataflows. Crea escenarios con evolución: por ejemplo, añade 5 columnas nuevas en uno de los ficheros y observa el comportamiento del pipeline. Mide cuántas ejecuciones fallan antes y después de aplicar la estrategia de almacenamiento en JSON auxiliar.

Para la preparación del examen, usa el Practice Assessment oficial y gratuito de Microsoft y la study guide de Microsoft (ambos gratuitos). Esos recursos ayudan a alinear el estudio con las áreas evaluadas sin recurrir a material prohibido. Complementa con labs prácticos: implementa 3 pipelines con diferentes estrategias (fallar, ignorar, anexar JSON) y compara el tiempo medio de recuperación (MTTR) — en pruebas típicas, pipelines con anexado JSON recuperan 2–3x más rápido.

En resumen

Schema mapping garantiza compatibilidad entre fuentes y esquemas de destino, evitando fallos y pérdida de datos.
Define siempre el esquema objetivo explícitamente y aplica transformaciones (rename, cast, parsing) antes de escribir al destino.
Define una política para columnas desconocidas y para cambios de esquema (versionado, columnas nullable, almacenamiento auxiliar en JSON).
Prueba con muestras variadas y automatiza validaciones (checks de nulls, tipos, conteos) para mantener pipelines resilientes; monitoriza tasas de error y MTTR para medir mejoras.