Guia

Projetar a camada inicial de ingestão de dados em uma arquitetura medallion para capturar dados brutos da fonte.

→Ingerir dados na camada Bronze com transformação mínima e um esquema permissivo.

Por quê: Preserva a fidelidade original dos dados, incluindo registros malformados, para reprocessamento, auditoria e linhagem de dados.

Implementar ambientes isolados e um processo de promoção para artefatos do Fabric.

→Usar Pipelines de Implantação do Fabric com estágios distintos de workspace de Desenvolvimento, Teste e Produção.

Por quê: Fornece um mecanismo estruturado e seguro para testar alterações e promover artefatos sem impactar as cargas de trabalho de produção.

Impor controle de código-fonte e fluxos de trabalho de aprovação para alterações em itens de produção do Fabric.

→Integrar o workspace do Fabric com o Azure DevOps Git. Usar políticas de branch para impor revisões de pull request.

Por quê: Permite controle de versão, rastreamento de alterações e revisões por pares obrigatórias, alinhando a engenharia de dados com as melhores práticas de DevOps.

Automatizar alterações de string de conexão específicas do ambiente durante as implantações de pipeline.

→Configurar regras de implantação no pipeline de implantação para parametrizar conexões de fonte de dados para cada estágio.

Por quê: Elimina a configuração manual pós-implantação, reduzindo erros e garantindo que cada ambiente se conecte à fonte de dados correta.

Organizar workspaces para múltiplas unidades de negócio que exigem isolamento e governança compartilhada.

→Criar workspaces separados por unidade de negócio e agrupá-los em Domínios do Fabric.

Por quê: Workspaces fornecem isolamento de conteúdo e segurança, enquanto Domínios permitem governança centralizada e descoberta em workspaces relacionados.

Melhorar a descoberta de dados e sinalizar a qualidade dos conjuntos de dados para os usuários de negócios.

→Aplicar descrições e tags a tabelas de lakehouse e usar rótulos de Endosso (Promovido, Certificado).

Por quê: Níveis de endosso constroem a confiança do usuário e os guiam para conjuntos de dados curados e de alta qualidade para relatórios e análises.

Garantir classificação e proteção de dados consistentes em todos os itens do Fabric.

→Integrar com o Microsoft Purview Information Protection e habilitar a herança downstream para rótulos de sensibilidade.

Por quê: Automatiza a aplicação de rótulos de sensibilidade de fontes de dados para artefatos downstream, como modelos semânticos e relatórios, aplicando políticas de segurança.

Determinar o fator principal para dimensionar uma capacidade do Fabric.

→Analisar a execução de consulta concorrente e os requisitos de computação da carga de trabalho.

Por quê: A capacidade do Fabric é consumida por operações de computação (Unidades de Capacidade), não pelo volume de armazenamento de dados. Concorrência e complexidade do trabalho são os principais fatores.

Fornecer acesso seguro, de nível de produção, de um atalho do Fabric para uma conta ADLS Gen2 externa.

→Usar um Service Principal com autenticação Azure AD, concedendo-lhe as funções RBAC de menor privilégio na conta de armazenamento.

Por quê: Service Principal é o método mais seguro e auditável, evitando os riscos de chaves de conta compartilhadas ou tokens SAS.

Criar uma réplica quase em tempo real, somente leitura, de um Banco de Dados SQL do Azure no Fabric sem impactar a fonte.

→Usar Fabric Mirroring para Banco de Dados SQL do Azure.

Por quê: O Mirroring fornece replicação contínua de baixa latência de dados para o OneLake como tabelas Delta, ideal para análises em tempo real sem desenvolvimento de ETL.

Compartilhar um conjunto de dados com outro workspace ou acessar dados externos sem criar uma cópia.

→Criar um Atalho apontando para a tabela de lakehouse de origem ou local de dados externo.

Por quê: Atalhos funcionam como links simbólicos, fornecendo uma visão unificada dos dados no OneLake, evitando duplicação de dados, custos de armazenamento e problemas de sincronização.

Combinar dados de streaming de alta velocidade com dados históricos em lote para análises unificadas.

→Usar Eventstream para ingestão em tempo real e um Lakehouse com tabelas Delta Lake para armazenamento unificado.

Por quê: Eventstream lida com o caminho de streaming, enquanto as propriedades ACID do Delta Lake permitem que ele sirva como um alvo para anexos de streaming e atualizações em lote.

Habilitar análises baseadas em T-SQL e ciência de dados baseada em Python nos mesmos dados do lakehouse.

→Aproveitar o endpoint de análise SQL gerado automaticamente para o Lakehouse.

Por quê: O Fabric fornece acesso de motor duplo às mesmas tabelas Delta: um endpoint SQL para consultas T-SQL e o motor Spark para notebooks, sem duplicação de dados.

Ingerir dados de uma fonte de dados local (por exemplo, Oracle, SQL Server) para o Fabric.

→Instalar e configurar um gateway de dados local.

Por quê: O gateway atua como uma ponte segura, retransmitindo dados entre a rede local e o serviço de nuvem do Fabric sem expor a fonte à internet.

Processar automaticamente novos arquivos assim que eles chegam ao Azure Blob Storage.

→Usar um trigger de Evento de Armazenamento para o pipeline de dados, configurado para disparar em eventos de criação de blob.

Por quê: Triggers orientados por eventos fornecem menor latência e são mais eficientes do que o polling agendado, que pode perder dados ou ser executado desnecessariamente.

Extrair todos os registros de uma REST API que retorna dados em páginas.

→Em uma atividade de Cópia, configurar as regras de paginação integradas do conector REST. Alternativamente, usar um loop Until ou ForEach com variáveis para gerenciar tokens de página.

Por quê: Automatiza o processo de iteração por todas as páginas da API até que todos os dados sejam recuperados, lidando com links ou offsets dinâmicos para a próxima página.

Implementar lógica de Dimensão de Alteração Lenta Tipo 2 ou processar fluxos de Change Data Capture (CDC).

→Usar a operação MERGE do Delta Lake com cláusulas `WHEN MATCHED` e `WHEN NOT MATCHED`.

Por quê: MERGE fornece capacidades atômicas de upsert (atualização/inserção/exclusão), que é a operação fundamental para manter registros históricos em padrões SCD2.

Transformar uma coluna de DataFrame contendo arrays aninhados de objetos em linhas separadas.

→Aplicar a função `explode()` à coluna de array em um notebook PySpark.

Por quê: `explode()` é a função Spark padrão para desagrupar arrays, criando uma nova linha para cada elemento no array.

Lidar com dados que chegam atrasados em uma agregação de streaming com estado (por exemplo, contagens por janela).

→Configurar uma marca d'água (watermark) na coluna de tempo do evento na consulta do Spark Structured Streaming.

Por quê: Watermarking define um limite de tempo para quanto tempo o motor esperará por dados atrasados, impedindo que o estado cresça indefinidamente enquanto garante a correção.

Realizar uma carga de dados incremental de um sistema de origem que possui uma coluna de timestamp, mas sem CDC.

→Implementar um padrão de alta marca d'água (high-watermark). Armazenar o timestamp máximo da última execução e usá-lo para filtrar a fonte na próxima execução.

Por quê: Este é um padrão eficiente e comum para extrair apenas registros novos ou atualizados sem a sobrecarga de varreduras completas de tabela ou a exigência de CDC formal.

Uma atividade de pipeline falha intermitentemente devido a problemas transitórios de rede ou carga do sistema de origem.

→Configurar a política de repetição da atividade com uma contagem especificada e intervalo de recuo exponencial.

Por quê: Cria resiliência no pipeline ao retentar automaticamente operações falhas, frequentemente resolvendo problemas transitórios sem intervenção manual.

Ingerir e consultar dados de telemetria ou log de alto volume e baixa latência para análise exploratória em tempo real.

→Ingerir dados em um Eventhouse e consultá-los usando a Linguagem de Consulta Kusto (KQL).

Por quê: Eventhouse (construído sobre o Azure Data Explorer) e KQL são projetados especificamente para análises de séries temporais e logs de alto desempenho.

Criar um pipeline único e reutilizável para carregar dezenas de tabelas que compartilham a mesma lógica de transformação.

→Usar uma abordagem orientada por metadados. Armazenar informações de origem/destino em uma tabela de controle e usar uma atividade ForEach para iterar e passar parâmetros para um pipeline filho genérico.

Por quê: Este padrão é altamente escalável e de fácil manutenção, evitando a duplicação e a sobrecarga de gerenciamento de criar pipelines separados para cada tabela.

Otimizar o desempenho de um Dataflow Gen2 que busca dados de um banco de dados relacional como SQL Server.

→Projetar transformações que possam ser "dobradas". Verificar o status de query folding no editor do Power Query.

Por quê: Query folding empurra a lógica de transformação para o motor do banco de dados de origem, o que é significativamente mais performático do que puxar todos os dados para o motor Spark para transformação.

Consultar uma tabela como ela existia em um ponto específico no passado para uma auditoria ou para recuperar de uma atualização acidental.

→Usar o recurso de viagem no tempo do Delta Lake com `VERSION AS OF` ou `TIMESTAMP AS OF` na consulta.

Por quê: O Delta Lake nativamente versiona cada transação, permitindo consultas de ponto no tempo sem a necessidade de snapshots ou backups manuais.

Impor segurança em nível de linha (RLS) onde os usuários devem ver apenas os dados correspondentes à sua região ou departamento.

→Implementar regras de RLS usando expressões DAX dentro do modelo semântico.

Por quê: O modelo semântico é a camada centralizada e recomendada para aplicar regras de negócio como RLS. A lógica é aplicada dinamicamente com base na identidade do usuário.

Impedir que um grupo de usuários veja colunas sensíveis (por exemplo, salário, PII) em uma tabela.

→Implementar Segurança em Nível de Coluna (CLS) no modelo semântico ou warehouse.

Por quê: CLS fornece controle granular para restringir o acesso a colunas específicas para funções de usuário designadas, protegendo dados sensíveis dentro de uma tabela compartilhada.

Construir um relatório do Power BI em um conjunto de dados lakehouse muito grande com altos requisitos de desempenho.

→Criar um modelo semântico usando o modo DirectLake.

Por quê: DirectLake oferece o desempenho do modo Import ao carregar dados na memória, mas sem duplicar os dados, lendo diretamente dos arquivos Delta no OneLake.

Melhorar o desempenho da consulta e reduzir o consumo de capacidade para relatórios com resumos de alto nível.

→Criar e configurar tabelas de agregação dentro do modelo semântico.

Por quê: Consultas que acessam dados pré-agregados são significativamente mais rápidas e consomem menos recursos do que aquelas que varrem a tabela de detalhes completa, otimizando a experiência do usuário e o custo.

Reduzir o tempo de atualização e o uso de recursos para um modelo semântico grande onde apenas dados recentes mudam.

→Configurar uma política de atualização incremental nas grandes tabelas de fatos no modelo semântico.

Por quê: Isso particiona os dados e atualiza apenas as partições mais recentes, evitando recargas completas e caras de dados históricos que não mudam.

O desempenho da consulta em uma tabela Delta se degradou devido a um grande número de arquivos pequenos de ingestão de streaming.

→Executar o comando `OPTIMIZE` na tabela Delta.

Por quê: `OPTIMIZE` compacta arquivos pequenos em um número menor de arquivos maiores. Isso melhora significativamente o desempenho de leitura, pois o motor de consulta precisa abrir menos arquivos.

Melhorar o desempenho da consulta em uma tabela Delta grande que é frequentemente filtrada por uma coluna não particionada e de alta cardinalidade.

→Executar `OPTIMIZE` com uma cláusula `ZORDER BY` nas colunas frequentemente filtradas.

Por quê: Z-Ordering co-localiza dados relacionados dentro dos arquivos, permitindo que o motor de consulta use o "data skipping" para ler menos dados, acelerando drasticamente as consultas filtradas.

Otimizar o desempenho de leitura para relatórios do Power BI que consultam tabelas Delta em um lakehouse do Fabric.

→Garantir que a otimização V-Order esteja habilitada nas tabelas Delta.

Por quê: V-Order é uma otimização de tempo de escrita específica do Fabric que melhora o desempenho de leitura para o motor do Power BI, otimizando a compressão e a ordenação dos dados.

Recuperar espaço de armazenamento de uma tabela Delta que acumulou um histórico significativo de atualizações e exclusões.

→Executar o comando `VACUUM` na tabela.

Por quê: `VACUUM` remove fisicamente arquivos de dados que não são mais referenciados pela tabela e são mais antigos que o período de retenção, reduzindo os custos de armazenamento.

Otimizar uma junção (join) do Spark entre uma tabela de fatos muito grande e uma tabela de dimensão pequena.

→Usar um broadcast join fornecendo uma dica (`broadcast()`) para enviar a tabela pequena para todos os executores.

Por quê: Broadcasting evita uma operação de "shuffle" cara e intensiva em rede da tabela grande, que é um grande gargalo de desempenho em junções em larga escala.

Uma operação de junção do Spark está lenta ou falhando porque um valor de chave tem uma quantidade desproporcionalmente grande de dados (distorção de dados).

→Implementar uma técnica de "salting": adicionar uma chave aleatória aos valores distorcidos para distribuí-los por mais partições, e então juntar e agregar.

Por quê: Salting quebra manualmente a partição distorcida, permitindo que a carga de trabalho seja balanceada entre todos os executores e prevenindo erros de OOM ou tarefas de longa duração.

Um trabalho de notebook Spark está rodando mais lentamente do que o esperado e a causa não está clara.

→Usar a Spark UI, acessível a partir do hub de monitoramento, para analisar o Grafo Acíclico Dirigido (DAG), durações de estágio e detalhes da tarefa.

Por quê: A Spark UI fornece uma visão física detalhada da execução da consulta, permitindo identificar gargalos como distorção de dados, derramamentos para disco ou shuffles ineficientes.

Um trabalho Spark falha com um OutOfMemoryError no nó driver, mesmo com grande memória de executor.

→Revisar o código em busca de ações como `.collect()` ou `.toPandas()` que puxam grandes quantidades de dados distribuídos para a memória do nó driver.

Por quê: O driver tem seu próprio limite de memória. Coletar um DataFrame grande para o driver é um anti-padrão comum que causa erros de OOM; use operações distribuídas em vez disso.

Identificar quais workspaces, relatórios ou pipelines estão consumindo a maioria dos recursos de computação em uma capacidade do Fabric.

→Instalar e analisar o aplicativo Fabric Capacity Metrics.

Por quê: Este aplicativo fornece um detalhamento detalhado do consumo de Unidades de Capacidade (CU) ao longo do tempo por workspace, tipo de item e operação específica, permitindo otimização direcionada e análise de custos.

Implementar auditoria e monitoramento centralizados e de longo prazo de todas as atividades dentro de um workspace do Fabric.

→Nas configurações de administrador do Fabric, configurar as configurações de diagnóstico para o workspace transmitir logs para um workspace do Azure Log Analytics.

Por quê: Fornece um armazenamento robusto, consultável e de longo prazo para todos os logs de auditoria e operacionais, permitindo monitoramento avançado, alertas e relatórios de conformidade.

Reduzir o custo operacional de uma capacidade do Fabric que possui períodos previsíveis de inatividade (por exemplo, noites, fins de semana).

→Implementar automação (por exemplo, via APIs e Azure Automation) para pausar a capacidade durante as horas de folga e retomá-la antes do horário comercial.

Por quê: A computação de capacidade é um principal fator de custo. Pausar a capacidade interrompe a cobrança de CU, proporcionando economias significativas de custo durante períodos de inatividade.

Um pipeline de dados crítico deve ser monitorado, e a equipe de operações precisa ser notificada imediatamente em caso de falha.

→Configurar alertas no Fabric Monitoring Hub ou usar o Data Activator para monitorar o status do pipeline e acionar notificações.

Por quê: Alertas proativos garantem que as falhas sejam detectadas e resolvidas rapidamente, minimizando o tempo de inatividade dos dados e o impacto nos usuários de negócios.