Os três domínios têm peso igual. Isso é incomum, e é o fato mais útil para planejar o DP-700: não existe um domínio "grande" em que valha a pena investir demais, nem um pequeno que dê para pular. Monitoramento e otimização vale exatamente o mesmo que ingestão.

O exame é escrito para quem já constrói soluções de dados e agora precisa tomar decisões específicas do Fabric. A maioria das questões não é "o que o OPTIMIZE faz" — é "dadas estas restrições, qual destes quatro itens do Fabric você usa, e por que não os outros três". Por isso as tabelas de decisão deste guia importam mais do que a sintaxe, e ambas importam mais do que decorar caminhos de menu.

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

Capacity, CUs, bursting e smoothing

Tudo no Fabric roda sobre uma capacity — um pool de computação medido em Capacity Units (CU), comprado como SKU F (F2 → F2048) ou herdado de um SKU P do Power BI. Uma capacity pertence a uma região; workspaces são atribuídos a uma capacity. Se você pausar a capacity, tudo dentro dela para, inclusive a replicação de mirroring.

O throttling é uma penalidade em estágios, aplicada contra o consumo futuro suavizado:

Como resolver uma capacity com throttling, em ordem de preferência: esperar (capacities se autorrecuperam à medida que o carryforward é consumido) → aumentar temporariamente o SKU → distribuir cargas entre capacities → habilitar overage billing (taxa 3×) → pausar e retomar, o que zera o uso futuro mas deixa o conteúdo indisponível. Diagnostique com o Microsoft Fabric Capacity Metrics app: a tabela de system events na página Compute, a aba Overages e a métrica Minutes to burndown.

OneLake

Um data lake lógico por tenant, provisionado automaticamente, sem infraestrutura para criar. Sua estrutura é fixa e vale desenhar no papel:

• Delta Parquet é o formato nativo de todas as cargas de trabalho. Warehouse, Lakehouse e Eventhouse gravam em Delta, e é isso que permite uma única cópia ser lida por todos os engines.
• O OneLake expõe um subconjunto das APIs do ADLS Gen2 e do Blob, então ferramentas externas o endereçam como https://onelake.dfs.fabric.microsoft.com/<workspace>/<item>/Tables/<table>.
• Uma tenant setting na seção OneLake controla se aplicativos externos (APIs do ADLS, OneLake file explorer) podem acessá-lo. Desligá-la não bloqueia os engines do próprio Fabric.
• Criptografia em repouso usa chaves gerenciadas pela Microsoft por padrão (chaves gerenciadas pelo cliente são opcionais); TLS 1.2 no mínimo em trânsito.

A taxonomia de itens que você precisa reconhecer de imediato

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

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

Workspace roles — decore esta matriz

Spark workspace settings

Workspace settings → Data Engineering/Science → Spark settings. Quatro abas importam: Pool, Environment, Job admission (High concurrency) e Automatic log.

Starter pools vs. custom pools

Famílias de nós

• Autoscale — defina nós mínimos e máximos; o decommissioning de executores vem ligado por padrão (spark.yarn.executor.decommission.enabled = true).
• Dynamic executor allocation — reserva executores na submissão a partir do mínimo, pede mais durante a execução e libera ao terminar. Elimina o tuning manual por estágio.
• Expiração de sessão — padrão de 20 minutos; o pool é desalocado 2 minutos depois da expiração. Pools de nó único são suportados (driver e executor no mesmo nó, com recursos pela metade).
• High concurrency — permite que vários notebooks compartilhem uma sessão Spark (e, quando habilitado para pipelines, que atividades de notebook da mesma execução compartilhem a sessão). Reduz drasticamente o custo de inicialização para muitos notebooks pequenos.

Environments

Um Environment é um item do workspace que agrupa três coisas: Spark compute (versão do runtime + propriedades de sessão), bibliotecas (feeds públicos e uploads de .whl/.jar próprios) e resources (arquivos pequenos compartilhados entre os notebooks anexados).

• Save deixa as mudanças em staging; Publish as aplica. Apenas um publish por vez; você não pode editar bibliotecas ou compute durante um publish.
• Quick mode publica em cerca de 5 segundos. Full mode leva de 3 a 6 minutos para publicar mais 1 a 3 minutos na inicialização da sessão, mas produz um snapshot — use-o para pipelines, execuções agendadas e cargas compartilhadas.
• Resources são em tempo real; nunca precisam de publish.
• Anexe em três níveis: padrão do workspace (Workspace settings → Spark settings → aba Environment), notebook ou Spark job definition. Assim que um environment vira o padrão do workspace, só workspace admins podem atualizá-lo.
• Anexar entre workspaces exige a mesma capacity e as mesmas configurações de segurança de rede, e a configuração de compute do environment de origem é ignorada — o pool do workspace atual prevalece.
• Mudanças só valem na próxima sessão.

Domain workspace settings

Domains são agrupamentos lógicos de workspaces por área de negócio — o mecanismo para um modelo de governança federado, tipo data mesh. Subdomains os refinam e herdam os admins do pai.

• Atribua workspaces de três formas: por nome do workspace, por workspace admin (pega todos os workspaces que aquelas pessoas administram) ou por capacity. As duas últimas excluem os "My workspaces" pessoais.
• Default domain — definido para usuários/grupos específicos: os workspaces não atribuídos deles passam a ser atribuídos, novos workspaces são atribuídos automaticamente e essas pessoas viram domain contributors.
• Delegated settings permitem que um domain sobrescreva certas tenant settings — em especial sensitivity labels padrão e certification (habilitar/desabilitar, nomear os certificadores, informar uma URL de documentação).

OneLake workspace settings

• Shortcut cache — On/Off, um período de retenção de 1 a 28 dias e um botão Reset cache. O contador de retenção reinicia a cada acesso ao arquivo. Arquivos maiores que 1 GB não são cacheados. O cache vale para shortcuts de GCS, Amazon S3, compatíveis com S3 e via on-premises gateway — é uma otimização de custo de egresso entre nuvens.
• Workspace identity — uma managed identity do workspace (criada só por um Admin). É o pré-requisito para trusted workspace access a contas ADLS Gen2 atrás de firewall e para managed private endpoints.
• Managed private endpoints — conectividade privada do Spark do Fabric a fontes de dados atrás de uma VNet.

Apache Airflow job workspace settings

Apache Airflow job é o sucessor do Workflow Orchestration Manager do ADF: um serviço gerenciado de Airflow para orquestração code-first com DAGs em Python.

• Airflow 2.10.5 sobre Python 3.12. Não dá para mudar a versão do Airflow de um job existente — crie um novo.
• Suporta Git sync para armazenar DAGs, Azure Key Vault como backend de segredos, pacotes privados, autoscaling, alta disponibilidade, deferrable operators e pause/resume TTL.
• Redes privadas/virtuais não são suportadas.
• Escolha Airflow em vez de um pipeline quando a equipe já escreve DAGs de Airflow, precisa de ramificação ou geração dinâmica de tarefas em Python, ou está migrando DAGs existentes. Escolha um pipeline do Fabric para orquestração sem código.

Configurar controle de versão (Git integration)

A Git integration é configurada no nível do workspace e liga um workspace a um branch e uma pasta. Provedores suportados: Azure DevOps, GitHub e GitHub Enterprise — apenas na nuvem. Somente um Admin do workspace pode conectá-lo a um repositório.

Tipos de item suportados (lista parcial — saiba o formato geral, não cada entrada): Lakehouse, Notebook, Spark Job Definition, Environment, GraphQL, User Data Functions, Copy Job, Dataflow Gen2, Pipeline, Mirrored Database, Warehouse, Mirrored Azure Databricks Catalog, Eventhouse, Eventstream, KQL Database, KQL Queryset, Real-Time Dashboard, Activator, SQL database, Variable Library. Vários itens de Power BI e Data Science ainda estão em Preview.

Estados do Git

• Synced — idêntico no workspace e no branch.
• Uncommitted — alterado só no workspace. Faça commit.
• Modified / Update required — alterado só no branch. Faça update.
• Conflict — alterado nos dois. Resolva escolhendo a versão do workspace ou a do branch, item a item.

Database projects

Para Warehouses, é o controle de versão do schema em si. Use a extensão SQL Database Projects no VS Code (ou Azure Data Studio) para extrair o warehouse num .sqlproj, comparar com outro ambiente usando Schema Compare e publicar com o SqlPackage. É a resposta quando o requisito é "implantar apenas as mudanças de schema como parte de um release pipeline de DevOps existente", em vez de "promover itens inteiros".

Deployment pipelines

O mecanismo nativo de promoção de conteúdo do Fabric: de 2 a 10 estágios (padrão 3 — Development, Test, Production), cada estágio com um workspace atribuído.

Variable libraries

Um item do workspace que guarda variáveis de configuração mais value sets alternativos — um por estágio do ciclo de vida — com exatamente um value set ativo por vez. Os consumidores resolvem o valor a partir do conjunto ativo no próprio workspace, então a mesma definição de pipeline aponta para o lakehouse de dev em Dev e para o de prod em Prod, sem precisar de deployment rule.

• Tipos: string, integer, boolean e referências a itens.
• Consumidores: Pipeline, shortcut de Lakehouse, Notebook (via notebookutils.variableLibrary e %%configure), Dataflow Gen2, Copy job, User data functions, Plan.
• Limites: até 1.000 variáveis e 1.000 value sets; menos de 10.000 células no total; item ≤ 1 MB; notas e descrições ≤ 2.048 caracteres.
• Não dá para excluir o value set ativo — ative outro antes.
• Funciona tanto com Git integration quanto com deployment pipelines, e é exposto pelas APIs públicas do Fabric.

As quatro camadas de controle de acesso do Fabric

Controles de acesso no nível do item

OneLake security (roles no plano de dados)

Uma OneLake security role tem quatro partes: dados (as tabelas ou pastas que ela cobre), permissões, membros e restrições (exclusões de linhas e colunas). As roles são definidas uma vez e aplicadas por todos os engines do Fabric — e por "authorized engines" externos registrados, que buscam a política efetiva pelas APIs do OneLake.

• Somente workspace Admin ou Member pode criar OneLake security roles.
• Elas governam Viewers e usuários com permissão de item Read/ReadData. Workspace Admins, Members e Contributors as ignoram completamente — sempre leem e escrevem tudo.
• Todo lakehouse já vem com uma role DefaultReader que concede acesso a quem tem ReadAll. Ela pode ser editada ou excluída.
• Segurança em nível de pasta no lakehouse de origem também governa os shortcuts que apontam para ele — a segurança acompanha o dado, não a referência.
• Subpastas herdam as permissões do pai por padrão.

Segurança de linha, coluna e objeto no Warehouse

Row-level security

Uma função de predicado inline table-valued mais uma security policy. RLS funciona tanto no Warehouse quanto no SQL analytics endpoint.

-- 1. A função de predicado: retorna uma linha quando o acesso é permitido
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() = 'gerente@contoso.com';
GO

-- 2. Vincule à tabela
CREATE SECURITY POLICY Security.SalesFilter
ADD FILTER PREDICATE Security.tvf_SecurityPredicate(SalesRep)
ON dbo.Sales
WITH (STATE = ON);
GO

Column-level security

GRANT SELECT ON dbo.Employees(EmployeeId, FirstName, LastName, Department)
    TO [analistas@contoso.com];

-- ou negue colunas específicas numa tabela já concedida
DENY SELECT ON dbo.Employees(Salary, NationalId) TO [analistas@contoso.com];

Object-level security

CREATE ROLE SalesAnalyst;
GRANT SELECT ON SCHEMA::sales TO SalesAnalyst;
DENY SELECT ON dbo.PayrollDetail TO SalesAnalyst;
ALTER ROLE SalesAnalyst ADD MEMBER [usuario@contoso.com];

Dynamic data masking

Mascara valores apenas no resultado da consulta — o dado armazenado não muda. Usuários com a permissão UNMASK (e workspace Admin/Member/Contributor) veem os valores reais.

ALTER TABLE dbo.Customers
    ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');

ALTER TABLE dbo.Payments
    ALTER COLUMN CardNumber ADD MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)');

GRANT UNMASK TO [financeiro-admin@contoso.com];
ALTER TABLE dbo.Customers ALTER COLUMN Email DROP MASKED;   -- remover

Sensitivity labels e endorsement

• Sensitivity labels vêm do Microsoft Purview Information Protection. São aplicados por item, propagam-se para baixo pela linhagem (um relatório herda do seu modelo semântico) e podem carregar criptografia que acompanha os arquivos exportados. Aplicá-los exige que o label esteja publicado para o usuário e a tenant setting habilitada. Um domain pode definir um label padrão via delegated settings.
• Endorsement tem três níveis:
  • Promoted — qualquer usuário com permissão de escrita no item pode promover.
  • Certified — somente usuários nomeados como certificadores pelo Fabric admin (ou pelo domain admin, via delegated settings) podem certificar.
  • Master data — a fonte autoritativa para uma área de assunto.
  Itens endossados aparecem melhor ranqueados e são filtráveis no OneLake catalog.

Fabric audit logs

• A atividade do Fabric flui para o unified audit log do Microsoft Purview / Microsoft 365. Acesse pelo portal de compliance do Purview, pelo link Audit logs no admin portal do Fabric, ou programaticamente com Get-PowerBIActivityEvent / a API REST Admin Activity Events.
• O admin monitoring workspace traz o relatório Feature usage and adoption e um modelo semântico de dados de atividade para Fabric admins.
• Workspace monitoring (workspace settings → Monitoring → Log workspace activity) provisiona um Eventhouse somente leitura no workspace que coleta logs de diagnóstico e métricas de Eventhouse, Eventstream, pipelines, Copy jobs, mirrored databases, GraphQL e modelos semânticos. A retenção é de 30 dias; é cobrado como consumo normal de capacity de Eventhouse/Eventstream; você pode habilitar workspace monitoring ou Log Analytics, não os dois. Consulte com KQL ou SQL.
• Operações de plano de dados do OneLake aparecem com nomes que correspondem às APIs do ADLS Gen2 (CreateFile, DeleteFile…). Requisições de leitura e requisições das cargas de trabalho do Fabric não são incluídas.

Escolher entre Dataflow Gen2, pipeline e notebook

Atividades de pipeline que você precisa reconhecer

Toda atividade suporta quatro condições de dependência na seta de saída: On success, On failure, On completion e On skip. As atividades também expõem Retry, Retry interval, Timeout e Secure output/input na aba General.

Parâmetros e expressões dinâmicas

Parâmetros são definidos uma vez por execução e são somente leitura dentro dela. Variáveis são mutáveis durante a execução, via as atividades Set variable e Append variable.

// Interpolação de string usa @{ }; um @ sozinho inicia uma expressão; @@ escapa um @ literal
"Test_@{formatDateTime(utcNow(), 'yyyy-MM-dd')}"

// Funções comuns por categoria
Data/hora : addDays addHours addMinutes formatDateTime utcNow startOfDay ticks convertFromUtc
String    : concat replace split substring startsWith endsWith toLower trim indexOf guid
Coleção   : contains empty first last length skip take union join intersection
Lógica    : and or not if equals greater greaterOrEquals less lessOrEquals
Conversão : array bool float int string json coalesce createArray base64 uriComponent
Matemática: add sub mul div mod min max rand range

// Exemplos práticos
@concat('vendas_', formatDateTime(utcNow(), 'yyyyMMdd'), '.parquet')
@if(greater(activity('Lookup_RowCount').output.firstRow.cnt, 0), 'load', 'skip')
@formatDateTime(addDays(utcNow(), -1), 'yyyy-MM-ddTHH:mm:ssZ')
@coalesce(pipeline().parameters.RunDate, formatDateTime(utcNow(), 'yyyy-MM-dd'))

Passando parâmetros para um notebook

# No notebook CHAMADO: marque uma célula como "parameter cell" (no menu da célula)
# e declare os padrões ali. Os valores do chamador sobrescrevem em tempo de execução.
run_date = "2026-01-01"
layer    = "bronze"

# Devolver um valor ao chamador
import notebookutils
notebookutils.notebook.exit(str(rows_written))

# No notebook CHAMADOR
exit_val = notebookutils.notebook.run("Load_Bronze", 90, {"run_date": "2026-08-30", "layer": "silver"})
# 4º argumento posicional = ID do workspace, para chamadas entre workspaces (Runtime 1.2+)

A partir de um pipeline, os Base parameters da atividade Notebook mapeiam para a mesma parameter cell, e o valor de exit() do notebook é lido adiante como @activity('Notebook1').output.result.exitValue.

Orquestrando muitos notebooks com um DAG

DAG = {
    "activities": [
        {"name": "LoadCustomers", "path": "nb_load_customers",
         "timeoutPerCellInSeconds": 120, "args": {"layer": "bronze"}},
        {"name": "LoadOrders", "path": "nb_load_orders",
         "timeoutPerCellInSeconds": 120, "args": {"layer": "bronze"}},
        {"name": "BuildFactSales", "path": "nb_build_fact",
         "timeoutPerCellInSeconds": 300,
         "retry": 1, "retryIntervalInSeconds": 30,
         "dependencies": ["LoadCustomers", "LoadOrders"]}
    ],
    "timeoutInSeconds": 43200,   # 12 h, o padrão
    "concurrency": 50          # 0 = sem limite
}
notebookutils.notebook.runMultiple(DAG, {"displayDAGViaGraphviz": True})

# Forma paralela simples, sem dependências:
notebookutils.notebook.runMultiple(["nb_a", "nb_b", "nb_c"])

Agendamentos e event-based triggers

Os payloads de storage event seguem o schema CloudEvents: source, subject, type (por exemplo Microsoft.Storage.BlobCreated), time, id, data, specversion. O Fabric extrai nome do arquivo e caminho da pasta do Subject e os expõe no expression builder como trigger parameters.

Padrões de orquestração que vale conhecer pelo nome

Cargas full e incremental

from delta.tables import DeltaTable
from pyspark.sql import functions as F

# 1. Ler o watermark atual do destino
watermark = spark.sql("SELECT COALESCE(MAX(ModifiedDate), '1900-01-01') AS wm FROM silver.customers") \
                 .collect()[0]["wm"]

# 2. Trazer apenas linhas novas/alteradas
src = (spark.read.format("delta").load("Tables/bronze/customers")
            .filter(F.col("ModifiedDate") > F.lit(watermark)))

# 3. UPSERT com MERGE
tgt = DeltaTable.forName(spark, "silver.customers")
(tgt.alias("t")
    .merge(src.alias("s"), "t.CustomerId = s.CustomerId")
    .whenMatchedUpdateAll(condition="s.ModifiedDate > t.ModifiedDate")
    .whenNotMatchedInsertAll()
    .whenNotMatchedBySourceUpdate(set={"IsDeleted": "true"})   # soft delete
    .execute())

# 4. Alternativa: sobrescrita idempotente de uma fatia delimitada
(df.write.format("delta").mode("overwrite")
   .option("replaceWhere", "LoadDate >= '2026-08-01' AND LoadDate < '2026-09-01'")
   .saveAsTable("silver.orders"))

Preparando dados para um modelo dimensional

A orientação do Fabric é o Kimball clássico: um star schema com tabelas fato cercadas por tabelas dimensão. Fatos guardam medidas mais as chaves de dimensão, num grão declarado; dimensões descrevem as entidades.

Slowly changing dimensions

-- Etapa 1: expirar linhas cujos atributos monitorados mudaram
UPDATE d
   SET d.EndDate  = CAST(GETDATE() AS date),
       d.IsCurrent = 0
  FROM dbo.DimProduct AS d
  JOIN staging.Products AS s ON s.ProductID = d.ProductID
 WHERE d.IsCurrent = 1
   AND (d.ProductName <> s.ProductName OR d.Category <> s.Category);

-- Etapa 2: inserir a nova versão vigente (e os membros totalmente novos)
INSERT INTO dbo.DimProduct
      (ProductID, ProductName, Category, StartDate, EndDate, IsCurrent, IsInferred)
SELECT s.ProductID, s.ProductName, s.Category, CAST(GETDATE() AS date), NULL, 1, 0
  FROM staging.Products AS s
  LEFT JOIN dbo.DimProduct AS d
       ON d.ProductID = s.ProductID AND d.IsCurrent = 1
 WHERE d.ProductID IS NULL;

-- Etapa 3: soft delete dos membros que sumiram da origem
UPDATE dbo.DimProduct
   SET IsDeleted = 1, IsCurrent = 0, EndDate = CAST(GETDATE() AS date)
 WHERE IsCurrent = 1
   AND NOT EXISTS (SELECT 1 FROM staging.Products s WHERE s.ProductID = DimProduct.ProductID);

INSERT INTO dbo.FactSales (DateKey, CustomerKey, ProductKey, Quantity, SalesAmount, SourceOrderNumber)
SELECT CONVERT(int, FORMAT(o.OrderDate, 'yyyyMMdd')),
       ISNULL(c.CustomerKey, -1),          -- -1 = o membro "Unknown"
       ISNULL(p.ProductKey,  -1),
       l.Quantity, l.Quantity * l.UnitPrice, o.SalesOrderNumber
  FROM staging.SalesOrders o
  JOIN staging.SalesOrderLines l ON l.SalesOrderID = o.SalesOrderID
  -- join point-in-time: pega a versão da dimensão válida na data do pedido
  LEFT JOIN dbo.DimCustomer c
         ON c.CustomerID = o.CustomerID
        AND o.OrderDate >= c.StartDate
        AND (o.OrderDate < c.EndDate OR c.EndDate IS NULL)
  LEFT JOIN dbo.DimProduct p
         ON p.ProductID = l.ProductID AND p.IsCurrent = 1
 WHERE o.SalesOrderNumber > @LastLoadedOrderNumber;   -- high-water mark

Regras que o exame cobra sobre carga dimensional

• Nunca faça truncate-and-reload numa dimensão cujas surrogate keys são referenciadas por fatos — você deixaria todas as linhas de fato órfãs.
• Soft delete, nunca hard delete, de membros de dimensão. Fatos históricos ainda apontam para eles.
• Membros inferidos (ou fatos que chegam cedo demais): quando um fato referencia uma chave de dimensão desconhecida, insira uma linha placeholder marcada com IsInferred = 1 e enriqueça-a quando o registro real chegar.
• A dimensão de data não tem sistema de origem — gere-a com uma CTE recursiva ou uma tabela de números, bem além da data atual.
• Carregue dimensões antes dos fatos, sempre. Os fatos precisam das chaves.
• Prefira tabelas de staging num schema staging próprio, limpas com TRUNCATE TABLE no início de cada execução.

Um padrão de carga para dados de streaming

Dados de streaming que chegam ao repouso seguem o formato medallion com um ajuste — a camada bronze é append-only e nunca é alterada:

Lakehouse ou Eventhouse para a landing zone? Eventhouse quando as consultas são de séries temporais e interativas e a latência é medida em segundos; Lakehouse quando o stream alimenta os mesmos pipelines em lote de todo o resto. Dá para ter os dois barato: aterrisse no Eventhouse e ligue o OneLake availability, que materializa uma cópia Delta legível pelo Spark e pelo SQL endpoint sem custo extra de armazenamento.

OneLake shortcuts

Um shortcut é um ponteiro que aparece como uma pasta. Nenhum dado é copiado e nenhum armazenamento é consumido.

# Spark — um shortcut em Tables/ se comporta exatamente como uma tabela nativa
df = spark.read.format("delta").load("Tables/MyShortcut")
df = spark.sql("SELECT * FROM MyLakehouse.MyShortcut LIMIT 1000")

-- SQL analytics endpoint
SELECT TOP (100) * FROM [MyLakehouse].[dbo].[MyShortcut];

// KQL — um shortcut numa KQL database é uma external table
external_table('MyShortcut')
| take 100

Mirroring

O mirroring replica continuamente um banco operacional externo para o OneLake como tabelas Delta, sem ETL para construir. A computação de replicação é gratuita e cada capacity unit inclui 1 TB de armazenamento de mirroring gratuito (então F64 → 64 TB). A latência pode chegar a ~15 segundos.

• Cria duas coisas no workspace: o processo de replicação e um SQL analytics endpoint somente leitura.
• Exige uma capacity do Fabric em execução — pausar a capacity interrompe a replicação.
• A retenção Delta é de 1 dia por padrão para bancos criados após meados de junho de 2025 (7 dias para os mais antigos); configurável em Settings → Delta table management ou via retentionInDays na API.

Ingerindo com pipelines e Copy job

Copy activity

• Mais de 50 conectores de origem e 40 de destino; suporta staging (um salto intermediário em blob/lakehouse) para origens que não conseguem enviar direto ao destino.
• Degree of copy parallelism, tolerância a falhas (pular linhas incompatíveis e registrá-las) e copy behavior (preservar hierarquia, achatar hierarquia, mesclar arquivos).
• Conectividade a ambientes on-premises pelo on-premises data gateway, e a uma VNet pelo VNet data gateway.
• Métricas de saída disponíveis adiante: rowsRead, rowsCopied, rowsSkipped, throughput, dataConsistencyVerification.

Copy job

Um item independente — sem precisar de pipeline — para cópia full, incremental e replicação por CDC.

Métodos de atualização no destino: Append (padrão), Merge (exige coluna-chave; com CDC também aplica deletes), Overwrite e SCD Tipo 2 com effective dating. O Copy job também grava colunas de auditoria opcionais por linha — hora de extração, caminho do arquivo de origem, IDs de workspace/job/run e os limites da janela incremental — que é a resposta nativa para questões de linhagem em nível de linha. Ele retoma do último checkpoint bem-sucedido após uma falha, suporta Git/CI-CD e Variable libraries, e tem um modo de auto-partitioning em Preview para leituras paralelas de tabelas grandes.

Transformando com PySpark, SQL e KQL

from pyspark.sql import functions as F, Window

# Leitura / escrita
df = spark.read.format("delta").load("Tables/bronze/orders")
df = spark.read.option("header",True).option("inferSchema",True).csv("Files/raw/*.csv")
df.write.format("delta").mode("append").saveAsTable("silver.orders")

# Formato
df2 = (df.withColumn("OrderYear", F.year("OrderDate"))
         .withColumn("Net", F.col("Gross") - F.col("Discount"))
         .withColumnRenamed("cust_id", "CustomerId")
         .drop("_ingest_raw")
         .filter(F.col("Status") != "Cancelled"))

# Agrupar e agregar
agg = (df2.groupBy("CustomerId", "OrderYear")
          .agg(F.sum("Net").alias("Revenue"),
               F.countDistinct("OrderId").alias("Orders"),
               F.max("OrderDate").alias("LastOrder")))

# Desnormalizar — faça broadcast do lado pequeno para evitar shuffle
wide = df2.join(F.broadcast(dim_customer), "CustomerId", "left")

# Window functions: manter a linha mais recente por chave
w = Window.partitionBy("CustomerId").orderBy(F.col("ModifiedDate").desc())
latest = df2.withColumn("rn", F.row_number().over(w)).filter("rn = 1").drop("rn")

# Semiestruturado
flat = (df.withColumn("j", F.from_json("payload", schema))
          .select("j.*")
          .withColumn("tag", F.explode("tags")))
pivoted = df2.groupBy("CustomerId").pivot("OrderYear").sum("Net")

# %%pyspark  %%sql  %%scala  %%sparkr  %%html  %%configure

%%sql
CREATE OR REPLACE TABLE silver.customers AS
SELECT CustomerId, INITCAP(Name) AS Name, Country
FROM   bronze.customers
WHERE  CustomerId IS NOT NULL;

%%configure
{ "defaultLakehouse": { "name": "lh_silver" },
  "conf": { "spark.sql.shuffle.partitions": "200" } }

-- CTAS: a forma mais rápida de materializar um resultado transformado
CREATE TABLE gold.SalesByRegion AS
SELECT r.RegionName,
       SUM(f.SalesAmount)                    AS Revenue,
       COUNT_BIG(*)                           AS OrderCount,
       SUM(f.SalesAmount) / NULLIF(COUNT_BIG(*),0) AS AvgOrder
  FROM dbo.FactSales f
  JOIN dbo.DimRegion r ON r.RegionKey = f.RegionKey
 GROUP BY r.RegionName;

-- Window functions
SELECT CustomerId, OrderDate, SalesAmount,
       SUM(SalesAmount) OVER (PARTITION BY CustomerId ORDER BY OrderDate
                              ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS RunningTotal,
       LAG(SalesAmount) OVER (PARTITION BY CustomerId ORDER BY OrderDate)        AS PrevOrder,
       ROW_NUMBER() OVER (PARTITION BY CustomerId ORDER BY OrderDate DESC)      AS Recency
  FROM dbo.FactSales;

-- Agregação em múltiplos níveis
SELECT Country, City, SUM(Revenue) AS Revenue, GROUPING(City) AS IsCityTotal
  FROM gold.Sales
 GROUP BY ROLLUP (Country, City);       -- também: CUBE, GROUPING SETS

-- Cross-warehouse / cross-lakehouse numa consulta só (nome em três partes)
INSERT INTO gold.DimProduct
SELECT * FROM LakehouseSilver.dbo.products;

Events
| where Timestamp > ago(7d) and Level in ("Error", "Critical")
| extend Duration = EndTime - StartTime,
         Region   = tostring(parse_json(Properties).region)
| project Timestamp, DeviceId, Region, Duration, Message
| summarize ErrorCount = count(),
            Devices    = dcount(DeviceId),
            p95        = percentile(Duration, 95),
            LastSeen   = max(Timestamp)
          by Region, bin(Timestamp, 1h)
| order by Timestamp asc, ErrorCount desc

Dados duplicados, ausentes e atrasados

Superfície T-SQL do Fabric Warehouse

O SQL analytics endpoint (de um Lakehouse ou mirrored database) é somente leitura: sem DDL, sem INSERT/UPDATE/DELETE. Ele suporta views, funções, stored procedures, RLS, CLS e DDM.

Lakehouses com schema habilitado

• Schemas agrupam tabelas por domínio e vêm ligados por padrão em lakehouses novos. Todo lakehouse com schema tem um schema dbo que não pode ser renomeado nem removido. Nomes de schema aceitam apenas letras, dígitos e underscores.
• Grave em um deles com df.write.mode("overwrite").saveAsTable("marketing.campaigns"). Sem o prefixo de schema, a tabela vai para dbo.
• Schema shortcuts mapeiam um schema inteiro para o schema de outro lakehouse ou uma pasta do ADLS Gen2.
• Spark SQL entre workspaces usa o nome em quatro partes workspace.lakehouse.schema.table (três partes para um lakehouse sem schema).
• Limitação: lakehouses com schema habilitado não podem ser compartilhados pelo compartilhamento de workspace — exponha-os por shortcuts em um lakehouse que o usuário já alcança.

A pilha do Real-Time Intelligence

Escolhendo um engine de streaming

Eventstream

Fontes

Operadores de transformação

Destinos

• Eventhouse — dois modos: direct ingestion (caminho mais rápido, eventos brutos direto para uma tabela KQL) ou event processing before ingestion (aplica os operadores antes).
• Lakehouse — grava em Delta. Formato de entrada JSON, Avro ou CSV. Ajuste Minimum rows (1 – 2.000.000) e Maximum duration (1 minuto – 2 horas): menos linhas ou duração menor ⇒ mais arquivos pequenos.
• Derived stream — o próprio stream transformado, republicado para que vários destinos (e o Real-Time hub) o consumam. Suporta pause/resume.
• Activator — para regras e alertas.
• Custom endpoint — aplicações externas leem pelo protocolo Kafka.
• Spark notebook Preview — entrega os eventos a um job de Structured Streaming.

Eventhouse, KQL databases e OneLake

• Um Eventhouse é um container que abriga uma ou mais KQL databases que compartilham sua capacity e seus recursos. Cada database ganha um KQL queryset embutido.
• Por padrão o serviço é suspenso quando fica ocioso e reativa em poucos segundos. O capacity planner permite definir um cronograma semanal recorrente em blocos de 60 minutos com um mínimo de CU por bloco (mínimo padrão de 2 CU) mais autoscale acima disso — é a resposta quando a questão diz "as consultas nunca podem pagar penalidade de cold start no horário comercial".
• Os dados são indexados e particionados por hora de chegada, e é por isso que KQL filtrado por tempo é tão rápido.

OneLake availability — "uma cópia lógica"

Habilite no nível de database ou de tabela (com backfill opcional das tabelas existentes) e os dados do KQL também são materializados como Delta no OneLake, legíveis por Spark, SQL endpoint, Warehouse, Lakehouse e Direct Lake — sem custo extra de armazenamento. A política de retenção do database também governa a cópia no OneLake.

// Padrão: agrupa até arquivos Parquet de ~200–256 MB ou até 3 horas. Faixa: 5 min – 3 h.
.alter-merge table Telemetry policy mirroring dataformat=parquet
    with (IsEnabled=true, TargetLatencyInMinutes=5)

// Latência 00:00:00 significa que tudo já está no OneLake
.show table mirroring operations

Tabelas nativas vs. OneLake shortcuts vs. query acceleration

O query acceleration mantém em cache os dados do shortcut dentro de uma janela configurável em dias (herdada do database pai por padrão), com base no modificationTime do log Delta. Habilite na criação do shortcut (botão Accelerate) ou depois via Manage → Data policies → Query acceleration. Funciona apenas com tabelas Delta, exige workspace Admin / Member / Contributor e, por conformidade, convém manter o Eventhouse na mesma região dos dados.

Processando dados com KQL

// ---- filtragem e formato ----
| where Level == "Error" and Timestamp between (ago(1d) .. now())
| where Message has "timeout"        // 'has' = correspondência de termo indexado, RÁPIDO
| where Message contains "time"     // varredura de substring, LENTO — saiba a diferença
| take 10  /  | limit 10            // linhas arbitrárias, sem garantia de ordem
| top 10 by Duration desc          // ordenado
| project Timestamp, DeviceId, Duration
| project-away RawPayload
| project-rename ts = Timestamp
| extend Minutes = Duration / 1m
| distinct DeviceId
| sort by Timestamp desc

// ---- agregação ----
| summarize count(), dcount(DeviceId), sum(Bytes), avg(Latency),
            min(Timestamp), max(Timestamp),
            percentile(Latency, 95), percentiles(Latency, 50, 90, 99),
            make_list(EventId), make_set(Region),
            arg_max(Timestamp, *),        // a linha mais recente inteira por grupo
            arg_min(Timestamp, Status),
            take_any(*)
          by Region, bin(Timestamp, 5m)

// ---- séries temporais ----
| make-series Total = sum(Bytes) default=0
    on Timestamp from ago(7d) to now() step 1h by DeviceId
| extend (anomalies, score, baseline) = series_decompose_anomalies(Total)
| render timechart

// ---- joins ----
Devices
| join kind=leftouter (Telemetry | summarize LastSeen = max(Timestamp) by DeviceId)
     on DeviceId
| join kind=inner hint.strategy=broadcast (SmallLookup) on $left.Id == $right.Key
| lookup (DimDevice) on DeviceId        // left-outer otimizado contra uma dimensão pequena
| union withsource=SourceTable Errors, Warnings

// ---- semiestruturado ----
| extend p = parse_json(Payload)
| extend City = tostring(p.location.city), Temp = todouble(p.temp)
| mv-expand tag = p.tags to typeof(string)
| parse Message with "user=" User " action=" Action

// ---- utilidades ----
let threshold = 500;
let hot = materialize(Telemetry | where Timestamp > ago(1h));   // cacheia uma subconsulta reutilizada
let demo = datatable(Id:int, Name:string) [1, "a", 2, "b"];
| extend Ingested = ingestion_time()      // quando o Kusto recebeu, vs. hora do evento
| serialize | extend Delta = Value - prev(Value, 1)

Tipos de join — a tabela completa

Update policies e materialized views

.create table RawLogs (OriginalRecord:string)
.create table ParsedLogs (Timestamp:datetime, ThreadId:int, Message:string)

.create function ExtractLogs() {
    RawLogs
    | parse OriginalRecord with "[" Timestamp:datetime "] [ThreadId:" ThreadId:int "] " Message:string
    | project-away OriginalRecord
}

.alter table ParsedLogs policy update
@'[{ "IsEnabled": true,
    "Source": "RawLogs",
    "Query": "ExtractLogs()",
    "IsTransactional": true,
    "PropagateIngestionProperties": false }]'

// Descartar a cópia bruta depois de transformada
.alter-merge table RawLogs policy retention softdelete = 0s

Update policies disparam em .ingest, .set, .append, .set-or-append, .set-or-replace, .move extents e .replace extents. Não podem fazer consultas cross-cluster, callouts, nem usar nomes qualificados database()/cluster(). Investigue falhas com .show ingestion failures | where OriginatesFromUpdatePolicy == true.

Update policy vs. materialized view: uma update policy transforma no momento da ingestão e grava numa segunda tabela (boa para parsing, divisão, filtragem). Uma materialized view (.create materialized-view) mantém uma agregação atualizada incrementalmente sobre uma tabela de origem (boa para rollups com summarize/arg_max que você consulta o tempo todo).

Spark Structured Streaming

from pyspark.sql import functions as F
from pyspark.sql.types import StructType, StructField, StringType, DoubleType, TimestampType

schema = StructType([
    StructField("deviceId", StringType(),   False),
    StructField("temp",     DoubleType(),   True),
    StructField("eventTime",TimestampType(),True)])

raw = (spark.readStream.format("eventhubs").options(**ehConf).load())

parsed = (raw
    .withColumn("body", F.col("body").cast("string"))
    .select(F.from_json("body", schema).alias("e"))
    .select("e.*"))

query = (parsed
    .repartition(48)                                # alinhar aos cores disponíveis
    .writeStream
    .format("delta")
    .option("checkpointLocation", "Files/checkpoints/telemetry")
    .outputMode("append")
    .partitionBy("deviceId")
    .trigger(processingTime="1 minute")
    .toTable("silver.telemetry"))

# Watermark = quanto tempo esperar por eventos atrasados antes de descartá-los e fechar o estado
windowed = (parsed
    .withWatermark("eventTime", "10 minutes")
    .groupBy(F.window("eventTime", "5 minutes"), "deviceId")   # TUMBLING
    .agg(F.avg("temp").alias("AvgTemp"), F.count("*").alias("Readings")))

# HOPPING / deslizante: windowDuration e depois slideDuration
F.window("eventTime", "10 minutes", "5 minutes")

# SESSION: timeout de intervalo
F.session_window("eventTime", "5 minutes")

# Upsert numa tabela Delta a partir de um stream
def upsert(batch_df, batch_id):
    batch_df.createOrReplaceTempView("updates")
    batch_df.sparkSession.sql("""
        MERGE INTO silver.telemetry AS t
        USING updates AS u ON t.deviceId = u.deviceId AND t.eventTime = u.eventTime
        WHEN MATCHED THEN UPDATE SET *
        WHEN NOT MATCHED THEN INSERT *""")

(parsed.writeStream
    .foreachBatch(upsert)
    .option("checkpointLocation", "Files/checkpoints/upsert")
    .trigger(availableNow=True)      # processa tudo o que há disponível e para
    .start())

Para streaming em produção use um Spark job definition com política de retry, e não um notebook, e monitore na aba Structured Streaming do monitoring hub (Input rate, Process rate, Input rows, Batch duration, Operation duration).

Windowing functions — uma tabela, três engines

Activator

• Objects são formados agrupando eventos por uma object key (ID do dispositivo, ID da conta). As regras então são avaliadas por instância de objeto.
• Regras stateless julgam cada evento isoladamente e disparam em frações de segundo. Regras stateful mantêm memória por objeto: BECOMES, INCREASES/DECREASES, EXIT RANGE, heartbeat (ausência de dados) e agregações sobre uma janela de lookback.
• As regras disparam na entrada em um novo estado, e é isso que suprime alertas repetidos.
• Fontes: Eventstream, Fabric workspace item events, Azure Blob events, Real-Time dashboards, relatórios do Power BI (observações periódicas atreladas ao agendamento de refresh), regras de consulta SQL sobre um Warehouse Preview.
• Ações: e-mail, mensagem no Teams, fluxo do Power Automate — e itens do Fabric: pipeline, notebook, Spark job definition, Dataflow, Copy job, user data function.

As superfícies de monitoramento, e qual usar

Detalhes do monitoring hub: mostra as 100 atividades mais recentes por tipo de item nos últimos 30 dias. Filtre por status, tipo de item, hora de início, quem submeteu e localização; pesquise por nome; ordene e reorganize colunas. Em cada linha você pode abrir um painel de detalhes (status, hora de início, duração, detalhe do erro), abrir Historical runs para o histórico completo de 30 dias daquele item, e configurar notificações de falha de agendamento Preview (exige Contributor ou Write no item). Dataflow Gen1 não aparece.

Monitorar a ingestão de dados

• Pipelines — histórico de execuções mais as execuções por atividade. A saída da Copy activity traz rowsRead, rowsCopied, rowsSkipped, throughput, dataConsistencyVerification, e a duração dividida em tempo de fila e de transferência.
• Copy job — tem seu próprio dashboard em tempo real: status e progresso por tabela, histórico de execuções e alertas de falha; também aparece no workspace monitoring.
• Eventstream — status dos nós, métricas de throughput e métricas de erro na live view e no workspace monitoring.
• Ingestão do Eventhouse — .show ingestion failures é o comando mais importante; a página System overview do Eventhouse mostra taxa de ingestão, principais databases ingeridos, armazenamento, uso de computação e mudanças de schema.
• Mirroring — status de replicação e contagem de linhas por tabela na página de monitoramento do mirrored database; uma capacity pausada interrompe a replicação.

Monitorar a transformação de dados

• Spark — cinco pontos de entrada: o monitoring hub, o Recent runs do item, o monitoramento contextual dentro do notebook (progresso do job por célula, tasks, executores, logs), o monitoramento inline do Spark job definition e os deep links da atividade Spark no pipeline. Por trás deles estão o Spark Advisor (dicas de código e análise de erro em tempo real), o Apache Spark History Server estendido e os snapshots de notebook, que capturam o código e a saída exatos de uma execução.
• Dataflow Gen2 — histórico de refresh com duração e performance por query, integrado ao monitoring hub.
• Warehouse — as views de Query Insights mais as DMVs ao vivo:

-- Retido por 30 dias; até ~15 minutos de latência; somente consultas de usuário
SELECT TOP 100 distributed_statement_id, query_hash, allocated_cpu_time_ms, label, command
FROM   queryinsights.exec_requests_history
ORDER BY allocated_cpu_time_ms DESC;

-- Detecção de cold start: leitura remota diferente de zero significa que NÃO estava em cache
SELECT distributed_statement_id, query_hash,
       data_scanned_remote_storage_mb, data_scanned_memory_mb, data_scanned_disk_mb, command
FROM   queryinsights.exec_requests_history
ORDER BY data_scanned_remote_storage_mb DESC;

SELECT * FROM queryinsights.long_running_queries    ORDER BY median_total_elapsed_time_ms DESC;
SELECT * FROM queryinsights.frequently_run_queries  ORDER BY number_of_successful_runs   DESC;
SELECT * FROM queryinsights.exec_sessions_history;
SELECT * FROM queryinsights.sql_pool_insights;       -- alocação de recursos e pressão no pool

-- Estado ao vivo (agora, não histórico)
SELECT * FROM sys.dm_exec_requests;
SELECT * FROM sys.dm_exec_sessions;
SELECT * FROM sys.dm_exec_connections;

Monitorar o refresh de modelos semânticos

• Modelos Import e DirectQuery: histórico de refresh no modelo, mais uma atividade Semantic model refresh que você pode encadear no fim de um pipeline.
• Modelos Direct Lake não fazem "refresh" de dados — eles fazem framing (uma operação só de metadados, de segundos, que aponta o modelo para os arquivos Delta mais recentes) e carregam segmentos de coluna na memória sob demanda (transcoding). O que você monitora é o sucesso do framing e se as consultas caíram para DirectQuery.

Monitoramento de capacity e alertas

• Capacity Metrics app — a página Compute mostra CU segundos por operação, separados em interactive e background; o detalhe de timepoint entra num único intervalo de 30 segundos para nomear a operação culpada; a aba Overages plota carryforward, uso cumulativo e burndown; a tabela de system events registra episódios de throttling; Minutes to burndown estima a recuperação.
• Alertas — regras do Activator sobre um Eventstream, KQL queryset ou Real-Time dashboard; alertas sobre um visual do Power BI; notificação de falha de pipeline via atividade do Outlook ou Teams, ou as notificações de falha de agendamento nativas; notificações de capacity configuradas pelo capacity admin.

Trate esta seção como uma consulta sintoma → causa → correção. O exame formula assim: "um job falha com X — o que você deve fazer primeiro?"

Erros de pipeline

Erros do Dataflow Gen2

• Comece pelo Refresh history → o refresh que falhou → o detalhe de erro por query.
• Falhas de staging — os itens internos DataflowsStagingLakehouse / DataflowsStagingWarehouse. Se o staging está falhando, verifique throttling de capacity antes de qualquer outra coisa.
• Erros de data destination — incompatibilidade de schema entre a saída da query e a tabela de destino existente, ou um tipo que o destino não aceita. Verifique a configuração de fixed vs. dynamic schema do destino.
• Erros de gateway — gateway on-premises offline, desatualizado ou sem o driver daquela fonte.
• Erros de avaliação — um passo M falhando com os dados reais (nulls, tipos inesperados). Corrija com try … otherwise ou um passo explícito de conversão de tipo.
• Query folding quebrado — um passo que não faz folding puxa tudo para o mashup engine e o refresh fica lentíssimo. Clique com o botão direito num passo → View native query; mova os passos que não dobram para o final.

Erros de notebook e Spark

Erros de Eventhouse e Eventstream

• .show ingestion failures — o primeiro comando de qualquer investigação em Eventhouse. Motivos comuns: schema incompatível, um ingestion mapping ausente ou errado, JSON/CSV malformado e throttling.
• Acrescente | where OriginatesFromUpdatePolicy == true para isolar falhas causadas por uma update policy.
• Se uma update policy transacional está falhando, a ingestão de origem também falha — defina IsTransactional = false se sucesso parcial for aceitável.
• Eventstream: conectividade da fonte (credenciais, firewall, consumer group já em uso), falhas de escrita no destino e schema drift contra o schema do primeiro registro do destino Lakehouse. Verifique status dos nós e métricas de erro na live view.

Erros de T-SQL e do SQL analytics endpoint

• T-SQL não suportado — triggers, materialized views, synonyms, CTEs recursivas, SET TRANSACTION ISOLATION LEVEL. É aqui que código migrado quebra primeiro.
• Uma tabela nova do Lakehouse não aparece no SQL endpoint — a sincronização de metadados do endpoint é assíncrona. Atualize os metadados do endpoint (ou use a atividade de pipeline Refresh SQL endpoint depois da etapa de carga). Este é um cenário de prova bastante comum.
• Aviso de non-scalable operation — um TOP/ORDER BY global forçou execução em nó único. Adicione OPTION (FORCE DISTRIBUTED PLAN) ou reestruture.
• Erros de lock / conflito — transações explícitas abertas por muito tempo. Mantenha as transações curtas e orientadas a lote; faça retry com backoff exponencial.
• Violações de constraint que nunca acontecem — lembre que as constraints são NOT ENFORCED; duplicatas são culpa do seu ETL, não do engine.

Erros de OneLake shortcut

• Credenciais expiradas ou revogadas na cloud connection — a causa mais frequente de um shortcut que "funcionava ontem". Recrie ou atualize a conexão.
• Erros de permissão em shortcuts internos — a autorização usa a identidade de quem chama; a pessoa precisa de permissão de leitura no item de destino, não apenas no shortcut.
• Direct Lake sobre SQL, ou T-SQL em modo delegated identity, passa a identidade do dono do item chamador em vez da do usuário. Mude para Direct Lake sobre OneLake, ou T-SQL em modo user identity.
• Tabela não reconhecida — um shortcut em Tables/ que não é uma tabela Delta válida, ou tem espaço no nome, ou está num subdiretório.
• Limite de encadeamento — mais de 5 níveis de shortcut apontando para shortcut.
• Latência entre regiões — reduza com o cache de shortcuts (retenção de 1 a 28 dias; arquivos acima de 1 GB não são cacheados).
• ADLS Gen2 atrás de firewall — precisa de workspace identity mais trusted workspace access, ou um managed private endpoint.

Otimizar uma tabela de Lakehouse

Quase todo problema de performance em Lakehouse é o problema dos arquivos pequenos: escritas de streaming ou micro-batch frequentes produzem milhares de arquivos Parquet minúsculos, e o overhead de metadados domina a leitura.

-- Manutenção de tabela via Spark SQL
OPTIMIZE silver.orders ZORDER BY (CustomerId, OrderDate);
VACUUM   silver.orders RETAIN 168 HOURS;   -- 168 h = o padrão de 7 dias
DESCRIBE HISTORY silver.orders;

-- V-Order, três níveis de controle
SET spark.sql.parquet.vorder.default;                 -- inspecionar (padrão da sessão: false)
SET spark.sql.parquet.vorder.default = TRUE;          -- sessão
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");  -- tabela

(df.write.format("delta").mode("overwrite")
   .option("replaceWhere", "start_date >= '2026-01-01' AND end_date <= '2026-01-31'")
   .option("parquet.vorder.enabled", "true")
   .saveAsTable("myschema.mytable"))

spark.conf.set("spark.databricks.delta.optimizeWrite.enabled", True)   # dimensiona arquivos na escrita
spark.conf.set("spark.databricks.delta.stats.collect", True)          # estatísticas para file skipping

Orientação de particionamento: particione apenas tabelas grandes o suficiente para justificar, numa coluna de baixa cardinalidade (ano, mês, região), mirando partições na faixa de centenas de MB a alguns GB. Particionar demais recria o problema dos arquivos pequenos. Use ZORDER, não particionamento, para colunas de alta seletividade. Rode a manutenção ad hoc pelo Lakehouse explorer (clique com o botão direito na tabela → Maintenance), ou agende-a com a atividade de pipeline Lakehouse maintenance Preview. Acompanhe no monitoring hub pelos nomes de atividade contendo TableMaintenance. OPTIMIZE e VACUUM valem apenas para tabelas Delta — não para Hive Parquet, ORC, AVRO ou CSV.

Otimizar um pipeline

• Aumente o degree of copy parallelism da Copy activity; habilite staging quando o caminho direto for lento.
• Num ForEach, desligue Sequential e defina o Batch count (máx. 50) para controlar a concorrência.
• Empurre a filtragem para a origem (uma query em vez de ler a tabela inteira) para trafegar menos dados.
• Prefira o Copy job a lógica incremental artesanal quando o padrão for convencional — ele particiona e paraleliza automaticamente.
• Nunca itere linha a linha. Substitua um ForEach interno que insere uma linha por vez por uma cópia em lote ou uma stored procedure.
• Adeque a computação ao trabalho — não suba uma sessão Spark para mover um arquivo.

Otimizar um data warehouse

Otimizar Eventstreams e Eventhouses

• Batching vs. streaming ingestion policy — o batching (padrão) troca um pouco de latência por arquivos bem maiores e desempenho de consulta muito melhor; a streaming ingestion dá visibilidade em menos de um segundo, com custo maior. Escolha por tabela.
• Caching (hot) policy — a quantidade de dados recentes mantida no SSD do cluster. Alargar a janela quente acelera as consultas e custa mais; estreitar faz o inverso. Ajuste para cobrir o período que as pessoas realmente consultam.
• Retention policy — por quanto tempo o dado sobrevive. A retenção precisa ser ≥ a janela quente para fazer sentido.
• Update policies para remodelar na ingestão; materialized views para agregações mantidas incrementalmente que as consultas acessam o tempo todo.
• Partitioning policy — só para padrões específicos de alta cardinalidade ou hora de ingestão embaralhada; não é o padrão.
• Eventstream — dimensione a capacity (F4+), mantenha Minimum rows e Maximum duration do destino Lakehouse altos o bastante para evitar arquivos pequenos, e rode Optimize table in notebook nos destinos Delta de streaming.
• Não baixe o TargetLatencyInMinutes da mirroring policy abaixo do necessário — arquivos pequenos prejudicam todos os leitores downstream.

Otimizar performance do Spark

Otimizar performance de consulta (camada semântica)

• Direct Lake sobre OneLake lê quaisquer tabelas Delta do Fabric, suporta composite models e colunas calculadas, aplica segurança na camada semântica e não tem fallback para DirectQuery.
• Direct Lake sobre SQL lê tabelas e views de Lakehouse/Warehouse, respeita RLS de SQL — e cai para DirectQuery quando encontra uma view não materializada ou controle de acesso granular baseado em SQL. O fallback é controlado pela propriedade Direct Lake behavior. Fallback costuma ser o motivo de um relatório Direct Lake "ficar lento de repente".
• Os guardrails escalam com o SKU — contagem de arquivos Parquet, de row groups, de linhas e memória. Ultrapassar a memória não é um bloqueio rígido; causa paging e degradação. F2–F8: 300 M linhas, 10 GB, 3 GB de memória. F64/P1: 1,5 B linhas, tamanho ilimitado, 25 GB de memória. F512/P4: 12 B linhas, 200 GB de memória.
• A melhor otimização isolada para um modelo Direct Lake é ter tabelas Delta bem mantidas: V-Order aplicado, arquivos compactados, contagem de row groups abaixo do guardrail.
• Não suportado em Direct Lake: tipos de coluna complexos (Binary, GUID), floats não numéricos, strings acima de 32.764 caracteres, hierarquias definidas pelo usuário em tabelas Direct Lake, gateways, workspaces pessoais e workspaces de origem em outra região.

Números que vale decorar

Fluxogramas de decisão em palavras

KQL vs. T-SQL vs. PySpark — a mesma operação, 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 · Implementar e gerenciar
• Configurar Spark workspace settings — pools, tamanhos de nó, autoscale, dynamic allocation, high concurrency, environments
• Configurar workspace settings de domain, OneLake e Apache Airflow
• Configurar controle de versão (Git integration) e implementar database projects
• Criar e configurar deployment pipelines, deployment rules e variable libraries
• Implementar controles de acesso no nível de workspace e de item
• Implementar controles de acesso de linha, coluna, objeto e pasta/arquivo
• Implementar dynamic data masking
• Aplicar sensitivity labels e endossar itens
• Implementar e usar Fabric audit logs e workspace monitoring
• Configurar e implementar OneLake security roles
• Escolher entre Dataflow Gen2, pipeline e notebook
• Projetar e implementar agendamentos e event-based triggers
• Implementar padrões de orquestração com notebooks e pipelines, incluindo parâmetros e expressões dinâmicas
• Domínio 2 · Ingerir e transformar
• Projetar e implementar cargas full e incremental
• Preparar dados para um modelo dimensional (SCD 1/2/3, surrogate keys, membros inferidos)
• Projetar e implementar um padrão de carga para dados de streaming
• Escolher um data store apropriado
• Escolher entre Dataflows Gen2, notebooks, KQL e T-SQL para transformação
• Criar e gerenciar OneLake shortcuts
• Implementar mirroring
• Ingerir dados usando pipelines e Copy job
• Transformar dados usando PySpark, SQL e KQL
• Desnormalizar, agrupar e agregar dados
• Tratar dados duplicados, ausentes e atrasados
• Escolher um engine de streaming apropriado
• Escolher entre tabelas nativas e OneLake shortcuts no Real-Time Intelligence
• Escolher entre query acceleration e OneLake shortcuts padrão
• Processar dados usando Eventstreams, Spark Structured Streaming e KQL
• Criar windowing functions
• Domínio 3 · Monitorar e otimizar
• Monitorar ingestão, transformação e refresh de modelo semântico
• Configurar alertas
• Identificar e resolver erros de pipeline
• Identificar e resolver erros de Dataflow Gen2
• Identificar e resolver erros de notebook
• Identificar e resolver erros de Eventhouse
• Identificar e resolver erros de Eventstream
• Identificar e resolver erros de T-SQL
• Identificar e resolver erros de OneLake shortcut
• Otimizar uma tabela de Lakehouse
• Otimizar um pipeline
• Otimizar um data warehouse
• Otimizar Eventstreams e Eventhouses
• Otimizar performance do Spark
• Otimizar performance de consulta