O Power Query sempre foi o alicerce da preparação de dados no ecossistema Microsoft, do Excel ao Power BI. Recentemente, a Microsoft iniciou a transição desse componente para um motor de transformação de dados totalmente programável através do Microsoft Fabric. A introdução de uma API de execução pública para o Power Query (em preview) não é apenas uma atualização de feature; é uma mudança de paradigma para engenheiros de dados que buscam maior automação e reuso de lógica.
Historicamente, a avaliação de queries estava limitada a fluxos de atualização de dataflows ou a interfaces interativas. Permitir que o código 'M' seja disparado via chamadas REST abre portas para integrações complexas onde a lógica de ETL (Extract, Transform, Load) pode ser orquestrada fora das amarras tradicionais, permitindo chamadas on-demand a partir de pipelines, aplicações customizadas ou notebooks.
Por que isso altera o jogo para times de engenharia
A grande vantagem estratégica aqui é a consolidação do Power Query como um first-class compute engine dentro do Fabric. Ao elevar a linguagem M a nível de API, os times podem obter:
- Automação de alto nível: Trigger de transformações diretamente via pipeline ou código, removendo a necessidade de intervenção manual nos dataflows.
- Interoperabilidade: A capacidade de invocar o motor de mashup do Power Query e receber resultados em formatos otimizados, como Apache Arrow, facilita a integração com fluxos de trabalho em Spark, Python e SQL.
- Reuso de Código: A padronização de scripts M através de repositórios Git, integrando práticas de CI/CD, permite que a mesma lógica de transformação seja aplicada em diferentes surfaces do Fabric.
- Conectividade híbrida: A integração com gateways permite que o processamento programático alcance dados on-premises ou em redes privadas, trazendo a capacidade de transformação in-cloud para ambientes legados.
Considerações de Implementação
Para times que buscam adotar essa abordagem, é essencial observar o comportamento da engine. O fluxo principal envolve autenticação via Azure Active Directory (token de acesso para https://analysis.windows.net/powerbi/api/) seguido pela requisição POST ao endpoint de executeQuery.
Para quem opera em ambientes críticos, fica o alerta sobre as limitações atuais da versão preview:
- SLA de Performance: Existe um timeout restrito de 90 segundos. Isso é um sinal claro de que essa funcionalidade deve ser utilizada para transformações modulares e rápidas, não para processamento de bulk pesado de longa duração.
- Imutabilidade: O motor é focado estritamente em leitura (read-only). O objetivo não é substituir pipelines de escrita ou o COPY, mas permitir a leitura e transformação dinâmica.
- Complexidade dos Conectores: Nem todos os conectores do Power Query, especialmente em modo headless via API, possuem suporte total. Testes exaustivos em cenários de rede privada são recomendados antes de colocar em produção.
- FinOps e Custo: A precificação segue a métrica de execução do Dataflow Gen2. Como cada chamada consome capacidade, o monitoramento via Capacity Metrics App é vital para evitar surpresas no custo operacional.
Em resumo, essa API torna o desenvolvimento de engenharia de dados mais flexível, mas exige que a equipe tenha maturidade em versionamento de código e monitoramento, tratando as transformações de dados como parte integrante da base de código do produto, e não apenas configurações de interface visual.
Artigo originalmente publicado por Mihir Wagle em Azure Updates - Latest from Azure Charts.
