Explorando configurações baseadas em YAML, logging de eventos e CI/CD em pipelines de dados no Fabric.

Porque é que as frameworks orientadas por metadados são importantes

Se já trabalhou em projetos de engenharia de dados, provavelmente já se deparou com o “caos da configuração”. Talvez alguém tenha atualizado uma tabela de configuração sem avisar. Talvez uma “correção rápida” para o Projeto A tenha quebrado o Projeto B. Ou talvez — sejamos honestos — tenha corrido um UPDATE sem um WHERE e acabou por ter uma noite muito calma (e muito longa).

A verdade é que gerir configurações de pipelines em larga escala é complicado. É precisamente por isso que existem frameworks orientadas por metadados.

Na sua essência, estas frameworks permitem abandonar o hardcoding e ganhar flexibilidade. Em vez de colocar a lógica diretamente em cada pipeline, define-se o que precisa de correr, onde estão os dados, onde devem ficar e como lá chegam — tudo através de metadados.

Estas frameworks permitem:

• Parametrizar tarefas e movimentos de dados.
• Acompanhar deltas e registar o histórico de execuções.
• Definir dependências e tolerância a erros.

O problema das tabelas SQL

Tradicionalmente, as configurações vivem em tabelas SQL. No Microsoft Fabric, isso significa, geralmente, um warehouse ou uma base de dados SQL, com pipelines a orquestrar o processo.

Funciona… até certo ponto. Mas à medida que os projetos e as equipas crescem, começam a surgir fissuras:

• As tabelas de configuração são atualizadas em produção “só desta vez” (famosas últimas palavras).
• O controlo de versões é praticamente inexistente.
• A integração com DevOps torna-se dolorosa.
• Debugging a alterações de configuração transforma-se num trabalho de detetive.

Rapidamente, aquilo que começou como uma solução elegante torna-se difícil de manter.

Uma abordagem mais limpa com YAML

É aqui que entra o YAML. Os ficheiros YAML são:

• Legíveis por humanos → fáceis de analisar, mesmo em projetos grandes.
• Controlados por versão → com o Git, seguir alterações torna-se trivial.
• Compatíveis com PySpark → o parsing é simples.

Sim, a indentação pode ser implacável (todos já fomos traídos por um espaço extra), mas as vantagens compensam.

Nos nossos projetos com Fabric, usamos YAML para substituir essas tabelas de configuração, alinhando com a arquitetura medallion — Bronze, Silver, Gold — com lakehouses distintos para cada camada. O YAML atua como um blueprint que orquestra a forma como os dados circulam entre elas.

Configuração da camada Bronze

Aqui está um exemplo simples de definição YAML para uma extração bronze:

O que está a acontecer aqui?

• Source → tabela SQL AdventureWorks Person.Person.
• Destination → lakehouse Bronze, guardado em formato Parquet.
• Load method → delta loads com base na coluna ModifiedDate.
• Executor → um pipeline (pl_copyFrom_adventureWorks2022).

Pense nisto como o GPS do projeto: sabe onde os dados começam, para onde vão e qual o veículo (pipeline) que os transporta até lá.

Configuração da camada Silver (dependências)

Agora vejamos como isto se apresenta na camada Silver:

Aqui vemos algumas diferenças:

• Load type é um merge no lakehouse Silver.
• Artifact é um notebook (NB_Load_Silver).
• Dependency aguarda primeiro pela conclusão de bronze.

Ou seja, mesmo em YAML, Bronze vem sempre antes de Silver — não há saltos no processo.

Como funciona a orquestração

Tudo isto converge num notebook de orquestração. A sua função é simples (em conceito):

1. Ler o YAML.
2. Interpretar as tarefas e dependências.
3. Construir um DAG (directed acyclic graph).
4. Executar as tarefas pela ordem correta.

• Pipelines e outros artefactos que não são notebooks são acionados via API do Fabric.
• O DAG é executado utilizando notebookutils.runMultiple.

Basicamente, o notebook atua como um controlador de tráfego aéreo para os seus pipelines de dados — decidindo calmamente quem descola e quando.

Os benefícios na prática

Mover as configurações para YAML traz benefícios claros:

• Escalabilidade → fácil adicionar novas tarefas à medida que os projetos crescem.
• Manutenção → configs estruturadas, legíveis e com controlo de versões.
• Implantações mais seguras → não há mais atualizações misteriosas em tabelas de configuração em produção.

Mantém os projetos de dados limpos, rastreáveis e mais fáceis de fazer debug.

Registo e gestão de erros

Uma framework orientada por metadados não fica completa sem o registo (logging) adequado e uma gestão de erros. Na nossa abordagem, cada execução de tarefa grava logs estruturados num eventhouse dedicado. Estes logs capturam:

• Nome da tarefa e camada (Bronze, Silver, Gold).
• Timestamps de execução (início, fim, duração).
• Contagem de linhas (processadas, inseridas, atualizadas).
• Estado (success, failure).

Em caso de falha, a framework regista os detalhes da exceção e interrompe automaticamente as tarefas dependentes. Como a orquestração constrói um DAG, as dependências não são executadas se uma tarefa a montante falhar — garantindo que as camadas seguintes não são poluídas com dados incompletos. As regras de gestão de erros também podem ser definidas em YAML (por exemplo, se deve tentar novamente um passo com falha ou ignorá-lo com um aviso). E, depois de corrigida a causa do problema, a framework pode até retomar a execução exatamente a partir da tarefa que falhou, evitando reprocessar tudo de início.

Implementação DevOps

Outra vantagem importante do uso de YAML é a integração fluida com pipelines de DevOps. Como todas as configurações vivem em ficheiros, elas:

• Acompanham o código → armazenadas em repositórios Git, revistas através de pull requests.
• São implantadas de forma consistente → os pipelines de implementação do Fabric podem mover YAML de Dev para Test e Prod com confiança.
• Suportam aprovações e rollbacks → se algo correr mal, reverter para uma versão anterior do YAML é tão simples como reverter um commit.

Isto significa que as equipas podem gerir configurações de pipelines da mesma forma que gerem código de aplicações — com práticas adequadas de CI/CD em vez de edições ad-hoc em tabelas.

Conclusão

As frameworks orientadas por metadados sempre tiveram como objetivo tornar os pipelines de dados mais fáceis de gerir. Usar YAML no Microsoft Fabric leva essa ideia mais longe — combinando a flexibilidade dos metadados com a segurança do controlo de versões, logging estruturado e práticas modernas de implementação DevOps.

Assim, da próxima vez que alguém perguntar onde vivem as configurações, já não terá de apontar para uma tabela SQL meio esquecida. Pode mostrar-lhes um ficheiro YAML no controlo de código, logs rastreáveis num eventhouse dedicado e um pipeline de implementação limpo que move tudo de Dev para Prod sem surpresas.

E isto é apenas o começo. Nos próximos artigos, irei explorar em mais detalhe como o logging é estruturado, como funciona a recuperação de erros e como foram configurados os pipelines de DevOps para implementação com YAML. Fique atento!