Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Use estas melhores práticas para definir resultados completos, proteger os dados do lakehouse, tornar as reexecuções previsíveis e exigir evidências mensuráveis de sucesso nas tarefas do agente de engenharia de dados do Fabric (Project Osmos).
Importante
O agente de engenharia de dados (Project Osmos) está em versão preliminar. As funcionalidades de pré-visualização são lançadas com capacidades limitadas e estão sujeitas a termos suplementares de pré-visualização separados. Não são destinados a uso em produção, não estão sujeitos a acordos de nível de serviço e podem estar disponíveis apenas em regiões selecionadas. Para mais informações, consulte informação de pré-visualização do Microsoft Fabric.
Defina um resultado completo do projeto
A competência define resultado do projeto da seguinte forma:
Descreva a tarefa completa de engenharia de dados de ponta a ponta. O agente de engenharia de dados recebe-o como um único projeto.
Defina o resultado completo em vez de apenas o primeiro passo de implementação. Inclua estes cinco elementos:
| Elemento | Pergunta a responder | Exemplo |
|---|---|---|
| Goal | Que resultado deverá existir quando a tarefa for concluída? | Crie uma tabela mensal de despesas com fornecedores. |
| Sources | Que dados deve a tarefa usar? | Leia ficheiros CSV de faturas e a tabela Delta de Fornecedores. |
| Transformations | Que regras deve aplicar a tarefa? | Padronizar IDs de fornecedores, rejeitar datas inválidas, juntar-se aos fornecedores e agregar os gastos mensais. |
| Outputs | O que deve a tarefa criar ou atualizar? | Escreve monthly_supplier_spend e guarda o caderno de transformação. |
| Validation | Como deve o agente de engenharia de dados provar sucesso? | Reconciliar os totais das faturas, verificar chaves duplicadas e reportar linhas rejeitadas. |
Use este modelo:
<goal>. Read <sources>. Apply <transformations>.
Create or update <outputs>. Validate <success criteria>. Preserve
<important constraints>.
Definir limites explícitos
Indique quais as fontes que o agente de engenharia de dados pode ler, para que destinos pode escrever e quais os artefactos existentes que deve preservar. Identifique quaisquer restrições de esquema, retenção, processamento regional ou regras de negócio que afetem a tarefa.
As permissões Fabric e OneLake continuam a ser o limite de autorização. Não inclua credenciais, tokens de acesso, cabeçalhos de autorização ou dados sensíveis no resultado do Project.
Escreva um resultado específico do Project
Os seguintes exemplos de resultados do Project combinam um objetivo, fontes, transformações, resultados, restrições e critérios de validação.
Exploração de dados
Profile the customer_events table without modifying it.
Summarize schema, row count, date range, null rates, duplicate event IDs,
category distributions, and outliers. Save the analysis in a notebook.
Ingestão de ficheiros
Ingest JSON files from Files/device-events. Flatten the
event payload, standardize timestamps to UTC, quarantine malformed records,
write valid rows to device_events_bronze, and report processed, accepted,
and rejected counts.
Transformação de dados
Join Orders, OrderLines, Customers, and Products. Create
a Delta table named sales_order_detail with calculated line revenue and margin.
Validate referential integrity, duplicate order-line keys, and source-to-output
revenue totals.
Remediação da qualidade dos dados
Assess customer_master for missing identifiers, invalid
email addresses, duplicate customers, and inconsistent country codes. Propose
a safe remediation plan, apply the approved changes to a staged table, and
produce before-and-after quality metrics.
Modernização de esquemas
Migrate the legacy_sales table to a documented schema
with typed dates, decimal monetary values, and standardized region codes.
Preserve the source table, create a tested notebook, and reconcile record
counts and revenue totals.
Carregamento incremental
Build an incremental load from Files/orders-daily into
the Orders Delta table. Deduplicate by order_id and modified_at, update changed
orders, preserve unchanged rows, save the notebook, and validate inserted,
updated, unchanged, and rejected counts.
Arquitetura do medalhão
Build bronze, silver, and gold layers for product,
inventory, and supplier files. Preserve raw inputs in bronze, standardize and
deduplicate entities in silver, create a gold inventory-risk table, save all
notebooks, and validate each layer.
Escolha um padrão de escrita seguro
Ao criar uma tarefa, selecione um padrão de escrita que corresponda ao impacto e reversibilidade da tarefa:
- Clonar e promover: Testar alterações numa cópia antes de mover o resultado validado para o destino.
- Tabela de preparação: Escreva os resultados separadamente para revisão ou numa etapa controlada de promoção.
- Iterar no local: Modificar o alvo diretamente. Utilize apenas quando compreender o risco e o plano de recuperação.
- Eliminação de duplicados na reexecução: Use uma chave de negócio estável para evitar registos duplicados.
- Esquema bloqueado: Rejeitar alterações inesperadas no esquema.
- Esquema de alargamento de tipos: Permitir alargamento compatível enquanto previne alterações arbitrárias.
As permissões Fabric continuam a ser o limite rígido de autorização. Não confie apenas no resultado do Project para proteger dados críticos.
Tornar as repetições previsíveis
Diga ao agente de engenharia de dados como lidar com os dados que processou anteriormente. Use chaves de negócio estáveis e especifique se uma reexecução deve falhar, acrescentar novos dados, eliminar registos duplicados, fundir alterações ou substituir o destino.
Para tarefas incrementais, peça contagens de registos inseridos, atualizados, inalterados e rejeitados. Preserve os dados de origem e as saídas verificadas, a menos que a substituição seja uma parte explícita do resultado solicitado.