Dando continuidade ao artigo anterior sobre frameworks orientadas por metadados baseadas em YAML, vamos falar sobre o logging – a parte da framework que, muitas vezes, fica invisível até algo falhar. Na Parte 1, o YAML ajudou-nos a substituir tabelas de configuração por definições mais limpas e controladas por versão. Agora, o logging garante a visibilidade necessária para perceber o que está realmente a acontecer dentro dos pipelines do Fabric.

Porque sem registos adequados, resolver uma execução falhada é como tentar arranjar um carro às escuras – sabe-se que algo avariou, mas não há qualquer pista sobre onde está o problema.

Porquê usar o Eventhouse para Logging?

Quando passámos a usar YAML para configurações, deixámos de armazenar metadados dos pipelines no warehouse ou em tabelas SQL para a configuração. Para o logging, optámos propositadamente pelo Eventhouse e a sua base de dados KQL.

Porquê? Porque o KQL foi feito exatamente para este tipo de trabalho:

• Otimizado para ingestão → lida bem com grandes volumes de dados append-only (um encaixe natural para logs).
• Consulta eficiente → o KQL foi desenhado para analisar rapidamente grandes volumes de dados, filtrando e agregando por tempo.
• Análises em tempo real → os registos podem acionar eventos (por exemplo, através do Fabric Activator).
• Suporte a séries temporais → ideal para acompanhar execuções de jobs e identificar padrões.

É exatamente assim que o Azure Monitor e o Log Analytics funcionam, por isso usar KQL no Fabric para logging não é reinventar a roda – é adotar um padrão já comprovado dentro do ecossistema Fabric.

Dito isto, a abordagem com Eventhouse não é isenta de limitações. Em SKUs mais baixos do Fabric, já observámos uma limitação de desempenho sob concorrência moderada a elevada. Mecanismos de retry (como exponential backoff) ajudam, mas são apenas soluções paliativas e não uma resolução definitiva.

Porque não Warehouse ou Lakehouse?

Embora tecnicamente os logs pudessem ser armazenados num Warehouse ou Lakehouse, na prática:

• O Warehouse no Fabric tem suporte de escrita limitado a partir do Spark (não existe conector nativo; apenas via pyodbc ou soluções em pipelines).
• O Lakehouse pode receber logs diretamente de notebooks, mas os pipelines não suportam escrita em tabelas Lakehouse — o que quebra a consistência do framework.
• Concorrência → o Eventhouse é simplesmente mais eficiente a lidar com múltiplas escritas simultâneas do que o Warehouse ou Lakehouse.

Mesmo que o volume de registos “não seja assim tão elevado”, a capacidade de gestão de concorrência do KQL e a sua API de escrita simples fazem dele a escolha mais prática.

Como funciona o Logging no Framework

Capturamos registos em dois níveis: execução de pipelines de ingestão e orquestração global.

1. Logging de Pipelines

Após cada pipeline de ingestão terminar, um passo genérico do pipeline chama uma atividade KQL que regista:

• Nome da tabela de origem
• Objeto/local de destino
• Linhas ingeridas
• Timestamps de início/fim
• Duração, estado e métricas personalizadas

2. Logging de Notebooks (orquestração)

Um único notebook de orquestração lê/analisa o YAML, constrói o DAG e executa as tarefas.

Em vez de adicionar código de logging em cada notebook, usamos um notebook wrapper.

• • O wrapper regista início/fim e estado de cada tarefa.
  • Captura erros de forma segura em qualquer célula do notebook chamado.
  • Regista o nome do processo, estado de execução (iniciado/completado/erro), timestamps de início/fim e mensagem de erro (quando aplicável).
  • Como o logging está centralizado, não é preciso alterar cada notebook individual, e a informação de falhas fica consistente (o que também ajuda em cenários de recuperação após uma falha).

O wrapper escreve cada entrada de log no Eventhouse usando o Kusto Spark Connector.

Isto dá-nos registos granulares de ingestão dos pipelines e registos de tarefas consistentes e centralizados da camada de orquestração — tudo no Eventhouse, para análise e resolução de problemas.

Conclusão

O logging não é apenas uma funcionalidade secundária; é a espinha dorsal de pipelines fiáveis.
Ao escolhermos o Eventhouse, alinhamos com os pontos fortes do Fabric — KQL para ingestão, análise e consultas de séries temporais — mantendo o registo de pipelines e notebooks consistente.

Outros motores também podem ser considerados, dependendo das necessidades:

• Lakehouse / Warehouse → ambos baseados em tabelas Delta, mas com dificuldades em escritas de alta concorrência, embora possam servir para cenários de auditoria ou registo de baixa frequência.
• Base de Dados SQL (atualmente em preview) → suporta inserções relacionais estruturadas, mas o consumo de CUs torna-o pouco atrativo para registo operacional de alto volume, especialmente em SKUs mais baixos.

Para a maioria dos cenários, o Eventhouse continua a ser a escolha natural: ingestão escalável, visibilidade em tempo real e análise de séries temporais integrada — exatamente o que o registo operacional exige.

Na próxima parte deste artigo, vamos explorar como foram configurados os pipelines de DevOps para deployment do YAML no Fabric, incluindo controlo de versões, promoção de ambientes e fluxos de aprovação.