Melhores práticas para criação e desenvolvimento de fluxos de dados complexos

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

Dividi-lo em vários fluxos de dados

Não faça tudo em um fluxo de dados. Um único fluxo de dados complexo não apenas torna o processo de transformação de dados mais longo, como também torna mais difícil de 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 os fluxos de dados de transformação de dados dos fluxos de preparo/extração

Ter alguns fluxos de dados apenas para extrair dados (ou seja, fluxos de dados de preparo) e outros apenas para transformar dados é útil não apenas para criar uma arquitetura multicamada, mas também é útil 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 para desenvolver.

Imagem mostrando dados sendo extraídos de uma fonte de dados para fluxos de dados de preparo, onde as tabelas são armazenadas no armazenamento do Dataverse ou do 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

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 por meio da interface gráfica em Editor do Power Query ou usando um script da M. As funções podem ser reutilizadas em um fluxo de dados em quantas tabelas forem necessárias.

A função personalizada ajuda pois tem apenas uma versão do código-fonte, de modo 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 o seguinte post de blog: Funções personalizadas facilitadas no Power BI Desktop.

Observação

À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 "habilitada para carga".

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 as consultas em pastas relacionadas. Usando essa abordagem, você pode encontrar consultas mais facilmente no futuro, e manter o código fica muito mais fácil.

Usar tabelas computadas

Além de tornar seu fluxo de dados mais compreensível, as tabelas computadas também fornecem melhor desempenho. Quando você usa uma tabela computada, as outras tabelas referenciadas a partir dela obtém os 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 transformações de filtro primeiro em uma tabela computada antes de fazer outros tipos de transformações.

Dividir muitas etapas em várias consultas

É difícil manter o controle de um grande número de etapas em uma tabela. Em vez disso, é recomendável dividir um grande número de etapas em várias tabelas. Você pode usar Habilitar Carga para outras consultas, desabilitá-las se forem consultas intermediárias e carregar apenas a tabela final por meio 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 acompanhar cada consulta para uma investigação mais aprofundada, em vez de pesquisar centenas de etapas em uma consulta.

Adicionar propriedades para consultas e etapas

A documentação é fundamental para ter um código fácil de manter. No Power Query, você pode adicionar propriedades às tabelas e também às etapas. 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 você a manter seu modelo no futuro. Com apenas uma olhada em uma tabela ou etapa, você poderá entender o que está acontecendo lá, em vez de repensar e relembrar o que você fez nessa etapa.

Verifique se a capacidade está na mesma região

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

Separar as fontes locais das fontes na nuvem

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

Separar os fluxos de dados 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 também tiver uma tabela de mapeamento de produto que é atualizada toda 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

Caso você seja frequentemente bloqueado de seus fluxos de dados que contêm tabelas vinculadas, isso pode ser causado por um fluxo de dados dependente correspondente no mesmo espaço de trabalho que é bloqueado durante a atualização do fluxo de dados. Esse bloqueio fornece precisão transacional e garante que os dois fluxos de dados sejam atualizados com êxito, mas pode impedir a edição.

Se você configurar um agendamento separado para o fluxo de dados vinculado, os fluxos de dados poderão ser atualizados desnecessariamente e bloquear a edição do fluxo de dados. Há duas recomendações para evitar esse problema:

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