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

  • Artigo

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

Data warehouse Lakehouse Datamart do Power BI Banco de dados KQL (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 tabela (ao usar T-SQL), nenhum para Spark Editor de RLS interno Segurança em nível de linha
Acessar dados por meio de atalhos Sim (indiretamente pelo lakehouse) 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
Análise avançada Elementos nativos da Série Temporal, Armazenamento geoespacial completo e recursos de consulta
Suporte à formatação avançada Indexação completa para texto gratuito e dados semiestruturados, como JSON
Latência de ingestão Ingestão na fila, ingestão de streaming tem uma latência de alguns segundos

Observação

O Eventhouse é um espaço de trabalho para múltiplos bancos de dados KQL. O banco de dados KQL está disponível para o público em geral, enquanto o Eventhouse está em Preview. Para obter mais informações, veja Visão geral do Eventhhouse (preview).

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.

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 Banco de Dados KQL 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.

Conteúdo relacionado