Conectores do Power BI: como escolher a fonte, o modo e o gateway
Autor: Pedro Tebaldi PM do KeepGreenA escolha do conector parece um detalhe de duas telas: selecionar a fonte, informar a credencial, carregar. Na prática, essa escolha define quatro coisas: o modo de armazenamento do modelo, a necessidade de gateway, a duração da atualização e o volume suportado.
Um relatório que atualiza em 3 minutos e outro que trava em 40 costumam ler a mesma fonte. A diferença nasce no conector escolhido e nas etapas de transformação aplicadas depois dele.
Por isso, este artigo trata da decisão, não do catálogo. Ele cobre o que muda entre os modos de conectividade e quando o gateway entra na conta. Também trata do que faz o query folding parar e de como avaliar um conector personalizado.
O que um conector do Power BI decide
Um conector do Power BI é o componente do Power Query que traduz a estrutura de uma fonte específica em tabelas do modelo. Junto com ele vêm três decisões. São elas: quais modos de conectividade a fonte aceita, quais operações vão para o servidor de origem e quais autenticações ficam disponíveis.
A lista oficial cobre arquivo local, banco relacional, serviço do Azure, plataforma SaaS e endpoint genérico via API ou OData. A tabela mantida pela Microsoft mostra, item por item, onde cada um funciona: modelo semântico, fluxo de dados, Fabric ou Analysis Services.
Nem todo conector aparece em todos esses destinos. Um que funciona no Power BI Desktop pode não estar disponível em fluxo de dados do Microsoft Fabric. A checagem custa dois minutos e evita retrabalho no meio do projeto.
Import, DirectQuery ou conexão dinâmica: o modo pesa mais que o conector
Antes de tudo, o modo de conectividade determina onde a consulta roda. No Import, o Power BI copia os dados para o modelo em memória e responde de lá. No DirectQuery, cada interação do usuário vira consulta na fonte. Na conexão dinâmica, o modelo semântico já existe fora e o relatório apenas o consome.
| Dimensão | Import | DirectQuery |
|---|---|---|
| Onde a consulta roda | No modelo em memória, comprimido pelo VertiPaq | Na fonte, a cada clique de filtro ou segmentação |
| Latência de leitura | Milissegundos, independente da fonte | Herda latência e concorrência do banco de origem |
| Frescor do dado | Idade do último refresh agendado | Estado atual da fonte |
| Volume suportado | Limitado pelo tamanho de modelo da sua licença | Limitado pela capacidade da fonte de responder |
| Transformação no Power Query | Qualquer etapa. O custo é pago uma vez, no refresh | Só o que faz folding. O resto é bloqueado ou penaliza cada consulta |
| Recursos de DAX | Conjunto completo | Subconjunto, com funções de tempo e texto restritas |
| Gateway para fonte local | Necessário no refresh agendado | Necessário em toda consulta, sempre no caminho crítico |
A regra prática cabe em duas linhas. Use Import quando a janela de atualização aceita dado com algumas horas de idade, que é o caso da maioria dos painéis gerenciais. Reserve o DirectQuery para o que precisa refletir o estado atual da operação, como estoque, fila de atendimento ou posição de caixa.
Os limites de tamanho de modelo e a frequência de atualização dependem do plano contratado. Esse recorte fica no artigo de licenciamento do Power BI, que detalha o que muda entre as licenças por usuário e as por capacidade.
Além disso, a documentação de referência do modo direto lista as restrições que ele impõe ao modelo. Vale ler antes de prometer tempo real ao time de negócio.
Quando o gateway de dados local é obrigatório
O gateway de dados local entra sempre que a fonte não é alcançável pela internet pública a partir do serviço do Power BI. Banco no datacenter, arquivo em compartilhamento de rede e sistema atrás de firewall dependem dele. Fonte em nuvem com endpoint público dispensa o gateway, desde que a autenticação seja aceita pelo serviço.
Entretanto, há um detalhe que costuma passar: no Power BI Desktop tudo funciona sem gateway, porque a consulta sai da máquina do analista. O erro aparece só depois da publicação, quando o serviço tenta atualizar e não enxerga a fonte. Teste a atualização no serviço antes de declarar o relatório pronto.
Vale separar os dois modos de instalação. O modo padrão é compartilhado entre usuários e suporta atualização agendada mais DirectQuery. Já o modo pessoal serve apenas para atualização agendada de quem instalou, o que o torna impróprio para relatório corporativo.
O gateway é servidor de produção
Na prática, a máquina do gateway vira um funil por onde passa toda a atualização de dados da empresa. Ainda assim, quase nunca entra no inventário de monitoramento. Quando ela fica sem memória, sem espaço em disco de spool ou fora do ar, todo painel corporativo para junto.
Trate o gateway como qualquer nó do pipeline de dados. Acompanhe CPU, memória, fila de atualizações, tempo de resposta por fonte e o status do serviço. Configure alerta de falha de refresh por origem, em vez de descobrir pelo usuário que abriu o relatório na segunda-feira.
Query folding: por que o mesmo conector atualiza em 3 ou em 40 minutos
Query folding é a capacidade do Power Query de converter as etapas de transformação em uma única consulta nativa, executada dentro da fonte. Com folding, o banco filtra, agrupa e devolve o resultado pronto. Sem folding, o Power BI baixa tudo e processa localmente. É aí que o refresh estoura.
Assim, o conector determina até onde a dobra chega. Conectores de banco relacional traduzem a maior parte das etapas para SQL. Conectores de arquivo e de API não têm para onde empurrar. Toda transformação roda no motor do Power Query, seja na sua máquina ou na capacidade do serviço.
Verifique isso antes de otimizar qualquer outra coisa. No editor do Power Query, clique com o botão direito em uma etapa e procure por “Exibir Consulta Nativa”. Quando a opção fica esmaecida, a dobra parou naquele ponto.
Em seguida, confirme o comportamento esperado de cada operação na referência oficial sobre o assunto.
As etapas que quebram o folding
Adicionar coluna de índice, mesclar tabelas de fontes diferentes e aplicar Table.Buffer estão entre as causas mais comuns. Função personalizada em M e ordenação antes do filtro também derrubam a dobra. Todas parecem inofensivas na tela do editor.
A ordem também importa. Uma etapa que quebra a dobra derruba tudo que vem depois dela, mesmo que as etapas seguintes fossem traduzíveis.
Por isso, empurre filtro, seleção de colunas e agrupamento para o começo da consulta. Deixe o que não dobra para o fim. Esse rearranjo costuma render mais que qualquer ajuste posterior de performance no relatório.
Homologado, de parceiro ou personalizado: como avaliar
Os conectores homologados pela Microsoft chegam prontos na instalação e são atualizados com o produto. Os de parceiro certificado também vêm embutidos, porém o ciclo de correção depende do fornecedor. Já o personalizado é um arquivo .mez feito com o SDK do Power Query, mantido pela sua equipe.
Por outro lado, o conector personalizado resolve o caso em que a fonte não tem conector nenhum, tipicamente uma API interna ou um sistema legado. O custo aparece depois. Ele exige gateway em modo personalizado, não recebe correção da Microsoft e quebra quando a API de origem muda de contrato.
Antes de partir para o caminho personalizado, teste o conector genérico de web ou de OData. Boa parte das APIs REST responde bem a ele, incluindo as paginadas. Gravamos há alguns anos um passo a passo de integração de API paginada. A interface mudou desde então, contudo a lógica de paginação continua a mesma.
Checagem antes de fechar a escolha
Por fim, cinco perguntas separam a escolha bem feita da que vira chamado três meses depois. Responda todas antes de publicar o modelo.
| Pergunta | Onde verificar | O que muda na decisão |
|---|---|---|
| O conector existe no destino certo? | Tabela oficial: modelo semântico, fluxo de dados, Fabric, Analysis Services | Se falta no destino, a arquitetura do projeto muda antes de começar |
| Qual modo a fonte aceita? | Tela de conexão do Desktop, no momento da seleção | Sem DirectQuery, dado em tempo real deixa de ser opção |
| A fonte é alcançável pelo serviço? | Teste de atualização no serviço, não só no Desktop | Define se o gateway entra e quem passa a operá-lo |
| As etapas fazem folding? | Exibir Consulta Nativa na última etapa |
Sem dobra, a janela de atualização cresce com o volume |
| Quem mantém esse conector? | Microsoft, parceiro certificado ou a sua própria equipe | Define para quem vai o chamado quando a fonte mudar de contrato |
Essa checagem também é matéria de governança de dados. Um inventário de quais modelos leem quais fontes, por qual conector e sob qual credencial resolve em minutos uma pergunta cara. A pergunta é simples: quem quebra quando esse banco sair do ar?
Transformamos dados brutos em decisões estratégicas e insights.
Construímos dashboards interativos, KPIs e relatórios automatizados integrados às suas fontes de dados existentes.
Onde a decisão realmente acontece
A escolha do conector não é a primeira tela do projeto. Ela é a consequência de três respostas anteriores: o frescor exigido pelo negócio, onde a fonte mora e quem sustenta a atualização em produção.
Portanto, quem responde a essas três antes de conectar acerta o modo na primeira tentativa. Quem começa pelo botão “Obter dados” descobre a resposta pelo caminho caro. São três sintomas: refresh estourando a janela, gateway sem dono e modelo refeito no trimestre seguinte.
Em resumo, o conector é a menor parte visível de uma decisão de arquitetura. Se a sua operação está nesse ponto, vale desenhar isso com quem já fez. Painéis de business intelligence costumam crescer mais rápido que a estrutura que os alimenta. Fale com um especialista da OpServices para avaliar o seu cenário de dados.
Perguntas Frequentes
Qual a diferença entre Import e DirectQuery no Power BI?
Quando é necessário o gateway de dados local?
O Power BI se conecta a qualquer API?
OData cobrem boa parte das APIs REST, incluindo as paginadas. A autenticação pode ser anônima, básica, por chave ou por conta organizacional. O trabalho costuma ficar no tratamento da paginação e na normalização do JSON aninhado. Quando a API exige um fluxo de autenticação que o conector genérico não suporta, o caminho passa a ser um conector personalizado. O mesmo vale para lógica de paginação muito específica.O que fazer quando o conector desejado não existe?
OData e o de ODBC. Os três resolvem a maioria dos casos sem código. Se nenhum servir, avalie extrair os dados para uma camada intermediária, como um banco ou um lakehouse. O Power BI passa a ler essa camada, não a origem. O conector personalizado em arquivo mez fica como última opção. Ele exige gateway em modo personalizado, não recebe correção da Microsoft e quebra quando a API muda de contrato.
