Compartilhar via

Entender e otimizar a atualização de fluxos de dados

Os fluxos de dados do Power BI permitem que você se conecte, transforme, combine e distribua dados para análise downstream. Um elemento-chave nos fluxos de dados é o processo de atualização, que aplica as etapas de transformação que você criou nos fluxos de dados e atualiza os dados nos próprios itens.

Para entender os tempos de execução, o desempenho e se você está aproveitando ao máximo o fluxo de dados, baixe o histórico de atualizações depois de atualizar um fluxo de dados.

Entender as atualizações

Há dois tipos de atualizações aplicáveis aos fluxos de dados:

  • Completo, que executa uma limpeza completa e recarregamento dos dados.

  • Incremental (somente Premium), que processa um subconjunto de seus dados com base em regras baseadas em tempo, expressas como um filtro, que você configura. O filtro na coluna de data particiona dinamicamente os dados em intervalos no serviço do Power BI. Depois de configurar a atualização incremental, o fluxo de dados alterará automaticamente sua consulta para incluir a filtragem por data. Você pode editar a consulta gerada automaticamente usando o Editor Avançado no Power Query para ajustar ou personalizar sua atualização. Se você trouxer seu próprio Azure Data Lake Storage, poderá ver fatias de tempo de seus dados com base na política de atualização definida.

    Observação

    Para saber mais sobre a atualização incremental e como ela funciona, confira Como usar a atualização incremental com fluxos de dados.

A atualização incremental permite grandes fluxos de dados no Power BI com os seguintes benefícios:

  • As atualizações são mais rápidas após a primeira atualização, devido aos seguintes fatos:

    • O Power BI atualiza as últimas N partições especificadas pelo usuário (em que a partição é dia/semana/mês e assim por diante) ou
    • O Power BI atualiza apenas os dados que precisam ser atualizados. Por exemplo, atualizando apenas os últimos cinco dias de um modelo semântico de 10 anos.
    • O Power BI atualiza apenas os dados que foram alterados, desde que você especifique a coluna que deseja verificar se há alterações.

  • As atualizações são mais confiáveis– não é mais necessário manter conexões de longa execução com sistemas de origem voláteis.

  • O consumo de recursos é reduzido – menos dados para atualizar reduz o consumo geral de memória e outros recursos.

  • Sempre que possível, o Power BI emprega o processamento paralelo em partições, o que pode levar a atualizações mais rápidas.

Em qualquer um desses cenários de atualização, se uma atualização falhar, os dados não serão atualizados. Seus dados podem estar obsoletos até que a atualização mais recente seja concluída ou você poderá atualizá-los manualmente e eles poderão ser concluídos sem erros. A atualização ocorre em uma partição ou entidade, portanto, se uma atualização incremental falhar ou uma entidade tiver um erro, toda a transação de atualização não ocorrerá. De outra forma, se uma partição (política de atualização incremental) ou entidade falhar para um fluxo de dados, toda a operação de atualização falhará e nenhum dado será atualizado.

Entender e otimizar atualizações

Para entender melhor como uma operação de atualização de fluxo de dados é executada, examine o Histórico de Atualização do fluxo de dados navegando até um de seus fluxos de dados. Selecione Mais opções (...) para o fluxo de dados. Em seguida, escolha Configurações Histórico de atualização. Você também pode selecionar o fluxo de dados no Workspace. Em seguida, escolha Mais opções (...) > Histórico de atualização.

Captura de tela do histórico de atualização de fluxos de dados.

O Histórico de Atualização fornece uma visão geral das atualizações, incluindo o tipo – sob demanda ou agendado, a duração e o status da execução. Para ver detalhes na forma de um arquivo CSV, selecione o ícone de download à direita da linha da descrição da atualização. O CSV baixado inclui os atributos descritos na tabela a seguir. As atualizações Premium fornecem mais informações com base nos recursos extras de computação e fluxos de dados, em comparação com fluxos de dados baseados em Pro que residem na capacidade compartilhada. Dessa forma, algumas das métricas a seguir estão disponíveis apenas no Premium.

Item Description Pro Premium
Solicitado em A atualização de hora foi agendada ou a atualização agora foi clicada, no horário local. ✔ ✔
Nome do fluxo de dados Nome do fluxo de dados. ✔ ✔
Status da atualização do fluxo de dados Concluído, com falha ou ignorado (para uma entidade) são possíveis status. Casos de uso como Entidades Interligadas são motivos pelos quais algo pode ser ignorado. ✔ ✔
Nome da entidade Nome da tabela. ✔ ✔
Nome da partição Esse item dependerá se o fluxo de dados for premium ou não e se o Pro aparecer como NA porque ele não oferecer suporte a atualizações incrementais. Premium mostra FullRefreshPolicyPartition ou IncrementalRefreshPolicyPartition-[IntervaloDeDatas]. ✔
Atualizar status Atualize o status da entidade ou partição individual, que fornece o status para aquela porção temporal dos dados que está sendo atualizada. ✔ ✔
Hora de início No Premium, esse item é o tempo em que o fluxo de dados foi enfileirado para processamento da entidade ou partição. Esse tempo poderá ser diferente se os fluxos de dados tiverem dependências e precisarem aguardar o conjunto de resultados de um fluxo de dados upstream iniciar o processamento. ✔ ✔
Hora de término A hora de término é a hora em que a entidade ou partição do fluxo de dados é concluída, se aplicável. ✔ ✔
Duração Tempo total decorrido para que o fluxo de dados seja atualizado expresso em HH:MM:SS. ✔ ✔
Linhas processadas Para uma determinada entidade ou partição, o número de linhas digitalizadas ou gravadas pelo mecanismo de fluxos de dados. Esse item pode nem sempre conter dados com base na operação que você executou. Os dados podem ser omitidos quando o mecanismo de computação não é usado ou quando você usa um gateway à medida que os dados são processados lá. ✔
Bytes processados Para uma determinada entidade ou partição, dados gravados pelo mecanismo de fluxos de dados, expressos em bytes.

Ao usar um gateway nesse fluxo de dados específico, essas informações não são fornecidas.		 ✔
Confirmação máxima (KB) Max Commit é o pico de memória de compromisso útil para diagnosticar falhas de memória insuficiente quando a consulta M não é otimizada.

Quando você usa um gateway nesse fluxo de dados específico, essas informações não são fornecidas.		 ✔
Tempo do processador Para uma determinada entidade ou partição, o tempo, expresso em HH:MM:SS, que o mecanismo de fluxos de dados gastou para executar transformações.

Quando você usa um gateway nesse fluxo de dados específico, essas informações não são fornecidas.		 ✔
Tempo de espera Para uma determinada entidade ou partição, o tempo que uma entidade gastou no status de espera, com base na carga de trabalho na capacidade Premium. ✔
Mecanismo de computação Para uma determinada entidade ou partição, detalhes sobre como a operação de atualização usa o mecanismo de computação. Os valores são:
- ND
- Dobrado
- Cacheado
- Armazenado em cache + Dobrado

Esses elementos são descritos com mais detalhes posteriormente neste artigo.		 ✔
Erro Se aplicável, a mensagem de erro detalhada é descrita por entidade ou partição. ✔ ✔

Diretrizes de atualização de fluxo de dados

As estatísticas de atualização fornecem informações valiosas que você pode usar para otimizar e acelerar o desempenho de seus fluxos de dados. Nas seções a seguir, descrevemos alguns cenários, o que tomar cuidado e como otimizar com base nas informações fornecidas.

Orquestração

O uso de fluxos de dados no mesmo workspace permite uma orquestração simples. Por exemplo, você pode ter fluxos de dados A, B e C em um único workspace e encadeamento como A > B > C. Se você atualizar a origem (A), as entidades downstream também serão atualizadas. No entanto, se você atualizar C, então precisará atualizar os outros de forma independente. Além disso, se você adicionar uma nova fonte de dados no fluxo de dados B (que não está incluído em A), esses dados não serão atualizados como parte da orquestração.

Talvez você queira encadear itens que não se ajustem à orquestração gerenciada executada pelo Power BI. Nesses cenários, você pode usar as APIs e/ou usar o Power Automate. Você pode consultar a documentação da API e o script do PowerShell para atualização programática. Há um conector do Power Automate que permite fazer esse procedimento sem escrever nenhum código. Você pode ver exemplos detalhados, com passo a passo específicos para atualizações sequenciais.

Monitorização

Usando as estatísticas de atualização aprimoradas descritas anteriormente neste artigo, você pode obter informações detalhadas de atualização por fluxo de dados. Mas, se você quiser ver fluxos de dados com uma visão geral das atualizações em nível de locatário ou workspace para talvez criar um painel de monitoramento, pode usar as APIs ou os modelos do Power Automate. Da mesma forma, para casos de uso, como enviar notificações simples ou complexas, você pode usar o conector do Power Automate ou criar seu próprio aplicativo personalizado usando as APIs.

Erros de tempo limite

Otimizar o tempo necessário para executar cenários de ETL (extrair, transformar e carregar) é o ideal. No Power BI, os seguintes casos se aplicam:

  • Alguns conectores têm configurações de tempo limite explícitas que você pode definir. Para obter mais informações, consulte Conectores no Power Query.
  • Os fluxos de dados do Power BI, usando o Power BI Pro, também podem experimentar tempos limite para consultas de execução prolongada em uma entidade ou fluxos de dados em si. Essa limitação não existe nos workspaces do Power BI Premium.

Diretrizes de Tempo de Espera

Os limites de tempo limite para fluxos de dados do Power BI Pro são:

  • Duas horas no nível de entidade individual.
  • Três horas no nível completo do fluxo de dados.

Por exemplo, se você tiver um fluxo de dados com três tabelas, nenhuma tabela individual poderá levar mais de duas horas e todo o fluxo de dados atingirá o tempo limite se a duração exceder três horas.

Se você estiver enfrentando tempos limite, considere otimizar suas consultas de fluxo de dados e considere usar a dobra de consulta em seus sistemas de origem.

Além disso, considere fazer upgrade para Premium por Usuário, que não está sujeito a esses limites de tempo e oferece maior desempenho por causa de diversos recursos do Power BI Premium por Usuário.

Durações longas

Fluxos de dados complexos ou grandes podem levar mais tempo para serem atualizados, assim como fluxos de dados com otimização ruim. As seções a seguir fornecem diretrizes sobre como atenuar longas durações de atualização.

Diretrizes para longas durações de atualização

A primeira etapa para melhorar as longas durações de atualização para fluxos de dados é criar fluxos de dados de acordo com as práticas recomendadas. Os padrões notáveis incluem:

Em seguida, isso pode ajudar na avaliação da viabilidade do uso da atualização incremental.

Usar atualização incremental pode melhorar o desempenho. É importante que os filtros de partição sejam enviados por push para o sistema de origem quando as consultas são enviadas para operações de atualização. Para reduzir a filtragem por push, a fonte de dados deve dar suporte à dobragem de consultas ou você pode expressar a lógica de negócios por meio de uma função ou outros meios que podem ajudar o Power Query a eliminar e filtrar arquivos ou pastas. A maioria das fontes de dados que dão suporte a consultas SQL dão suporte à dobragem de consultas e alguns feeds OData também podem dar suporte à filtragem.

No entanto, fontes de dados como arquivos simples, blobs e APIs normalmente não dão suporte à filtragem. Nos casos em que o back-end da fonte de dados não dá suporte ao filtro, ele não pode ser propagado até os níveis inferiores. Nesses casos, o mecanismo de mash-up compensa e aplica o filtro localmente, o que pode exigir a recuperação do modelo semântico completo da fonte de dados. Essa operação pode fazer com que a atualização incremental seja lenta e o processo pode ficar sem recursos no serviço do Power BI ou no gateway de dados local, se usado.

Considerando os vários níveis de suporte à dobra de consulta para cada fonte de dados, você deve executar a verificação para garantir que a lógica de filtro seja incluída nas consultas de origem. Para facilitar isso, o Power BI tenta executar essa verificação para você, com indicadores de dobragem de etapas para o Power Query Online. Muitas dessas otimizações são experiências durante o design, mas depois que ocorre uma atualização, você tem a oportunidade de analisar e otimizar o desempenho do processo de atualização.

Por fim, considere otimizar seu ambiente. Você pode otimizar o ambiente do Power BI aumentando sua capacidade, dimensionando corretamente os gateways de dados e reduzindo a latência de rede com as seguintes otimizações:

  • Ao usar as capacidades disponíveis com o Power BI Premium ou Premium por Usuário, você pode aumentar o desempenho aumentando sua instância Premium ou atribuindo o conteúdo a uma capacidade diferente.

  • Um gateway é necessário sempre que o Power BI precisa acessar dados que não estão disponíveis diretamente pela Internet. Você pode instalar o gateway de dados local em um servidor local ou em uma máquina virtual.

    • Para entender as cargas de trabalho de gateway e as recomendações de dimensionamento, consulte o dimensionamento do gateway de dados local.
    • Avalie também colocar os dados primeiro em um fluxo de dados de preparo e referenciá-los downstream usando entidades vinculadas e computadas.

  • A latência de rede pode afetar o desempenho de atualização aumentando o tempo necessário para que as solicitações cheguem ao serviço do Power BI e para que as respostas sejam entregues. Os locatários no Power BI são atribuídos a uma região específica. Para determinar onde seu locatário está localizado, consulte Localizar a região padrão para sua organização. Quando os usuários de um locatário acessam o serviço do Power BI, suas solicitações sempre roteiam para essa região. À medida que as solicitações chegam ao serviço do Power BI, o serviço pode enviar solicitações extras, por exemplo, para a fonte de dados subjacente ou um gateway de dados, que também estão sujeitos à latência de rede.

    • Ferramentas como o Teste de Velocidade do Azure fornecem uma indicação de latência de rede entre o cliente e a região do Azure. Em geral, para minimizar o impacto da latência de rede, procure manter as fontes de dados, os gateways e o cluster do Power BI o mais próximo possível. Residir na mesma região é preferível. Se a latência de rede for um problema, tente localizar gateways e fontes de dados mais próximas do cluster do Power BI colocando-os dentro de máquinas virtuais hospedadas na nuvem.

Tempo alto do processador

Se você perceber um uso elevado do processador, provavelmente terá transformações caras que não estão sendo otimizadas. O tempo alto do processador é devido ao número de etapas aplicadas que você tem ou ao tipo de transformações que você está fazendo. Cada uma dessas possibilidades pode resultar em tempos de atualização mais altos.

Orientações para o alto uso de tempo de processamento

Há duas opções para otimizar o tempo alto do processador.

Primeiro, utilize a dobra de consultas na fonte de dados em si, o que deve diminuir diretamente a carga no mecanismo de computação do fluxo de dados. O dobramento de consulta na fonte de dados permite que o sistema de origem faça a maior parte do trabalho. O fluxo de dados pode passar por consultas no idioma nativo da origem, em vez de ter que executar todos os cálculos na memória após a consulta inicial.

Nem todas as fontes de dados suportam o encadeamento de consultas e, mesmo quando o encadeamento de consultas é viável, pode haver dataflows que realizam determinadas transformações que não podem ser integradas de volta à origem. Nesses casos, o mecanismo de computação aprimorado é uma funcionalidade introduzida pelo Power BI para potencialmente melhorar o desempenho em até 25 vezes, especificamente para transformações.

Usar o mecanismo de computação para maximizar o desempenho

Embora o Power Query tenha visibilidade de tempo de design na dobragem de consultas, a coluna do mecanismo de computação fornece detalhes sobre se o próprio mecanismo interno é usado. O mecanismo de computação é útil quando você tem um fluxo de dados complexo e está executando transformações na memória. Essa situação é onde as estatísticas de atualização aprimoradas podem ser úteis, já que a coluna do mecanismo de computação fornece detalhes sobre se o próprio mecanismo foi usado ou não.

As seções a seguir fornecem diretrizes sobre como usar o mecanismo de computação e suas estatísticas.

Aviso

Durante o tempo de design, o indicador de dobra no editor pode mostrar que a consulta não é dobrada ao consumir dados de outro fluxo de dados. Verifique se a computação aprimorada está habilitada no fluxo de dados de origem para garantir que o dobramento no fluxo de dados de origem esteja habilitado.

Diretrizes sobre status do motor de computação

Ativar o mecanismo de computação aprimorado e entender os vários status é útil. Internamente, o mecanismo de computação aprimorado usa um banco de dados SQL para ler e armazenar dados. É melhor executar suas transformações no mecanismo de consulta aqui. Os parágrafos a seguir fornecem várias situações e orientações sobre o que fazer para cada um.

NA - Esse status significa que o mecanismo de computação também não foi usado porque:

  • Você está usando fluxos de dados do Power BI Pro.
  • Você desativou explicitamente o mecanismo de computação.
  • Você está usando o dobramento de consulta na fonte de dados.
  • Você está executando transformações complexas que não podem usar o mecanismo SQL usado para acelerar as consultas.

Se você estiver enfrentando longas durações e ainda obter um status de NA, verifique se ele está ativado e não está desativado acidentalmente. Um padrão recomendado é usar fluxos de dados de preparo para inicialmente colocar seus dados no serviço do Power BI e, em seguida, criar fluxos de dados sobre esses dados, depois que eles estiverem em um fluxo de dados de preparo. Esse padrão pode reduzir a carga em sistemas de origem e, juntamente com o mecanismo de computação, fornecer um aumento de velocidade para transformações e melhorar o desempenho.

Armazenados em cache – se você vir o status armazenado em cache , os dados de fluxo de dados foram armazenados no mecanismo de computação e disponíveis para serem referenciados como parte de outra consulta. Essa situação é ideal se você estiver usando-a como uma entidade vinculada, pois o mecanismo de computação armazena esses dados em cache para uso downstream. Os dados armazenados em cache não precisam ser atualizados várias vezes no mesmo fluxo de dados. Essa situação também é potencialmente ideal se você quiser usá-la para o DirectQuery.

Quando armazenado em cache, o impacto no desempenho na ingestão inicial compensa mais tarde, no mesmo fluxo de dados ou em um fluxo de dados diferente no mesmo workspace.

Se você tiver uma duração grande para a entidade, considere desativar o mecanismo de computação. Para armazenar em cache a entidade, o Power BI a grava em armazenamento e no banco de dados SQL. Se for uma entidade de uso único, o benefício de desempenho para os usuários pode não valer a pena da ingestão dupla.

Folded – Folded significa que o fluxo de dados foi capaz de usar a computação SQL para ler dados. A entidade calculada usou a tabela do SQL para ler dados e o SQL usado está relacionado aos constructos de sua consulta.

O status dobrado será exibido se, quando você estiver usando fontes de dados locais ou de nuvem, você carregou os dados primeiro em um fluxo de dados de preparo e referenciou isso nesse fluxo de dados. Esse status se aplica apenas a entidades que fazem referência a outra entidade. Isso significa que suas consultas foram executadas em cima do mecanismo SQL e elas têm o potencial de serem aprimoradas com a computação SQL. Para garantir que o mecanismo SQL processe suas transformações, use transformações que dão suporte à dobra do SQL, como mesclagem (junção), agrupar por (agregação) e acrescentar ações (união) no Editor de Consultas.

Armazenado em cache + Agrupado – quando você vê armazenado em cache + agrupado, é provável que a atualização de dados seja otimizada, pois você tem uma entidade que faz referência a outra entidade e é referenciada por outra entidade anterior no fluxo de processamento. Essa operação também é executada em cima do SQL e, como tal, também tem o potencial de aprimoramento com a computação SQL. Para ter certeza de que você está obtendo o melhor desempenho possível, use transformações que dão suporte à dobra do SQL, como mesclagem (junção), agrupar por (agregação) e acrescentar ações (união) no Editor de Consultas.

Diretrizes para otimização de desempenho do mecanismo de computação

As etapas a seguir permitem que as cargas de trabalho disparem o mecanismo de computação e, assim, sempre melhorem o desempenho.

Entidades computadas e vinculadas no mesmo workspace:

Para ingestão, concentre-se em colocar os dados no armazenamento o mais rápido possível, use filtros somente se eles reduzirem o tamanho geral do modelo semântico. Mantenha sua lógica de transformação separada desta etapa. Em seguida, separe sua transformação e lógica de negócios em um fluxo de dados separado no mesmo espaço de trabalho. Use entidades vinculadas ou computadas. Isso permite que o mecanismo ative e acelere seus cálculos. Para uma analogia simples, é como a preparação de alimentos em uma cozinha: a preparação de alimentos é tipicamente um passo separado e distinto da coleta de seus ingredientes crus, e um pré-requisito para colocar a comida no forno. Da mesma forma, você precisa preparar sua lógica separadamente antes que ela possa tirar proveito do mecanismo de computação.

Verifique se você executa as operações que dobram, como mesclagens, junções, conversão e outras.

Além disso, crie fluxos de dados dentro de diretrizes e limitações publicadas.

Quando o mecanismo de computação está ativado, mas o desempenho é lento:

Execute as seguintes etapas ao investigar cenários em que o mecanismo de computação está ativado, mas você está vendo um desempenho ruim:

  • Limite entidades computadas e vinculadas que existem em todo o workspace.
  • Se a atualização inicial for feita com o engine de computação ativado, os dados serão gravados no lago e no cache. Essa gravação dupla faz com que as atualizações sejam mais lentas.
  • Se você tiver um fluxo de dados vinculado a vários fluxos de dados, agende atualizações dos fluxos de dados de origem para que eles não sejam atualizados ao mesmo tempo.

Considerações e limitações

Uma licença do Power BI Pro tem um limite de atualização de fluxos de dados de 8 atualizações por dia.

Conteúdo relacionado

  • Last updated on