Guia de decisão do Microsoft Fabric: escolha um armazenamento de dados
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
Esta tabela compara armazenamentos de dados como armazém, lakehouse, datamart do Power BI e eventhouse com base no volume de dados, tipo, persona do desenvolvedor, conjunto de habilidades e operações. e outras capacidades.
| Armazém | Casa do Lago | Power BI Datamart | Casa de eventos | |
|---|---|---|---|---|
| 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, funções, 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 coluna (para lakehouse acessado por meio de um ponto de extremidade de análise SQL), nível de tabela (ao usar T-SQL), nenhum para 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 |
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 lakehouse e acessa os recursos de data warehouse com o ponto de extremidade de análise SQL lakehouse. 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 uma casa de eventos 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.