Power BI Eixo Personalizado

O Problema

Como criar um eixo com os meses da minha tabela de calendário e no final colocar mais uma informação no eixo? Ou seja, como criar um eixo customizado.

Veja o exemplo abaixo:

o que o cliente quer

No gráfico acima temos um eixo customizado, ou eixo personalizado, que vai de Jan a Dec e no final tem um FY BGT. E ainda tem uma linha mostrando o percentual de diferença entre uma coluna e a outra (chamamos isso de Growth).

Primeiros Passos

Primeira coisa que temos que fazer é entender como chegar nessa solução. Então vamos pensar na lógica por trás disso antes de sair fazendo.

Primeiro ponto é, de onde vem esse eixo de Jan a Dec? Vem da sua dimensão calendário. Então muito provavelmente você tem uma dimensão calendário com esses meses aí. Então beleza, é pegar essa lista de valores da calendário e ao final dela adicionar, “apendar”, essa palavra aí “FY BGT”.

Depois do eixo criado criado basta criar as medidas pra identificar os valores, então quando o eixo for FY BGT vai receber a medida de BGT e quando for diferente vai receber outra medida que queremos passar.

Além disso temos que relacionar as medidas que criarmos ao modelo já existente, pra que ela seja filtrada pelas nossas dimensões e tal.

Mão na massa – criando o eixo personalizado

Primeiro passo então é criar o eixo personalizado. Pra isso vamos fazer o seguinte, vamos no Power Query e vamos criar uma nova tabela lá. Então New Source > Blank Query.

O código é esse aqui, se você quiser copiar:

let
     // uso como source a coluna da minha dimensao calendario pra criar uma lista de valores unicos
     Source = List.Distinct(dDateInput[MonthName]),
     // converto a lista pra tabela
     #"Converted to Table" = Table.FromList(Source, Splitter.SplitByNothing(), null, null, ExtraValues.Error),
     // renomeio a coluna pra CustomAxis
     #"Renamed Columns" = Table.RenameColumns(#"Converted to Table",{{"Column1", "CustomAxis"}}),
     // mudo o tipo pra texto
     #"Changed Type" = Table.TransformColumnTypes(#"Renamed Columns",{{"CustomAxis", type text}}),
     // adiciono um step after
     // adiciono esse codigo pra inserir ao final uma linha nova com nome de BGT
     Custom1 = 
     Table.InsertRows(
         #"Changed Type",
         12,
         {[CustomAxis = "BGT"]}
     ),
     // adiciono uma coluna de indice que vou usar pra ordenar meu eixo
     #"Added Index" = Table.AddIndexColumn(Custom1, "Index", 1, 1, Int64.Type)
 in
     #"Added Index"

O que estamos fazendo aqui é:

  1. Criando uma blank query
  2. “= List.Distinct(dDateInput[MonthName])” Com esse comando criamos uma lista de valores únicos com base na dDateInput[MonthName] que é nossa coluna da dimensão calendário
  3. Transformamos essa lista em uma table
  4. Dou um nome pra tabela (pode ser qualquer nome)
  5. Renomeio a coluna pra CustomAxis
  6. Mudo o tipo da coluna pra Texto
  7. Adiciono uma linha nova ao final da coluna com o valor BGT
  8. Adiciono uma coluna de índice que vou usar pra ordenar o eixo

Fechar e aplicar o power query. No Power BI agora temos uma tabela nova, assim:

Pra garantir que a coluna CustomAxis fique na ordem que eu desejo eu ordeno ela pela Index.

Criando as medidas

Agora que temos o eixo, precisamos preencher esse eixo com valores. No meu caso quero 2 medidas, uma com o valor mês a mês e o valor do BGT no final.

Todas as duas medidas eu já tenho pronta porque uso em outros lugares do report onde uso eixos “normais” da minha calendário. Vou aproveitar essa medida e já passar no eixo. Claro, vai dar errado, vai gerar um produto cartesiano porque esse novo eixo não tem relacionamento com o restante do dataset.

medida VALUES ACTLE no novo eixo personalizado, antes do relacionamento

Pra resolver esse problema vamos utilizar a função TREATAS(). Assim:

CALCULATE( [Values ACTLE], TREATAS( VALUES( dDateInputBGT[CustomAxis] ), dDateInput[MonthName] ) )

O que o TREATAS() está fazendo é relacionando os VALUES() da nova coluna de eixo com a mesma coluna da dimensão de calendário. O resultado disso é que agora a medida vai conseguir identificar se é janeiro, fevereiro, etc e filtrar o valor da medida.

nova medida com relacionamento do TREATAS()

Só que agora preciso do BGT. A ideia é a mesma, preciso criar um DAX que me dê o valor que quero colocar ali naquela célula. No meu caso eu peguei sempre o valor de DECEMBER do BGT. Eu poderia pegar o FullYear também, ou seja, somar todo ano de BGT e colocar ali o valor, enfim, aí é só questão de criar a fórmula em DAX, mas o importante é saber como preencher aquela célula ali. Pra isso eu fiz o seguinte:

  1. criei a fórmula de BGT (nota: como eu não preciso que o valor de BGT mude de acordo com eixo, eu não preciso usar o TREATAS() como usei na medida anterior)
CALCULATE( [Values BGT w/o Zero], dDateInput[MonthName] = "December" )

2. criei um SWITCH pra identificar, quando for BGT retornar a medida de BGT, senao, retornar a medida geral.

SWITCH(
    TRUE(),
    vSelectAxis = "BGT", CALCULATE( [Values BGT w/o Zero], dDateInput[MonthName] = "December" ), // GETS ALWAYS THE DECEMBER VALUE FOR BGT
    vACTLE
)

resultado final com BGT preenchido

O valor final não está correto, mas ele não importa pra gente nesse exemplo.

Agora precisamos criar a segunda medida, que é o percentual variável entre um mês e outro e BGT. Pra criar essa medida precisa de alguma lógica, então você precisa entender o seu modelo de dados, as informações a sua disposição pra criar essa medida. No meu caso, como eu tenho uma coluna de índice que vai de 1 a 13, basta pegar o valor do índice atual, menos o valor do índice anterior e esse resultado dividir pelo valor do índice anterior.

medida pra gerar growth %

O resultado vai ficar como na tabela abaixo. Fim :), agora é só criar o gráfico (claro, removendo antes as colunas INDEX e a VALUES ACTLE).

clique pra aumentar

Para mais detalhes e informações recomendo assistir os vídeos que estão nas referências.

Referências

https://www.youtube.com/watch?v=LYgncqFXkNw – [Power BI] Criando um Gráfico de Barras com um Eixo totalmente Personalizado. Parte – 1

https://www.youtube.com/watch?v=xu670pWkw7g – [Power BI] Criando um Gráfico de Barras com um Eixo totalmente Personalizado. Parte Final

https://www.youtube.com/watch?v=GOGcdu135h0 – [DATAB Live] #10 – Linguagem DAX: Manipulando Eixos dos Visuais

Azure AZ-900 Describe core resources available in Azure | Marketplace

Este é o segundo tópico do módulo “Describe Core Azure Services (15-20%)”.

Para encontrar todos outros posts para estudo da certificação Azure AZ-900 acesse:
Azure AZ-900: Microsoft Azure Fundamentals

Describe Core Azure Services (15-20%)

Describe core resources available in Azure

  • describe the benefits and usage of Azure Marketplace

fonte:
https://docs.microsoft.com/en-us/learn/modules/simplify-cloud-procurement-governance-azure-marketplace/

Azure Marketplace é um lugar onde você pode encontrar um monte de serviços diferentes do que os “nativos” oferecidos pela Microsoft, então lá você pode encontrar vários outros serviços de outros fornecedores.

  • Azure Marketplace economiza tempo, oferecendo um vasto catálogo de produtos e serviços de software que qualquer equipe de desenvolvedores, arquitetos de nuvem, especialistas em segurança e engenheiros de TI podem usar para executar e gerenciar cargas de trabalho na nuvem
  • Encontrar e testar o software no Azure Marketplace é simples, com maneiras intuitivas de pesquisar, avaliar e testar o software antes de comprar
  • Comprar no Azure Marketplace remove o atrito da aquisição. Um contrato padrão, emendas personalizadas, faturamento consolidado e ofertas privadas com preços e termos pré-negociados simplificam a compra
  • Controlar custos e gerenciar a aquisição de software é fácil com Private Azure Marketplace, política do Azure e controle de acesso baseado em função (RBAC)

Referências

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

https://www.udemy.com/course/introducao-ao-microsoft-azure-certificacao-az-900/

https://www.exampro.co/az-900

Azure AZ-900 Describe core resources available in Azure | Database and Analytics

Este é o segundo tópico do módulo “Describe Core Azure Services (15-20%)”.

Para encontrar todos outros posts para estudo da certificação Azure AZ-900 acesse:
Azure AZ-900: Microsoft Azure Fundamentals

Describe Core Azure Services (15-20%)

Describe core resources available in Azure

  • describe the benefits and usage of Cosmos DB, Azure SQL Database, Azure Database for MySQL, Azure Database for PostgreSQL, and SQL Managed Instance

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-database-fundamentals/

Azure Cosmos DB

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-database-fundamentals/azure-cosmos-db
https://docs.microsoft.com/en-us/azure/cosmos-db/introduction

Azure Cosmos DB é um multi-model database service NoSQL, globalmente distribuído. No Cosmos DB é possível escalar sua storage entre diferentes regiões, aumentando ou diminuindo capacidade de entrega de dados, e o acesso aos dados pode ser feito usando diferentes APIs.

No Cosmos DB os dados são armazenados num nível chamado atom-record-sequence (ARS), esse dado é acessado através de uma API que você especifica quando for criar a database. Você pode criar a database no Cosmos para SQL, MonboDB, Cassandra, Table e Gremlin. Esse nível de flexibilidade significa que, conforme você migra os bancos de dados de sua empresa para o Azure Cosmos DB, seus desenvolvedores podem manter a API com a qual estão mais familiarizados.

Cosmos DB tem tempos de resposta em milissegundos, escalabilidade automática e instantânea garantem velocidade em qualquer escala. A continuidade dos negócios é garantida com disponibilidade apoiada por SLA e segurança de nível empresarial. O desenvolvimento de aplicativos é mais rápido e produtivo graças à distribuição de dados multirregionais em qualquer lugar do mundo, APIs e SDKs de código aberto para linguagens populares.

Como um serviço totalmente gerenciado, o Azure Cosmos DB tira a administração do banco de dados de suas mãos com gerenciamento automático, atualizações e patches. Ele também lida com o gerenciamento de capacidade com opções econômicas sem servidor e de dimensionamento automático que respondem às necessidades do aplicativo para corresponder a capacidade com a demanda.

Azure SQL Database

Azure SQL Database é um PaaS, isso significa que a grande maioria do gerenciamento do banco de dados, como upgrade, atualização, backup e monitoramento é feita pela Azure, sem envolvimento do usuário. Você pode ficar mais focado em trabalhar nos seus dados.

Azure SQL Database entrega 99,99% de disponibilidade, com Azure SQL Database você pode trabalhar com bancos de dados relacionais e também não-relacionais, como graphs, JSON, spatial e XML.

Também é possível migrar do SQL on-premises para o Azure atrabés do DMS (database migration service) usando Microsoft Data Migration Assistant.

Azure Database for MySQL

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-database-fundamentals/azure-mysql-database

Azure Database for MySQL é um serviço de database relacional na cloud, com base na versão do MySQL Community Edition e garante 99,99% de disponibilidade, distribuído globalmente nos servidores da Azure gerenciados pela Microsoft, o que ajuda que ele esteja disponível 24/7.

Em cada Azure Database for MySQL , você aproveita a segurança interna, tolerância a falhas e proteção de dados que, de outra forma, teria que fazer você mesmo no seu on-premises. Com o Azure Database for MySQL , você pode usar a restauração de backup pontual para recuperar um servidor a um estado anterior, de até 35 dias.

Azure Database for MySQL é recomendado para uso com LAMP stack (Linux, Apache, MySQL, PHP).

Azure Database for PostgreSQL

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-database-fundamentals/azure-postgresql-database

Assim como o Azure Database for MySQL o Azure Database for PostgreSQL também é uma base de dados relacional na cloud. Também é baseado na versão de comunidade do open-source PostgreSQL.

Azure PostgreSQL conta com benefícios como: alta disponibilidade sem necessidade de configurações adicionais; precificação simplificada, você tem performance e preço previsíveis de acordo com a configuração contratada e isso inclui atualizações, backups automáticos, monitoramento e segurança; escalabilidade pra cima e pra baixo conforme necessário pra que se adeque a sua necessidade; segurança a nível empresarial e compliance pra proteger seus dados, isso cobre data encryption no disco e SSL na comunicação cliente-servidor.

Azure PostgreSQL tem duas opções de deploy: Single Server e Hyperscale (Citus).

Single Server: database normal, como o MySQL, mas com escalabilidade vertical.

Hyperscale (Citus): aqui a escala pode ser horizontal, onde queries ao banco de dados serão processadas através de diferentes servers pra otimizar performance. Utilizado especialmente para databases grandes, com 100gb ou mais.

Azure SQL Managed Instance

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-database-fundamentals/azure-sql-managed-instance

Assim como o Azure SQL o Azure SQL Managed Instance também é um PaaS, só que, diferente do SQL o SQL Managed Instance é um serviço de dados da cloud altamente escalável e que provê maior compatibilidade com databases SQL Server.

O Azure SQL e o Azure SQL Managed Instance oferecem muitos dos mesmos recursos; no entanto, o Azure SQL Managed Instance oferece várias opções que podem não estar disponíveis para o Azure SQL, como por exemplo server collation que no Azure SQL só aceita “SQL_Latin1_General_CP1_CI_AS” enquanto que no Azure SQL Managed Instance várias outras collations podem ser utilizadas.

Lista de comparação entre Azure SQL e Azure SQL Managed Instance: https://docs.microsoft.com/en-us/azure/azure-sql/database/features-comparison

Referências

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

https://www.udemy.com/course/introducao-ao-microsoft-azure-certificacao-az-900/

https://www.exampro.co/az-900

Azure AZ-900 Describe core resources available in Azure | Storage

Este é o segundo tópico do módulo “Describe Core Azure Services (15-20%)”.

Para encontrar todos outros posts para estudo da certificação Azure AZ-900 acesse:
Azure AZ-900: Microsoft Azure Fundamentals

Describe Core Azure Services (15-20%)

Describe core resources available in Azure

  • describe the benefits and usage of Container (Blob) Storage, Disk Storage, File Storage, and storage tiers

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-storage-fundamentals/

Antes de mais nada, pra usar serviços de storage você precisa criar uma conta tipo Azure Storage, que pode ser criada através do portal. Dentro dessa conta você vai ter todos tipos de objetos de storage disponíveis, como blobs, files, disks. Azure Storage Account é um recurso, como qualquer outro precisa de subscription, estar associado a um resource group, etc.

Pra VM em específico você não precisa de uma Azure Storage Account, basta usar um Azure Disk Storage na VM, no entanto esses Disks Storages da VM não podem ser utilizados fora da VM.

Disk Storage

Esses Disks Storage para as VM podem ser usados como um disco dentro de uma máquina, logo podem ser normalmente utilizados pelas apps e outros serviços da VM.

Os discos que você pode associar ao seu Disk Storage podem ser HDD ou SSD, ou ainda premium SSD, ou também ultra disks pra cargas de trabalhos mais violentas, tipo SAP HANA, e outras bases de dados mais gulosas.

Container (Blob) Storage

Blob vem de Binary Large Object, bom saber o que esses acronimos significam. Blog na Azure é um tipo de “storage object solution”, ou seja, usando o blob você pode armazenar um monte de coisas diferentes, como text, dados binários, arquivos gigantes, arquivos pequenos, etc. Azure Blob é do tipo não estruturado, por isso permite que qualquer tipo de dados seja armazenado.

Blob aceita uma porrada de acessos simultâneos, ou seja, faz um monte de upload ao mesmo tempo, entrega um monte de vídeo, lida com arquivos de log que estão constantemente crescendo e o Blob pode ser acessado de qualquer lugar na internet.

Quando estamos falando de Blob você não precisa se preocupar em qual disco o dado está sendo gravado, a Azure toma conta disso. Voce pode organizar blob em containers, um exemplo de uso seria assim:

Diagram of hierarchy of a storage account.

File Storage

Azure Files é o recurso da Azure que permite que você armazene dados como em um servidor de arquivos, o famoso barra barra. Com Azure você consegue ter esse mesmo comportamento facilmente. Dá pra mapear um drive, como seu f:, dá pra permitir acesso da sua app no Azure Files pra que a app escreva o arquivo lá, dá pra ser uma pasta compartilhada pra o time usar ou guardar logs, etc.

Storage Tiers

Azure fornece 3 tiers diferentes pra seus armazenamentos tipo blob: Hot, Cool e Archive.

Hot: é o padrão, seus dados estão disponíveis pra serem utilizados, otimizados para dados frequentemente acessados, tipo imagens num website.

Cool: tipo de armazenamento otimizado pra dados não frequentemente acessados, tipo notas fiscais.

Archive: dados que são raramente acessados, tipo backups que ninguém mais vai usar.

Importante saber que: se seu dado estiver num Archive ele vai estar offline e poderá demorar um bom tempo (horas) até ser colocado disponível pra uso.

Referências

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

https://www.udemy.com/course/introducao-ao-microsoft-azure-certificacao-az-900/

https://www.exampro.co/az-900

Azure AZ-900 Describe core resources available in Azure | Compute

Este é o segundo tópico do módulo “Describe Core Azure Services (15-20%)”.

Para encontrar todos outros posts para estudo da certificação Azure AZ-900 acesse:
Azure AZ-900: Microsoft Azure Fundamentals

Describe Core Azure Services (15-20%)

Describe core resources available in Azure

  • describe the benefits and usage of Virtual Machines, Azure App Services, Azure Container Instances (ACI), Azure Kubernetes Service (AKS), and Windows Virtual Desktop

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-compute-fundamentals/overview
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/overview
https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree

Screenshot of the Azure portal compute services page that includes VMs and containers.
algumas opções de recursos de compute

Vou separar os recursos por partes. Abaixo cada um deles estará um pouco mais detalhado.

Virtual Machines

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-compute-fundamentals/azure-virtual-machines

VMs é como se fosse um computador físico, mas na cloud. Isso significa que com uma VM você tem um computador, com memória, disco e sistema operacional disponível pra você fazer o que você quiser com ele.

definições macro de VM

VMs provê um ambiente IaaS (já falamos sobre IaaS no post passado), portanto, se você precisa de controle total do sistema operacional, VMs são sua melhor escolha. VMs é particularmente útil quando você precisa executar ou hospedar um software customizado.

Uma VM do Azure oferece a flexibilidade de virtualização sem você precisar comprar e manter o hardware físico pra isso. No entanto, você ainda precisa dar manutenção na VM, como realizar configurações, correção e instalação do software que roda nela.

Além do recurso computacional de Virtual Machine, existe um outro chamado Virtual machine scale sets. Esse recurso permite você implantar e gerenciar um conjunto de VMs idênticas. Com todas as VMs configuradas da mesma forma, os conjuntos de dimensionamento de máquinas virtuais são projetados para oferecer suporte à escala automática. Nenhum pré-provisionamento de VMs é necessário. Por esse motivo, é mais fácil construir serviços em grande escala visando big data e cargas de trabalho em contêiner. Conforme a demanda aumenta, mais instâncias de VM podem ser adicionadas. Conforme a demanda diminui, as instâncias de VM podem ser removidas. O processo pode ser manual, automatizado ou uma mistura dos dois.

Azure App Services

fonte:
https://docs.microsoft.com/en-us/azure/app-service/overview
https://docs.microsoft.com/en-us/learn/modules/azure-compute-fundamentals/azure-app-services

Apps Services funciona como PaaS. Diferente da VM onde você levanta o servidor e instala um serviço, no App Services você apenas escolhe qual serviço (web, mobile ou API) você quer e o resto fica transparente pra você, ou seja, você não precisa se preocupar em subir servidor, qual aplicação instalar, nem nada disso.

O Azure App Services é um serviço baseado em HTTP para hospedar aplicativos da web, APIs REST e back-ends de mobile na linguagem de programação que você escolher. Azure App Services ainda adiciona o poder do Azure ao seu aplicativo, como segurança, balanceamento de carga, escalonamento automático e gerenciamento automatizado. Você também pode tirar proveito dos recursos de DevOps, como implantação contínua do Azure DevOps, GitHub, Docker Hub e outras fontes, gerenciamento de pacotes, ambientes de preparação, domínio personalizado e certificados TLS / SSL.

Apps Services oferece escalonamento automático, e alta disponibilidade. Apps Services suporta Windows e Linux e habilita deploy automatizado vindos do GitHub, Azure DevOps ou qualquer outro repositório Git com suporte a “continuous deployment model”.

Você paga pelos serviços de compute que seu app usa do Azure enquanto seu app processa as requisições com base no plano que você escolheu. O plano escolhido para seu App Service determina quando de hardware sua app vai poder usar, se é um hardware dedicado ou compartilhado, quanto de memória tem reservado, etc. Existe até um tier gratuito no App Service que você pode usar pra apps pequenas e com poucos acessos.

Azure Container Instances (ACI)

fonte:
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-overview
https://docs.microsoft.com/en-us/learn/modules/azure-compute-fundamentals/azure-container-services

Contêineres são gerenciados por meio de um orquestrador de contêineres, que pode iniciar, parar e dimensionar instâncias de aplicativos conforme necessário. Existem duas maneiras de gerenciar os contêineres na Azure: utilizando Azure Container Instances ou Azure Kubernetes Service (AKS).

Azure Container Instances (ACI) oferecem a maneira mais rápida e simples de executar um contêiner no Azure sem ter que gerenciar máquina virtual ou adotar quaisquer serviços adicionais. É uma oferta de plataforma como serviço (PaaS) que permite fazer upload de seus contêineres, que são executados para você.

Contêineres são ambientes de aplicativos virtualizados leves. Eles foram projetados para serem criados, dimensionados e interrompidos rapidamente de forma dinâmica. Você pode executar várias instâncias de um aplicativo em contêiner em uma única máquina host.

características de um container

ACI são uma ótima solução para qualquer cenário que possa operar em contêineres isolados, incluindo aplicativos simples, automação de tarefas e build jobs. Para cenários em que você precisa de orquestração de contêiner completa, incluindo descoberta de serviço em vários contêineres, dimensionamento automático e atualizações de aplicativo coordenadas, recomendamos o Azure Kubernetes Service (AKS).

Azure Kubernetes Service (AKS)

fonte:
https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes
https://docs.microsoft.com/en-us/azure/aks/concepts-clusters-workloads

Contêineres são gerenciados por meio de um orquestrador de contêineres, que pode iniciar, parar e dimensionar instâncias de aplicativos conforme necessário. Existem duas maneiras de gerenciar os contêineres na Azure: utilizando Azure Container Instances ou Azure Kubernetes Service (AKS).

A tarefa de automatizar, gerenciar e interagir com um grande número de contêineres é conhecida como orquestração. O Azure Kubernetes Service é um serviço de orquestração completo para contêineres com arquiteturas distribuídas e grandes volumes de contêineres. A orquestração é a tarefa de automatizar e gerenciar um grande número de contêineres e como eles interagem.

Windows Virtual Desktop

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-compute-fundamentals/windows-virtual-desktop
https://docs.microsoft.com/en-us/azure/virtual-desktop/overview

O Windows Virtual Desktop no Azure é um serviço de virtualização de desktop executado na nuvem. Ele permite que seus usuários usem uma versão do Windows hospedada na nuvem a partir de qualquer local. O Windows Virtual Desktop funciona em dispositivos tipo Windows, Mac, iOS, Android e Linux. Funciona com aplicativos que você pode usar para acessar desktops e aplicativos remotos. Você também pode usar a maioria dos navegadores modernos para acessar seu Windows Virtual Desktop.

Pensa assim, você tem um time de desenvolvedores que trabalha remoto e enviar notebooks pra eles demora pra chegar e é caro, além do que o note pode ser perder nos correios. Esse é um bom cenário pra se implementar WVD. Usando o WVD o funcionário pode ser logar através de acesso remoto ou browser e funcionar como um thin-client (quem lembra disso? rs), deixando todo poder computacional no WVD, conexões, dados, dando mais segurança pra empresa de que nada será tirado da rede deles e nem nada será colocado “sem querer”. WVD ainda facilita o controle e gerenciamento do time de segurança na hora de aplicar politicas de segurança nas máquinas e na rede como um todo.

Benefícios e usos do Windows Virtual Desktop (WVD) são;
Melhor experiência para o usuário: você pode utilizar o WVD através do seu computador, ou usando um browser com suporte HTML5.
Menor tempo de load: como seus bancos de dados e apps estão na nuvem, seu desktop virtual também pode estar bem pertinho, diminuindo tempo de load, latência entre o desktop e os serviços que usa.
User profile sign-in: seu usuário fica na nuvem, então carregar seu usuário em um desktop virtual do WVD é bem rápido, não precisa ficar esperando o profile carregar como normalmente teria se você tivesse puxando um profile num desktop físico.
Maior segurança: você pode facilmente habilitar autenticação multi-factor (MFA) nos seus desktops virtuais e também pode dar permissões mais granulares com RBAC.

Referências

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

https://www.udemy.com/course/introducao-ao-microsoft-azure-certificacao-az-900/

https://www.exampro.co/az-900

Azure AZ-900 Describe core resources available in Azure | Network

Este é o segundo tópico do módulo “Describe Core Azure Services (15-20%)”.

Para encontrar todos outros posts para estudo da certificação Azure AZ-900 acesse:
Azure AZ-900: Microsoft Azure Fundamentals

Describe Core Azure Services (15-20%)

Describe core resources available in Azure

  • describe the benefits and usage of Virtual Networks, VPN Gateway, Virtual Network peering, and ExpressRoute

Virtual Networks

fonte:
https://www.youtube.com/watch?v=5NMcM4zJPM4&list=PLGjZwEtPN7j-Q59JYso3L4_yoCjj2syrM&index=11
https://docs.microsoft.com/en-us/learn/modules/azure-networking-fundamentals/azure-virtual-network-fundamentals
https://docs.microsoft.com/en-us/azure/networking/fundamentals/networking-overview
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview

Virtual Networks (VNet) são recursos fundamentais pra criação da sua rede no Azure. Você pode utilizar as Virtual Networks para: comunicar entre diferentes recursos na Azure; comunicar entre diferentes virtual networks; comunicar com a internet; comunicar com redes privadas (on-premises).

Usando Virtual Networks os recursos da Azure podem conversar uns com os outros das seguintes formas: usando uma virtual network; service endpoints; e VNet peering.

Service endpoints são como conexões ponto a ponto entre recursos Azure (detalhamento do Service Endpoints https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview)

VNet peering é uma forma de conectar networks entre si, dessa forma todos recursos de uma rede podem falar com os recursos da outra. Os recursos podem até estar em Regions diferentes da Azure (detalhamento do VNet Peering https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview).

Já pra se conectar a recursos on-premise você pode usar: point-to-site VPN; site-to-site VPN; ou Azure ExpressRoute. Point-to-site é vpn do seu pc para rede na Azure, site-to-site é sua rede on-premises numa rede da Azure, e ExpressRoute a gente fala na sequencia.

Outros pontos importantes no uso das VNets são: isolation e segmentation; ou seja, usando VNets você pode criar redes isoladas uma da outra e subdividir (segmentar) uma rede em sub-redes (subnets), definindo range de ips e máscaras.

Por padrão todas VNet estão conectadas na internet. Você pode habilitar isso definindo um IP público ou um Load Balancer público.

Virtual Network peering

fonte:
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq#vnet-peering

VNet peering serve pra tu conectar duas ou mais VNets. Usando peering é como se as redes conectadas fossem uma só, de forma que, uma VM (máquina virtual) acharia outra VM na rede, mesmo elas em Regions diferente do Azure.

Existem dois tipos de peering: virtual network peering e global virtual network peering, sendo que o global é quando as VNets estão em regions diferentes.

Usar peering é vantagem pois proporciona uma latência menor, uma banda mais larga, capacidade de se transferir dados entre diferentes Vnets que estejam nesse peering.

O tráfego usando peering é privado, ocorre dentro da Azure, não vai pra internet.

VPN Gateway

fonte:
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways
https://docs.microsoft.com/en-us/learn/modules/azure-networking-fundamentals/azure-vpn-gateway-fundamentals
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-vpn-faq

VPN Gateway é um tipo de gateway, que é colocado numa VNet pra habilitar uma conexão segura entre um destino e outro, geralmente entre uma rede on-premises e uma VNet Azure. Cada VNet só pode ter um gateway de VPN, porém várias conexões de fora podem se conectar nesse gateway pra acessar sua Azure VNet.

Por exemplo, se você tem uns servidores físicos num lugar e quer conectar usando uma conexão segura, criptografada, você pode fazer isso usando uma VPN. VPNs na Azure podem ser do tipo site-site, point-to-site e network-to-network. E as VPNs podem ser do tipo Policy-based ou Route-based.

Policy-based VPNs, ou static-routing VPN, são VPNs que criptografam e direcionam os pacotes de dados pelos túneis de IPSec de acordo com a combinação de prefixos de endereços IP entre sua rede on-premises e a Azure VNet.

Route-based ou Dynamic-routing VPN, são VPNs que usam rotas na tabela de IP Forwarding pra direcionar os pacotes para suas interfaces de túnel correspondentes. As interfaces do túnel então criptografam ou descriptografam os pacotes que entram e saem dos túneis. (você entendeu? nem eu, rs).

ExpressRoute

fonte:
https://docs.microsoft.com/en-us/azure/expressroute/
https://docs.microsoft.com/en-us/azure/expressroute/expressroute-introduction
https://docs.microsoft.com/en-us/azure/expressroute/expressroute-faqs
https://docs.microsoft.com/en-us/learn/modules/azure-networking-fundamentals/express-route-fundamentals

ExpressRoute é uma rede on-premises que você cria dentro do Azure. Então você contrata um link dedicado com um parceiro da Microsoft e ele passe esse link pra dentro da Azure, é básicamente isso.

Conexões usando ExpressRoute não vão pra internet, o que ajuda na questão da segurança, confiabilidade, velocidades maiores, latencias consistentes, se comparada com a internet pública.

Visualization that shows a high-level overview of the Azure ExpressRoute service.

ExpressRoute usa um protocolo chamado de BGP, que é utilizado pra fazer com que os serviços da Microsoft Cloud funcionem como se fosse uma rede privada on-premises sua.

ExpressRoute tem 3 modelos diferentes de conexão, CloudExchance colocation, point-to-point ethernet connection, any-to-any connection.

Visualization of Azure connectivity models.

Point-to-point é como ter um datacenter on-premises seu conectado via ethernet na Microsoft.

Any-to-any você pode conectar várias redes diferentes numa WAN e conectar essa WAN na Microsoft.

Colocation é como se seu datacenter tivesse dentro de um ISP (um provedor de internet, tipo um localWeb, e tu vai e conecta ele direto na cloud da Microsoft.

Referências

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

https://www.udemy.com/course/introducao-ao-microsoft-azure-certificacao-az-900/

https://www.exampro.co/az-900

Power BI Fonte Pequena no Gráfico modo Foco

Coisa simples, pessoal, mas quero ver se posto mais coisas simples no blog pra ajudar qualquer um que esteja passando por situação parecida.

Resumindo: tinha um gráfico com números pequenos e quando dava foco nele o número continuava pequeno. O cliente queria que o número ficasse maior quando em foco.

Como era

No report do cliente a página tem 7 gráficos idênticos a esse, com o mesmo tamanho, fonte, estilos, etc. Então, como você pode ver, é pequeno e se der foco, continua pequeno.

Perceba que na configuração de página do relatório estou usando o tipo 16:9, padrão.

clique pra aumentar

Em foco fica assim:

clique pra aumentar

Então perceba que, fica pequeno e difícil de ler.

Como resolvi

Simplesmente aumentei o tamanho da págino de 16:9 pra custom com 1920 x 1080, redimensionei as fontes de tamanhos, também aumentei um pouco o tamanho do chart e tirei decimais do data label.

O resultado ficou assim:

clique pra aumentar

E o resultado com foco:

clique pra aumentar

Coisa simples, mas espero que possa ajudar alguém, como foi meu caso, hehe.

Azure AZ-900 Describe the core Azure architectural components

Este é o primeiro tópico do módulo “Describe Core Azure Services (15-20%)”.

Para encontrar todos outros posts para estudo da certificação Azure AZ-900 acesse:
Azure AZ-900: Microsoft Azure Fundamentals

Describe Core Azure Services (15-20%)

Describe the core Azure architectural components

  • describe the benefits and usage of Regions and Region Pairs

fonte:
https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions
https://docs.microsoft.com/en-us/azure/availability-zones/az-overview
https://docs.microsoft.com/en-us/azure/virtual-machines/regions
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/regions-availability-zones

Region é um conjunto de datacenters interligados entre si num perímetro de até 300 milhas – quando possível – e que utilizam rede de baixa latência. Então podemos dizer que Region são datacenters em algum lugar, como mostra o mapa acima. Perceba que no Brazil South temos uma região do tipo “Availability Zone” (AV), falo sobre isso na sequência. Mesmo que uma Region não seja do tipo AV ela ainda pode ter mais que um datacenter no mesmo local.

Region Pairs consiste em duas ou mais Regions dentro da mesma geografia (EUA com EUA, Europa com Europa). Dessa forma Azure garante que problemas como incêndios, guerras, desastres naturais, não afetem o serviço como um todo, uma vez que a Região pode assumir os serviços da outra.

AzureGeography

Atualizações no ambiente do Azure são feitas em uma Region de cada vez, de forma a não gerar outage do serviço.

Alguns serviços da Azure replicam dados automaticamente usando Region Pairs pra garantir alta disponibilidade desses dados, como é o caso do Azure Geo-redundant Storage (GRS)

Importante: nem todos serviços replicam dados automaticamente, nem todos serviços se recuperam automaticamente usando seus pares. Nesses casos o cliente deve configurar a replicação e recuperação ele mesmo.

Os benefícios para uso de Region Pairs são
– physical isolation; quando possível os datacenters estarão no mínimo a 300 milhas uns dos outros. Essa separação física previne ou diminui a chance de problemas como falta de energia, guerras, desastres naturais, etc.
– platform-provided replication; alguns serviços fazem replicação automática entre regiões pares, como o exemplo do GRS.
– region recovery order; no caso de algum problema generalizado de outage a recuperação de uma região de cada par é priorizada. Aplicações que fazem uso dessas regiões tem garantido que pelo menos uma das regiões será recuperada com high priority. Aplicações que não fazem uso de regiões pares podem acabar tendo sua região como a última recuperada e gerar um outage maior.
– sequencial updates; atualizações planejadas do Azure são feitas em cada região de uma vez, pra diminuir o tempo de downtime, ou efeito de bugs ou falhas lógicas no caso de um update ruim.
– data residency; os dados ficam resididos na mesma geografia para atender propósitos jurídicos e de impostos.

exemplo de region pairs

Lista de Region Pairs: https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions#azure-regional-pairs

  • describe the benefits and usage of Availability Zones

fonte:
https://docs.microsoft.com/en-us/azure/availability-zones/az-overview
https://docs.microsoft.com/en-us/azure/availability-zones/az-region
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/regions-availability-zones

Entendemos que uma Region é composta de vários datacenters e podem ter datacenters pareados entre Regions, que eles chamam de Region Pairs. Sabemos também que esses datacenters podem estar interligados em rede de baixa latência e afastados entre si para evitar que problemas afetem mais de um datacenter ao mesmo tempo.

conceptual view of an Azure region with 3 zones

Availability Zones (AZs) são locações físicas únicas dentro de uma Region, portanto dentro de uma Region podemos ter várias AZs. Cada AZ é composta por um ou mais datacenters com independência de energia, rede, resfriamento, e estão separadas fisicamente entre si para prevenir problemas de desastre naturais e outros tipos de catástrofes que possam gerar outage dos serviços como um todo.

Todas AZs são arquitetadas pensando em ser resilientes a problemas num nível de Region, de forma que tenhamos serviços com high availability. Nas Regions que tem AZs habilitadas existe sempre um mínimo de 3 AZs. Quando existe algum problema dentro de uma Region as AZs são trazidas de volta uma a uma. As manutenções críticas também são realizadas uma zone por vez dentro de cada Region.

Zone-redundant services; esse tipo de serviço replica seus dados e aplicações entre AZs dentro de uma mesma Region.

Uma AZ em um Region é um domínio de falha e de atualização, de forma que, se por exemplo, você tem 3 ou mais VMs espalhadas por 3 AZs, então suas VMs estão efetivamente distribuídas por 3 diferentes domínios de falha e de atualização. O Azure reconhece essa distribuição por 3 AZs diferentes e garante que essas VMs não sejam atualizadas ao mesmo tempo (pra não gerar indisponibilidade).

conceptual view of one zone going down in a region

Para garantir durability e high availability construa seus serviços utilizando diferentes AZs em Region Pairs. Você pode replicar de forma síncrona seus aplicativos e dados usando AZs em uma Region para alta disponibilidade e replicar de forma assíncrona entre Regions para proteção de recuperação de desastre.

Os serviços do Azure que oferecem suporte a AZs se enquadram em três categorias:
– Zonal services; aqui o recurso do Azure é definido a uma AZ específica. Se for preciso você pode replicar seus dados e serviços para uma ou mais AZs dentro da mesma Region.
– Zone-redundant services; os serviços desse tipo são automaticamente replicados entre diferentes AZs
– Non-regional services; Os serviços estão sempre disponíveis nas geografias do Azure e são resilientes a interrupções em toda a zona e também em toda a Region.

  • describe the benefits and usage of Resource Groups

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/overview
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview

Screenshot of the hierarchy for objects in Azure.

A estrutura de organização do Azure tem quatro níveis, conforme podem ser visto na imagem acima: Management groups, Subscriptions, Resource groups, Resources. Cada uma delas é descrita em detalhes nos tópicos a seguir.

Nesse tópico vamos falar de Resource Groups, que são containers lógicos onde agrupamos Resources, com objetivo de organizar o gerenciamento desses recursos. Você decide quais recursos pertencem a um Resource GRoups com base no que faz mais sentido para sua organização.

Resources são tudo o que você cria com uma Subscription do Azure, como VMs, instâncias do Gateway, e instâncias do Azure Cosmos DB. Todos os Resources devem estar em um Resource Group e um Resource só pode ser membro de um único Resource Group. Muitos Resources podem ser movidos entre Resource Groups, com alguns Resources tendo limitações ou requisitos específicos para mover. Os Resource Groups não podem ser aninhados. Antes que qualquer Resource possa ser provisionado/criado/instanciado, você precisa de um Resource Group para colocá-lo.

Geralmente, adicione Resources que compartilham o mesmo ciclo de vida ao mesmo Resource Group para que você possa implementá-los, atualizá-los e excluí-los facilmente como um grupo.

Se você excluir um Resource Group, todos os Resources contidos nele também serão excluídos. Organizar recursos por ciclo de vida pode ser útil em ambientes de não produção, onde você pode tentar um experimento e depois descartá-lo. Os Resource Groups facilitam a remoção de um conjunto de recursos de uma só vez.

Os Resource Groups também são utilizados para aplicar permissões RBAC (role-based access control). Ao aplicar permissões RBAC a um Resource Group, você pode facilitar a administração e gerenciamento de acesso aos Resources para permitir apenas o que é necessário.

Resource Groups armazenam metadados sobre os Resources. Portanto, ao especificar um local para o Resource Group, você está especificando onde esses metadados serão armazenados. Por motivos de compliance, pode ser necessário que seus metadados sejam armazenados na mesma Region que seus dados ou suas aplicações, mas também é possível que o Resource Group seja criado numa Region diferente das que seus Resources.

Pontos de atenção:

  • Todos os Resources em um Resource Group devem compartilhar o mesmo ciclo de vida. Você os implanta, atualiza e exclui juntos. Se um recurso, como um servidor, precisa existir em um ciclo de implantação diferente, ele deve estar em um Resource Group diferente.
  • Cada Resource só pode pertencer a um único Resource Group.
  • Você pode adicionar, mover ou remover recursos de um Resource Group a qualquer momento.
  • Se a Region do Resource Group estiver indisponível, você não poderá atualizar os recursos desse Resource Group porque os metadados estarão indisponíveis. Os recursos em outras Regions ainda funcionarão normalmente, mas você não poderá atualizá-los.
  • Através do Resource Group você pode aplicar controle administrativo a todos recursos do grupo, através de Azure Policies, Azure Roles ou Resource Locks.
  • Você pode aplicar tags a Resource Groups, mas os recursos não herdam automaticamente essas tags.
  • Um recurso pode se conectar a recursos em outros Resource Groups. Este cenário é comum quando os dois recursos estão relacionados, mas não compartilham o mesmo ciclo de vida.
  • Você pode implantar até 800 instâncias de um tipo de recurso em cada Resource Group.
  • Existem alguns Resources específicos que podem existir fora de Resource Groups.
  • describe the benefits and usage of Subscriptions

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/management-groups-subscriptions
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/subscriptions/
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions

Diagram showing Azure subscriptions using authentication and authorization to access Azure accounts.

Azure Subscription (ou assinatura), como podemos ver na imagem acima, é uma unidade lógica de serviços do Azure que se vincula a uma conta do Azure, que é uma identidade no Azure Active Directory (Azure AD) ou em um diretório em que o Azure AD confia.

Uma Azure Subscription fornece acesso autenticado e autorizado aos produtos e serviços do Azure. Também permite provisionar recursos.

Uma conta pode ter uma ou várias Subscriptions com diferentes modelos de faturamento e às quais você aplica diferentes políticas de gerenciamento de acesso. Existem dois tipos de limites de assinatura que você pode usar:

Billing Boundary; Este tipo de assinatura determina como uma conta do Azure é cobrada pelo uso do Azure. Você pode criar várias subscriptions para diferentes tipos de requisitos de faturamento. O Azure gera relatórios de cobrança e faturas separados para cada subscription para que você possa organizar e gerenciar os custos.

Access control boundary; O Azure aplica políticas de gerenciamento de acesso no nível de subscription e você pode criar subscription separadas para refletir diferentes estruturas organizacionais. Um exemplo é que, em uma empresa, você tem departamentos diferentes aos quais aplica políticas de subscriptions distintas do Azure. Este modelo de cobrança permite que você gerencie e controle o acesso aos recursos que os usuários provisionam com assinaturas específicas.

Além desses limites descritos acima, você pode criar subscriptions adicionais com o simples propósito de organização do seu faturamento. Por exemplo, você pode criar assinaturas adicionais pra separar seu faturamento por:

Ambiente; você pode criar uma subscription diferente pra cada ambiente, de teste, produção ou algum outro ambiente necessário. Dessa forma os acessos aos recursos já ficam controlados num nível de assinatura.

Estrutura Organizacional; também pode criar assinaturas pra cada departamento, assim fica mais fácil controlar qual departamento tem acesso a quais recursos. Por exemplo, você pode criar uma assinatura pra TI onde esse time terá acesso a todos os recursos disponíveis, enquanto em outra assinatura um time de contabilidade tem acesso apenas a recursos mais simples.

Tipo de Faturamento; seus custos na Azure são agrupados primeiro num nível de assinatura, portanto pode ser interessante criar assinaturas pra controlar e acompanhar suas faturas na Azure. Por exemplo, você pode criar uma assinatura pra ambiente de Prod e outra pra ambiente de Dev, dessa forma fica fácil compara quanto está custando cada um desses ambientes apenas olhando o faturamento de cada uma dessas duas assinaturas.

Existem alguns limites nas assinaturas, por exemplo, o número máximo de Azure ExpressRoute circuits por assinatura é de 10, portanto ao planejar suas assinaturas, levem esses limites em consideração.

business oriented subscription design
um exemplo de distribuição de subscriptions
Mixed subscription strategy
outro exemplo de distribuição de subscriptions

Subscriptions, ou assinaturas, podem ser organizadas em “invoice sections”. Cada invoice section é uma linha na invoice (nota fiscal) que mostra quanto foi gasto mensalmente, ou seja, você pode pegar uma ou duas ou três assinaturas e colocar tudo na mesma invoice section, que daí na invoice vai aparecer como uma linha agregada.

Você também pode criar perfis diferentes para faturamento, ou seja, pode criar um “billing profile” que contém um conjunto de invoices section e subscriptions pro setor de compras e outro billing profile com outras invoices e assinaturas pro setor de vendas.

Flowchart-style diagram showing an example of setting up a billing structure where different groups like marketing or development have their own Azure subscription that rolls up into a larger company-paid Azure billing account.
billing profiling
  • describe the benefits and usage of Management Groups

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/management-groups-subscriptions
https://docs.microsoft.com/en-us/azure/governance/management-groups/overview
https://docs.microsoft.com/en-us/azure/governance/management-groups/
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/govern/resource-consistency/resource-access-management#what-is-azure-resource-manager

Se você tem várias subscriptions e quer organizar tudo de uma forma melhor utilize os Management Groups (vou abreviar para MG). Através os Management Groups você pode definir nível de acesso, políticas (policies) e compliances para as subscriptions pertencentes aos Management Groups.

Assim como Resource Groups são containers de Resources, Management Groups são containers de Subscriptions.

Todas as assinaturas dentro de um MG herdam automaticamente as condições aplicadas nesse MG. Os MG fornecem gerenciamento de nível empresarial em grande escala, não importa o tipo de assinatura que você possa ter. Todas as assinaturas em um único MG devem confiar no mesmo tenant do Azure AD.

Por exemplo, com MG você pode aplicar políticas que não permitam a criação de VMs em regions que você não queira. Essa política seria então aplicada a tudo que estiver embaixo desse MG, sendo: outros MG, subscriptions, e resources. Essa política aplicada a nível de MG não pode ser alterada a nível de subscription ou recurso, o que facilita a governança da sua estrutura.

Você também pode dar acesso a todas subscriptions que estiverem dentro do seu MG, ou seja, se seu MG tem várias assinaturas você pode facilmente dar acesso a todas elas de uma só vez. Você pode criar uma atribuição role-based access control (RBAC) no MG, que aplicará esse acesso a todas as assinaturas. Uma atribuição no MG pode permitir que os usuários tenham acesso a tudo o que precisam, em vez de criar scripts RBAC em assinaturas diferentes.

Diagram showing an example of a management group hierarchy tree.
estrutura de Management Groups e Assinaturas

Pontos importantes:

  • 10 mil management groups podem existir em cada diretório
  • Uma árvore de Management Group pode ter até 6 níveis de profundidade. Esse limite não inclui o root nem o nível de assinatura (ou seja, 6 Management Group um embaixo do outro, além do root).
  • Cada Management Group e Assinatura só suporta 1 parente
  • Cada Management Group pode ter vários filhos
  • Todos Management Groups e Assinaturas ficam dentro de uma única hierarquia dentro do mesmo diretório
  • describe the benefits and usage of Azure Resource Manager

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/resources-resource-manager
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview

Azure Resource Manager (abrevia ARM, ou Gerenciador de Recursos em português), como o nome já diz, é uma camada de orquestração dos recursos na Azure. É através dele que você cria, atualiza, e deleta seus recursos na Azure, e também gerencia coisas como controle acesso, travas e tags pra organizar e deixar mais seguro seus recursos depois de serem deploiados.

Diagram showing a Resource Manager request model.

A imagem acima mostra como a camada do Resource Manager trata requisições.

Quando uma requisição é feita para um serviço da Azure é o Resource Manager recebe essa requisição e faz sua autenticação, e depois transmite essa requisição para os serviços da Azure (os recursos). Como todas requests são tratadas pela mesma API (Resource Manager), você vê resultados e recursos consistentes em todas as diferentes ferramentas.

Todos os recursos que estão disponíveis no portal do Azure também estão disponíveis por meio do PowerShell, CLI do Azure, REST APIs e client SDKs. A funcionalidade inicialmente lançada por meio de APIs será representada no portal em 180 dias após o lançamento inicial.

Reforçando os níveis de escopo do Azure

Management levels
azure levels of scope

No Azure existem 4 nívels de escopo: Management Groups, Subscriptions, Resource Groups, Resources.

Isso significa que, permissões, políticas, regras, travas, e demais configurações de gerenciamento podem ser aplicadas a cada um desses níveis, sendo que os níveis mais baixos herdam dos níveis mais altos.

Existem também outra coisa chamada de “template”, que são arquivos JSON que definem uma série de comportamentos e que podem ser aplicados nos seguintes níveis: tenants, management groups, subscriptions, ou resource groups. Acredito que templates não devem cair na prova, mas aqui vai o link sobre o assunto: https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview

Azure Resource Manager connecting to the Microsoft.Compute resource provider
visão de uso do ARM

Benefícios do uso do Azure Resource Manager (ARM)

  • Através do ARM você pode gerenciar seu ambiente através de templates e não apenas de scripts.
  • ARM permite você gerenciar e monitorar todos seus recursos como um grupo, ao invés de fazer isso individualmente recurso por recurso.
  • Redeploy da sua solução ao longo do ciclo de vida de desenvolvimento e garante que seus recursos serão deployados em um estado consistente.
  • Defina as dependências entre os recursos para que sejam deployados na ordem correta.
  • Aplica controle de acesso em todos serviços através do RBAC que é nativo no ARM.
  • Aplica tags nos recursos pra organizá-los de forma lógica dentro da sua subscription.
  • Aumenta a clareza na hora do faturamento porque os custos dos recursos pode ser visto de acordo com o agrupamento de recursos que compartilham a mesma tag.
  • explain Azure resources

fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/resources-resource-manager
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/govern/resource-consistency/resource-access-management

Resources (recursos em pt-br) são qualquer coisa que você cria numa Azure Subscription, como VMs, Gateways de Aplicação, instâncias do Cosmos DB, etc. Todos recursos precisam estar dentro de um Resource Group, e cada recurso só pode estar em apenas um Resource Group por vez. Muitos recursos podem ser movidos entre Resource Groups, com alguns deles tendo algumas limitações específicas pra realizar esse movimento. Antes de qualquer recurso ser criado (provisionado é a palavra certa) você precisa ter um Resource Group pra colocar ele dentro.

Na Azure o termo RESOURCE se refere a uma entidade gerenciada pela Azure, como por exemplo as VMs, Virtual Networks, Storage Accounts, etc, tudo isso são chamados de Resource (ou recursos) na Azure.

exemplos de alguns recursos

Referências

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

https://www.udemy.com/course/introducao-ao-microsoft-azure-certificacao-az-900/

https://www.exampro.co/az-900

Azure AZ-900 Describe Cloud Concepts (20-25%)

Acesse a página principal com as informações agrupadas sobre AZ-900 clicando aqui!

Resolvi estudar pra tirar a certificação “AZ-900: Microsoft Azure Fundamentals”, e como de costume, vou compartilhar vocês meus resumos, que uso como base pra estudar para prova!

Se você quer saber todos detalhes da certificação, verifique no site da Microsoft, clicando aqui.

A primeira parte já é uma das mais importantes, com 20 a 25% de peso.

Describe Cloud Concepts (20-25%)

Identify the benefits and considerations of using cloud services

fonte: https://docs.microsoft.com/en-us/learn/modules/fundamental-azure-concepts/benefits-of-cloud-computing

  • identify the benefits of cloud computing, such as High Availability, Scalability, Elasticity, Agility, and Disaster Recovery

    Cloud computing é vantajoso por vários motivos, alguns deles sendo essas características de High Availability, Scalability, Elasticity, Agility e Disaster Recovery.

    High Availability; significa que seu ambiente se mantém disponível, ou seja, imagina num cenário on-premises, onde você instala sua aplicação num servidor dedicado, e aí esse servidor vai e queima ou para de funcionar, lascou. Já na cloud isso não acontece, simplesmente pelo modelo de infraestrutura que existe por trás de uma cloud. No Azure existem as Availability Zones, então se uma zona cair a outra assume, além disso mesmo dentro da mesma zona existem vários servidores de backup distribuídos por trás de um Load Balancer.

Scalability; apps na cloud podem escalar vertical ou horizontalmente. Isso significa que seu ambiente pode ser aumentado de acordo com aumento de tráfego, necessidade de mais memória ou processamento. Escala vertical aumenta o poder computacional aumentando ram e cpu da sua maquina virtual, enquanto que escala horizontal aumenta o poder computacional adicionando instancias de recursos, como adicionando VMs no seu ambiente atual.

Elasticity; é a capacidade de realizar scalability automaticamente, aumentando ou diminuindo seu ambiente da forma que for necessária pro seu negócio, de forma que você sempre tenha os recursos computacionais necessários, nem sobrando, nem faltando.

Agility; é ser ágil, rápido, colocar ou remover recursos no seu ambiente de cloud de forma rápida e dinâmica de acordo com a necessidade do seus apps.

Disaster Recovery; recuperação de desastre é a capacidade de se recuperar de desastres e o ambiente de cloud permite isso pois nele temos alta redundância de computadores, load balancers, várias zonas, poder computacional distribuído em várias regiões do mundo, o que garante que, se explodir o datacenter do Brasil, seus dados estarão replicados no datacenter dos Estados Unidos, por exemplo.

  • Identify the differences between Capital Expenditure (CapEx) and Operational Expenditure (OpEx)

    Capex; ou Capital Expenses, despesas de capital, são gastos antecipados de dinheiro com infra física e que depois é diluído ao longo do tempo que você faz uso dessa infra.

    Opex; cloud é sempre Opex, pelo menos pra o exame, foi o que eu ouvi nos vídeos e nos treinamentos oficiais que participei da Microsoft. Opex significa Operational Expenses, ou despesas operacionais, que nada mais são do que gastos com serviços ou produtos. Não há nenhum custo antecipado, pois você paga por um serviço ou produto conforme usa.
  • describe the consumption-based model

    O modelo de consumo do Azure opera de forma “pague conforme consumo”, onde você só paga pelos recursos que utilizar. Isso traz uma melhor previsão de custo, preços melhores porque você paga somente por exatamente o que você precisa e a cobrança só é feita de acordo com o uso. Alguns dos benefícios desse modelo de consumo são:
    – Não existem custos iniciais, você não precisa desembolsar uma grana logo de cara;
    – Não gasta dinheiro comprando infra que não será totalmente aproveitada;
    – Se precisar de mais recursos pode pagar apenas quando esses recursos forem necessários;
    – Se não precisar mais de recursos alocados pode simplesmente desalocar eles e parar de pagar por isso.

Describe the differences between categories of cloud services

fonte: https://docs.microsoft.com/en-us/learn/modules/fundamental-azure-concepts/types-of-cloud-computing

  • describe the shared responsibility model

fonte: https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility

Illustration showing the cloud responsibility model.
responsabilidades compartilhada de acordo com tipos de cloud

O modelo de responsabilidade compartilhada muda de acordo com o tipo de serviço de cloud utilizado (IaaS, PaaS, SaaS).

Em um cenário de on-premises toda responsabilidade é do usuário, e a medida que passamos para nuvem a responsabilidade vai sendo transferida entre usuário e Microsoft.

  • describe Infrastructure-as-a-Service (IaaS),

IaaS nada mais é do que alugar recursos computacionais na nuvem, mas de forma que você tenha total controle do hardware que você alugou, ou seja, ao invés de comprar o servidor como fazemos no on-premises, você pode alugar ele na nuvem.

Nesse modelo a cloud vai manter seu ambiente de hardware atualizado, mas toda manutenção de app, sistema operacional, configuração de rede fica sob sua responsabilidade. Um exemplo de IaaS são as Virtual Machines.

IaaS é o serviço mais flexível da cloud, o objetivo aqui é te dar total controle sob o hardware.

Vantagens do IaaS são:
– Nada de CAPEX: você não tem custos iniciais, porque na cloud você só paga pelo que precisa e quando usar.
– Agility: rápido e fácil de adicionar ou remover recursos computacionais.
– Gerenciamento: aqui o modelo de responsabilidade compartilhada se aplica; o usuário gerencia e mantêm os serviços que ele provisiona e a cloud fica responsável por manter a infra.
– Skills: não precisa ter muita habilidade ou conhecimento pra usar os recursos computacionais da cloud, porque a parte de disponibilizar a máquina e a infra fica por conta da cloud.
– Flexibilidade: você pode configurar o hardware cedido pela cloud da forma que for necessário para o seu negócio.

  • describe Platform-as-a-Service (PaaS)

fonte: https://azure.microsoft.com/pt-br/overview/what-is-paas/

No PaaS, assim como no IaaS você recebe a infra, mas além disso ainda recebe software, de forma que você não precisa se preocupar em comprar licenças de um SQL Server, por exemplo, ou de um sistema operacional.

PaaS é ainda mais ágil que o IaaS, uma vez que você não precisa mais configurar servidores e nem aplicações. PaaS permite que você foque no que é importante pra você, que é desenvolver suas aplicações. PaaS também facilita trabalhar com times distribuídos em diferente localidades, pois pode facilmente tornar a plataforma acessível a nível global.

  • describe serverless computing

Assim como PaaS, serverless computing permite como que desenvolvedores construam apps mais rapidamente eliminando a necessidade de qualquer controle de infra.

Nesse modelo de serverless computing claro que ainda existem os servidores por trás, mas eles são invisíveis para o desenvolvedor, a ideia é de que o dev foque tão e somente na app que ele está desenvolvendo e deixando a preocupação de quanto poder computacional, se vai precisar de mais ou menos servidores, se vai precisar de mais cpu ou ram para a cloud.

Nesse modelo de serverlerss computing o ambiente é altamente escalável e orientado a eventos, alocando ou desalocando recursos de acordo com os eventos mencionados.

O objetivo com serverless computing é aumentar a produtividade do time, trazer produtos mais rapidamente para o mercado e permitir que as empresas otimizem seus recursos e foquem na inovação.

  • describe Software-as-a-Service (SaaS)

No SaaS a cloud gerencia tudo, menos os dados e acessos, claro. Nesse modelo todos aspectos como, infra, virtual machines, recursos de rede, armazenamento de dados, sistemas operacionais e até mesmo a aplicação fica por conta da cloud, como gmail, spotify, netflix, por exemplo. Tudo que precisamos é inputar os dados.

No SaaS a app é provisionada pela cloud e geralmente apenas uma versão do app é disponibilizada para todos usuários e seu licenciamento é feito geralmente por uma mensalidade.

No SaaS temos a modalidade de pagamento “Pay as you go”, onde os usuários pagam de acordo com o modelo de assinatura, geralmente mensal ou anualmente, independente de quanto daquele app eles usaram ou não.

  • identify a service type based on a use case

fonte:
https://azure.microsoft.com/en-in/blog/how-i-choose-which-services-to-use-in-azure/
https://azure.microsoft.com/en-us/overview/what-is-cloud-computing/#uses
https://azure.microsoft.com/en-gb/overview/cloud-computing-dictionary/

tipos de cloud

Identificar um tipo de serviço com base num caso de uso. Aqui é conhecer bem os tipos de serviço disponíveis, como na imagem acima.

E se perguntar algumas perguntas, tipo “quanto controle eu preciso”, ou seja, preciso de um colocar isso num ambiente IaaS, ou PaaS, ou SaaS? Porque em cada um desses ambientes você vai ter responsabilidades e controles diferentes.

Também pode se perguntar “onde minha app deve rodar”? Tem que ser on-premises, ou pode ser na cloud? Leiam o artigo da fonte, ele explica melhor sob como tomar essas decisões.

Describe the differences between types of cloud

  • define cloud computing

fonte: https://azure.microsoft.com/en-us/overview/what-is-cloud-computing/

Falando de forma simples, Cloud Computing é a entrega de serviços de computação – incluindo servidores, armazenamento, bancos de dados, rede, software, análise e inteligência – pela Internet (“a nuvem”) para oferecer inovação mais rápida, recursos flexíveis e economias em escala. Normalmente, você paga apenas pelos serviços em nuvem que usa, ajudando a reduzir seus custos operacionais, administrar sua infraestrutura com mais eficiência e escalar conforme suas necessidades de negócios mudam.

Sao tipos de cloud computing: public, private e hibrida.

São tipos de serviços de cloud computing: IaaS, PaaS, SaaS.

Tipos de uso de cloud computing: Criar cloud-native applications; Armazenar dados, fazer backup de dados e recuperar dados; Stream de audio e video; Desenvolver software sob demanda; Testar e construir apps; Analisar dados; Desenvolver modelos inteligentes (IA)

Vantagens de se usar cloud computing: Custo, Agility, Scalability, Performance, Segurança, Produtividade, Confiabilidade

  • describe Public cloud

fonte: https://azure.microsoft.com/en-us/overview/what-is-a-public-cloud/

Existem 3 formas de se “deploiar” cloud computing, que são os tipos de cloud pública, privada e híbrida.

Na nuvem pública os serviços oferecidos estão disponíveis de forma pública, pra qualquer um que queira pagar por eles. Recursos de cloud como servidores e armazenamento são proprietários da cloud, operados pela cloud e disponibilizados na internet. Isso não quer dizer que qualquer um pode entrar na cloud e usar um serviço seu que esteja hospedado em uma nuvem pública.

Em cloud pública não tem gasto up-front, ou seja, você não precisa comprar infra nem nada logo de cara, você só vai pagar pelo que usar, quando usar. Recursos podem ser rapidamente e facilmente provisionados ou desprovisionados.

  • describe Private cloud

fonte: https://azure.microsoft.com/en-us/overview/what-is-a-private-cloud/

A cloud privada é criada pela empresa, dela pra ela mesma. Nesse modelo você vai precisar fazer todo investimento necessário pra criar um ambiente de cloud, vai ter que comprar os computadores, montar toda infra, a rede, armazenamento, ou seja, vai ter que desembolsar uma grana violenta logo de cara. Uma vez que essa cloud privada esteja pública ela pode fornecedor poder computacional pra sua própria empresa.

Clouds privadas podem estar no datacenter da própria empresa, ou também em datacenters de terceiros.

Em clouds privadas você tem controle de tudo, mas também fica responsável por tudo, como manutenção de hardware, updates, etc.

  • describe Hybrid cloud

fonte: https://azure.microsoft.com/en-us/overview/what-is-hybrid-cloud-computing/

Cloud hibrida é um ambiente de cloud que combina a cloud publica e a privada permitindo que dados e apps sejam compartilhados entre elas. Esse tipo de cloud é considerada a mais flexível e é a empresa que determina o que vai rodar aonde. Cloud hibrida é especialmente utilizada quando existem requerimentos específicos de segurança, compliance ou jurídicos.

  • compare and contrast the three types of cloud computing

fonte: https://docs.microsoft.com/en-us/learn/modules/fundamental-azure-concepts/types-of-cloud-computing

Quando comparadas as três diferentes tipos de ambiente de cloud nós temos quatro tópicos que valem a pena serem observados; sendo Custo, Segurança, Nível de Personalização/Configuração, Conhecimento Técnico necessário.

Traduzindo a imagem abaixo, para:

Public cloud;
– Custo: é a mais eficiente a nível de custo, isso porque somente os componentes necessários serão alocados e cobrados quando utilizados.
– Segurança: recebe controles de segurança padrão, que embora sejam muito bons podem não atender as necessidades do negócio.
– Nível de Configuração: só vai até onde o provedor da cloud permitir.
– Conhecimento técnico: não precisa de muita coisa, só mesmo do que você vai fazer. Toda infra, updates, hardware, etc, fica por conta da cloud.

Private cloud;
– Custo: o mais caro, aqui você tem que criar seu datacenter, ou precisa alugar um datacenter dedicado.
– Segurança: é tão segura quando sua equipe de TI conseguir deixar seguro… porém pode atender perfeitamente as necessidades do negócio.
– Nível de Configuração: total e flexível, de acordo com tudo que você quiser, só comprar e instalar.
– Conhecimento técnico: precisa de grande e profundo conhecimento técnico pra todos níveis do ambiente.

Hybrid cloud;
– Custo: pode ser mais ou menos cara, a depender do quanto você vai utilizar de private ou public cloud.
– Segurança: você vai precisar garantir que sua conexão entre a privada e a pública esteja segura, mas isso também te dá possibilidade de atender todas as regras de segurança desejadas pelo seu negócio.
– Nível de Configuração: o melhor dos dois mundos, você pode ter a flexibilidade da cloud privada e também da pública, vai depender de onde você quer colocar seus serviços/apps.
– Conhecimento técnico: continua sendo alto, porque você ainda precisa configurar toda sua cloud privada e ainda garantir conexão segura com a cloud pública.

Referências

https://docs.microsoft.com/en-us/learn/modules/fundamental-azure-concepts/benefits-of-cloud-computing

https://docs.microsoft.com/en-us/learn/paths/az-900-describe-cloud-concepts/

https://www.exampro.co/az-900

https://www.udemy.com/course/introducao-ao-microsoft-azure-certificacao-az-900/

Power BI DAX Mesma medida, resultados diferentes

Hoje apareceu uma dúvida interessante no grupo de Power BI e como já falamos um pouco sobre contexto e transição de contexto nesse post, vamos continuar tratando essas dúvidas pra ir esclarecendo melhor o que a engine do DAX faz e porque esses “problemas” acontecem.

O cara por trás do DAX

Agradecimento especial ao Fred! Sem ele esse post não seria possível! Fred trouxe a dúvida e a resposta e ainda me ajudou a entender toda essa resolução. Obrigado, Fred! Quer saber quem é o Fred? Linkedin dele aqui!

O Problema a ser resolvido

A dúvida foi a seguinte:

Na dCalendario tem uma hierarquia com as colunas ano, mês e dia. Também nessa tabela tenho uma outra coluna "mês/ano".

Quero fazer uma comparação de um mês com o mesmo mês do ano de 2018. Pra isso aplico a função CALCULATE com filtro dCalendario[Ano] = 2018.

Porém, somente visuais em que utilizo a hierarquia ano-mes-dia são filtrados por essa função. Se utilizo a coluna "mês/ano" a fórmula retorna blank.

Veja na imagem abaixo a diferença entre as duas tabelas. Por que o filtro funciona diferente pra "mês/ano"?
TotalSales
TotalSales 2018

Perceba que na tabela da esquerda os valores aparecem, enquanto que na da direita não.

Isso acontece pelo seguinte; antes de mais nada é importante lembrar que cada datapoint, ou seja, cada ponto de cálculo é calculado independentemente, ou seja, cada célula é calculada independentemente e cada uma tem seu próprio contexto de filtro.

Antes de seguirmos, lembrem-se de que quando passamos filtros tipo “dCalendario[Ano] = 2018” o que na verdade o DAX interpreta é “FILTER( ALL(dCalendário[Ano]), dCalendário[Ano] = 2018”, logo a fórmula completa seria:

Sabendo disso, ao calcular o valor para coluna ano 2020 TotalSales o resultado é 10.450, enquanto que nessa mesma linha para TotalSales 2018 o valor é 12.174.

Tabela da Esquerda

O que acontece é que, TotalSales 2018 tem um filtro na coluna dCalendario[Ano] , dessa forma, no contexto de filtro onde existe dCalendario[Ano] sofrerá interferência da função ALL(), e o que ALL() faz? Remove todo e qualquer contexto de filtro no report substituindo pela expressão que ele aplica, no nosso caso, dCalendario[Ano] = 2018, como na imagem abaixo.

Pra ser mais claro, quando TotalSales 2018 estiver sendo executada, ela vai remover o filtro de ano de 2020 e colocar 2018.

Tecnicamente falando, ao executar TotalSales temos esse comportamento:

dCalendario[Ano] = 2020
     && (dCalendario[mesabrev] = "Jan" ||
         dCalendario[mesabrev] = "Fev" ||
         dCalendario[mesabrev] = "Mar" ||
         dCalendario[mesabrev] = "Abr" … etc)

Enquanto que, ao executar TotalSales2018, temos esse:

dCalendario[Ano] = 2018
     && (dCalendario[mesabrev] = "Jan" ||
         dCalendario[mesabrev] = "Fev" ||
         dCalendario[mesabrev] = "Mar" ||
         dCalendario[mesabrev] = "Abr" … etc)

Ou seja, como não há filtro sendo alterado por ALL() ou CALCULATE() os campos de dCalendário[mesabrev] se mantém estáveis, obedecendo a hierarquia recém alterada pela CALCULATE() em TotalSales2018.

Tabela da Direita

Na tabela da direita nós não temos nenhum campo sendo alterado pela CALCULATE(), logo o contexto de filtro permanece imutável. Dessa forma, quando TotalSales2018 é aplicada no contexto da tabela da direita, nenhum dado é retornado, pois não existem dados visíveis naquele contexto.

Qual seria o contexto, exatamente, nessa tabela da direita?

Bem, o contexto …

Valor Total

Vamos explicar primeiro o Total, perceba que o valor total é exibido, 12.174.

O Total aparece porque ali o contexto é simplesmente o valor total da medida, que no caso de TotalSales2018 é toda tabela de Sales, filtrada pelo FILTER() da calculate, que diz dCalendario[Ano] = 2018. Então o DAX vai pegar toda tabela de Sales, vai filtrar = 2018, vai pegar o resultado do SUMX e vai retornar no datapoint referente ao Total. Ou seja, no datapoint de Total não existem filtros externos sendo aplicados (que no caso seriam o slicer 2020 e o eixo da tabela na coluna mes/ano).

Valores nas linhas da tabela

Porém, como cada datapoint é calculado de maneira independente, como já falamos, ao tentar recuperar o valor para o datapoint referente a primeira linha, Jan/2020, o que o DAX vai fazer descrevo logo abaixo, porém é importante entender que, esse acesso de verificação, filtragem e retorno da informação é executado ao mesmo tempo, de forma concomitante, simultaneamente.

  • acessar a tabela SALES,
  • verificar os filtros externos, no caso dCalendário[Ano] = 2020, porque temos um slicer na tela,
  • e também já vai estar filtrada no eixo da tabela por Jan/2020, no caso dCalendario[Mes/Ano] = “Jan/2020”,
  • vai então aplicar o filtro de dCalendario[Ano] = 2018
  • vai pegar o resultado e aplicar o SUM (resultado da medida TotalSales2018, que é invocada no CALCULATE() )

O resultado da medida TotalSales2018 vai dar blank, porque não existe nenhuma linha na nossa base de dados que possa ser filtrada por Jan/2020 e ano 2018 ao mesmo tempo. Pense numa planilha de excel.

Inicialmente temos toda base de dados, toda tabela:

Daí ao considerarmos os filtros externos, temos Ano = 2020 no slicer que já reduz pra:

Daí o visual da tabela da direita, ao utilizar o campo dCalendario[mes/ano] em seu eixo aplica, automaticamente, um filtro na coluna de mes/ano. Considerando a primeira linha de jan/2020, o que vai acontecer na nossa base de dados é que ela vai ser filtrada para aquele datapoint.

essa é a visão do datapoint Jan/2020

nota: ignorem o valor das imagens do excel, eu mudei depois que já tinha tirado todos prints do power bi, aí ia dar maior trabalhão…

É esse o resultado que está sendo visto nesse momento pelo DAX para as linhas destacadas da tabela da direita:

Mas por que esse contexto se aplica também para coluna onde está TotalSales2018?

Bem, o contexto de filtro inicial é definido pelos elementos externos, e depois aplicados às medidas (não exatamente depois, ocorre em tempo de execução, mas pensa assim pra facilitar por agora), no entanto, usando CALCULATE() podemos alterar o contexto de filtro em vigência nos datapoints desejados.

Lembrando, nosso contexto de filtro atual é: dCalendario[Ano] = 2020 e mais o eixo da tabela.

Portanto, se quisermos mesmo trazer o valor de TotalSales2018 na tabela da direita, o que precisamos fazer é uma medida assim:

Veja o resultado da tabela da direita, usando a medida que criamos:

Por que essa nova medida funciona?

TotalSales2018mes/ano funciona pelo seguinte, quando utilizamos ALL() o contexto de filtro vigente que existe na tabela dCalendário é removido, então o contexto de filtro do slicer que diz ano 2020 é removido e o contexto de filtro imposto pelo eixo mes/ano da tabela também é removido.

Ao mesmo tempo o filtro de VALUES( dCalendario[mes abrev] ) é verificado.
Nesse caso aqui, VALUES() vai retornar uma tabela, de valores únicos dessa coluna mes abrev. Que no caso, pra primeira linha da tabela da direita, vai ser JAN, ou seja, uma tabela de uma linha e uma coluna.

Nesse momento existe um detalhe importante. Por que usamos [mes abrev] e não [mes/ano]?

Usamos mes abrev por ser uma coluna relacionada, mas que funciona como um “coringa”, porque JAN existe para vários anos, enquanto que, se utilizarmos mes/ano vamos, obrigatoriamente, retornar na nossa VALUES() o valor de Jan/2020.

Aí você se pergunta, mas eu não passei ALL() antes? Por que então VALUES() simplesmente não retorna todos VALUES() da dCalendário[mes abrev]?

Respondo… Porque VALUES() não sabe que existe ALL(), porque elas acontecem ao mesmo tempo! Dessa forma, quando VALUES() acontecer, o contexto de filtro do slicer no nosso report e do eixo da tabela ainda existem! Logo, se utilizarmos VALUES() em mes/ano o resultado será sempre Jan/2020, e é por isso que utilizamos o coringa [mes abrev], porque dessa forma vamos ter o resultado como JAN.

Esse resultado, JAN, assim como todos resultados dos outros demais filtros da CALCULATE(), serão armazenados pra depois que todos filtros forem avaliados acontecer a interseção e verificar a tabela resultado e depois aplicar a medida de CALCULATE() sobre essa tabela resultante.

ALL() só está removendo o contexto de filtro para a expressão da própria, porém VALUES() ainda sofre pelo contexto de filtro atual, de forma que, se utilizarmos mes/ano na nossa medida TotalSales2018mes/ano o resultado não daria certo.

resultado errado usando mes/ano em VALUES()

Isso acontece porque, como o contexto de filtro ainda está lá, usando VALUES() com mes/ano o valor resultante da VALUE() será Jan/2020 e Jan/2020 é sempre Jan/2020, mesmo que você remova todos filtros da galáxia, Jan/2020 será sempre Jan/2020 e nunca existirá nenhum resultado em 2018 pra nenhum mês de 2018 onde Jan/2020 possa gerar algum resultado. Isso é o que chamamos de interseção vazia. Por esse motivo é que utilizamos [mes abrev] em VALUES(), pois mes abrev, considerando o contexto de filtro atual, irá retornar JAN, e JAN sim existe em todos os anos!

Pense assim, se você usar VALUES() em mes/ano você vai ter como resultado uma tabela de uma coluna e uma linha, que depois será utilizada na interseção, e o resultado dessa tabela será Jan/2020, conforme mostro na parte esquerda da imagem abaixo.
Enquanto que, se você fizer a mesma coisa, mas utilizando [mes abrev] o resultado será Jan.

Perceba na imagem abaixo que, embora o resultado de VALUES() venham do mesmo contexto, em um o resultado é Jan/2020 e na outra é Jan. Portanto lembre-se, todo filtro é uma tabela! Essas tabelas depois serão utilizadas na interseção, como já expliquei acima.

O último argumento, dCalendario[Ano] = 2018, vai criar a mesma coisa, uma tabela de uma coluna e uma linha com o valor 2018. Esse valor depois será avaliado com os valores de todos outros filtro pra gerar a interseção, que vai gerar a tabela resultado, que depois será utilizada pra calcular a medida!

Conclusão

Juntando tudo, o que acontece é que:

  • com ALL() em dCalendario as colunas da tabela vão ignorar o contexto de filtro e ficar sem nenhum filtro
  • um filtro, que nada mais é do que uma tabela, será criada com o resultado da coluna dCalendario[mes abrev] recebendo JAN
  • um filtro, que nada mais é do que uma tabela, será criada com o resultado da coluna dCalendario[ano] recebe 2018

E essa avaliação de contexto de filtro que descrevi acima ocorre pra cada datapoint, pra cada célula, linha e coluna da tabela. Portanto, na nossa primeira linha Jan/2020 na coluna TotalSales2018mes/ano o valor resultante será o de Jan para 2018!

Pronto, vencemos o contexto de filtro do DAX! Obrigado pra você que ficou até aqui!!!

Power BI DAX.do

Se você quer testar códigos DAX pelo celular, sem precisar do Power BI, ou se você quiser testar código sem precisar de criar uma base de dados ou modelo, ou se ainda você quer simplesmente rodar códigos que encontra no site do SQLBI.com, pra tudo isso você pode usar o DAX.do.

Esse é um novo site do pessoal do SQLBI.com e é uma ferramenta pra ajudar as pessoas a aprenderem e ensinarem DAX.

No DAX.do você já tem um modelo de dados prontinho, na verdade dois modelos, um do Contoso Database e outro do DAX Guide, que é o modelo de dados utilizado pra exemplos e testes do outro site desse mesmo pessoal, o DAX.guide.

Na verdade o DAX.do vem como uma ferramenta pra facilitar o uso do site deles, agora que todos exemplos de seus artigos podem ser facilmente executados no DAX.do

Mão na massa

O DAX.do é bem fácil de usar, mas você precisa entender que todos resultados precisam ser uma tabela. Portanto, se quiser ver o resultado de uma medida simples, como

SUM( Sales[Net Price] )

não será possível, porque esse código não retorna uma tabela. No entanto, se você tentar

EVALUATE
{ SUM ( Sales[Net Price] ) }

o código vai rodar.

Se você precisar entender melhor qual sintaxe você precisa usar no DAX.do dê uma lida em EVALUATE().

Examplo de código que testei hoje 🙂

Conheça

Referências

https://www.sqlbi.com/blog/marco/2021/02/17/introducing-dax-do/

Power BI DAX Time Intelligence

Aprender os conceitos é muito importante pra conseguir extrair o máximo do DAX, por conta disso, estou estudando mais a fundo a teoria e, como sempre, vou deixar aqui todas minhas anotações sobre o que ando estudando.

Highlights

  • colunas calculadas são calculadas a nível de dados, enquanto que medidas são calculadas a nível de relatório, portanto, nada que seja feito no relatório irá alterar o resultado do que foi calculado nas colunas calculadas.
  • colunas calculadas são contexto de linha, enquanto medidas são contexto de filtro
  • todas medidas aplicam, implicitamente, calculate()
  • todas medidas transformam row context em filter context

Time Intelligence

  • funções DAX de time intel não criam datas, apenas andam pra frente ou para trás em datas já existentes na tabela de data
  • funções DAX de time intel não se aplicam a células (rows), apenas a filtros (tabelas)
  • funções de time intel sempre trabalham a nível de data
  • funções de time intel removem os filtros existentes no contexto para conseguirem calcular seus resultados adequadamente (melhor explicado ao longo do texto) (new filters overwrite the old filters)
  • funções de time intel funcionam apenas em datas regulares (ano, trimestre, mês, dia). Não funciona em granularidades irregulares, como semana, por ex.
  • funções de time intel funcionam apenas em calendários regulares.

Funções de time intel vem do MDX, logo, são funções de manipulação de filtros (filter context, filter manipulation).

Importante entender que funções de time intel manipulam filtros, e todos filtros são tabelas, logo funções de time intel manipulam tabelas. Elas também não conseguem produzir novas datas, não é possível utilizar a função Dateadd() para criar uma data aleatória que não exista na sua tabela de data, portanto, para que Dateadd() funcione é preciso que, antes, essa data que você quer atingir já exista dentro da sua tabela de data. Logo, perceba que as funções de inteligência de tempo não vão criar uma data nova, mas sim “shiftar”, ir pra frente ou pra trás, dentro das suas datas já existentes na sua tabela de data.

No exemplo da imagem acima, a expressão DAX cria, com summarize(), uma tabela de duas colunas. Pense em Summarize() como um group by, criando uma tabela de duas colunas, trazendo resultados únicos desses dois campos. Na sequência utiliza addcolumns() para adicionar mais uma coluna, chamada LastYearSales, que é o resultado de uma expressão calculate() que retorna a soma de Sales Amount no mesmo período do ano anterior, usando sameperiodlastyear().

O objetivo com essa medida é trazer, pra cada registro da tabela criada, que foi nossa tabela de duas colunas, Year e Quarter, o valor de quanto foi vendido no ano anterior para cada linha dessa tabela.

Addcolumns() é uma função iteradora, ela vai linha a linha executando o código. Então a tabela é criada com summarize() no row context, e depois, quando é a hora de executar calculate() o contexto é transformado em contexto de filtro.

Quando sameperiodlastyear() é executado uma lista de datas será retornada de acordo com a tabela que temos, nesse caso uma lista de datas referente ao Quarter 2 de 2012, que vai de 01/04/2012 a 30/06/2012. Lembrando que esse ciclo de cálculo se repetirá linha a linha. Outro ponto importante é saber que funções de time intelligence sempre funcionam a nível de data, e mesmo que nesse caso a granularidade seja de Ano e Quarter, o retorno da função de time intelligence será uma lista de datas.

Uma vez que o filtro da função de time intel é adicionado ao contexto do dax, o filtro anterior é removido do contexto, isso porque nenhum registro, nenhuma linha, nenhum resultado sobreviveria a um filtro como esse, onde o ano é 2013 e 2012 ao mesmo tempo. Por causa disso, o contexto anterior é removido e o cálculo é feito com base na nova lista de datas. Depois disso é verificado quais linhas de Sales Amount sobrevivem a esse filtro, aquelas que forem selecionadas serão então agregadas, nesse caso em SUM(). Somente depois de agregada, será inserida de volta no contexto original.

Filtros e Time Intelligence

Uma das partes mais importantes é entender como as funções de time intel aplicam seus filtros. Isso porque esses filtros são os responsáveis por garantir o bom funcionamento, e o resultado de função de time intel. Por isso, saiba que:

  • toda função de time intel aplica, implicitamente, um all() em toda tabela de data

Ou seja, toda vez que você chama uma função de time intel ela aplica implicitamente um All( Date ), e faz isso pra garantir que o filtro do contexto atual não atrapalhe na hora de conseguir a lista de datas necessárias para executar a função de time intel. Por isso, é importante sempre garantir que sua dimensão dCalendário, no caso desse post estamos chamando de Date, esteja sempre marcada como date-table, pois dessa forma, quando a função de time intel for aplicar o ALL() ela saberá qual tabela filtrar!

Vamos analisar a medida acima. Perceba que o argumento que passamos na sameperiodlastyear() é apenas Date[Date], ou seja, apenas a coluna de date. Sabendo que toda medida trabalha em filter context e que todo filtro é uma tabela, esse filtro então representa uma tabela de uma única coluna, Date[Date]. No entanto, no nosso exemplo não existe nenhum filtro sobre a coluna de Date[Date], na verdade, os filtros no contexto atual são sobre Year e Quarter. Portanto, se a função de time intel não aplicasse o All( Date ) ele jamais seria capaz de retornar a lista de datas que precisamos. No nosso contexto o ano é 2013 e o quarter 2, e precisamos pegar o sameperiodlastyear() desse período, porém, como nosso contexto aplica filtro sobre Year e Quarter, por mais que fosse passado um Calculate() com Filter em Date[Date] o filtro não seria desfeito, pois as colunas filtradas são Year e Quarter, o que impossibilitaria para o DAX retornar a lista de Datas que precisamos, que vai de 01/04/2012 a 30/06/2012. Para prevenir esse comportamento, toda função de time intel aplica All( Date ), dessa forma desfaz, remove o filtro do contexto inicial, abrindo toda tabela, dessa forma agora tem condições de encontrar a lista de datas que precisa.

Porém, para garantir que esse comportamento aconteça o DAX precisa de algumas condições, sendo:

  • uma tabela de datas com datas únicas e com anos completos, de 01/01 a 31/12, sem gaps, sem falhas, na lista de datas
  • a coluna de data deve ser do tipo date ou datetime
  • a tabela de data deve ser, preferencialmente, marcada como date-table
  • caso sua tabela de data não faça relacionamento usando a tabela de data e sim um id de data (campo numérico) sua tabela de data deve ser obrigatoriamente marcada como data-table, ou então não será possível realizar cálculos com funções de time intel
  • caso sua tabela de data faça relacionamento usando o campo date, isso ajuda a indicar pra o DAX de que aquela é a tabela a ser utilizada pelas funções de time intel
  • caso sua data contenha time (datetime) o valor do tempo deve ser sempre o mesmo entre todas linhas de date[date]

Caso você não tenha uma tabela marcada como date-table e o Power BI não consiga identificar através dos relacionamentos, ou de suas tabelas de datas escondidas (assunto pra outro post), o resultado da sua função de time intel será obrigatoriamente incorreto. Para contornar isso, garanta que você passe em sua medida um ALL( Date ), para ignorar quaisquer filtros na tabela de data e conseguir recuperar a lista de datas desejada.

Referências

https://youtu.be/8v4eqssS4a4 – Learn Dax Part II by Jeffrey Wang

https://dax.guide/sameperiodlastyear/

Conversa com Fred, o cara é fera mesmo =)

× Como posso te ajudar?