Guia

Os dados são organizados em um layout tabular fixo com um esquema predefinido (linhas e colunas), como um catálogo de produtos ou registros financeiros.

→Representar como Dados Estruturados.

Por quê: Dados estruturados estão em conformidade com um esquema rígido, ideal para bancos de dados relacionais (OLTP). Contraste com semiestruturados (JSON/XML) e não estruturados (imagens/áudio).

Os dados têm alguma estrutura organizacional (tags, chaves), mas carecem de um esquema rígido. Cada registro pode ter campos diferentes, como documentos JSON de sensores IoT.

→Representar como Dados Semi-estruturados (por exemplo, JSON, XML).

Por quê: JSON e XML são autodescritivos, oferecendo flexibilidade sobre os esquemas fixos de dados estruturados. Ideais para bancos de dados NoSQL e data lakes.

Armazenar arquivos grandes sem esquema predefinido ou estrutura organizacional, como exames de ressonância magnética, vídeos ou gravações de áudio.

→Representar como Dados Não Estruturados.

Por quê: Este tipo de dado não pode ser armazenado em bancos de dados tradicionais de linha/coluna. Requer armazenamento de objetos como o Azure Blob Storage.

Diferenciar entre cargas de trabalho para operações do dia a dia versus análise histórica.

→Use OLTP (Online Transaction Processing) para transações de alto volume e baixa latência (por exemplo, pedidos de e-commerce). Use OLAP (Online Analytical Processing) para consultas complexas sobre grandes conjuntos de dados históricos (por exemplo, análise de tendências de vendas).

Por quê: Sistemas OLTP são normalizados e otimizados para gravações rápidas. Sistemas OLAP são desnormalizados (esquema estrela) e otimizados para leituras e agregações rápidas.

Escolher um padrão de integração de dados para um data warehouse.

→Use ETL (Extract, Transform, Load) quando a lógica de transformação é complexa e realizada em um servidor de staging antes do carregamento. Use ELT (Extract, Load, Transform) para carregar dados brutos em um sistema de destino poderoso (por exemplo, Synapse Analytics) e aproveitar seu poder computacional para transformações.

Por quê: ELT é o padrão de nuvem moderno, aproveitando a computação escalável no armazenamento de dados de destino (data warehouse/lakehouse) e simplificando a ingestão.

Atribuindo responsabilidade pelas tarefas da plataforma de dados.

→Engenheiro de Dados: Constrói e mantém pipelines ETL/ELT. Administrador de Banco de Dados: Gerencia a segurança, desempenho e disponibilidade do banco de dados. Analista de Dados: Cria relatórios e visualizações (por exemplo, Power BI) para insights de negócios.

Por quê: Funções claramente definidas são essenciais. A distinção principal é construir (Engenheiro), gerenciar (DBA) e analisar (Analista).

Processar grandes volumes de dados com diferentes requisitos de latência.

→Use Processamento em Lote para dados em repouso, processados em intervalos agendados (por exemplo, relatórios noturnos). Use Processamento de Fluxo para dados em movimento, processados continuamente à medida que chegam (por exemplo, detecção de fraude em tempo real).

Por quê: A principal compensação é latência vs. custo/throughput. O processamento de fluxo oferece baixa latência, mas requer recursos sempre ativos. O processamento em lote tem alta latência, mas é econômico para grandes volumes.

Projetar um esquema para um data warehouse para suportar consultas analíticas.

→Use um Esquema Estrela que consiste em uma tabela de fatos central (contendo medidas numéricas) conectada a múltiplas tabelas de dimensão (contendo atributos descritivos).

Por quê: Esta estrutura desnormalizada minimiza junções para consultas analíticas, melhorando o desempenho em comparação com um esquema normalizado (OLTP). É mais simples e rápido para a maioria das ferramentas de BI do que um esquema floco de neve.

Escolher um repositório central para análise.

→Use um Data Lake (por exemplo, Azure Data Lake Storage) para armazenar grandes volumes de dados brutos em seu formato nativo (schema-on-read). Use um Data Warehouse (por exemplo, Synapse Dedicated SQL Pool) para armazenar dados estruturados e processados para BI e relatórios (schema-on-write).

Por quê: Data lakes oferecem flexibilidade para ciência de dados e exploração de dados brutos. Data warehouses fornecem alto desempenho e estrutura para inteligência de negócios.

Precisa de um banco de dados relacional totalmente gerenciado para um novo aplicativo nativo da nuvem sem gerenciar a infraestrutura subjacente.

→Use o Azure SQL Database.

Por quê: É uma oferta PaaS com aplicação automática de patches, backups e alta disponibilidade. Ideal para cargas de trabalho SQL padrão onde o acesso ao nível do SO não é necessário.

Referência↗

Migração lift-and-shift de uma carga de trabalho do SQL Server local que usa recursos com escopo de instância, como SQL Server Agent, consultas entre bancos de dados ou Service Broker.

→Use o Azure SQL Managed Instance.

Por quê: O SQL MI oferece compatibilidade de quase 100% com o mecanismo do SQL Server local, minimizando as alterações de migração. O Azure SQL Database não suporta esses recursos de nível de instância.

Referência↗

Migrar um banco de dados SQL Server para o Azure exigindo controle total sobre o SO, versões específicas do SQL Server ou recursos com suporte PaaS limitado (por exemplo, certas assemblies CLR).

→Use o SQL Server em Máquinas Virtuais do Azure.

Por quê: Esta opção IaaS oferece máxima compatibilidade e controle, mas exige que o usuário gerencie o SO, aplicação de patches e backups, diferentemente das ofertas PaaS.

Um aplicativo possui padrões de uso intermitentes e imprevisíveis com longos períodos de inatividade. Precisa minimizar os custos durante a inatividade.

→Use a camada de computação Serverless para o Azure SQL Database.

Por quê: Serverless dimensiona automaticamente a computação com base na demanda e pode pausar automaticamente o banco de dados, cobrando apenas pelo armazenamento durante períodos de inatividade. Ideal para cargas de trabalho variáveis.

Referência↗

Hospedar múltiplos pequenos bancos de dados para diferentes inquilinos (SaaS) com cargas de trabalho variáveis. Precisa compartilhar recursos para reduzir custos.

→Use pools elásticos do Azure SQL Database.

Por quê: Pools elásticos permitem que vários bancos de dados compartilhem um conjunto pré-alocado de recursos (DTUs ou vCores), oferecendo uma solução econômica para aplicativos multi-inquilino.

Espera-se que um banco de dados cresça além de 4 TB (até 100 TB) e exija escalabilidade rápida e backups e restaurações quase instantâneos, independentemente do tamanho.

→Use a camada de serviço Hyperscale para o Azure SQL Database.

Por quê: Hyperscale usa uma arquitetura distribuída única para bancos de dados muito grandes (VLDBs), quebrando os limites de tamanho de outras camadas e fornecendo operações de banco de dados em tempo constante.

Implementar um banco de dados PostgreSQL gerenciado para um aplicativo de microsserviços, exigindo alta disponibilidade com redundância de zona e dimensionamento independente de computação e armazenamento.

→Use o Azure Database for PostgreSQL - Flexible Server.

Por quê: O Flexible Server é a oferta recomendada, fornecendo HA com redundância de zona, janelas de manutenção personalizadas e melhor otimização de custos em comparação com o modelo Single Server mais antigo.

Proteger dados confidenciais (por exemplo, números de cartão de crédito) para que permaneçam criptografados em repouso, em trânsito E em uso (em memória) no servidor. Mesmo os DBAs não devem ver os dados em texto claro.

→Use Always Encrypted.

Por quê: Always Encrypted é uma tecnologia de criptografia do lado do cliente onde as chaves são mantidas pelo cliente, garantindo que os dados nunca sejam descriptografados no servidor. TDE apenas protege os dados em repouso.

Precisa ocultar dados confidenciais de usuários não privilegiados nos resultados de consultas (por exemplo, mostrar apenas os últimos quatro dígitos de um número de segurança social) sem alterar os dados armazenados.

→Use Dynamic Data Masking.

Por quê: DDM aplica regras de mascaramento no momento da consulta com base nas permissões do usuário. É um recurso de segurança para limitar a exposição de dados, não um recurso de criptografia.

Garantir a continuidade dos negócios para um grupo de bancos de dados Azure SQL, habilitando o failover automático para uma região secundária em caso de interrupção regional.

→Configure um grupo de auto-failover.

Por quê: Grupos de auto-failover fornecem um endpoint de ouvinte unificado que redireciona automaticamente o tráfego após o failover, simplificando o design do aplicativo para DR. Ele oferece um RPO/RTO menor do que a restauração a partir de backups geo-redundantes.

Precisa armazenar grandes quantidades de dados não estruturados, como arquivos de vídeo, imagens, backups e logs, de forma econômica.

→Use o Azure Blob Storage.

Por quê: O Blob Storage é um serviço de armazenamento de objetos otimizado para armazenar petabytes de dados não estruturados. Não é adequado para cargas de trabalho de consulta estruturada.

Referência↗

Otimizar os custos de armazenamento para dados com padrões de acesso variados.

→Use os níveis de acesso do Azure Blob Storage: Hot (acessado frequentemente), Cool (acessado infrequentemente, >30 dias), Archive (acessado raramente, >180 dias).

Por quê: Os níveis oferecem uma compensação de custo: Hot tem o custo de armazenamento mais alto, mas o custo de acesso mais baixo. Archive tem o custo de armazenamento mais baixo, mas o custo de acesso mais alto e latência de recuperação (horas).

Mover blobs automaticamente entre os níveis Hot, Cool e Archive com base na idade ou última vez de acesso para otimizar custos.

→Configure uma política de gerenciamento de ciclo de vida na conta de armazenamento.

Por quê: Isso automatiza o processo de hierarquização, garantindo que os dados estejam sempre no nível mais econômico sem intervenção manual.

Migrar um aplicativo local que usa compartilhamentos de arquivos SMB. Várias VMs precisam montar e acessar a mesma pasta compartilhada.

→Use o Azure File Storage.

Por quê: O Azure Files fornece compartilhamentos de arquivos totalmente gerenciados na nuvem acessíveis via protocolos SMB e NFS, tornando-o um substituto direto para servidores de arquivos locais.

Construir um data lake para análise de big data que requer operações eficientes no nível de diretório e controle de acesso granular, semelhante ao POSIX.

→Use o Azure Data Lake Storage Gen2.

Por quê: O ADLS Gen2 se baseia no Blob Storage adicionando um namespace hierárquico (para operações de diretório atômicas) e suporte para ACLs compatíveis com POSIX, que são críticas para o desempenho e a segurança em frameworks de big data como o Spark.

Um aplicativo global requer latência de leitura/gravação de um dígito de milissegundos, replicação multirregional automática e escalabilidade horizontal para um banco de dados NoSQL.

→Use o Azure Cosmos DB.

Por quê: O Cosmos DB é projetado para aplicativos distribuídos globalmente e de missão crítica, fornecendo distribuição global pronta para uso, SLAs de baixa latência garantidos e múltiplos modelos de consistência.

Referência↗

Escolhendo um modelo de dados e API para um novo aplicativo Cosmos DB.

→Use a API para NoSQL (documento), API MongoDB (documento), API Apache Gremlin (grafo), API de Tabela (chave-valor) ou API Apache Cassandra (coluna larga).

Por quê: Selecione a API que melhor se adapta ao seu modelo de dados e stack de aplicativos existente. Use NoSQL para novos aplicativos baseados em JSON, Gremlin para dados com muitas relações e outros para migrar cargas de trabalho existentes (MongoDB, Cassandra, Table Storage).

Equilibrar consistência de leitura, disponibilidade e desempenho para um aplicativo Cosmos DB.

→Escolha entre cinco níveis de consistência: Forte, Desatualização Limitada, Sessão (padrão), Prefixo Consistente, Eventual.

Por quê: Forte oferece a maior consistência, mas a maior latência. Eventual oferece a menor latência, mas a consistência mais fraca. Sessão é o mais comum, garantindo que um usuário leia suas próprias gravações dentro de sua sessão.

Um serviço downstream precisa reagir em tempo quase real a quaisquer dados criados ou atualizados em um contêiner Cosmos DB (por exemplo, para atualizar um índice de pesquisa).

→Use o feed de alterações do Cosmos DB.

Por quê: O feed de alterações fornece um log persistente e ordenado de alterações. É comumente consumido por uma Azure Function para construir arquiteturas orientadas a eventos sem pesquisar o banco de dados.

Precisa executar consultas analíticas complexas em dados operacionais do Cosmos DB sem impactar o desempenho da carga de trabalho transacional (HTAP).

→Habilite o armazenamento analítico do Azure Cosmos DB e use o Azure Synapse Link.

Por quê: O armazenamento analítico é uma representação colunar totalmente isolada e auto-sincronizada dos seus dados transacionais. Ele permite consultas analíticas via Synapse sem consumir Unidades de Solicitação (RUs) transacionais.

Armazenar grandes quantidades de dados não relacionais simples e estruturados (por exemplo, telemetria de dispositivos) para buscas rápidas baseadas em chave a um custo muito baixo.

→Use o Azure Table Storage.

Por quê: O Table Storage é um armazenamento de chave-valor NoSQL otimizado para buscas simples de alto volume com uma PartitionKey e RowKey. É significativamente mais barato que o Cosmos DB quando SLAs de baixa latência e distribuição global não são necessários.

Precisa de um sistema de mensagens simples e confiável para desacoplar componentes de aplicativos, onde as mensagens são processadas assincronamente.

→Use o Azure Queue Storage.

Por quê: O Queue Storage fornece uma fila de mensagens simples, econômica e confiável para padrões básicos de comunicação assíncrona.

Precisa construir, agendar e monitorar fluxos de trabalho complexos de integração de dados que movem e transformam dados de várias fontes locais e na nuvem.

→Use o Azure Data Factory (ADF).

Por quê: ADF é um serviço de orquestração de nuvem gerenciado para construir e gerenciar pipelines ETL/ELT em escala, com amplas capacidades de conectividade e monitoramento.

Referência↗

Um pipeline do Azure Data Factory precisa acessar uma fonte de dados localizada on-premises atrás de um firewall corporativo.

→Instale um Integration Runtime (IR) auto-hospedado em uma máquina dentro da rede on-premises.

Por quê: O IR auto-hospedado atua como um gateway seguro, permitindo que o ADF na nuvem se conecte e mova dados de fontes on-premises sem expô-las à internet pública.

Precisa de uma plataforma única e integrada para data warehousing (SQL), análise de big data (Spark), exploração de dados (SQL serverless) e integração de dados.

→Use o Azure Synapse Analytics.

Por quê: O Synapse fornece um workspace unificado (Synapse Studio) que reúne esses diferentes motores analíticos, reduzindo a complexidade e a sobrecarga de integração.

Escolhendo um motor de consulta SQL dentro do Synapse Analytics.

→Use o pool SQL Serverless para consultas ad-hoc e exploratórias em dados no data lake com um modelo de pagamento por consulta. Use o pool SQL Dedicado para cargas de trabalho de data warehousing de alto desempenho e previsíveis com recursos provisionados.

Por quê: Serverless é para exploração e descoberta imprevisíveis. Dedicado é para BI e relatórios de produção com SLAs de desempenho.

Precisa processar e analisar dados de streaming de alto volume em tempo real de fontes como IoT Hub ou Event Hubs para alimentar dashboards ao vivo ou acionar alertas.

→Use o Azure Stream Analytics.

Por quê: O Stream Analytics é um motor de processamento de eventos em tempo real que usa uma linguagem de consulta simples, semelhante ao SQL, para analisar dados em movimento com baixa latência.

Uma equipe de ciência de dados precisa de um ambiente colaborativo, baseado em notebooks, para engenharia de dados e aprendizado de máquina em larga escala usando Apache Spark.

→Use o Azure Databricks.

Por quê: Databricks fornece um runtime Spark otimizado, notebooks colaborativos e capacidades de ML integradas (MLflow), tornando-o a plataforma principal para análise avançada e ML no Azure.

Precisa ingerir milhões de eventos por segundo de fontes como aplicativos móveis, telemetria da web ou dispositivos IoT para processamento em tempo real.

→Use o Azure Event Hubs.

Por quê: O Event Hubs é uma plataforma de streaming de big data projetada para ingestão de eventos de alto throughput. Ele atua como a "porta de entrada" para dados de streaming, desacoplando produtores de consumidores.

Uma organização deseja uma plataforma de análise SaaS única e unificada que combine engenharia de dados, ciência de dados, data warehousing e BI com gerenciamento mínimo de infraestrutura.

→Use o Microsoft Fabric.

Por quê: O Fabric oferece uma experiência de análise de ponta a ponta, baseada em SaaS, construída sobre um único data lake (OneLake). Ele simplifica a arquitetura e reduz a sobrecarga de integração em comparação com a construção com serviços PaaS separados.

Referência↗

Dentro do Microsoft Fabric, precisa de um único artefato para armazenar dados no formato aberto Delta Lake que possa ser acessado por motores Spark (para engenharia de dados) e motores SQL (para BI).

→Use um Microsoft Fabric Lakehouse.

Por quê: O Lakehouse é o padrão arquitetônico central no Fabric. Ele combina a escalabilidade e flexibilidade de um data lake com as garantias transacionais e capacidades de consulta SQL de um data warehouse.

Um relatório do Power BI no Microsoft Fabric precisa consultar grandes volumes de dados diretamente do OneLake com o desempenho do modo de importação, mas a atualização de dados do DirectQuery.

→Use o modo Direct Lake no Power BI.

Por quê: Direct Lake é um recurso exclusivo do Fabric que carrega arquivos Parquet/Delta diretamente na memória do motor do Power BI sob demanda, evitando duplicação de dados e latência de consulta, ao mesmo tempo que fornece acesso a dados quase em tempo real.

Usuários de negócios precisam se conectar a várias fontes de dados, criar dashboards e relatórios interativos e compartilhar insights em toda a organização.

→Use o Power BI.

Por quê: Power BI é o serviço de análise de negócios da Microsoft para construir visualizações de dados interativas. Use o Power BI Desktop para autoria e o Power BI Service para compartilhamento e colaboração.

Diferenciar entre uma análise interativa de várias páginas e uma visão geral de alto nível de página única no Power BI.

→Um Relatório é uma coleção de várias páginas de visuais detalhados e interativos construídos a partir de um único conjunto de dados. Um Dashboard é uma tela única de blocos fixados de um ou mais relatórios, fornecendo uma visão geral rápida.

Por quê: Relatórios são para análise aprofundada. Dashboards são para monitorar métricas chave.

Um único relatório do Power BI deve ser compartilhado com vários usuários, mas cada usuário deve ver apenas os dados relevantes para ele (por exemplo, um gerente de vendas vê apenas os dados de sua região).

→Implementar Segurança em Nível de Linha (RLS).

Por quê: RLS define regras de filtro com base nas funções do usuário, aplicando a segurança dos dados no nível do modelo de dados para que os usuários que acessam o mesmo relatório vejam diferentes subconjuntos de dados.

Precisa gerar relatórios altamente formatados e pixel-perfeitos (como faturas ou demonstrativos financeiros) que são otimizados para impressão ou exportação em PDF.

→Use Relatórios Paginados do Power BI.

Por quê: Relatórios paginados são projetados para layouts prontos para impressão com controle preciso sobre cabeçalhos, rodapés e quebras de página, ao contrário dos relatórios interativos padrão do Power BI que são para exploração em tela.

Um conjunto de dados do Power BI contendo bilhões de linhas leva muito tempo para ser atualizado. Apenas os últimos dias de dados mudam frequentemente.

→Configure a atualização incremental no conjunto de dados.

Por quê: A atualização incremental particiona os dados (geralmente por data) e atualiza apenas as partições mais recentes, reduzindo drasticamente o tempo de atualização e o uso de recursos para grandes conjuntos de dados.

Um único relatório do Power BI precisa combinar dados pré-carregados de alto desempenho (modo Importar) com dados em tempo real de uma fonte operacional (modo DirectQuery).

→Use modelos compostos do Power BI.

Por quê: Modelos compostos permitem que um único conjunto de dados misture tabelas com diferentes modos de armazenamento, proporcionando flexibilidade para equilibrar desempenho e atualização de dados.

Uma organização precisa descobrir, classificar e catalogar todos os ativos de dados em seu patrimônio de dados híbrido para habilitar a governança e descoberta de dados.

→Use o Microsoft Purview.

Por quê: O Purview é um serviço unificado de governança de dados que oferece digitalização automatizada de dados, um glossário de negócios, classificação de dados e visualização de linhagem de dados de ponta a ponta.