Guia

Consultar uma tabela Delta massiva (mais de 500 milhões de linhas) em um lakehouse do Fabric com desempenho ideal e acesso a dados quase em tempo real.

→Usar um modelo semântico no modo Direct Lake.

Por quê: O Direct Lake lê arquivos Parquet diretamente do OneLake, ignorando a importação de dados ou a tradução de consultas. Ele oferece desempenho semelhante ao modo de importação, sem duplicação de dados ou latência de atualização. O DirectQuery é mais lento; o modo Import introduz latência.

Aplicar cálculos comuns de inteligência de tempo (YTD, QTD, MTD) a dezenas de medidas base (Vendas, Lucro, Quantidade) sem criar centenas de medidas DAX.

→Implementar um grupo de cálculo com itens de cálculo para YTD, QTD e MTD.

Por quê: Grupos de cálculo eliminam a proliferação de medidas. Eles definem um conjunto de cálculos genéricos que podem ser aplicados dinamicamente a qualquer medida selecionada, simplificando drasticamente a manutenção do modelo.

Vários modelos semânticos em um workspace precisam compartilhar tabelas de dimensão comuns (por exemplo, Date, Customer) para garantir consistência e reduzir a duplicação de dados.

→Criar um modelo semântico "central" contendo as dimensões compartilhadas. Construir outros modelos "compostos" que se conectam ao modelo central via DirectQuery e às tabelas de fatos via Direct Lake/Import.

Por quê: Esta arquitetura "hub and spoke" promove uma única fonte de verdade para as dimensões. Modelos compostos permitem combinar dados de diferentes fontes e modos de armazenamento em um modelo unificado.

Uma tabela de fatos tem várias colunas de data (por exemplo, OrderDate, ShipDate) que devem todas se relacionar com uma única tabela de dimensão de data.

→Criar um relacionamento ativo e vários relacionamentos inativos entre as tabelas de fatos e de datas. Usar a função DAX `USERELATIONSHIP()` em medidas para ativar o relacionamento inativo apropriado.

Por quê: O Power BI permite apenas um relacionamento ativo entre duas tabelas. Este padrão permite a análise por diferentes funções de data sem duplicar a tabela de dimensão.

Um modelo semântico com uma tabela de fatos grande (bilhões de linhas) leva muito tempo para ser atualizado. Apenas os últimos 30 dias de dados mudam com frequência.

→Configurar a atualização incremental na tabela de fatos. Definir os parâmetros `RangeStart` e `RangeEnd`. Definir uma política para arquivar dados antigos (por exemplo, armazenar os últimos 5 anos) e atualizar dados recentes (por exemplo, atualizar os últimos 30 dias).

Por quê: Isso reduz drasticamente o tempo de atualização e o consumo de recursos, processando apenas partições que contêm dados novos ou alterados, em vez de recarregar a tabela inteira.

Uma medida DAX complexa é lenta porque calcula repetidamente o mesmo valor intermediário dentro de sua fórmula.

→Usar variáveis (`VAR`) para armazenar o resultado do cálculo intermediário uma vez, e então referenciar a variável várias vezes na declaração `RETURN`.

Por quê: Variáveis impedem que o motor reavalie a mesma lógica várias vezes dentro de uma única execução de medida, o que melhora significativamente o desempenho, especialmente em contextos iterativos.

Criar uma medida para calcular a porcentagem de contribuição de um valor (por exemplo, vendas de produtos) para um total maior (por exemplo, todas as vendas de produtos), respeitando outros filtros (como data).

→Usar `DIVIDE([Sales], CALCULATE([Sales], ALLEXCEPT(Product, Product[Category])))` para porcentagem da categoria ou `CALCULATE([Sales], ALL(Product))` para porcentagem do total geral.

Por quê: `CALCULATE` combinado com `ALL`, `ALLEXCEPT` ou `REMOVEFILTERS` permite modificar o contexto do filtro para obter o denominador correto para o cálculo da porcentagem.

Um relatório precisa de um slicer que permita aos usuários escolher qual métrica (por exemplo, "Revenue", "Cost", "Profit") um visual deve exibir.

→Criar uma tabela desconectada com os nomes das métricas. Criar uma única medida DAX usando `SWITCH(SELECTEDVALUE(MetricTable[Metric]), "Revenue", [Total Revenue], "Cost", [Total Cost], ...)` .

Por quê: Este padrão, frequentemente usando um Parâmetro de Campo, oferece uma maneira dinâmica e amigável de alternar cálculos sem a necessidade de bookmarks ou múltiplos visuais, tornando os relatórios mais interativos e concisos.

Uma equipe de BI empresarial precisa usar ferramentas profissionais (como Visual Studio, Tabular Editor, SQL Profiler) para gerenciar, implantar e solucionar problemas de um modelo semântico do Fabric.

→Habilitar o endpoint XMLA Read/Write para o workspace.

Por quê: O endpoint XMLA expõe o modelo semântico como uma instância padrão do Analysis Services, permitindo a conectividade de um vasto ecossistema de ferramentas avançadas de BI e ALM para acesso programático e tarefas de modelagem complexas.

Um modelo Direct Lake está com desempenho lento. A investigação revela que ele está caindo de volta para o modo DirectQuery.

→Usar DAX Studio ou Performance Analyzer para identificar a consulta que causa o fallback. Causas comuns incluem funções DAX não suportadas, RLS complexo ou um lakehouse não otimizado/desatualizado.

Por quê: O Direct Lake tem limitações. Quando uma consulta usa um recurso não suportado, ele silenciosamente retorna para o motor DirectQuery, que é mais lento. Identificar e corrigir a causa raiz (por exemplo, otimizar o DAX, executar OPTIMIZE na tabela Delta) é fundamental para restaurar o desempenho.

Um modelo tem um relacionamento muitos para muitos (por exemplo, Vendas e Promoções via uma tabela ponte). As medidas estão retornando totais incorretos ao filtrar pelo lado "muitos".

→Garantir que a direção do filtro cruzado nos relacionamentos (Dimension -> Bridge -> Fact) esteja definida corretamente (tipicamente direcional única). Usar funções DAX como `TREATAS` ou `INTERSECT` para cálculos M2M mais complexos, se necessário.

Por quê: A direção incorreta do filtro cruzado é uma causa comum de resultados incorretos em modelos M2M. Embora o filtro bidirecional possa parecer funcionar, ele frequentemente leva a ambiguidade e contagem dupla. Um modelo bem definido com padrões DAX explícitos é mais robusto.

Um modelo composto usando DirectQuery em uma tabela de fatos massiva está lento. A maioria das consultas dos usuários está em um nível agregado (por exemplo, vendas mensais por categoria).

→Criar uma tabela de agregação definida pelo usuário no modo Import. A tabela de agregação deve conter dados pré-resumidos no nível de granularidade das consultas comuns (Mês, Categoria).

Por quê: O motor de consulta redirecionará automaticamente as consultas para a tabela de agregação menor e em memória sempre que possível, proporcionando enormes ganhos de desempenho. Ele só acessará a fonte DirectQuery para consultas que exigem um nível de detalhe inferior.

Calcular totais acumulados ou médias móveis complexas em DAX que estão apresentando baixo desempenho com abordagens tradicionais baseadas em filtro.

→Usar funções de janela DAX como `WINDOW` ou `OFFSET`.

Por quê: Essas funções são otimizadas especificamente para cálculos posicionais sobre um conjunto ordenado de linhas. Elas são frequentemente mais eficientes e sintaticamente mais simples do que padrões mais antigos que dependem de filtragem pesada e transições de contexto.

Calcular totais Ano-a-Data (YTD) para uma empresa com um ano fiscal que começa em 1º de julho.

→Usar as funções `TOTALYTD` ou `DATESYTD` com o parâmetro opcional `YearEndDate`. Exemplo: `TOTALYTD([Sales], 'Date'[Date], "6/30")` .

Por quê: Especificar o parâmetro de data de fim de ano é a maneira correta e mais simples de fazer com que as funções de inteligência de tempo DAX reconheçam o calendário fiscal personalizado.

Promover um modelo semântico entre os estágios Dev, Test e Prod, onde cada estágio tem uma string de conexão de banco de dados diferente.

→Usar pipelines de implantação do Fabric com regras de implantação.

Por quê: As regras de implantação automatizam a modificação de conexões de fonte de dados, parâmetros e outras configurações para cada ambiente. Isso evita alterações manuais e propensas a erros pós-implantação.

Referência↗

Implementar uma arquitetura de malha de dados descentralizada onde os domínios de negócios possuem e gerenciam seus próprios produtos de dados.

→Criar workspaces específicos do domínio. Usar atalhos do OneLake para permitir o compartilhamento e consumo de dados entre domínios sem centralizar a propriedade dos dados.

Por quê: Este padrão se alinha com os princípios da malha de dados de propriedade do domínio e dados como produto. Os workspaces fornecem o limite para a propriedade, enquanto os atalhos fornecem a camada de interoperabilidade.

Uma equipe de desenvolvedores precisa colaborar em itens do Fabric (modelos semânticos, relatórios, notebooks) com controle de código-fonte e histórico de versões.

→Configurar a integração Git para o workspace do Fabric, conectando-o a um repositório Azure DevOps ou GitHub.

Por quê: A integração Git armazena as definições de itens do Fabric como arquivos de texto (JSON, TMDL), permitindo práticas padrão de DevOps como branching, pull requests e rastreamento de versão. Isso é essencial para o Application Lifecycle Management (ALM) de nível empresarial.

Antes de alterar uma tabela do lakehouse, um engenheiro deve identificar todos os relatórios downstream e modelos semânticos que serão afetados.

→Usar a Visualização de Linhagem e selecionar "Análise de impacto" no item do lakehouse.

Por quê: Este recurso fornece uma visão completa e automatizada de todas as dependências. É uma ferramenta de governança crítica para gerenciar mudanças em um ambiente de análise complexo, evitando quebras inesperadas.

Uma equipe precisa controlar a versão de um modelo semântico em um formato baseado em texto, legível por humanos, que seja fácil de diferenciar e mesclar.

→Salvar o arquivo do Power BI como um Power BI Project (.pbip). Isso armazena a definição do modelo no formato Tabular Model Definition Language (TMDL).

Por quê: TMDL é um formato amigável para desenvolvedores que representa o modelo como uma estrutura de pastas com arquivos de texto individuais para tabelas, medidas, etc. Isso é muito superior ao arquivo binário .bim para colaboração baseada em Git e CI/CD.

Implementar uma arquitetura medallion (Bronze, Silver, Gold) e precisar acessar dados entre as camadas sem duplicação física de dados.

→Usar atalhos do OneLake para referenciar dados em outros lakehouses ou camadas.

Por quê: Atalhos são links simbólicos no OneLake. Eles fornecem um namespace unificado e permitem acesso a dados sem copiar, o que é ideal para uma malha de dados lógica ou arquitetura medallion.

Referência↗

Migrar uma carga de trabalho de análise existente com uso intensivo de T-SQL do Azure Synapse para o Fabric.

→Usar um Fabric Data Warehouse.

Por quê: O Fabric Warehouse oferece compatibilidade total com T-SQL, tornando-o o alvo ideal para migrar scripts SQL existentes, stored procedures e consultas de analistas com alterações mínimas. O endpoint SQL do Lakehouse tem acesso T-SQL somente leitura e usa Spark SQL para gravações.

Ingerir e consultar dados de streaming de alto volume e alta velocidade (por exemplo, telemetria de IoT) com latência abaixo de um segundo.

→Usar o Fabric Eventstream para ingestão e um KQL Database para armazenamento e análise.

Por quê: Esta é a pilha de análise de streaming construída especificamente no Fabric. O KQL (Kusto Query Language) é otimizado para análise de séries temporais em dados de streaming, oferecendo latência muito menor do que lakehouses ou warehouses orientados a lote.

Implementar Slowly Changing Dimension (SCD) Tipo 2 para manter um histórico completo de alterações de dimensão em um lakehouse.

→Usar uma declaração `MERGE INTO` em um notebook ou pipeline Spark. Fazer a correspondência pela chave de negócio; `WHEN MATCHED` atualiza o registro antigo (define `IsCurrent` como falso, `EndDate` para agora); `WHEN NOT MATCHED` insere o novo registro.

Por quê: A operação `MERGE` do Delta Lake fornece capacidades de upsert atômico, tornando-a a forma padrão e mais eficiente de implementar a lógica SCD em um lakehouse do Fabric.

Replicar dados quase em tempo real de um banco de dados operacional (por exemplo, Azure SQL DB) para um lakehouse do Fabric para análise.

→Usar Fabric Mirroring.

Por quê: Mirroring é uma solução de Change Data Capture (CDC) de baixa latência e baixo impacto, integrada ao Fabric. Ele replica automaticamente os dados e as alterações de esquema para o OneLake como tabelas Delta, eliminando a necessidade de pipelines ETL complexos.

Ingerir e transformar dados JSON complexos e aninhados de uma API em uma tabela Delta estruturada e achatada.

→Usar um notebook PySpark. Usar funções como `from_json` para analisar o esquema e `explode` para achatar arrays em linhas.

Por quê: PySpark fornece as ferramentas mais poderosas e flexíveis para lidar com estruturas JSON complexas e em evolução programaticamente, muito além das capacidades de uma atividade de cópia padrão.

Ingerir dados no Fabric a partir de um banco de dados SQL Server on-premises que está atrás de um firewall corporativo.

→Instalar e configurar um gateway de dados on-premises em um servidor dentro da rede local. Adicionar o gateway como uma fonte de dados no Fabric.

Por quê: O gateway atua como uma ponte segura, retransmitindo consultas e dados entre os serviços de nuvem do Fabric e as fontes de dados on-premises sem a necessidade de abrir portas de firewall de entrada.

O desempenho da consulta em uma tabela Delta grande e frequentemente atualizada se degradou devido ao acúmulo de muitos arquivos de dados pequenos.

→Executar o comando `OPTIMIZE` para compactar arquivos pequenos em arquivos maiores. Opcionalmente, usar `ZORDER BY` em colunas frequentemente filtradas para co-localizar dados relacionados.

Por quê: Menos arquivos e arquivos maiores são significativamente mais eficientes para o Spark ler. A ordenação Z melhora o salto de dados, permitindo que as consultas leiam ainda menos dados. Esta é uma tarefa de manutenção crítica para tabelas Delta.

Agregar dados de séries temporais de streaming em intervalos de tempo fixos e não sobrepostos (por exemplo, temperatura média por sensor a cada 5 minutos).

→Usar uma consulta KQL com o operador `summarize` e a função `bin()`. Exemplo: `SensorData | summarize avg(temperature) by sensor_id, bin(timestamp, 5m)` .

Por quê: A função `bin()` é a maneira padrão e altamente otimizada no KQL para agrupar eventos em intervalos de tempo fixos (tumbling windows) para agregação.

Uma atualização do Dataflow Gen2 está lenta. A fonte de dados é um banco de dados relacional como o Azure SQL.

→Revisar as etapas de transformação no editor do Power Query para garantir que o query folding esteja ativo. Reordenar ou modificar as etapas para maximizar o folding.

Por quê: O query folding empurra a lógica de transformação de volta para o banco de dados de origem para ser executada como uma única consulta nativa. Isso é muito mais eficiente do que puxar todos os dados brutos para o motor do dataflow e transformá-los na memória.

Um notebook Spark está realizando uma junção lenta entre uma tabela de fatos muito grande (bilhões de linhas) e uma tabela de dimensão pequena (milhares de linhas).

→Usar uma junção de broadcast fornecendo uma dica (`spark.sql.functions.broadcast`) ou deixando o otimizador escolher com base nas estatísticas.

Por quê: O broadcasting envia a tabela pequena inteira para cada nó executor. Isso evita uma operação de "shuffle" custosa onde os dados da tabela grande devem ser repartitionados e enviados pela rede, melhorando drasticamente o desempenho.

Um pipeline de dados orquestra várias atividades. Uma atividade pode falhar, mas as atividades subsequentes e independentes ainda devem ser executadas, e a falha geral deve ser registrada.

→Configurar dependências de atividade. As atividades que devem ser executadas independentemente do resultado devem depender da atividade anterior com a condição "Conclusão".

Por quê: Isso permite a construção de caminhos de execução robustos e paralelos. Você pode criar ramificações separadas para as condições "Êxito" e "Falha" para implementar lógica personalizada de log ou notificação.

Um pipeline para carregar dados incrementalmente de uma fonte com um timestamp `last_modified`.

→Implementar um padrão de marca d'água (watermark). Armazenar o `max(last_modified)` da última execução bem-sucedida. Na próxima execução, consultar a fonte para registros onde `last_modified` é maior que a marca d'água armazenada.

Por quê: Este é o padrão mais eficiente para cargas incrementais de fontes que fornecem um timestamp de modificação, garantindo que apenas dados novos ou atualizados sejam processados, minimizando a transferência de dados e o cálculo.

Analisar um fluxo em tempo real de dados de IoT para detectar picos ou quedas incomuns nas leituras de sensores.

→Usar a função `series_decompose_anomalies()` em uma consulta KQL dentro de um Eventhouse/KQL Database.

Por quê: Esta função KQL integrada é projetada especificamente para detecção de anomalias em séries temporais. Ela decompõe automaticamente a série em componentes sazonais, de tendência e residuais para identificar outliers estatisticamente significativos, exigindo configuração manual mínima.

Precisa-se unir dados de um Warehouse, um Lakehouse e um Azure SQL Database espelhado em uma única consulta T-SQL sem mover dados.

→Usar convenções de nomenclatura de três partes (`database.schema.table`) em uma consulta executada a partir do Warehouse ou do endpoint SQL do Lakehouse. Usar atalhos para referenciar o banco de dados espelhado.

Por quê: O Fabric fornece um motor de consulta unificado que pode acessar dados entre diferentes itens do Fabric dentro do mesmo workspace usando uma única declaração SQL, permitindo a virtualização de dados.

Um dataflow precisa processar um arquivo onde algumas linhas podem ser inválidas. O fluxo inteiro não deve falhar; linhas válidas devem ser carregadas e linhas inválidas devem ser registradas.

→No Power Query, adicionar uma etapa para validar linhas e criar uma coluna "IsValid". Em seguida, criar duas consultas de referência a partir desse ponto: uma que filtra por `IsValid = true` para carregar no destino, e outra que filtra por `IsValid = false` para carregar em um log de erros.

Por quê: Este padrão fornece tratamento de erros robusto, dividindo o fluxo de dados. Ele evita que algumas linhas incorretas parem todo o processo e oferece um mecanismo claro para auditar problemas de qualidade de dados.

Implementar segurança em nível de linha (RLS) onde os usuários devem ver apenas os dados correspondentes à sua identidade (por exemplo, um gerente de vendas vê apenas suas lojas).

→Criar uma tabela de segurança mapeando usuários para entidades de dados. Na função RLS, usar uma expressão de filtro DAX como `[ManagerEmail] = USERPRINCIPALNAME()` .

Por quê: O RLS dinâmico é escalável. Ele usa uma abordagem baseada em dados em vez de criar uma função estática para cada pessoa ou entidade. `USERPRINCIPALNAME()` resolve corretamente a identidade do Azure AD.

Ocultar colunas sensíveis ou tabelas inteiras (por exemplo, Salário) de um grupo específico de usuários, permitindo que eles acessem o restante do modelo semântico.

→Definir funções de segurança e configurar a Object-Level Security (OLS) usando uma ferramenta externa como o Tabular Editor para definir as permissões de tabela/coluna como "None".

Por quê: O OLS fornece controle granular sobre a visibilidade dos metadados do modelo. Ao contrário do RLS que filtra linhas, o OLS oculta o objeto inteiro. Ele deve ser configurado via endpoint XMLA.

Usuários estão relatando desempenho lento e throttling no Fabric. O administrador precisa identificar a causa raiz.

→Usar o aplicativo Fabric Capacity Metrics.

Por quê: Este aplicativo fornece insights detalhados sobre o consumo de unidades de capacidade (CU), eventos de throttling e uso de recursos por tipo de carga de trabalho (por exemplo, consulta de modelo semântico, atualização de dataflow). É a principal ferramenta para monitoramento de desempenho e planejamento de capacidade.

Impor uma política de classificação de dados onde relatórios e dashboards herdam automaticamente o rótulo de sensibilidade do modelo semântico ao qual se conectam.

→Habilitar a configuração do tenant para herança downstream de rótulos de sensibilidade.

Por quê: Isso automatiza a governança de dados, garantindo que as proteções aplicadas à fonte de dados (por exemplo, "Altamente Confidencial") sejam consistentemente aplicadas a todo o conteúdo downstream, reduzindo o risco de vazamento de dados.

Em um Fabric Warehouse, usuários gerais devem ver dados PII mascarados (por exemplo, `XXX-XX-1234`), enquanto usuários privilegiados veem os dados completos e não mascarados.

→Aplicar Dynamic Data Masking (DDM) nas colunas sensíveis no Warehouse. Conceder permissões `UNMASK` às funções de usuário privilegiadas.

Por quê: DDM é um recurso de segurança no nível do banco de dados que redige dados em tempo real com base nas permissões do usuário. Ele protege dados sensíveis no local sem exigir visualizações ou cópias separadas dos dados.