Fala galera!!! Tudo bem? Hoje, nosso post é sobre a Live #16!!
Nela, falamos principalmente sobre temas relacionados a consultoria. Esse tema é bem importante mesmo para aqueles que não são consultores atualmente, pois pode ser um ótima oportunidade para o futuro.
Então, vem comigo para aprender sobre:
- Tipos de trabalho com Power BI e desafios como consultor
- Formas de conexão e atualização de base dos clientes
- Azure SQL Database
Tipos de trabalho com Power BI e desafios como consultor
Antes de ir para a parte de conexão e atualização, acho importante divulgar as formas de projetos de Power BI e falar um pouco dos desafios como consultor. Isso é importante, pois nem todos conhecem todo o leque de oportunidades da comunidade. De maneira geral, existem 3 principais tipos de projetos com Power BI:
– Projetos internos das empresas: esse é o caso mais comum onde o profissional é contratado da empresa e nele trabalham os analistas de negócio (financeiro, vendas, controladoria, engenharia, logístico, etc), os analistas de BI (se houver a área de TI ou de BI) e os consultores internos.
– Consultorias externas: esse é o segundo caso mais comum, nele o profissional que trabalha com BI tem clientes externos e realiza projetos em diferentes empresas.
– Desenvolvimento de produtos com o Power BI: esse é um trabalho de consultoria para clientes internos (normalmente recorrentes). Um exemplo seria uma empresa de sistemas que quer fornecer relatórios desenvolvidos em Power BI para seus clientes. Outro exemplo, é um escritório de contabilidade que queira fornecer ao seu cliente um relatório desenvolvido no Power BI. E por último, soluções de Power BI embedded.
Se eu fosse distribuir (sem dados, pelo contato que tenho da comunidade) eu diria que a maioria dos profissionais trabalham em projetos internos da empresa, seguido de consultorias externas e por último com desenvolvimento de produtos.
O cenário de profissionais internos das empresas migrarem ou pensarem em migrar para consultoria após adquirirem experiência é bem comum.
Mas na hora de fazer a migração fica a dúvida: “Quais desafios vou enfrentar como consultor?” Para te ajudar, fiz uma lista com alguns problemas que você vai encontrar nesse tipo de carreira:
Ter acesso à informação:
- Entender do negócio do seu cliente: para isso você vai ter que ter acesso à pessoas e informações para poder entender o negócio do seu cliente antes de sair desenvolvendo a solução. Sem isso, pode perder muito tempo para entregar ou acabar não entregando a solução esperada pelo cliente;
- Ter acesso ao servidor do cliente: esse item depende bastante da relação com o cliente ou quem faz as permissões do sistema do cliente;
- Ter acesso ao banco de dados do cliente: assim como para o servidor, como consultor você precisa das permissões de acesso para desenvolver a solução;
- Entender as tabelas do banco de dados: Como fazer isso? Existem alguns opções. A primeira é ter alguém no cliente que entenda do Banco de Dados e te apoie na tarefa. Outra forma, é acessar o dicionário do Banco de Dados. E também, você pode gastar seu tempo para entender e cobrar por esse serviço.
Compartilhamento:
- Alinhar a forma de compartilhamento: para isso, você pode ter um usuário dentro do domínio de cada cliente para fazer o compartilhamento. porém, existem diversas outras opções e isso deve ser alinhado com o cliente.
Gateway:
- Conexão gateway para atualizações: conseguir instalar e configurar o gateway no servidor do cliente (envolve bastante o relacionamento com a TI). Esse quesito pode demandar horas de trabalho e muito alinhamento com a equipe do cliente, ou seja, atenção nesse ponto!
| Importante: Tudo isso deve estar incluso na proposta; portanto; cuidado no momento de quantificar as horas do projeto para precificar e não dar um tiro no pé! |
Para fazer uma boa quantificação de horas de trabalho é necessário um ótimo mapeamento de requisitos com perguntas corretas pro cliente! Dois pontos essenciais: conversar com o pessoal da TI e ter um exemplo de amostra de dados. Conforme você adquirir experiência (após o 4° ou 5° projeto) você terá entendido melhor como funciona esse processo.
Em um projeto comum, o consultor independente cobra entre R$ 100,00 – R$ 200,00/ h de trabalho no projeto. E para consultores não independentes, depende da faixa de senioridade, na escala:
- Júnior: entre R$30 e R$40/h;
- Pleno: entre R$40 e R$55/h;
- Sênior: entre R$55 e R$100/h.
E quanto tempo vai levar um projeto? Isso depende de projeto para projeto (até do humor das pessoas envolvidas para liberação das permissões, por exemplo).
Fica aqui um desafio legal para quem é da área da Ciência de Dados. Criar um machine learning para predizer o tempo de trabalho de um projeto de BI. E aí, seria interessante né?
Formas de conexão e atualização de base dos clientes
Aqui, gosto sempre de recordar as etapas do processo de Power BI:
Banco OLTP de Produção → Staging → Data Warehouse (DW) → Power BI Desktop → Power BI Online
Esse é o processo mais utilizado? Não! No processo mais adotado o pessoal pula staging e vai direto para área de produção, ficando assim:
Banco OLTP de Produção → Power BI Desktop → Power BI Online
Minha opinião sobre isso? Já desenvolvi projeto direto no ambiente de produção, porém tive a experiência de derrubar um banco de dados do cliente e não repeti mais esse erro.
A forma mais segura de se desenvolver o projeto é ter acesso a uma cópia/backup do banco de dados do cliente (área de staging). Eu não diria que você é obrigado a ter o Data Warehouse (DW), mas a área de staging é essencial (mitiga muito o risco)! Então, recomendo que mesmo para projetos pequenos tenha o ambiente de staging para desenvolver à vontade e sem receio de afetar o banco de dados.
Vou aproveitar para compartilhar algumas falhas comuns em projeto:
Usar o banco de dados de produção, ao invés do staging:
- Este banco de staging pode estar no ambiente do cliente, ele não precisa te enviar o backup se não quiser.
- Se o cliente não quiser criar o DW e também não quiser manter a alimentação diária do staging, após finalizar o desenvolvimento você pode mudar a conexão para o ambiente de produção através de parâmetros criados no Power Query!
Trazer todo o histórico das tabelas para desenvolvimento:
- Aqui você também pode usar parâmetros para restringir os dados no desenvolvimento. Mostro isso em detalhes na live de atualização incremental (Live #7).
Como consultor, para acessar o ambiente do servidor do cliente temos algumas opções:
- Utilizar uma máquina na rede do cliente de forma remota
- Utilizar a própria máquina acessando o Banco de Dados via VPN
- Utilização de um Data Warehouse
Utilizar uma máquina na rede do cliente de forma remota
Esse método é bem comum e fazemos o acesso a máquina de forma remota via WTS, por exemplo. Ah, mas como fazer isso? Depende da permissão e deve ser alinhado com o cliente (exs.: VPN, por IP, máquina aberta para fazer o login).
Nessa opção, o fluxo de desenvolvimento ficaria assim:
Figura 1: Fluxo no caso de acesso remoto
No nosso exemplo, imagine que estamos acessando remotamente a máquina do cliente (que deve ter o Power BI Desktop instalado) via WTS. Nessa máquina, eu fazemos a importação dos dados e o desenvolvimento. Por fim, publicamos.
| Importante: Peça um usuário apenas de leitura ao banco de dados. Evite o usuário com permissão de alterações! Isso diminui riscos caso o cliente venha a ter um problema no banco de dados. |
Já com o acesso remoto a máquina entramos no visualizador do banco de dados do cliente (nesse caso o SQL Server):
Figura 2: Acesso ao banco de dados no servidor do cliente
Figura 3: Visualização do banco de dados
Etapas: Conectar remotamente a máquina do cliente → Abrir o visualizador → Fornecer as credenciais para login → Visualizar o banco de dados
Então, entramos no Power BI Desktop (no ambiente do cliente) para obter os dados do SQL Server:
Figura 4: Obtendo dados do SQL Server no Power BI
Figura 5: Informando Credenciais
Figura 6: Preview da Tabela
Etapas: Abrir o Power BI Desktop → Em "Página Inicial" clicar em "Obter dados" → Selecionar "Banco de dados SQL Server" → Em "Banco de Dados" informar as credenciais → Selecionar o Banco de Dados para importação
Após carregar os dados, vamos criar dois visuais de exemplo para publicar o relatório:
Figura 7: Visual de Tabela
Etapas: Na aba de visuais clicar em "Tabela" → Arrastar "Grupo" e "DescProduto" para "Valores"
Figura 8: Visual de Cartão
Etapas: Na aba de visuais clicar em "Cartão" → Arrastar "cdProduto" para "Campos"
Figura 9: Página 1 com os visuais de Tabela e de Cartão
E então, salvamos o arquivo:
Figura 10: Salvando o arquivo
Para otimizar o processo de atualização, precisamos criar 2 parâmetros (Servidor e Database) para a fonte de dados no Power Query:
Figura 11: Acessando o Ambiente do Power Query
Etapas: Em "Página Inicial" clicar em "Transformar dados"
No Power Query, vamos em gerenciar parâmetros e criar um parâmetro para o Servidor e outro para o Banco de Dados:
Figura 12: Parâmetro do Servidor
Etapas: Em "Página Inicial" clicar em "Gerenciar Parâmetros" → Configurar "Nome" e "Valor Atual" conforme informações do Servidor → "Tipo" = Texto
Figura 13: Parâmetro Banco de Dados
Etapas: Em "Página Inicial" clicar em "Gerenciar Parâmetros" → Configurar "Nome" e "Valor Atual" conforme informações do Banco de Dados → "Tipo" = Texto
Com os parâmetros criados, alteramos a configuração das fontes:
Figura 14: Configurando a fonte de dados
Etapas: Em "Página Inicial" clicar em "Configuração de fonte de dados" → Clicar em "Alterar fonte" → Alterar a fonte de servidor e banco para os parâmetros criados
E então, alterar a fonte de dados de PRD_Database no editor avançado, pois está fixa e precisamos em forma dinâmica (parâmetro):
Figura 15: Alteração no editor avançado
Etapas: Com a consulta selecionada clicar em "Editor Avançado" → Alterar o "BancodeDados" (entre parênteses, pois está fixo como texto) para BancoDeDados (sem parênteses para referenciar o parâmetro criado)
Após finalizar a configuração de fonte, precisamos informar as credenciais para o acesso como fizemos para obter os dados:
Figura 16: Informando Credenciais
Etapas: Clicar em "Editar Credenciais" → Em "Banco de Dados" informar as credenciais
Fechamos e aplicamos para voltar ao ambiente do Power BI:
Figura 17: Visualização dos dados sem erro após alteração para parâmetros
E por fim, salvamos o arquivo .pbix para publicação.
Utilizar a própria máquina acessando o Banco de Dados via VPN
Nessa opção, o fluxo de desenvolvimento ficaria assim:
Figura 18: Fluxo de desenvolvimento
Para fazer esse exemplo, vou enviar o projeto que criamos (ambiente do cliente) para o One Drive e transferir para minha máquina (ambiente do consultor):
Figura 19: Arquivo (ambiente do cliente)
Figura 20: Arquivo na nuvem
Figura 21: Transferindo o arquivo de pasta
Figura 22: Arquivo do projeto na pasta final
Etapas: Selecionar o arquivo .pbix do projeto criado no ambiente do cliente → Enviar o arquivo para a nuvem → Baixar o arquivo para a própria máquina (ambiente do consultor)
Agora, o arquivo já está na máquina do consultor. Vamos abrir para visualizar:
Figura 23: Projeto (máquina do consultor)
O arquivo mostra as informações, mas se atualizamos ele pedirá as credenciais:
Figura 24: Informando as credenciais
Figura 25: Arquivo atualizado com sucesso
Etapas: Abrir o arquivo .pbix → Em "Página Inicial" clicar em "Atualizar" → Em "Banco de Dados" informar as credenciais
Agora, imagine que o cliente forneceu um backup do banco de dados e podemos fazer o staging para desenvolvimento (ambiente do consultor). Vamos abrir o arquivo do banco de dados enviado pelo cliente no SQL (máquina do consultor):
Figura 26: Conectando no SQL Server (máquina do consultor)
Figura 27 : Banco de dados de backup para staging
Etapas: Abrir o arquivo de banco de dados enviado pelo cliente → Abrir no "localhost" → Visualizar banco de dados (perceba que o nome do arquivo é diferente daquele do ambiente de produção)
Como vamos desenvolver o projeto com base nesse arquivo de staging, precisamos alterar os parâmetros da fonte de dados no Power BI:
Figura 28: Editando parâmetros no Power BI
Etapas: Em "Página Inicial" clicar na seta embaixo de "Transformar dados" → Atualizar os parâmetros
Figura 29: Relatório sem erros com fonte alterada
No arquivo “DEV_Database“, vamos fazer uma alteração retirando alguns itens de produtos, ou seja, será diferente do arquivo do banco de dados do ambiente de produção:
Figura 30: Alteração no banco de dados
Etapas: Abrir o SQL Server → Selecionar o banco de dados → Clicar em "Nova Consulta" → Efetuar a consulta → Salvar arquivo Consulta: select * from Produto delete from Produto where cdGrupo = '9999'
Veja que foram eliminadas 796 linhas:
Figura 31: Resultado da alteração
Vamos atualizar o Power BI e verificar a sincronização de informação:
Figura 32: Atualização do arquivo no Power BI
Etapas: No Power BI, em "Página Inicial" clicar em "Atualizar"
Reparou a mudança no valor do cartão? O valor do cartão era de 2736 e foi para 1940 (2736 – 796 = 1940), ou seja, arquivo atualizado com sucesso! Com a atualização feita, salvamos nosso arquivo e publicamos para o ambiente do Power BI Online:
Figura 33: Publicando o arquivo
Etapas: Em "Página Inicial" clicar em "Publicar" → Selecionar o workspace onde relatório será publicado
O desenvolvimento foi feito na máquina do consultor, porém no Power BI Online a atualização dos dados tem que vir do servidor do cliente! Daí o motivo de usarmos os parâmetros que irão facilitar bastante essa modificação.
Para atualizar o relatório no Power BI Online com as informações do servidor do cliente, precisamos de uma conexão com gateway. Vamos instalar um modo padrão de gateway no ambiente do servidor do cliente, como exemplo:
Figura 34: Baixando a gateway padrão pelo navegador
Etapas: Abrir o navegador (no ambiente do cliente) → Buscar "gateway power bi" → Abrir o primeiro link → Fazer o download do modo padrão
Após terminar o download do arquivo, fazemos a instalação:
Figura 35: Instalando e configurando a gateway
Etapas: Abrir o arquivo baixado → Selecionar local de instalação → Ler "termos de uso" e avaliar se vai aceitar ou não → Selecionar e-mail de uso → Nomear gateway → Criar chave de recuperação
Figura 36: Gateway pronta para uso
Podemos verificar se a gateway está em serviço no gerenciador de tarefas:
Figura 37: Verificação do uso de gateway no Task Manager
Etapas: Abrir o gerenciador de tarefas → Clicar em "Serviços"
| Importante: Normalmente não é papel do consultor de BI fazer a configuração de gateway de um cliente. Isso é papel da TI do cliente ou contratada por ele! Caso você tenha conhecimento desse assunto e for realizar a atividade descreva como um item específico no seu contrato. |
Com a gateway instalada e configurada no ambiente do cliente, vamos no ambiente do Power BI Online fazer o gerenciamento de gateways:
Figura 38: Gerenciamento de gateways no Power BI Online
Etapas: Abrir o Power BI Online → Clicar em "Configurações" → Selecionar "Gerenciar gateways"
Figura 39: Gateway habilitada para uso no ambiente do Power BI Online
Estamos com a gateway habilitada! O próximo passo é alterar os parâmetros da fonte de dados no ambiente do Power BI Online para utilizar o banco de dados de produção (ambiente do cliente):
Figura 40: Acessando o ambiente para alterar os parâmetros
Etapas: Selecionar o workspace do relatório → Clicar em "Conjunto de dados + fluxo de dados" → Clicar em "Agendar atualização"
Figura 41: Parâmetros atuais (Banco de Dados de staging e servidor localhost)
Figura 42: Parâmetros atualizados (Banco de Dados de produção e servidor do cliente)
Etapas: Alterar os parâmetros "BancoDeDados" e "Servidor"
Parâmetros atualizados com sucesso! Agora, voltamos para a configuração da gateway no ambiente do Power BI Online:
Figura 43: Selecionando a conexão com a gateway que criamos
Etapas: Em "Conjunto de dados" e "Conexão de gateway" clicar na seta da gateway criada → Clicar em "Adicionar gateway"
Figura 44: Configuração da fonte de dados
Etapas: Preencher as informações da fonte de dados e do servidor
A última etapa de configuração, é mapear a fonte da gateway em conjunto de dados (temos que voltar na área de conexão de gateway do conjunto de dados):
Figura 45: Mapeamento da fonte na gateway
Etapas: Em "Conjunto de dados" clicar em "Conexão de gateway" → Em "Mapeia para:" selecionar a fonte de dados configurada
Vamos abrir o relatório para ver se funcionou?
Figura 46: Abrindo o relatório
Etapas: No workspace do relatório clicar em "Conteúdo" → Clicar no relatório
Figura 47: Relatório com dados desatualizados
Como podemos ver, os dados são do ambiente de staging (máquina do consultor). Imagina o motivo? Se você lembrou que faltou atualizar o conjunto de dados está correto! Vamos atualizar:
Figura 48: Atualização do conjunto de dados
Etapas: No workspace do relatório clicar em "Conjunto de dados + fluxo de dados" → Clicar em "Atualizar agora"
Abrindo o relatório novamente:
Figura 49: Abrindo o relatório
Figura 50: Relatório com dados desatualizados
Léo, fizemos algo errado? Todo esse trabalho para não funcionar a configuração? Calma, sem apavorar quando algo parece estar errado! Aqui é somente um delay no cache do navegador. Como atualizamos o conteúdo do conjunto de dados e instantaneamente abrimos o relatório, o cache não foi atualizado. Podemos forçar a atualização no próprio relatório e verificar a atualização:
Figura 51: Atualização do Relatório
Etapas: Clicar em "Mais opções" → Selecionar "Atualizar"
Figura 52: Dados atualizados
| Dica: Se o seu cliente trabalha com o sistema “SAAS” ou dados na nuvem os acessos terão que ser feitos via APIs ou de relatórios extraídos manualmente. |
Em todos os casos, para a importação do banco de dados de produção do cliente para o Power BI Online precisa de uma conexão de gateway!
Utilização de um Data Warehouse
Aqui estamos num cenário de excelência! O desenvolvimento é feito com acesso ao DW (Azure SQL Database).
A Azure SQL Database é uma ferramenta bem simples de utilizar e possibilita a atualização periódica. Ele que vai servir como fonte de dados para o Power BI! O fluxo de desenvolvimento ficaria assim:
Figura 53: Fluxo do Processo com a utilização de DW (Azure SQL Database)
Dessa maneira não precisamos de conexão da gateway para atualização. Vai ser necessário utilizar uma ferramenta para enviar os dados da origem (banco OLTP) para o DW (Azure SQL Database). Essa ferramenta é o “Integration Runtime“. O fluxo de atualizado ficaria assim.
Figura 54: Fluxo de atualização na nuvem com o novo processo
| Dica: Para mais detalhes sobre o “Integration Runtime” acesse o link da Microsoft: https://docs.microsoft.com/pt-br/azure/data-factory/concepts-integration-runtime |
Vamos conectar na Azure para mostrar a máquina virtual que acessamos remotamente para o primeiro desenvolvimento e também ver as opções de Azure SQL Database:
Figura 55: Conectando na Azure
Figura 56: Ambiente da Azure com lista de produtos
Figura 57: Ambiente do cliente
Figura 58: Máquina virtual
Etapas: Selecionar "Grupos de Recursos" → Clicar no ambiente da máquina → Selecionar a máquina virtual
Aqui podemos visualizar a configuração da máquina virtual:
Figura 59: Especificações da máquina virtual
Figura 60: Algumas opções de máquina virtual
Etapas: Clicar em "Tamanho"
Vamos entrar no ambiente de consulta para criação do Data Warehouse:
Figura 61: Ambiente para criação do Azure SQL Database
Figura 62: Ambiente para criação do Azure SQL Database 2
Figura 63: Detalhes e seleção de configuração
Etapas: Selecionar "Todos os Recursos" → Selecionar um recurso de SQL Server → Clicar em "Criar banco de dados" → Clicar em "Configurar banco de dados"
Figura 64: Configurando o banco de dados e estimativa de custo/mês (Básico)
Figura 65: Exemplo de parâmetros que afetam o custo/mês
Quando estiver em um projeto envolvendo banco de dados na nuvem negocie se a conta da Azure utilizada para o Data Warehouse será a sua ou a do cliente. Isso deve ser negociado e firmado em contrato, pois se for na sua conta (do consultor) o preço do projeto deve incluir a mensalidade do serviço!
Perguntas e Respostas
Bom, no final da Live#16 tivemos nossas perguntas e respostas! Segue abaixo a lista do que conversamos:
“Léo, se uma aplicação já possui o banco de produção e desenvolvimento em diferentes servers, posso assumir que o próprio banco de desenvolvimento seria uma staging, certo?” – Thiago Esmerine
Sim, pode assumir!
“Boa noite, Leonardo! Qual o maior desafio como consultor?” – Edson
Mapeamento de requisitos do projeto! Se isso não for bem feito seu projeto pode ser um fracasso e ter impacto financeiro negativo.
“Na Azure tem possibilidade de criar banco de dados gratuito? Ou somente pago? Somente a conta é gratuita?” – Sergio Oliver
Somente a conta é gratuita! Tem a opção de criar uma assinatura e colocar seu cartão associado a ela, daí você ganha em torno de R$ 700,00 para “teste”.
“Como fazer um bom mapeamento de requisitos?” – Rafael Martins
Entrevistas! Focar nas perguntas corretas…..conversar com os usuários finais e TI do cliente.
“Você usa algum termo de confidencialidade dos dados do cliente? Se sim, pode mostrar um exemplo?” – Lucas Harmatiuk
Sim! Normalmente é o cliente que envia…..mas você pode encontrar modelos na Internet.
Bom galera, esse foi o conteúdo da nossa Live#16!! Se ficou com alguma dúvida ou tem sugestão de um tema para a próxima Live deixa nos comentários.
Abraços, pessoal.
Leonardo!
