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

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

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 4

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

Próxima etapa