Os três domínios não têm peso igual. Preparar dados sozinho vale de 45 a 50% da prova — quase metade. É onde você deve investir a maior parte do tempo. Os outros dois domínios, governança/ALM e modelos semânticos, dividem a metade restante em partes iguais.

O exame é escrito para o analytics engineer: alguém que projeta lakehouses e warehouses, prepara dados num star schema e constrói modelos semânticos de alto desempenho. Espera-se que você consulte e transforme dados em quatro dialetos — SQL, KQL, DAX e o Visual Query Editor (Power Query). A maioria das questões não é "o que essa função faz" — é "dadas estas restrições, qual store, qual storage mode, qual padrão de modelagem você escolhe, e por que não os outros".

Os quatro formatos de questão que você vai encontrar

OneLake — a cópia única

O OneLake é o data lake lógico único do tenant, provisionado automaticamente, sem infraestrutura para criar. Todo item que armazena dados grava em Delta Parquet no OneLake, e é isso que permite que uma única cópia do dado seja lida por todos os engines — SQL, Spark, KQL e o Analysis Services por trás do Direct Lake — sem duplicação.

• Delta Parquet é o formato nativo de todas as cargas. Warehouse, Lakehouse e Eventhouse gravam em Delta — a base do "one copy".
• Ferramentas externas endereçam o OneLake como ADLS Gen2: https://onelake.dfs.fabric.microsoft.com/<workspace>/<item>/Tables/<table>.
• Shortcuts apontam para dados em outro lugar (OneLake, ADLS, S3, GCS, Dataverse) sem copiá-los; mirroring replica um banco externo continuamente para o OneLake.

A taxonomia de itens que o analytics engineer precisa reconhecer

Escolhendo um data store — a tabela de decisão mestra

Esta tabela responde a uma fatia desproporcional das questões do Domínio 2.

Import, DirectQuery, Direct Lake e Dual

O storage mode de uma tabela decide onde os dados residem na hora da consulta. Esta é a distinção mais cobrada do Domínio 3.

Workspace roles — a matriz essencial

Quatro roles governam tudo no workspace. Decore quem pode compartilhar e quem só lê (detalhes e as pegadinhas de segurança estão no Domínio 1).

SQL, KQL e DAX — quando cada uma

As camadas de acesso do Fabric

O Fabric avalia a segurança em camadas sequenciais. Um usuário precisa passar em cada camada para acessar o dado. A ordem de operação é: 1) autenticação no Microsoft Entra, 2) acesso ao Fabric, 3) segurança de dados (tabela/arquivo). Pense em três escopos de concessão: o workspace (plano de controle), o item (compartilhamento individual) e os controles de dados (OneLake, SQL, semantic model).

Controles no nível do workspace

Existem quatro workspace roles. Elas se aplicam a todos os itens do workspace e não vazam para outros workspaces, para a capacity ou para o tenant. Quem não tem nenhuma role não acessa o workspace.

Controles no nível do item

Permissões de item controlam o acesso a um item específico, independentemente das workspace roles. Compartilhar um item concede por padrão a permissão Read (ver metadados e relatórios associados). Read não dá acesso aos dados subjacentes em SQL ou OneLake — para isso, conceda permissões de compute adicionais.

RLS, CLS, OLS e acesso a arquivos

A segurança granular acontece em dois motores independentes: o Warehouse / SQL analytics endpoint (via T-SQL) e o semantic model (via Tabular/DAX). Separadamente, o OneLake security aplica segurança de arquivo/pasta/tabela/linha/coluna no próprio lake.

-- 1) Função-predicado (inline TVF) com SCHEMABINDING
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
-- 2) Política que aplica o filtro sobre a tabela
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders WITH (STATE = ON);

-- Charlie vê tudo, menos a coluna sensível CreditCard
GRANT SELECT ON Customers(CustomerID, FirstName, LastName, Phone, Email)
    TO [Charlie@contoso.com];
-- SELECT * agora falha para Charlie:
-- Msg 230: The SELECT permission was denied on the column 'CreditCard'

-- Negar acesso a uma coluna inteira (deny-list)
DENY SELECT ON dbo.Payroll(Salary) TO [analysts];
-- Para OLS de tabela/coluna no semantic model, use
-- Tabular Editor sobre o modelo (não T-SQL).

Sensitivity labels

Sensitivity labels vêm do Microsoft Purview Information Protection e protegem o conteúdo contra vazamento e acesso não autorizado. Diferentemente de RLS/CLS, o label viaja com o dado: ele é herdado por itens downstream e persiste na exportação (Excel, PowerPoint, PDF), inclusive fora do Fabric.

Endossar itens

Endossamento sinaliza conteúdo confiável e o destaca na busca. Há três níveis:

Controle de versão (Git integration)

O Git integration conecta um workspace a um branch de repositório para versionar, reverter e colaborar. A integração é no nível do workspace e preserva a estrutura de subpastas no Git.

Power BI Desktop projects (.pbip)

Preview Ao salvar como Power BI Project (.pbip), o relatório e o semantic model são gravados como arquivos de texto simples em pastas separadas — ideais para Git, diff e colaboração. Habilite em File > Options > Preview features.

Project/
├── AdventureWorks.Report/       -- definition.pbir (PBIR)
├── AdventureWorks.SemanticModel/ -- definition.pbism + TMDL
├── .gitignore                   -- ignora cache.abf, localSettings
└── AdventureWorks.pbip          -- ponteiro p/ a pasta Report

Deployment pipelines

Deployment pipelines promovem conteúdo entre estágios (tipicamente Dev → Test → Prod). Git cuida do controle de versão; pipelines cuidam da promoção entre ambientes.

Impact analysis de dependências

Antes de mudar um item, avalie o que quebra downstream. A lineage view mostra as conexões dentro do workspace (mais fontes externas um nível acima); a impact analysis mostra os dependentes downstream, inclusive em outros workspaces.

XMLA endpoint

O XMLA endpoint expõe o semantic model como se fosse um servidor Analysis Services, para ferramentas externas. É read-only por padrão (querying); operações de escrita exigem read-write.

Assets reutilizáveis

Reduza retrabalho reutilizando templates e fontes de dados padronizados, e conectando-se a modelos compartilhados em vez de duplicá-los.

Conexões de dados e gateways

Uma conexão encapsula o endereço da fonte, o tipo de autenticação e as credenciais. No Fabric você gerencia tudo de forma centralizada em Configurações → Gerenciar conexões e gateways. A pergunta de decisão é sempre: onde a fonte vive e como o Fabric consegue alcançá-la? A resposta define se você precisa apenas de uma conexão em nuvem ou de um gateway como ponte para a rede onde o dado mora.

Tipos de credencial / autenticação. Ao criar a conexão você escolhe como o Fabric se autentica na fonte. A opção disponível depende do conector. Para automação, prefira service principal ou Managed Identity em vez de senhas embutidas.

Compartilhamento e papéis da conexão. Uma conexão é um objeto governável: você concede papéis a outros usuários — Owner (gerencia e usa), User (usa em itens) e User with sharing (usa e reconcede). Assim uma equipe reaproveita uma única conexão sem redistribuir credenciais.

OneLake catalog e Real-Time hub

São os dois pontos de descoberta do Fabric. Regra de bolso: dados analíticos em repouso → OneLake catalog; dados em movimento / streaming → Real-Time hub. Saber qual dos dois usar é frequentemente a pergunta inteira na prova.

Ingerir ou acessar dados

A decisão-mãe do domínio. Copiar move fisicamente os dados para OneLake; shortcut aponta para os dados no lugar (virtual, zero cópia); mirroring replica continuamente uma base operacional para OneLake via CDC. Se você memorizar uma única tabela deste guia, memorize esta.

Mirroring — bancos suportados e características

O mirroring replica um banco operacional para OneLake como tabelas Delta, sem ETL para construir. A computação de replicação é gratuita e cada capacity unit inclui uma cota de storage de mirroring gratuito (aproximadamente 1 TB por CU). A latência é near real-time — tipicamente segundos a poucos minutos, dependendo do volume de mudanças.

• Cria dois artefatos no workspace: o processo de replicação e um SQL analytics endpoint somente leitura sobre a cópia Delta.
• Exige uma capacity do Fabric em execução — pausar a capacity interrompe a replicação.
• É a rota certa quando a origem é um banco transacional que você quer analisar de forma contínua e barata, sem construir pipeline.

Tipos de shortcut

Você cria shortcuts em lakehouses e KQL databases. Eles aparecem como pastas e se comportam como links simbólicos — apagar o shortcut não afeta o alvo, mas apagar conteúdo dentro do shortcut apaga na origem se você tiver permissão lá.

Ferramentas de cópia — qual usar

# Um shortcut em Tables/ se comporta como tabela Delta local
df = spark.read.format("delta").load("Tables/vendas_s3")
df = spark.sql("SELECT * FROM MeuLakehouse.vendas_s3 LIMIT 1000")

Escolher entre data stores

Quatro perguntas resolvem quase todo cenário: (1) É telemetria/tempo real de alto volume? (2) Desenvolve em Spark ou T-SQL? (3) Precisa de transações multi-tabela e DML? (4) É OLTP operacional de app? Responda nessa ordem e o item cai sozinho.

Integração OneLake (Eventhouse e semantic models)

O princípio do Fabric é uma cópia lógica: o dado fica em Delta no OneLake e todos os motores leem o mesmo arquivo. Três integrações caem muito na prova: OneLake availability do Eventhouse, Direct Lake lendo OneLake e shortcut de KQL para OneLake.

Shortcut de KQL para OneLake. Numa KQL database você cria um shortcut apontando para tabelas Delta no OneLake e as consulta como external table. É a via oposta: em vez de expor KQL para o lake, você traz dados do lake para o motor Kusto sem copiá-los.

external_table('vendas_gold')
| where Regiao == "Sul"
| take 100

Views, functions e stored procedures

No Warehouse você tem T-SQL completo (DQL + DML + DDL). Use views para encapsular lógica de leitura, funções para lógica reutilizável (escalares e inline TVFs) e stored procedures para pipelines de transformação com DML. No SQL analytics endpoint do Lakehouse a superfície é read-only: só views e TVFs, sem procedures com DML.

CREATE VIEW dbo.vw_vendas_gold AS
SELECT d.ano, d.mes, p.categoria,
       SUM(f.valor) AS total
FROM dbo.fato_vendas f
JOIN dbo.dim_data d    ON f.data_key = d.data_key
JOIN dbo.dim_produto p ON f.prod_key = p.prod_key
GROUP BY d.ano, d.mes, p.categoria;

CREATE FUNCTION dbo.fn_vendas_por_ano (@ano INT)
RETURNS TABLE AS
RETURN (
  SELECT p.categoria, SUM(f.valor) AS total
  FROM dbo.fato_vendas f
  JOIN dbo.dim_data d ON f.data_key = d.data_key
  JOIN dbo.dim_produto p ON f.prod_key = p.prod_key
  WHERE d.ano = @ano
  GROUP BY p.categoria
);

CREATE PROCEDURE dbo.sp_carrega_gold AS
BEGIN
  TRUNCATE TABLE dbo.agg_vendas_mes;

  INSERT INTO dbo.agg_vendas_mes (ano, mes, total)
  SELECT d.ano, d.mes, SUM(f.valor)
  FROM dbo.fato_vendas f
  JOIN dbo.dim_data d ON f.data_key = d.data_key
  GROUP BY d.ano, d.mes;
END;

Enriquecer. Adicionar colunas ou tabelas derivadas (computadas) que agregam contexto de negócio — margem, faixa etária, flag de churn — antes do consumo por BI. A operação existe nos três dialetos.

Implementar um star schema

O star schema é a estrutura preferida para modelagem analítica: uma tabela fato central (eventos mensuráveis — vendas, cliques, visitas) cercada de tabelas dimensão (contexto descritivo — produto, cliente, data). Aplica-se tanto ao lakehouse quanto ao warehouse. Cada fato usa surrogate keys (chaves substitutas geradas) para apontar às dimensões, isolando o modelo das chaves naturais da origem.

Slowly Changing Dimensions (SCD). Gerenciam mudança de atributos de dimensão ao longo do tempo.

MERGE dbo.dim_cliente AS tgt
USING staging.cliente AS src
   ON tgt.cliente_id = src.cliente_id
WHEN MATCHED THEN UPDATE SET
   tgt.email = src.email, tgt.cidade = src.cidade
WHEN NOT MATCHED THEN
   INSERT (cliente_id, email, cidade)
   VALUES (src.cliente_id, src.email, src.cidade);

dim = (spark.table("staging.cliente")
  .dropDuplicates(["cliente_id"])
  .withColumn("cliente_key",
      monotonically_increasing_id()))
dim.write.format("delta") \
   .mode("overwrite") \
   .saveAsTable("gold.dim_cliente")

Desnormalizar e agregar

Desnormalizar = achatar tabelas relacionadas em uma só, reduzindo joins em tempo de query (troca storage por velocidade de leitura). Agregar = pré-somar em uma granularidade mais grossa para acelerar dashboards. A mesma operação de agregação, lado a lado nos três dialetos:

from pyspark.sql import functions as F
agg = (df.groupBy("ano", "mes", "categoria")
         .agg(F.sum("valor").alias("total"),
              F.countDistinct("cliente_id").alias("clientes")))
agg.write.mode("overwrite").saveAsTable("gold.agg_vendas")

SELECT ano, mes, categoria,
       SUM(valor) AS total,
       COUNT(DISTINCT cliente_id) AS clientes
FROM dbo.fato_vendas f
JOIN dbo.dim_data d ON f.data_key = d.data_key
GROUP BY ano, mes, categoria;

let
  Fonte = fato_vendas,
  Agrup = Table.Group(Fonte,
    { "ano", "mes", "categoria" },
    { { "total", each List.Sum([valor]), type number } })
in
  Agrup

Merge e join

Combinar tabelas por chave. Cuidado com o tipo de join (inner descarta não-correspondentes; left preserva a esquerda) e com fan-out (join com dimensão duplicada infla o fato).

vendas_enr = (fato
  .join(dim_produto, "prod_key", "left")
  .join(dim_cliente, "cliente_key", "left")
  .select("data_key", "categoria",
          "segmento", "valor"))

Duplicados, ausentes e nulos

Limpeza é obrigatória antes do star schema. Identifique duplicados por chave de negócio, decida a política para nulos (remover, imputar ou sinalizar) e documente. Cada operação nos três dialetos:

limpo = (bruto
  .dropDuplicates(["pedido_id"])
  .fillna({"desconto": 0, "canal": "desconhecido"})
  .filter(F.col("cliente_id").isNotNull()))

WITH ranked AS (
  SELECT *, ROW_NUMBER() OVER (
    PARTITION BY pedido_id
    ORDER BY atualizado_em DESC) AS rn
  FROM staging.pedidos
)
SELECT * FROM ranked WHERE rn = 1;

let
  Fonte = staging_pedidos,
  SemDup = Table.Distinct(Fonte, { "pedido_id" }),
  Imputa = Table.ReplaceValue(SemDup,
    null, 0, Replacer.ReplaceValue, { "desconto" })
in
  Imputa

Converter tipos e filtrar

Tipos corretos evitam erros de agregação e melhoram compressão. Converta na camada silver, e filtre cedo (predicate pushdown) para reduzir volume antes das transformações caras. Prefira TRY_CAST/TRY_CONVERT para conversões que podem falhar — retornam NULL em vez de quebrar a query.

silver = (bronze
  .filter(F.col("valor").isNotNull())
  .withColumn("valor", F.col("valor").cast("decimal(18,2)"))
  .withColumn("data", F.to_date("data_str", "yyyy-MM-dd"))
  .filter(F.col("valor") > 0))

Quatro linguagens, quatro contextos. Saiba qual usar onde: Visual Query Editor (no-code sobre lakehouse/warehouse), SQL (endpoint/warehouse), KQL (Eventhouse) e DAX (semantic model). Escolher a linguagem certa para a fonte certa é exatamente o que a prova testa.

Visual Query Editor

Editor no-code baseado no diagrama do Power Query. Você arrasta operações (selecionar colunas, filtrar linhas, agrupar, mesclar) e o Fabric gera o M/SQL por trás. Disponível no SQL analytics endpoint do Lakehouse e no Warehouse. Ideal para select/filter/aggregate sem escrever código, e você pode salvar o resultado como view diretamente.

SQL

T-SQL via SQL analytics endpoint (leitura sobre lakehouse) ou diretamente no Warehouse (leitura e escrita). É a linguagem de consulta padrão para dados tabulares Delta. Domine WHERE, GROUP BY, HAVING e window functions (ROW_NUMBER, RANK, SUM() OVER).

SELECT p.categoria,
       COUNT(*) AS pedidos,
       SUM(f.valor) AS receita
FROM dbo.fato_vendas f
JOIN dbo.dim_produto p ON f.prod_key = p.prod_key
JOIN dbo.dim_data d    ON f.data_key = d.data_key
WHERE d.ano = 2026
GROUP BY p.categoria
HAVING SUM(f.valor) > 10000
ORDER BY receita DESC;

SELECT categoria, produto, receita,
       RANK() OVER (
         PARTITION BY categoria
         ORDER BY receita DESC) AS posicao
FROM dbo.vw_receita_produto;

KQL

Kusto Query Language em um KQL queryset sobre o Eventhouse. Read-only e otimizado para séries temporais e logs. Operadores-chave: where (filtra), project (seleciona colunas), summarize (agrega por), extend (coluna calculada), join (combina tabelas), top (N maiores), take (amostra).

Vendas
| where Timestamp > ago(30d)
| where Categoria == "Eletronicos"
| summarize Receita = sum(Valor),
            Pedidos = count()
    by bin(Timestamp, 1d), Regiao
| extend Ticket = Receita / Pedidos
| project Timestamp, Regiao, Receita, Ticket
| top 100 by Receita desc

Vendas
| join kind=inner (
    Produtos | project ProdId, Categoria
  ) on ProdId
| summarize Receita = sum(Valor) by Categoria

DAX

DAX query view no Power BI executa consultas DAX sobre o semantic model. Toda consulta começa com EVALUATE retornando uma tabela. SUMMARIZECOLUMNS agrupa e agrega — o padrão para inspecionar medidas sem construir um visual. TOPN corta os N maiores; FILTER aplica predicados.

EVALUATE
SUMMARIZECOLUMNS (
    dim_produto[categoria],
    dim_data[ano],
    FILTER ( dim_data, dim_data[ano] = 2026 ),
    "Receita", SUM ( fato_vendas[valor] ),
    "Pedidos", COUNTROWS ( fato_vendas )
)
ORDER BY [Receita] DESC

EVALUATE
TOPN (
    5,
    SUMMARIZECOLUMNS (
        dim_produto[categoria],
        "Receita", SUM ( fato_vendas[valor] )
    ),
    [Receita], DESC
)

Escolher um storage mode

O storage mode é uma propriedade por tabela. Um modelo com tabelas em modos diferentes é um composite model. Import e Direct Lake são processados pela engine VertiPaq (in-memory); DirectQuery traduz o DAX para a linguagem nativa da fonte (SQL) e federa a query.

Star schema no modelo semântico

O star schema é o alicerce: tabelas fato (métricas transacionais, muitas linhas) no centro, ligadas a tabelas dimensão (atributos descritivos, poucas linhas) por relacionamentos um-para-muitos. Prefira star a snowflake — menos junções, filtros mais simples, DAX mais previsível.

Relacionamentos, bridge e many-to-many

Cada relacionamento tem cardinalidade (1:*, 1:1, *:*), direção de cross-filter (single/both) e estado ativo/inativo. Só um relacionamento ativo pode existir entre duas tabelas; os demais ficam inativos e são ativados sob demanda com USERELATIONSHIP dentro de CALCULATE.

Para relação muitos-para-muitos entre duas dimensões (ex.: Cliente × Conta), insira uma bridge table com os pares distintos de chaves e conecte cada dimensão à bridge por 1:*. Ative cross-filter both na bridge apenas se precisar propagar o filtro. Relacionamentos *:* diretos existem, mas geram relacionamentos "limitados" e devem ser usados com cautela.

// Vendas tem 2 datas: OrderDate (ativo) e ShipDate (inativo)
Vendas por Envio =
CALCULATE (
    [Total Vendas],
    USERELATIONSHIP ( Vendas[ShipDateKey], 'Date'[DateKey] )
)

DAX: variáveis, iteradores, windowing

Use variáveis (VAR/RETURN) para clareza e performance — cada VAR é avaliada uma vez, no contexto onde é declarada, e reutilizada. Iteradores (SUMX, AVERAGEX) avaliam uma expressão linha a linha. Para table filtering, combine CALCULATE + FILTER/ALL/KEEPFILTERS. Information functions (SELECTEDVALUE, HASONEVALUE, ISFILTERED, ISINSCOPE) inspecionam o contexto.

Margem % =
VAR Receita = SUMX ( Vendas, Vendas[Qtd] * Vendas[Preco] )
VAR Custo   = SUMX ( Vendas, Vendas[Qtd] * Vendas[CustoUnit] )
VAR Lucro   = Receita - Custo
RETURN
    DIVIDE ( Lucro, Receita )   // evita erro de divisão por zero

Vendas Alto Valor =
CALCULATE (
    [Total Vendas],
    KEEPFILTERS ( FILTER ( Vendas, Vendas[Preco] > 1000 ) )
)

Windowing (WINDOW, OFFSET, INDEX, RANK) opera sobre uma tabela ordenada com ORDERBY/PARTITIONBY — ideal para variações período-a-período sem time intelligence tradicional.

Vs Mês Anterior =
VAR Atual = [Total Vendas]
VAR Anterior =
    CALCULATE (
        [Total Vendas],
        OFFSET ( -1, ALLSELECTED ( 'Date'[Mes] ), ORDERBY ( 'Date'[Mes] ) )
    )
RETURN Atual - Anterior

Calculation groups, DFS e field parameters

Um calculation group substitui dezenas de medidas repetidas (MTD, QTD, YTD, PY…) por calculation items reutilizáveis. SELECTEDMEASURE() é o placeholder da medida em contexto. Exige Discourage implicit measures = true — calculation items só se aplicam a medidas explícitas.

// item "YTD" do grupo Time Intelligence
CALCULATE ( SELECTEDMEASURE (), DATESYTD ( 'Date'[Date] ) )

Precedência: quando dois calculation groups se aplicam à mesma medida, o de maior precedência é aplicado por fora (avaliado primeiro), e seu SELECTEDMEASURE() é substituído pelo grupo de precedência menor, até chegar à medida.

Dynamic format strings (DFS) aplicam formato condicional sem forçar a medida a virar texto. Ex.: item YOY% sobrescreve o formato para 0.00%;-0.00%;0.00%; use SELECTEDMEASUREFORMATSTRING() para reverter ao formato base.

Large semantic model storage format

O Large semantic model storage format remove o limite de 1 GB por modelo, permitindo modelos que crescem até o limite da capacidade. Habilite antes da primeira refresh, especialmente com incremental refresh de modelos que podem passar de 1 GB.

Composite models

Um composite model mistura storage modes num só modelo. O modo Dual é a peça-chave: uma tabela Dual age como Import (quando serve tabelas Import) ou como DirectQuery (quando serve tabelas DQ), reduzindo limited relationships e melhorando junções. A propagação Dual percorre só o lado "um" dos relacionamentos 1:*.

Aggregations: tabelas de agregação Import sobre tabelas DirectQuery aceleram queries — o motor redireciona a query para a agregação quando possível e faz fallback à fonte quando não. Source groups organizam tabelas por fonte no composite. Limitações: coluna calculada em tabela DirectQuery só referencia colunas da mesma tabela; SAP HANA/BW não entram em composite.

Performance de queries e visuais

Use o Performance Analyzer (Power BI Desktop) para medir, por visual, o tempo de DAX query, visual display e other. Copie a query DAX de um visual lento para o DAX Studio e analise Server Timings.

Melhorar performance de DAX

Toda query DAX divide-se entre a formula engine (FE) — single-thread, resolve lógica complexa — e a storage engine (SE) — multi-thread, cacheável, varre o VertiPaq. Empurre o trabalho para a SE; grandes materializações e callbacks para a FE são o sintoma clássico de DAX lento.

Configurar Direct Lake

Direct Lake lê colunas de Delta tables no OneLake sob demanda. Entenda o ciclo: framing (metadados) → transcoding (carga de coluna) → query → possível fallback. Refresh em Direct Lake é framing: copia só metadados e aponta para os Parquet mais recentes — segundos, não a cópia completa do Import.

Automatic updates ("Keep your Direct Lake data up to date"), ligado por padrão, dispara framing quando detecta mudança no Delta — escopado só às tabelas alteradas. Desligue para segurar dados até o ETL terminar; refaça framing manual, por agenda, REST API ou TOM. Após um erro não-recuperável, o Power BI suspende os updates automáticos até uma refresh on-demand bem-sucedida.

Direct Lake: OneLake vs SQL endpoint

Duas variantes com trade-offs distintos, sobretudo em segurança e fallback.

Incremental refresh

Incremental refresh particiona a tabela e refresca só o período recente, usando dois parâmetros Power Query date/time de nomes reservados e case-sensitive: RangeStart (mais antigo) e RangeEnd (mais recente). Você filtra a coluna de data por eles; o serviço sobrescreve os valores por partição na hora do refresh (padrão de janela deslizante — rolling window).

let
  Source = Sql.Database("srv", "DW"),
  Data = Source{[Schema="dbo", Item="FactSales"]}[Data],
  Ini = Table.SelectRows(Data, each [OrderDate] >= RangeStart),
  Fim = Table.SelectRows(Ini,  each [OrderDate] < RangeEnd)
in Fim

Números que vale decorar

Fluxogramas de decisão em palavras

SQL vs. KQL vs. DAX — a mesma pergunta, três dialetos

A lista de prontidão

Marque cada item somente quando conseguir explicá-lo para outra pessoa sem consultar nada.

• Domínio 1 · Manter uma solução de análise
• Implementar controles de acesso no nível de workspace e de item (incl. Build permission)
• Implementar RLS, CLS, OLS e acesso a arquivos (Warehouse, semantic model e OneLake roles)
• Aplicar sensitivity labels e endossar itens (Promoted / Certified / Master data)
• Configurar controle de versão (Git integration) e Power BI projects (.pbip)
• Criar e configurar deployment pipelines, deployment rules e parameter rules
• Fazer impact analysis de dependências downstream
• Deployar e gerenciar semantic models pelo XMLA endpoint
• Criar e atualizar assets reutilizáveis (.pbit, .pbids, shared semantic models)
• Domínio 2 · Preparar dados
• Criar conexões de dados e escolher o gateway certo
• Descobrir dados com o OneLake catalog e o Real-Time hub
• Escolher entre ingerir e acessar (shortcut vs mirror vs copy)
• Escolher entre os data stores
• Implementar integração OneLake para Eventhouse e semantic models
• Criar views, functions e stored procedures
• Implementar um star schema em lakehouse ou warehouse
• Enriquecer, desnormalizar, agregar e juntar dados
• Tratar duplicados, dados ausentes e nulos; converter tipos; filtrar
• Consultar e agregar com Visual Query Editor, SQL, KQL e DAX
• Domínio 3 · Implementar e gerenciar modelos semânticos
• Escolher um storage mode (Import/DirectQuery/Direct Lake/Dual)
• Implementar um star schema no modelo semântico
• Implementar relacionamentos: bridge tables e many-to-many
• Escrever DAX com variáveis, iteradores, table filtering, windowing e information functions
• Implementar calculation groups, dynamic format strings e field parameters
• Configurar large semantic model storage format e composite models
• Melhorar performance de queries, visuais e DAX
• Configurar Direct Lake (fallback e refresh) e escolher OneLake vs SQL endpoint
• Implementar refresh incremental