DP-700: como planear e implementar schema mapping para ingestão no Fabric

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

Nesta lição vou ensinar a competência de planear e implementar schema mapping durante a ingestão de dados no Microsoft Fabric. Esta competência é importante para o exame DP-700 porque garante que os dados recebidos são coerentes com os modelos analíticos; na prática evita erros de compatibilidade, perda de informação e facilita pipelines resilientes. Uma boa estratégia de schema mapping pode reduzir rejeições de ingestão em 60–90% num ambiente com evolução frequente de esquemas.

O que precisas de saber

Schema mapping é o processo de mapear colunas, tipos e estruturas de dados de uma fonte de ingestão para o esquema de destino usado em tabelas do Fabric (por exemplo em Tables dentro de Lakehouse/Delta ou numa Synapse SQL pool). O objetivo é, entre outros, harmonizar nomes, converter tipos, tratar colunas em falta/excedentes e garantir que a ingestão suporta evoluções do esquema sem interromper consumidores downstream.

Exemplo simples: uma fonte CSV tem as colunas (id, name, created_at) onde created_at é texto ISO; o destino requer (Id INT, Nome STRING, CreatedAt DATETIME). O schema mapping define que id -> Id com conversão para INT, name -> Nome (renomear), created_at -> CreatedAt com parsing para DATETIME e regras quando o campo estiver vazio. Em cenários reais vês tabelas com 20–200 colunas; aplicar mapeamento explícito para as 10–20 colunas críticas costuma ser suficiente para proteger relatórios essenciais enquanto se faz evolução gradual do resto.

Como funciona na prática

Em Fabric podes aplicar schema mapping em vários pontos do pipeline: no processo de leitura (Dataflows, Notebooks, Spark), durante a escrita para Delta/OneLake (usando DataFrame schemas ou DDL) ou em pipelines de Data Factory/Synapse. As abordagens variam consoante uses Spark/Apache/Delta ou componentes low-code como Dataflows. Em ingestões de alta velocidade (p.ex. 10k–100k registos/minuto) preferes transformações em Spark por serem mais eficientes; para cargas pontuais e transformação leve, Dataflows dão visibilidade e controlo sem código.

Pontos-chave práticos:

Definir o esquema alvo de forma explícita: evita inferência automática. No Spark/PySpark definimos um StructType/DDL; nos Dataflows criamos as colunas com o tipo pretendido. Em ambientes de produção, manter um ficheiro de esquema (JSON/DDL) versionado facilita auditoria e deployment.
Mapear nomes e tipos: renomear colunas e transformar tipos (ex.: string -> timestamp). Documenta também colunas opcionais e obrigatórias e quantifica: p.ex. 15 colunas obrigatórias, 25 opcionais. Esse inventário ajuda a priorizar validações.
Gerir colunas desconhecidas: escolher entre ignorar, armazenar numa coluna JSON de anexo, ou falhar a ingestão. Uma prática comum é armazenar colunas não mapeadas num campo auxiliar JSON para auditoria — reduz falhas sem perder dados.
Lidar com mudanças de esquema: aplicar versionamento do esquema (p.ex. v1, v2), usar colunas permissivas (nullable) e pipelines idempotentes. Define SLAs: por exemplo, exigir compatibilidade de leitura por 2 semanas antes de descontinuar campos antigos.

# 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")

Se usares Dataflows em Fabric podes configurar os mapeamentos visualmente: importas a fonte, adicionas passos de transformação (Rename, Derived column, Convert data type) e defines regras de tratamento de valores nulos ou inválidos. Para fluxos críticos implementa testes automáticos que verifiquem amostras de 1% a 5% dos ficheiros diariamente para detetar regressões de esquema.

Erros comuns

1) Confiar sempre na inferência automática de tipos: isto causa diferenças entre execuções (p.ex. um campo numérico com valores mistos pode ser inferido como string). Sempre que possível define o schema explicitamente e inclui checks que alertem quando a inferência muda.

2) Ignorar colunas adicionais na fonte: podem surgir colunas novas que contêm informação importante ou que quebram operações downstream. Decide uma estratégia (log, armazenar como JSON, ou rejeitar) e aplica-a de forma consistente. Em ambientes de integração contínua, 30–40% das falhas iniciais de pipelines derivam de colunas inesperadas.

3) Falhar na normalização de formatos de data/locale: datas em formatos diferentes conduzem a parsing inválido. Centraliza as regras de parsing (p.ex. UTC vs time zone local) e testa com amostras representativas — testa pelo menos 1000 linhas por formato para reduzir falsos positivos.

Como praticar

Pratica criando pequenos pipelines em Fabric: usa um Lakehouse/Delta ou um workspace com Spark, cria fontes com variações de esquema (CSV/JSON) e implementa mapeamentos em PySpark e em Dataflows. Cria cenários com evolução: por exemplo, adiciona 5 colunas novas num dos ficheiros e observa o comportamento do pipeline. Mede quantas execuções falham antes e depois de aplicar a estratégia de armazenamento em JSON auxiliar.

Para preparação para o exame, usa o Practice Assessment oficial e gratuito da Microsoft e a study guide da Microsoft (ambos gratuitos). Esses recursos ajudam a alinhar o estudo com as áreas avaliadas sem recorrer a material proibido. Complementa com labs práticos: implementa 3 pipelines com diferentes estratégias (falhar, ignorar, anexar JSON) e compara o tempo médio de recuperação (MTTR) — em testes típicos, pipelines com anexação JSON recuperam 2–3x mais rápido.

Em resumo

Schema mapping garante compatibilidade entre fontes e esquemas de destino, evitando falhas e perda de dados.
Define sempre o esquema alvo explicitamente e aplica transformações (rename, cast, parsing) antes de escrever para o destino.
Define uma política para colunas desconhecidas e para alterações de esquema (versionamento, colunas nullable, armazenamento auxiliar em JSON).
Testa com amostras variadas e automatiza validações (checks de nulls, tipos, contagens) para manter pipelines resilientes; monitoriza taxas de erro e MTTR para medir melhorias.