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, tudo disponível em um armazenamento unificado no OneLake.

Personas e conjuntos de habilidades

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

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 4

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 com o Fabric Data Factory para importar dados para o Fabric SQL database.

Próximo passo