Share via


Práticas recomendadas para projetar e desenvolver fluxos de dados complexos

Se o fluxo de dados que você está desenvolvendo está ficando maior e mais complexo, aqui estão algumas coisas que você pode fazer para melhorar seu design original.

Divida-o em vários fluxos de dados

Não faça tudo em um fluxo de dados. Um fluxo de dados único e complexo não apenas torna o processo de transformação de dados mais longo, mas também torna mais difícil entender e reutilizar o fluxo de dados. A divisão do fluxo de dados em vários fluxos de dados pode ser feita separando tabelas em fluxos de dados diferentes ou até mesmo uma tabela em vários fluxos de dados. Você pode usar o conceito de uma tabela computada ou tabela vinculada para criar parte da transformação em um fluxo de dados e reutilizá-la em outros fluxos de dados.

Dividir fluxos de dados de transformação de dados de fluxos de dados de preparação/extração

Ter alguns fluxos de dados apenas para extrair dados (ou seja, preparar fluxos de dados) e outros apenas para transformar dados é útil não apenas para criar uma arquitetura multicamadas, mas também para reduzir a complexidade dos fluxos de dados. Algumas etapas apenas extraem dados da fonte de dados, como obter dados, navegação e alterações de tipo de dados. Ao separar os fluxos de dados de preparo e os fluxos de dados de transformação, você torna seus fluxos de dados mais simples de desenvolver.

Multilayered dataflow architecture.

Imagem mostrando dados sendo extraídos de uma fonte de dados para fluxos de dados de preparação, onde as tabelas são armazenadas no armazenamento Dataverse ou Azure Data Lake. Em seguida, os dados são movidos para fluxos de dados de transformação, onde os dados são transformados e convertidos na estrutura do data warehouse. Em seguida, os dados são movidos para o modelo semântico.

Usar funções personalizadas

As funções personalizadas são úteis em cenários em que um determinado número de etapas precisa ser feito para várias consultas de diferentes fontes. As funções personalizadas podem ser desenvolvidas através da interface gráfica no Power Query Editor ou utilizando um script M. As funções podem ser reutilizadas em um fluxo de dados em quantas tabelas forem necessárias.

Ter uma função personalizada ajuda por ter apenas uma única versão do código-fonte, para que você não precise duplicar o código. Como resultado, manter a lógica de transformação do Power Query e todo o fluxo de dados é muito mais fácil. Para obter mais informações, vá para a seguinte postagem de blog: Funções personalizadas facilitadas no Power BI Desktop.

Screenshot of the Queries pane with the Get Holidays custom function and its data emphasized.

Nota

Às vezes, você pode receber uma notificação informando que uma capacidade premium é necessária para atualizar um fluxo de dados com uma função personalizada. Você pode ignorar essa mensagem e reabrir o editor de fluxo de dados. Isso geralmente resolve seu problema, a menos que sua função se refira a uma consulta "carga habilitada".

Colocar consultas em pastas

O uso de pastas para consultas ajuda a agrupar consultas relacionadas. Ao desenvolver o fluxo de dados, gaste um pouco mais de tempo para organizar consultas em pastas que façam sentido. Usando essa abordagem, você pode encontrar consultas mais facilmente no futuro e manter o código é muito mais fácil.

Usar tabelas computadas

As tabelas computadas não só tornam o seu fluxo de dados mais compreensível, como também proporcionam um melhor desempenho. Quando você usa uma tabela computada, as outras tabelas referenciadas a partir dela estão obtendo dados de uma tabela "já processada e armazenada". A transformação é muito mais simples e rápida.

Aproveite o mecanismo de computação aprimorado

Para fluxos de dados desenvolvidos no portal de administração do Power BI, certifique-se de usar o mecanismo de computação aprimorado executando junções e filtrando transformações primeiro em uma tabela computada antes de fazer outros tipos de transformações.

Divida muitas etapas em várias consultas

É difícil acompanhar um grande número de etapas em uma tabela. Em vez disso, você deve dividir um grande número de etapas em várias tabelas. Você pode usar Habilitar Carregar para outras consultas e desativá-las se forem consultas intermediárias e carregar apenas a tabela final através do fluxo de dados. Quando você tem várias consultas com etapas menores em cada uma, é mais fácil usar o diagrama de dependência e controlar cada consulta para investigação adicional, em vez de se aprofundar em centenas de etapas em uma consulta.

Adicionar propriedades para consultas e etapas

A documentação é a chave para ter um código fácil de manter. No Power Query, pode adicionar propriedades às tabelas e também aos passos. O texto que você adiciona nas propriedades aparece como uma dica de ferramenta quando você passa o mouse sobre essa consulta ou etapa. Esta documentação ajuda-o a manter o seu modelo no futuro. Com um olhar para uma mesa ou etapa, você pode entender o que está acontecendo lá, em vez de repensar e lembrar o que você fez nessa etapa.

Garantir que a capacidade está na mesma região

Atualmente, os fluxos de dados não suportam vários países ou regiões. A capacidade Premium deve estar na mesma região que seu locatário do Power BI.

Separe as fontes locais das fontes de nuvem

Recomendamos que você crie um fluxo de dados separado para cada tipo de fonte, como local, nuvem, SQL Server, Spark e Dynamics 365. Separar fluxos de dados por tipo de origem facilita a solução de problemas rápida e evita limites internos quando você atualiza seus fluxos de dados.

Fluxos de dados separados com base na atualização agendada necessária para tabelas

Se você tiver uma tabela de transações de vendas que é atualizada no sistema de origem a cada hora e tem uma tabela de mapeamento de produtos que é atualizada a cada semana, divida essas duas tabelas em dois fluxos de dados com agendas de atualização de dados diferentes.

Evite agendar a atualização para tabelas vinculadas no mesmo espaço de trabalho

Se você estiver sendo regularmente bloqueado de seus fluxos de dados que contêm tabelas vinculadas, isso pode ser causado por um fluxo de dados correspondente e dependente no mesmo espaço de trabalho que está bloqueado durante a atualização do fluxo de dados. Esse bloqueio fornece precisão transacional e garante que ambos os fluxos de dados sejam atualizados com êxito, mas pode bloqueá-lo de editar.

Se você configurar uma agenda separada para o fluxo de dados vinculado, os fluxos de dados poderão ser atualizados desnecessariamente e impedi-lo de editar o fluxo de dados. Existem duas recomendações para evitar este problema:

  • Não defina uma agenda de atualização para um fluxo de dados vinculado no mesmo espaço de trabalho que o fluxo de dados de origem.
  • Se você quiser configurar uma agenda de atualização separadamente e quiser evitar o comportamento de bloqueio, mova o fluxo de dados para um espaço de trabalho separado.