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. Estas comparações estão organizadas nos dois quadros seguintes:
| Tabela 1 de 2 | Casa do Lago | Armazém | Casa de eventos |
|---|---|---|---|
| Volume de dados | Ilimitado | Ilimitado | Ilimitado |
| Tipo de dados | Não estruturado, semi-estruturada, estruturado |
Estruturado, semi-estruturado (JSON) |
Não estruturado, semi-estruturada, estruturado |
| Persona principal 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 principal | 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 | Faísca, T-SQL | T-SQL, Faísca* | KQL, T-SQL, Faísca |
| Operações de gravação | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Faísca, ecossistema de conectores |
| Transações com várias tabelas | Não | Sim | Sim, para ingestão de várias mesas |
| Interface de desenvolvimento primária | 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 o Spark | Nível de objeto, RLS, CLS, DDL/DML, mascaramento dinâmico de dados | SPI |
| Aceder a dados através de atalhos | Sim | Sim | Sim |
| Pode ser uma fonte de atalhos | Sim (ficheiros e tabelas) | Sim (tabelas) | Sim |
| Consulta entre itens | Sim | Sim | Sim |
| Análise avançada | Interface para processamento de dados em larga escala, paralelismo de dados integrado e tolerância a falhas | Interface para processamento de dados em larga escala, paralelismo de dados integrado e tolerância a falhas | Elementos nativos de séries temporais, recursos geoespaciais e de consulta completos |
| Suporte avançado de formatação | 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 livre 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 um par de segundos de latência |
* O Spark suporta a leitura de tabelas usando atalhos, ainda não suporta o acesso a visualizações, procedimentos armazenados, funções, etc.
| Tabela 2 de 2 | Banco de dados SQL de malha | Power BI Datamart |
|---|---|---|
| Volume de dados | 4 TB | Até 100 GB |
| Tipo de dados | Estruturado, semi-estruturada, não estruturado |
estruturado |
| Persona principal do desenvolvedor | Desenvolvedor de IA, Desenvolvedor de aplicativos, Desenvolvedor de banco de dados, Administrador de banco de dados | Cientista de dados, analista de dados |
| Habilidade de desenvolvimento principal | SQL | Sem código, SQL |
| Dados organizados por | Bancos de dados, esquemas, tabelas | Base de dados, tabelas, consultas |
| Operações de leitura | T-SQL | Faísca, T-SQL |
| Operações de gravação | T-SQL | Fluxos de dados, T-SQL |
| Transações com várias tabelas | Sim, conformidade total com ACID | Não |
| Interface de desenvolvimento primária | Scripts SQL | Power BI |
| Segurança | Nível de objeto, RLS, CLS, DDL/DML, mascaramento de dados dinâmicos | Editor RLS integrado |
| Aceder a dados através de atalhos | Sim | Não |
| Pode ser uma fonte de atalhos | Sim (tabelas) | Não |
| Consulta entre itens | Sim | Não |
| Análise avançada | Recursos analíticos T-SQL, dados replicados para parquet delta no OneLake para análise | Interface para processamento de dados com ajuste de desempenho automatizado |
| Suporte avançado de formatação | Suporte de tabela para OLTP, JSON, vetor, gráfico, 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
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 armazém Fabric, 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 um novo armazém de dados e interage com ele usando T-SQL, assim como seus outros bancos de dados de servidor SQL. A maioria do código T-SQL existente que ela escreveu para criar seu depósito no SQL Server funcionará no data warehouse do Fabric, facilitando a transição. Se desejar, ela pode até usar as mesmas ferramentas que funcionam com seus outros bancos de dados, como o SQL Server Management Studio. Usando o editor SQL no portal Fabric, Susan e outros membros da equipa escrevem consultas analíticas que fazem referência a outros armazéns de dados e tabelas Delta em lakehouses simplesmente usando nomes de três partes para executar consultas entre bases 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 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 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 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 Eventhouse 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.
Cenário 5
Kirby é um arquiteto de aplicativos com experiência no desenvolvimento de aplicativos .NET para dados operacionais. Eles precisam de um banco de dados de alta simultaneidade com total conformidade 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 diário do banco de dados.
Kirby decide sobre um banco de dados SQL no Fabric, com o mesmo Mecanismo de Banco de Dados SQL do Banco de Dados SQL do Azure. Os bancos de dados SQL no Fabric são dimensionados automaticamente para atender à demanda durante todo o dia útil. Eles têm a capacidade total de tabelas transacionais e a flexibilidade dos níveis de isolamento de transações, desde instantâneo serializável até instantâneo confirmado de leitura. 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 e de eventos em tempo real em uma Eventhouse. Cada banco de dados Fabric inclui um ponto de extremidade de análise SQL, portanto, os dados podem ser acessados em tempo real a partir do Spark ou com consultas do Power BI usando o modo DirectLake. Essas soluções de relatórios 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 qualquer 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 de malha.