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 | Lakehouse | Armazém | Eventhouse |
|---|---|---|---|
| Volume de dados | Ilimitado | Ilimitado | Ilimitado |
| Tipo de dados | Não estruturado, semi-estruturada, estruturado |
Estruturado, semi-estruturado (JSON) |
Não estruturado, semi-estruturado 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 principal de desenvolvimento | 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 com várias tabelas | Não | Sim | Sim, para ingestão de múltiplas tabelas |
| Interface de desenvolvimento primário | Blocos de anotações do Spark, definições de trabalho do Spark | Scripts de SQL | KQL Queryset, Banco de Dados KQL |
| Segurança | RLS, CLS**, de nível de tabela (T-SQL), nenhum para o Spark | nível de objeto, RLS, CLS, DDL/DML, mascaramento dinâmico de dados | SPI |
| Aceda aos dados através de atalhos | Sim | Sim, via endpoint de análise SQL | Sim |
| Pode ser uma fonte para 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 | A ingestão em fila e a ingestão de streaming têm alguns 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.
** 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 repositório 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 se vão construir um data warehouse ou um 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. Quando consideramos a equipa alargada, os principais consumidores desses dados também são habilidosos com SQL e ferramentas analíticas de SQL. Susan decide usar umde armazém doFabric, 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 equipe escrevem consultas analíticas que fazem referência a outros data warehouses e tabelas Delta em lakehouses simplesmente 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 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 utilizar um lakehouse, que permite que a equipa de engenharia dos dados use as suas diversas competências nos dados, enquanto permite que os membros da equipa que são altamente qualificados em T-SQL acedam aos 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-se usar um datamart do Power BI , que permite à equipa interagir e criar a funcionalidade rapidamente, através de 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 umEventhouse 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 escolhe um banco de dados SQL no Fabric, que utiliza o mesmo mecanismo 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 serializável até confirmado de leitura instantâneo. 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 base de dados Fabric inclui um ponto de extremidade de análise SQL, o que permite que os dados sejam acessados em tempo real a partir do Spark ou através de consultas do Power BI utilizando 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 do Fabric.