Guia de decisão do Microsoft Fabric: escolher um armazenamento de dados
Use este guia de referência e os cenários de exemplo para ajudar a escolher um armazenamento de dados para suas cargas de trabalho do Microsoft Fabric.
Propriedades de armazenamento de dados
Esta tabela compara armazenamentos de dados como warehouse, 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 funcionalidades.
| Depósito | Lakehouse | Datamart do Power BI | Eventhouse | |
|---|---|---|---|---|
| Volume de dados | Ilimitado | Ilimitado | Até 100 GB | Ilimitado |
| Tipo de dados | Estruturados | Não estruturado, semiestruturado, estruturado | Estruturados | Não estruturado, semiestruturado, estruturado |
| Persona do desenvolvedor principal | Desenvolvedor de data warehouse, engenheiro de SQL | Engenheiro de dados, cientista de dados | Desenvolvedor cidadão | Cientista de dados cidadão, engenheiro de dados, cientista de dados, engenheiro de SQL |
| Conjunto de habilidades do desenvolvedor primário | SQL | Spark(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 | Banco 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 acesso a visualizações, procedimentos armazenados, funções etc.) | Spark,T-SQL | Spark,T-SQL,Power BI | KQL, T-SQL, Spark, Power BI |
| Operações de gravação | T-SQL | Spark(Scala, PySpark, Spark SQL, R) | Fluxos de dados, T-SQL | KQL, Spark, ecossistema do conector |
| Transações de várias tabelas | Sim | Não | Não | Sim, para ingestão de várias tabelas. Consulte Política de atualização. |
| Interface de desenvolvimento principal | Scripts SQL | Notebooks Spark, definições de trabalho do Spark | Power BI | KQL Queryset, Banco de Dados KQL |
| Segurança | Nível do objeto (tabela, exibição, função, procedimento armazenado etc.), nível da coluna, nível de linha, DDL/DML, mascaramento de dados dinâmico | Nível de linha, nível de coluna (para lakehouse acessado por meio de um ponto de extremidade de análise do SQL), nível de tabela (ao usar o T-SQL), nenhum para o Spark | Editor de RLS interno | Segurança em nível de linha |
| Acessar dados por meio de atalhos | Sim, por meio de um lakehouse usando nomes de três partes | Sim | Não | Sim |
| Pode ser uma origem para atalhos | Sim (tabelas) | Sim (arquivos e tabelas) | Não | Sim |
| Consultar entre itens | Sim, consulte as tabelas de lakehouse e warehouse | Sim, consulte em tabelas de lakehouse e warehouse;consulta entre lakehouses (incluindo atalhos usando Spark) | Não | Sim, consulte bancos de dados KQL, lakehouses e warehouses com atalhos |
Cenários
Examine esses cenários para obter ajuda para escolher um armazenamento de dados no Fabric.
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 criar um data warehouse ou um lakehouse. Após a revisão dos detalhes na tabela anterior, os pontos de decisão primários são o conjunto de habilidades disponível e a necessidade de transações de várias tabelas.
Susan passou muitos anos criando data warehouses em mecanismos de banco de dados relacionais e está familiarizada com a sintaxe e a funcionalidade do SQL. Pensando na equipe maior, os principais consumidores desses dados também são qualificados com ferramentas analíticas de SQL e SQL. Susan decide usar um data warehouse, que permite que a equipe interaja principalmente com o T-SQL, permitindo também que todos os usuários do Spark na organização acessem os dados.
Susan cria um novo lakehouse e acessa os recursos do data warehouse com o ponto de extremidade de análise SQL do lakehouse. Usando o portal do Fabric, ela cria atalhos para as tabelas de dados externos e os coloca na pasta /Tables. Susan agora pode escrever consultas T-SQL que fazem referência a atalhos para consultar dados do Delta Lake no lakehouse. Os atalhos aparecem como tabelas automaticamente no ponto de extremidade da análise SQL e podem ser consultados com 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 combinação de habilidades de 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 em trabalhar 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 em relação aos dados, permitindo que os membros da equipe altamente qualificados no 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, o Power BI e o 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 criar um data warehouse ou um lakehouse, e eles parecem ser demais para suas necessidades e volumes de dados. Eles revisam os detalhes na tabela anterior e veem que os pontos de decisão primários são suas próprias habilidades e sua necessidade de autoatendimento, sem capacidade de código e volume de dados abaixo de 100 GB.
O 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 na equipe, 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 rapidamente para criar a funcionalidade, usando uma experiência sem código. As consultas podem ser executadas por meio do Power BI e do T-SQL, permitindo também que os usuários do Spark na organização acessem os dados.
Cenário 4
Daisy é uma analista de negócios experiente no uso de Power BI para analisar gargalos da cadeia de fornecedores para uma grande cadeia de varejo global. Eles precisam criar uma solução de dados escalonável que possa lidar com bilhões de linhas de dados e ser usada para criar dashboards e relatórios que podem ser usados para tomar decisões de negócios. Os dados são provenientes de plantas, fornecedores, transportadoras e outras fontes em vários formatos estruturados, semiestruturados e não estruturados.
Daisy decide usar um eventhouse devido à escalabilidade, tempos de resposta rápidos, recursos de análise avançada, incluindo análise de série temporal, funções geoespaciais e atualização rápida de dados 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.