Compreender 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álises downstream. Um elemento-chave nos fluxos de dados é o processo de atualização, que aplica as etapas de transformação criadas 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 seu fluxo de dados, você pode baixar o histórico de atualizações depois de atualizar um fluxo de dados.
Compreender as atualizações
Há dois tipos de atualizações aplicáveis aos fluxos de dados:
Full, que realiza uma descarga completa e recarga dos seus dados.
Incremental (somente Premium), que processa um subconjunto de seus dados com base em regras baseadas no 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 altera automaticamente a consulta para incluir a filtragem por data. Pode editar a consulta gerada automaticamente utilizando o Editor Avançado no Power Query para ajustar ou personalizar a sua atualização. Se você trouxer seu próprio Armazenamento do Azure Data Lake, poderá ver fatias de tempo de seus dados com base na política de atualização que você definiu.
Nota
Para saber mais sobre a atualização incremental e como ela funciona, consulte Usando 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 partições N especificadas pelo usuário (onde 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, atualizar apenas os últimos cinco dias de um modelo semântico de 10 anos.
- O Power BI apenas atualiza os dados que foram alterados, desde que especifique a coluna que pretende verificar se existem alterações.
As atualizações são mais confiáveis - não é mais necessário manter conexões de longa duraçã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 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ê pode atualizá-los manualmente e eles podem 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á. Dito 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.
Compreender e otimizar atualizações
Para entender melhor como uma operação de atualização de fluxo de dados é executada, revise 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 > Atualizar histórico. Você também pode selecionar o fluxo de dados no espaço de trabalho. Em seguida, escolha Mais opções (...) > Atualize o histórico.
O Histórico de atualizações fornece uma visão geral das atualizações, incluindo o tipo – sob demanda ou agendado, a duração e o status de execução. Para ver os detalhes na forma de um arquivo CSV, selecione o ícone de download na extremidade 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 os fluxos de dados baseados em Pro que residem na capacidade compartilhada. Como tal, algumas das seguintes métricas 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 seu fluxo de dados. | ✔ | ✔ |
| Status de atualização do fluxo de dados | Concluído, Reprovado ou Ignorado (para uma entidade) são status possíveis. Casos de uso como Entidades Vinculadas são motivos pelos quais alguém pode ver ignorado. | ✔ | ✔ |
| Nome da entidade | Nome da tabela. | ✔ | ✔ |
| Nome da partição | Este item depende se o fluxo de dados é premium ou não, e se Pro mostra como NA porque não suporta atualizações incrementais. Premium mostra FullRefreshPolicyPartition ou IncrementalRefreshPolicyPartition-[DateRange]. | ✔ | |
| Atualizar status | Atualizar o status da entidade ou partição individual, que fornece o status para essa fatia de tempo dos dados que estão sendo atualizados. | ✔ | ✔ |
| Hora de início | No Premium, esse item é o tempo em que o fluxo de dados foi enfileirado para processamento para a entidade ou partição. Esse tempo pode diferir se os fluxos de dados tiverem dependências e precisarem aguardar o conjunto de resultados de um fluxo de dados upstream para iniciar o processamento. | ✔ | ✔ |
| Hora de fim | Hora de término é a hora em que a entidade ou partição de fluxo de dados foi concluída, se aplicável. | ✔ | ✔ |
| Duration | Tempo total decorrido para a atualização do fluxo de dados 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. Este item pode nem sempre conter dados com base na operação executada. 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 é a memória de confirmação de pico útil para diagnosticar falhas de falta de memória quando a consulta M não está otimizada. Quando você usa um gateway nesse fluxo de dados específico, essas informações não são fornecidas. |
✔ | |
| Hora do Processador | Para uma determinada entidade ou partição, tempo, expresso em HH:MM:SS que o mecanismo de fluxos de dados passou executando 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 passou 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: - NA - Dobrado - Armazenado em cache - Cache + Dobrado Esses elementos são descritos com mais detalhes mais adiante neste artigo. |
✔ | |
| Error | 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 observar e como otimizar com base nas informações fornecidas.
Orquestração
O uso de fluxos de dados no mesmo espaço de trabalho permite uma orquestração simples. Como exemplo, você pode ter fluxos de dados A, B e C em um único espaço de trabalho e encadeamento como A > B > C. Se você atualizar a fonte (A), as entidades a jusante também serão atualizadas. No entanto, se você atualizar C, então você tem que atualizar os outros independentemente. 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 encaixam na 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 Power Automate que permite fazer esse procedimento sem escrever nenhum código. Você pode ver exemplos detalhados, com instruções específicas 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 de atualizações em todo o locatário ou em todo o espaço de trabalho, talvez para criar um painel de monitoramento, você pode usar as APIs ou os modelos PowerAutomatic. Da mesma forma, para casos de uso, como o envio de notificações simples ou complexas, você pode usar o conector PowerAutomate ou criar seu próprio aplicativo personalizado usando as APIs.
Erros de tempo limite
Otimizar o tempo necessário para executar cenários de extração, transformação e carregamento (ETL) é ideal. No Power BI, aplicam-se os seguintes casos:
- Alguns conectores têm configurações explícitas de tempo limite que você pode configurar. 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 enfrentar tempos limite para consultas de longa execução dentro de uma entidade ou dos próprios fluxos de dados. Essa limitação não existe nos espaços de trabalho do Power BI Premium.
Orientações de tempo limite
Os limites de tempo limite para fluxos de dados do Power BI Pro são:
- Duas horas a nível de entidade individual.
- Três horas em todo o nível de 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 expirará se a duração exceder três horas.
Se você estiver enfrentando tempos limites, considere otimizar suas consultas de fluxo de dados e considere o uso de dobramento de consulta em seus sistemas de origem.
Separadamente, considere atualizar para Premium Por Usuário, que não está sujeito a esses tempos limite e oferece maior desempenho devido a muitos recursos do Power BI Premium Por Usuário.
Longas durações
Fluxos de dados complexos ou grandes podem levar mais tempo para serem atualizados, assim como fluxos de dados mal otimizados. As seções a seguir fornecem orientação sobre como reduzir as longas durações de atualização.
Orientação para longas durações de atualização
A primeira etapa para melhorar as durações de atualização longas para fluxos de dados é criar fluxos de dados de acordo com as práticas recomendadas. Padrões notáveis incluem:
- Use entidades vinculadas para dados que podem ser usados posteriormente em outras transformações.
- Use entidades computadas para armazenar dados em cache, reduzindo o carregamento de dados e a carga de ingestão de dados nos sistemas de origem.
- Divida os dados em fluxos de dados de preparo e fluxos de dados de transformação, separando o ETL em diferentes fluxos de dados.
- Otimize as operações de tabela em expansão.
- Siga as orientações para fluxos de dados complexos.
Em seguida, ele pode ajudar a avaliar se você pode usar a atualização incremental.
O uso da 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 forem enviadas para operações de atualização. Empurrar a filtragem para baixo significa que a fonte de dados deve suportar dobragem de consulta ou você pode expressar a lógica de negócios por meio de uma função ou outros meios que possam ajudar o Power Query a eliminar e filtrar arquivos ou pastas. A maioria das fontes de dados que oferecem suporte a consultas SQL oferecem suporte ao dobramento de consultas, e alguns feeds OData também podem oferecer suporte à filtragem.
No entanto, fontes de dados como arquivos simples, blobs e APIs normalmente não oferecem suporte à filtragem. Nos casos em que o back-end da fonte de dados não suporta o filtro, ele não pode ser empurrado para baixo. 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.
Dados os vários níveis de suporte a dobragem de consulta para cada fonte de dados, você deve executar a verificação para garantir que a lógica do filtro seja incluída nas consultas de origem. Para tornar isso mais fácil, 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 em tempo de design, mas depois que uma atualização ocorre, você tem a oportunidade de analisar e otimizar seu desempenho de atualização.
Por fim, considere otimizar seu ambiente. Você pode otimizar o ambiente do Power BI dimensionando sua capacidade, dimensionando corretamente os gateways de dados e reduzindo a latência da 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 do gateway e as recomendações de dimensionamento, consulte Dimensionamento do gateway de dados local.
- Avalie também trazer os dados primeiro para um fluxo de dados de preparo e fazer referência a jusante usando entidades vinculadas e computadas.
A latência da rede pode afetar o desempenho da 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 são encaminhadas 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 para um gateway de dados, que também estão sujeitos à latência da rede.
- Ferramentas como o Teste de Velocidade do Azure fornecem uma indicação da latência da rede entre o cliente e a região do Azure. Em geral, para minimizar o impacto da latência da rede, esforce-se para manter as fontes de dados, gateways e seu cluster do Power BI o mais próximo possível. É preferível residir na mesma região. Se a latência da rede for um problema, tente localizar gateways e fontes de dados mais próximos do cluster do Power BI colocando-os dentro de máquinas virtuais hospedadas na nuvem.
Tempo de processador elevado
Se você vir um tempo de processador alto, provavelmente terá transformações caras que não estão sendo dobradas. O alto tempo 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ção para alto tempo de processador
Há duas opções para otimizar o alto tempo do processador.
Primeiro, use dobramento de consulta dentro da própria fonte de dados, o que deve reduzir a carga no mecanismo de computação de fluxo de dados diretamente. A dobragem de consultas dentro da fonte de dados permite que o sistema de origem faça a maior parte do trabalho. O fluxo de dados pode então passar por consultas no idioma nativo da fonte, em vez de ter que executar todos os cálculos na memória após a consulta inicial.
Nem todas as fontes de dados podem executar dobragem de consulta e, mesmo quando a dobragem de consulta é possível, pode haver fluxos de dados que executam determinadas transformações que não podem dobrar para a fonte. Nesses casos, o mecanismo de computação aprimorado é um recurso introduzido pelo Power BI para potencialmente melhorar o desempenho em até 25 vezes, especificamente para transformações.
Use o mecanismo de computação para maximizar o desempenho
Enquanto o Power Query tem visibilidade em 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, uma vez que a coluna do mecanismo de computação fornece detalhes sobre se o mecanismo em si foi usado ou não.
As seções a seguir fornecem orientação sobre como usar o mecanismo de computação e suas estatísticas.
Aviso
Durante o tempo de design, o indicador de dobragem no editor pode mostrar que a consulta não dobra ao consumir dados de outro fluxo de dados. Verifique o fluxo de dados de origem se a computação aprimorada estiver habilitada para garantir que a dobragem no fluxo de dados de origem esteja habilitada.
Orientação sobre status do mecanismo de computação
Ligar 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 que suas transformações sejam executadas no mecanismo de consulta aqui. Os parágrafos seguintes fornecem várias situações e orientações sobre o que fazer para cada uma delas.
NA - Este status significa que o mecanismo de computação não foi usado, também porque:
- Você está usando fluxos de dados do Power BI Pro.
- Você desativou explicitamente o mecanismo de computação.
- Você está usando dobragem de consulta na fonte de dados.
- Você está executando transformações complexas que não podem usar o mecanismo SQL usado para acelerar consultas.
Se você estiver enfrentando longas durações e ainda obtiver um status de NA, certifique-se de que ele esteja ligado e não acidentalmente desligado. 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 nos sistemas de origem e, juntamente com o mecanismo de computação, fornecer um aumento de velocidade para transformações e melhorar o desempenho.
Armazenado em cache - Se você vir o status 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-o como uma entidade vinculada, porque o mecanismo de computação armazena em cache esses dados para uso a jusante. 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á-lo para 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 espaço de trabalho.
Se você tiver uma grande duração para a entidade, considere desativar o mecanismo de computação. Para armazenar a entidade em cache, o Power BI grava-a no armazenamento e no SQL. Se for uma entidade de uso único, o benefício de desempenho para os usuários pode não valer a pena da dupla ingestão.
Dobrado - Dobrado 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 às construções de sua consulta.
O status dobrado aparece se, ao usar fontes de dados locais ou na nuvem, você primeiro carregou dados em um fluxo de dados de preparo e fez referência a isso nesse fluxo de dados. Este estatuto aplica-se apenas a entidades que façam referência a outra entidade. Isso significa que suas consultas foram executadas sobre o mecanismo SQL e elas têm o potencial de serem melhoradas com a computação SQL. Para garantir que o mecanismo SQL processe suas transformações, use transformações que ofereçam suporte à dobragem SQL, como ações de mesclagem (junção), agrupamento por (agregação) e acréscimo (união) no Editor de Consultas.
Armazenado em cache + dobrado - Quando você vê armazenado em cache + dobrado, é provável que a atualização de dados seja otimizada, pois você tem uma entidade que faz referência a outra entidade e é referida por outra entidade a montante. Esta operação também é executada em cima do SQL e, como tal, também tem o potencial de melhoria com a computação SQL. Para ter certeza de que você está obtendo o melhor desempenho possível, use transformações que ofereçam suporte à dobragem SQL, como ações de mesclagem (junção), agrupamento por (agregação) e acréscimo (união) no Editor de Consultas.
Orientação para otimização do desempenho do mecanismo de computação
As etapas a seguir permitem que as cargas de trabalho acionem o mecanismo de computação e, assim, sempre melhorem o desempenho.
Entidades computadas e vinculadas no mesmo espaço de trabalho:
Para ingestão, concentre-se em colocar os dados no armazenamento o mais rápido possível, use filtros apenas 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 é normalmente uma etapa separada e distinta da coleta de seus ingredientes crus, e um pré-requisito para colocar os alimentos no forno. Da mesma forma, você precisa preparar sua lógica separadamente antes que ela possa tirar proveito do mecanismo de computação.
Certifique-se de executar as operações que dobram, como mesclagens, junções, conversões e outras.
Além disso, crie fluxos de dados dentro das diretrizes e limitações publicadas.
Quando o mecanismo de computação está ativado, mas o desempenho está lento:
Siga 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 no espaço de trabalho.
- Se a atualização inicial estiver com o mecanismo de computação ativado, os dados serão gravados no lago e no cache. Essa gravação dupla resulta em atualizações mais lentas.
- Se você tiver um fluxo de dados vinculando a vários fluxos de dados, certifique-se de agendar atualizações dos fluxos de dados de origem para que eles não sejam todos 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.