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
Use essas informações para comparar armazenamentos de dados do Fabric, como warehouse, lakehouse, Eventhouse, banco de dados SQL e datamart do Power BI, com base no volume de dados, tipo, persona do desenvolvedor, conjunto de habilidades, operações e outros recursos. Essas comparações são organizadas nas duas tabelas a seguir:
| Tabela 1 de 2 | casa de lago | Armazém | Eventhouse |
|---|---|---|---|
| Volume de dados | Ilimitado | Ilimitado | Ilimitado |
| Tipo de dados | Desestruturado semiestruturados, estruturados |
Estruturados, JSON (semiestruturado) |
Desestruturado semiestruturados, estruturados |
| Persona primária do desenvolvedor | Engenheiro de dados, cientista de dados | Desenvolvedor de data warehouse, arquiteto de dados, engenheiro de dados, desenvolvedor de banco de dados | Desenvolvedor de aplicativos, cientista de dados, engenheiro de dados |
| Habilidade de desenvolvimento primária | Spark (Scala, PySpark, Spark SQL, R) | SQL | Sem código, KQL, SQL |
| Dados organizados por | Pastas e arquivos, bancos de dados e tabelas | Bancos de dados, esquemas e tabelas | Bancos de dados, esquemas e tabelas |
| Operações de leitura | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Operações de gravação | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, ecossistema de conectores |
| Transações de várias tabelas | Não | Sim | Sim, para ingestão de várias tabelas |
| interface de desenvolvimento principal | Blocos de anotações do Spark, definições de trabalho do Spark | Scripts SQL | KQL Queryset, Banco de Dados KQL |
| Segurança | RLS, CLS**, nível de tabela (T-SQL), nenhum para Spark | Nível de objeto, RLS, CLS, DDL/DML, mascaramento dinâmico de dados | RLS |
| Acesse dados via atalhos | Sim | Sim, por meio do endpoint de análise SQL | Sim |
| Pode ser uma origem para atalhos | Sim (arquivos e tabelas) | Sim (tabelas) | Sim |
| Consultar entre itens | Sim | Sim | Sim |
| Análise avançada | Interface para processamento de dados em larga escala, paralelismo de dados interno e tolerância a falhas | Interface para processamento de dados em larga escala, paralelismo de dados interno e tolerância a falhas | Elementos nativos do Time Series, recursos geoespaciais e de consulta completos |
| suporte à formatação avançada | Tabelas definidas usando PARQUET, CSV, AVRO, JSON e qualquer formato de arquivo compatível com Apache Hive | Tabelas definidas usando PARQUET, CSV, AVRO, JSON e qualquer formato de arquivo compatível com Apache Hive | Indexação completa para texto gratuito e dados semiestruturados, como JSON |
| Latência de ingestão | Disponível instantaneamente para consulta | Disponível instantaneamente para consulta | Ingestão em fila, ingestão de streaming tem uma latência de alguns segundos |
* O Spark dá suporte à leitura de tabelas usando atalhos, ainda não dá suporte ao acesso a exibições, procedimentos armazenados, funções etc.
| Tabela 2 de 2 | banco de dados SQL Fabric | Datamart do Power BI |
|---|---|---|
| Volume de dados | 4 TB | Até 100 GB |
| Tipo de dados | Estruturados, semiestruturados, Desestruturado |
Estruturados |
| Persona do desenvolvedor primário | Desenvolvedor de IA, desenvolvedor de aplicativos, desenvolvedor de banco de dados, administrador do BD | Cientista de dados, analista de dados |
| Habilidade de desenvolvimento primária | SQL | Sem código, SQL |
| Dados organizados por | Bancos de dados, esquemas, tabelas | Banco de dados, tabelas, consultas |
| Operações de leitura | T-SQL | Spark, T-SQL |
| Operações de gravação | T-SQL | Fluxos de dados, T-SQL |
| Transações de várias tabelas | Sim, conformidade total com ACID | Não |
| interface de desenvolvimento principal | Scripts SQL | Power BI |
| Segurança | Nível do objeto, RLS, CLS, DDL/DML, mascaramento dinâmico de dados | Editor RLS incorporado |
| Acessar dados por meio de atalhos | Sim | Não |
| Pode ser uma origem para atalhos | Sim (tabelas) | Não |
| Consultar entre itens | Sim | Não |
| Análise avançada | Recursos analíticos de T-SQL, dados replicados para delta parquet no OneLake para análise | Interface para processamento de dados com ajuste automatizado de desempenho |
| suporte à formatação avançada | Suporte à tabela para OLTP, JSON, vetor, grafo, XML, espacial, chave-valor | Tabelas definidas usando PARQUET, CSV, AVRO, JSON e qualquer formato de arquivo compatível com Apache Hive |
| Latência de ingestão | Disponível instantaneamente para consulta | Disponível instantaneamente para consulta |
** Segurança em nível de coluna disponível no Lakehouse através de um endpoint de análise SQL, usando T-SQL.
Cenários
Examine esses cenários para obter ajuda na escolha de 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 (armazém de dados) ou um lakehouse (armazém de dados em lago). Após a revisão dos detalhes na tabela anterior, os principais pontos de decisão 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. Considerando a equipe maior, os principais consumidores desses dados também são proficientes em SQL e em ferramentas analíticas relacionadas. Susan decide usar um warehouse do Fabric, 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 data warehouse e interage com ele usando o T-SQL, assim como seus outros bancos de dados do SQL Server. A maior parte do código T-SQL existente que ela escreveu para criar seu armazém no SQL Server funcionará no data warehouse do Fabric facilitando a transição. Se optar por isso, ela pode até mesmo usar as mesmas ferramentas que funcionam com seus outros bancos de dados, como o SQL Server Management Studio. Usando o editor de SQL no portal do Fabric, Susan e outros membros da equipe escrevem consultas analíticas que fazem referência a outros data warehouses e tabelas Delta em lakehouses apenas usando nomes de três partes para executar consultas entre bancos de 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 gravar instruções INSERT, UPDATE ou DELETE. Os desenvolvedores restantes estão 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, que 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, nenhuma funcionalidade 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 Premium de capacidade. Ao pensar em sua equipe maior, eles percebem que os principais consumidores desses dados são 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 é analista de negócios experiente em usar o Power BI para analisar gargalos da cadeia de suprimentos 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 pode ser usada para criar dashboards e relatórios que possam ser usados para tomar decisões de negócios. Os dados são provenientes de plantas, fornecedores, carregadores 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 modo de consulta direta rápida no Power BI. As consultas podem ser executadas usando o Power BI e o KQL para comparar entre os períodos atuais e anteriores, identificar rapidamente problemas emergentes ou fornecer análise geográfica de rotas terrestres e marítimas.
Cenário 5
Kirby é um arquiteto de aplicativos experiente no desenvolvimento de aplicativos .NET para dados operacionais. Eles precisam de um banco de dados de alta simultaneidade, com conformidade total com transações ACID e chaves estrangeiras fortemente impostas para integridade relacional. Kirby quer o benefício do ajuste automático de desempenho para simplificar o gerenciamento de banco de dados diário.
Kirby decide usar um banco de dados SQL no Fabric, com o mesmo Mecanismo de Banco de Dados SQL que o Banco de Dados SQL do Azure. Os bancos de dados SQL no Fabric são dimensionados automaticamente para atender à demanda ao longo do dia útil. Eles têm toda a capacidade das tabelas transacionais e a flexibilidade dos níveis de isolamento de transações de serializáveis para ler instantâneos confirmados. O banco de dados SQL no Fabric cria e descarta automaticamente índices não clusterizados com base em sinais fortes de planos de execução observados ao longo do tempo.
No cenário de Kirby, os dados do aplicativo operacional devem ser unidos a outros dados no Fabric: no Spark, em um armazém de dados e a partir de eventos em tempo real em um Eventhouse. Cada banco de dados do Fabric inclui um ponto de extremidade de análise SQL, de modo que os dados sejam acessados em tempo real de consultas do Spark ou Power BI usando o modo DirectLake. Essas soluções de relatório poupam o banco de dados operacional primário da sobrecarga de cargas de trabalho analíticas e evitam a desnormalização. Kirby também tem dados operacionais existentes em outros bancos de dados SQL e precisa importar esses dados sem transformação. Para importar dados operacionais existentes sem nenhuma conversão de tipo de dados, Kirby projeta pipelines de dados com o Fabric Data Factory para importar dados para o banco de dados SQL do Fabric.