Partilhar via

Guia de decisão do Microsoft Fabric: escolha um armazenamento de dados

  • Artigo

Use este guia de referência e os cenários de exemplo para ajudá-lo a escolher um armazenamento de dados para suas cargas de trabalho do Microsoft Fabric.

Propriedades do armazenamento de dados

Armazém Casa do Lago Power BI Datamart Base de Dados KQL (Eventhouse)
Volume de dados Ilimitado Ilimitado Até 100 GB Ilimitado
Tipo de dados estruturado Não estruturado, semi-estruturado, estruturado estruturado Não estruturado, semi-estruturado, estruturado
Persona principal do desenvolvedor Desenvolvedor de data warehouse, engenheiro SQL Engenheiro de dados, cientista de dados Desenvolvedor cidadão Cientista de dados cidadão, engenheiro de dados, cientista de dados, engenheiro SQL
Conjunto de habilidades principais do desenvolvedor SQL Faísca (Scala, PySpark, Spark SQL, R) Sem código, SQL Sem código, KQL, SQL
Dados organizados por Bancos de dados, esquemas e tabelas Pastas e arquivos, bancos de dados e tabelas Base de dados, tabelas, consultas Bancos de dados, esquemas e tabelas
Operações de leitura T-SQL, Spark (suporta leitura de tabelas usando atalhos, ainda não suporta o acesso a visualizações, procedimentos armazenados, fuctions etc.) Faísca,T-SQL Faísca,T-SQL,Power BI KQL, T-SQL, Faísca, Power BI
Operações de gravação T-SQL Faísca (Scala, PySpark, Spark SQL, R) Fluxos de dados, T-SQL KQL, Faísca, ecossistema de conectores
Transações com várias tabelas Sim No Não Sim, para ingestão de várias mesas. Consulte a política de atualização.
Interface de desenvolvimento primária Scripts SQL Blocos de anotações do Spark,definições de trabalho do Spark Power BI KQL Queryset, Banco de Dados KQL
Segurança Nível do objeto (tabela, visualização, função, procedimento armazenado, etc.), nível da coluna, nível da linha, DDL/DML, mascaramento dinâmico de dados Nível de linha, nível de tabela (ao usar T-SQL), nenhum para o Spark Editor RLS integrado Segurança ao Nível da Linha
Aceder a dados através de atalhos Sim, através de uma casa de lago usando nomes de três partes Sim No Sim
Pode ser uma fonte de atalhos Sim (tabelas) Sim (ficheiros e tabelas) Não Sim
Consulta entre itens Sim, consulte as tabelas lakehouse e warehouse Sim, consulte as mesas do lakehouse e do armazém; consulta em lakehouses (incluindo atalhos usando o Spark) Não Sim, consulte bancos de dados KQL, lakehouses e armazéns com atalhos
Análise avançada Elementos nativos de séries temporais, armazenamento geoespacial completo e recursos de consulta
Suporte avançado de formatação Indexação completa para texto livre e dados semiestruturados como JSON
Latência de ingestão Ingestão em fila, ingestão de streaming tem um par de segundos de latência

Nota

O Eventhouse é um espaço de trabalho para vários bancos de dados KQL. O banco de dados KQL está geralmente disponível, enquanto o Eventhouse está em visualização. Para obter mais informações, consulte Visão geral do Eventhouse (visualização).

Cenários

Analise esses cenários para obter ajuda com a escolha de um armazenamento de dados na malha.

Cenário 1

Susan, uma desenvolvedora profissional, é nova no Microsoft Fabric. Eles estão prontos para começar a limpar, modelar e analisar dados, mas precisam decidir construir um data warehouse ou uma lakehouse. Após a revisão dos detalhes na tabela anterior, os principais pontos de decisão são o conjunto de habilidades disponíveis e a necessidade de transações com várias tabelas.

Susan passou muitos anos criando armazéns de dados em mecanismos de banco de dados relacionais e está familiarizada com a sintaxe e a funcionalidade SQL. Pensando na equipe maior, os principais consumidores desses dados também são hábeis com ferramentas analíticas SQL e SQL. Susan decide usar um data warehouse, que permite que a equipe interaja principalmente com o T-SQL, ao mesmo tempo em que permite que qualquer usuário do Spark na organização acesse os dados.

Susan cria uma nova casa no lago. Usando o portal Fabric, cria atalhos para as tabelas de dados externas e as coloca na /Tables pasta. Susan agora pode escrever consultas T-SQL que fazem referência a atalhos para consultar dados do Delta Lake na casa do lago. Os atalhos aparecem automaticamente como tabelas no ponto de extremidade de análise SQL e podem ser consultados com o T-SQL usando nomes de três partes.

Cenário 2

Rob, um engenheiro de dados, precisa armazenar e modelar vários terabytes de dados no Fabric. A equipe tem uma mistura de habilidades PySpark e T-SQL. A maioria da equipe que executa consultas T-SQL são consumidores e, portanto, não precisam escrever instruções INSERT, UPDATE ou DELETE. Os desenvolvedores restantes se sentem confortáveis trabalhando em notebooks e, como os dados são armazenados no Delta, eles podem interagir com uma sintaxe SQL semelhante.

Rob decide usar um lakehouse, que permite que a equipe de engenharia de dados use suas diversas habilidades contra os dados, enquanto permite que os membros da equipe que são altamente qualificados em T-SQL consumam os dados.

Cenário 3

Ash, um desenvolvedor cidadão, é um desenvolvedor do Power BI. Eles estão familiarizados com o Excel, Power BI e Office. Eles precisam criar um produto de dados para uma unidade de negócios. Eles sabem que não têm as habilidades necessárias para construir um armazém de dados ou uma casa de lago, e isso parece demais para suas necessidades e volumes de dados. Eles analisam os detalhes na tabela anterior e veem que os principais pontos de decisão são suas próprias habilidades e sua necessidade de autosserviço, sem capacidade de código e volume de dados abaixo de 100 GB.

Ash trabalha com analistas de negócios familiarizados com o Power BI e o Microsoft Office e sabe que eles já têm uma assinatura de capacidade Premium. Ao pensar em sua equipe maior, eles percebem que os principais consumidores desses dados podem ser analistas, familiarizados com ferramentas analíticas sem código e SQL. Ash decide usar um datamart do Power BI, que permite que a equipe interaja criando o recurso rapidamente, usando uma experiência sem código. As consultas podem ser executadas via Power BI e T-SQL, permitindo também que qualquer usuário do Spark na organização acesse os dados.

Cenário 4

Daisy é analista de negócios com experiência no uso do Power BI para analisar gargalos da cadeia de suprimentos para uma grande cadeia de varejo global. Eles precisam criar uma solução de dados escalável que possa lidar com bilhões de linhas de dados e possa ser usada para criar painéis e relatórios que possam ser usados para tomar decisões de negócios. Os dados vêm de fábricas, fornecedores, transportadores e outras fontes em vários formatos estruturados, semi-estruturados e não estruturados.

Daisy decide usar um banco de dados KQL por causa de sua escalabilidade, tempos de resposta rápidos, recursos avançados de análise, incluindo análise de séries temporais, funções geoespaciais e modo de consulta direta rápida no Power BI. As consultas podem ser executadas usando o Power BI e o KQL para comparar entre períodos atuais e anteriores, identificar rapidamente problemas emergentes ou fornecer análises geoespaciais de rotas terrestres e marítimas.

Conteúdos relacionados