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.
Para melhorar o desempenho e a confiabilidade, o Dataflow Gen2 usa itens de preparo para armazenar dados intermediários durante a transformação de dados. Este artigo descreve o que são os itens de staging, os padrões ELT que desbloqueiam através do stage uma vez, referência a muitos modelos e como gerir os dados que contêm.
O que são itens de preparação?
Os itens de preparo são locais intermediários de armazenamento de dados usados pelo Dataflow Gen2 para armazenar dados durante a transformação de dados. Esses itens usam os nomes "DataflowsStagingLakehouse" e "DataflowsStagingWarehouse". Os itens de preparo são usados para armazenar dados intermediários durante a transformação de dados para melhorar o desempenho. Esses itens são criados automaticamente quando você cria seu primeiro fluxo de dados e são gerenciados pelo Dataflow Gen2. Esses itens ficam ocultos do usuário no espaço de trabalho, mas podem estar visíveis em outras experiências, como Obter Dados ou o explorador Lakehouse. Aconselhamos vivamente a não aceder nem modificar diretamente os dados nos itens de staging, pois isso pode levar a comportamentos inesperados. Além disso, o armazenamento de dados por si só nos itens de preparo não é suportado e pode resultar em perda de dados.
Padrões ELT: processar uma vez, reutilizar muitas vezes
Para além de fornecer armazenamento intermédio, o staging desbloqueia um conjunto de padrões ELT construídos sobre uma única base: configurar uma vez, referenciar várias. Uma consulta de origem é marcada como "preparada" para que a sua saída seja materializada para um armazenamento interno intermediário. As consultas seguintes referem-se então a essa consulta preparada em vez de voltarem a ler a fonte. O Fast Copy é um acelerador opcional que faz com que a consulta em fases se preencha mais rapidamente, mas não é isso que define o padrão.
O padrão é importante porque, uma vez que os dados estão armazenados, as consultas posteriores podem:
- Executar contra uma cópia indexada e consultável sem acessar novamente a fonte.
- Dobrar filtros, junções e agregações de volta ao endpoint SQL de preparação em vez de executar no motor mashup.
- Ramifica-se em múltiplas transformações paralelas ou destinos a partir de um único resultado materializado.
Casos comuns de utilização
Os padrões seguintes são normalmente sobrepostos a uma consulta de fonte em etapas.
| Caso de uso | Description |
|---|---|
| Transformar dados em etapas em modelos analíticos | Consultas referenciadas organizam dados escalonados em tabelas de factos e dimensões, resumos, agregações ou KPIs através de deduplicação, agrupamentos e geração de chaves. |
| Otimização de cálculo rebatível | Consultas referenciadas escritas contra dados em estágio integram as junções, filtros e operações de agrupamento para o endpoint SQL de staging, enviando o cálculo para o motor de armazém de dados em vez do motor de combinação. Este é frequentemente o maior ganho de desempenho que o staging permite. |
| Qualidade dos dados e ramo de auditoria | Consultas referenciadas validam ou inspecionam dados em etapas (verificações nulas, validação de restrições, contagens de linhas) sem reler a fonte. |
| Espalha-te para múltiplos destinos | Múltiplas consultas referenciadas carregam cada uma um destino diferente a partir da mesma fonte em etapas (por exemplo, um Lakehouse e um Warehouse). |
| Etapa e depois fusão | Cada fonte é preparada na sua própria consulta. Posteriormente, uma consulta subsequente integra os resultados preparados, encaixando a integração de volta no endpoint SQL de preparação. |
Quando a encenação não é a escolha certa
O staging acrescenta custo de armazenamento e uma gravação extra antes de as consultas subsequentes serem executadas. Considere omití-lo quando:
- A sua transformação já está integrada de ponta a ponta no sistema de origem, sem cálculo no motor de mashup.
- O fluxo de dados tem uma única saída e não tem ramificações a jusante, validação ou dispersão.
- A latência da fonte é o gargalo e a fonte não pode ser paralelizada através do processo de staging.
Para mais orientações sobre quando ativar ou desativar o staging, consulte Melhores práticas para obter o melhor desempenho com o Dataflow Gen2.
Dados em itens em preparação
Os itens de preparação temporária não foram projetados para acesso direto pelos usuários. O Dataflow Gen2 gerencia os dados nos itens de preparo e garante que os dados estejam em um estado consistente. O acesso direto a dados em itens de preparação não é suportado, pois não é possível garantir que os dados estejam em um estado consistente. Se precisares de aceder a dados em itens de staging, podes usar o conector dataflow no Power BI, Excel ou outros dataflows.
Importante
A API interna que fornece dados escalonados aos consumidores a jusante (como modelos semânticos ou outros fluxos de dados usando o conector Dataflows) pode sofrer timeouts intermitentes. Estes timeouts podem causar falhas de atualização ao consumir itens, frequentemente apresentando o erro "A chave não correspondeu a nenhuma linha da tabela." Este erro não indica um problema de dados. Isto significa que o backend não conseguiu recuperar os resultados em fases a tempo.
Solução alternativa recomendada: Configure um destino de dados (Lakehouse ou Data Warehouse) para o seu fluxo de dados e atualize os itens a jusante para que a leitura seja feita diretamente desse destino usando o conector Lakehouse ou Data Warehouse. Isto contorna a API interna de staging e melhora a fiabilidade da atualização.
Para mais informações, consulte limitações da Data Factory.
A remoção de dados dos elementos de estágio pode ser forçada através de uma das seguintes ações:
- Desative o estágio no fluxo de dados e atualize (após 30 dias, removemos os dados).
- Exclua o fluxo de dados (remove diretamente os dados).
- Exclua o espaço de trabalho (apaga diretamente StagingLakehouse e StagingWarehouse).
Implicações de custo da encenação
O Lakehouse de staging e o Warehouse de staging armazenam dados intermédios como parte do processamento do seu fluxo de dados. O armazenamento consumido por estes itens de preparação é faturado como parte do seu armazenamento OneLake. Isto significa que os dados armazenados nos itens de staging contam para o seu consumo total de armazenamento OneLake e para os custos associados.
Para gerir eficazmente os custos de armazenamento:
- Monitorize o uso de armazenamento por etapas: Esteja atento a que os dados de staging acumulam-se a cada atualização do fluxo de dados até serem recolhidos como lixo ou explicitamente removidos.
- Desative o staging quando não for necessário: Se as suas transformações se integram no sistema de origem, pode não precisar de manter o staging ativado. Desativar o staging reduz o consumo de armazenamento.
- Limpar fluxos de dados não utilizados: Eliminar fluxos de dados que já não são necessários remove imediatamente os seus dados de staging associados.
- Considere a frequência de atualização: Atualizações frequentes com staging ativado podem levar a um maior consumo de armazenamento. Equilibre os benefícios de desempenho com os custos de armazenamento.
Para mais informações sobre os preços do armazenamento OneLake, consulte preços Microsoft Fabric.