Como implementar CI/CD com o Power BI?

O desafio começou em um projeto de Datalake na AWS utilizando o S3 para o armazenamento, o Athena para o consumo dos dados estruturados via SQL sem a necessidade de servidores e o Microsoft Power BI para apresentação de dashboards. Por padrão, o Power BI acessa o Athena através de um driver ODBC chamado Simba. Com esse driver as consultas SQLs criadas pelo Power BI serão executadas através do Athena nos dados que estão armazenados em S3.

Como os dados acessados pelo Power BI são dados em ambiente produtivo, surgiu a necessidade de se fazer a publicação dos relatórios do PBI de forma automatizada, fazendo a alteração da fonte de dados entre os ambientes de desenvolvimento, homologação e produção, assim como também de manter o controle de alterações para que se necessário seja possível voltar a uma versão anterior já publicada.

Para o projeto foram desenvolvidos vários dashboards, e para cada dashboard foi preciso ter um controle de permissão diferente para separar os assuntos distintos de cada departamento. Além disso, houve a necessidade de se reduzir o custo de atualização dos dados de forma automatizada.

Em suma, nesse cenário proposto temos as seguintes dificuldades: 

  • Ambientes distintos no Power BI Service; 
  • Alterar a fonte de dados para cada ambiente; 
  • Controle de versionamento; 
  • Publicar relatórios e configurar os workspaces de forma automatizada; 
  • Ter um CI/CD para desburocratizar o processo de deploy; 
  • Atualizar o conjunto de dados com um baixo custo. 

Vamos aos detalhes de cada uma das etapas.

 

Ambientes distintos no Power BI Service

O Power BI possui as licenças Power BI Pro Power BI Premium. Caso seja utilizada a licença Power BI Premium, tem-se a ferramenta de Pipeline de Power BI Service que disponibiliza para você um controle de ambientes separados como desenvolvimento, homologação e produção. No entanto, o foco não será nela, pois foi utilizada a licença do Power BI Pro, então a opção era fazer um controle manual dos ambientes, criando um Workspace para cada ambiente desejado, como por exemplo: Recrutamento e Seleção [Test], Recrutamento e Seleção [Hml], Recrutamento e Seleção.

 

Alterar a fonte de dados para cada ambiente 

Para alterar a fonte de dados conforme o ambiente, é útil utilizar os parâmetros no modelo do Power BI, assim poderá ser alterado pelo painel do Power BI Service ou pela API REST do Power BI Service.

Foi criado, por exemplo, os parâmetros dsn para definir o DSN da conexão ODBC e o Schema para definir qual schema (banco de dados) a ser acessado no Athena para definir o acesso aos dados, conforme imagem abaixo.

 

 

Foram configurados esses parâmetros no Source da Query. No Odbc.DataSource na linha 2 e no AwsDataCatalag_Database na linha 4 da imagem abaixo. 

 

 

Assim, toda vez que for necessário alterar a fonte de dados, seja o Schema ou o DSN, apenas é necessário alterar os parâmetros, seja no Power BI Desktop ou no Power BI Service. 

Após publicar o relatório no Power BI Service, é possível acessar as configurações do “Conjunto de dados” e alterar os parâmetros como na imagem abaixo. 

 

 

Não se esqueça de atualizar o “Conjunto de dados” após alterar os parâmetros.

 

Controle de versionamento

Para termos um controle de versionamento dos relatórios existem algumas opções viáveis, uma delas é utilizar a sincronização automática do Power BI com o OneDrive. A outra seria utilizar uma ferramenta de controle de versionamento como o GIT.

A segunda opção muitas vezes se torna mais viável, pois a empresa normalmente já tem um controle de versionamento como o GIT e uma ferramenta de CI/CD. 

 

Publicar relatórios e configurar os workspaces de forma automatizada 

Para conseguir esse objetivo, temos duas opções. Uma delas é utilizar Pipeline do Azure DevOps + extensão Power BI Actions conforme descrito nesse artigo, ou utilizar o Power BI REST API. 

Utilizando os endpoints REST do Power BI Service, é possível criar um fluxo personalizado para as suas necessidades, enquanto que utilizando o Power BI Actions você obrigatoriamente deverá utilizar o Azure DevOps. 

 

Ter um CI/CD para desburocratizar o processo de deploy 

É possível utilizar qualquer ferramenta de controle de versionamento e nesse caso qualquer ferramenta de CI/CD, se utilizar o Azure DevOps, é possível fazer uso da extensão Power BI Actions, como já mencionado, para automatizar a publicação dos relatórios para ambientes distintos.  

Na ocasião do uso de outra ferramenta de CI/CD, você deverá partir para a utilização do Power BI REST API e criar um script para customizar o processo. 

Neste caso apresentado foi desenvolvido um script em Python que é responsável por criar todos os workspaces, configurar as permissões de acesso dos usuários e publicar todos os relatórios em cada workspace conforme o ambiente definido. Esse script também é responsável por configurar os parâmetros e atualizar os dados no Power BI Service, automatizando todo o processo. 

Cada vez que for feito um commit no repositório o Jenkins irá rodar o script Python que irá se encarregar de fazer todo o processo. Para o script conseguir separar os relatórios entre workspaces, foi definida uma estrutura de arquivos dentro do repositório, por exemplo: 

  • workspaces 
  •  RecrutamentoESelecoes 
  • config.json 
  • Recrutamento Movimentações.pbix 
  • Dashboard de Seleções.pbix

 

Foi criado uma pasta chamada workspaces, e dentro dessa pasta subpastas que representam cada workspace. Dentro da subpasta existe um arquivo config.json e os arquivos .pbix gerados pelo Power BI Desktop. 

O arquivo config.json teve a seguinte estrutura definida: 

 

 

Com essa estrutura, cada workspace tem a suas configurações definidas por ambiente, neste caso, Homologação e Produção. 

 

Atualizar o conjunto de dados com um baixo custo 

Aqui surgiu outro desafio. Para o Power BI Desktop conseguir acessar os dados do Athena, ele deve se conectar via ODBC ou JDBC, e para publicar esse relatório o acesso aos dados deverá ser feito via On-Premises data gateway. Foi utilizado as recomendações da AWS para essa configuração, abaixo o exemplo de arquitetura recomendada pela AWS para interoperabilidade entre as nuvens. 

 

 

O driver do ODBC ou JDBC pode ser instalado tanto no Windows como no Linux, mas o Gateway do Power BI Service pode ser instalado apenas no Windows. Dessa forma, como a estrutura do Datalake está na AWS, a opção foi aproximar o Power BI Gateway On-Premise da origem dos dados, com o objetivo de “empurrar” os dados assim que fossem atualizados no S3 para o PowerBI. Neste caso, foi utilizado uma EC2 Windows com o ODBC e o Power BI Gateway On-Premises configurados.

Para reduzir os custos com essa máquina foi criada uma função AWS Lambda que é executada toda vez que o processo de carga do Datalake é concluído, assim sendo, sempre que os dados forem alterados no Datalake eles automaticamente são atualizados no Power BI Service. Essa função Lambda é responsável por subir uma nova instância EC2, baseada na IAM configurada com o OBDC o Power BI Gateway On-Premises do Power BI Service. Após a máquina estar operando, a função Lambda utiliza os recursos do Power BI REST API e atualiza todos os conjuntos de dados no Power BI Service. Assim que todos forem atualizados, a Lambda encerra a EC2 reduzindo custos de operação.

Gostou da solução? Nós podemos ajudar!

Conheça nossos conteúdos gratuitos, direcionados aos assuntos de sua preferência!

Enviar

Receba nosso conteúdo

Gostaria de receber de forma gratuita mais conteúdos sobre este ou outros assuntos? Preencha o formulário abaixo e receba nosso conteúdo gratuito!

Parabéns!

Você receberá nosso conteúdo em breve!

Atenção

Tivemos um problema com seu formulário, tente novamente.