Guia de decisão do Microsoft Fabric: escolher um armazenamento de dados
Use este guia de referência e os cenários de exemplo para ajudar a escolher um armazenamento de dados para suas cargas de trabalho do Microsoft Fabric.
Propriedades de 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:
| Lakehouse | Depósito | Eventhouse | |
|---|---|---|---|
| Volume de dados | Ilimitado | Ilimitado | Ilimitado |
| Tipo de dados | Não estruturados, semiestruturados, estruturado |
Estruturados | Não estruturados, semiestruturados, estruturado |
| Persona do desenvolvedor principal | Engenheiro de dados, cientista de dados | Desenvolvedor de data warehouse, arquiteto de dados, desenvolvedor de banco de dados | Desenvolvedor de aplicativos, cientista de dados, engenheiro de dados |
| Habilidade de desenvolvimento primário | 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 do conector |
| Transações de várias tabelas | Não | Sim | Sim, para ingestão de várias tabelas |
| Interface de desenvolvimento principal | Notebooks 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 do objeto, RLS, CLS, DDL/DML, máscara dinâmica de dados | RLS |
| Acessar dados por meio de atalhos | Sim | Sim | 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 na 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.
| Banco de dados SQL do Fabric | Datamart do Power BI | |
|---|---|---|
| Volume de dados | 4 TB | Até 100 GB |
| Tipo de dados | Estruturados, semiestruturados, não estruturados |
Estruturados |
| Persona do desenvolvedor principal | Desenvolvedor de IA, desenvolvedor de aplicativos, desenvolvedor de banco de dados, administrador do BD | Cientista de dados, analista de dados |
| Habilidade de desenvolvimento primário | 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, máscara dinâmica de dados | Editor de RLS interno |
| Acessar dados por meio de atalhos | Sim | No |
| Pode ser uma origem para atalhos | Sim (tabelas) | Não |
| Consultar entre itens | Sim | No |
| Análise avançada | Recursos analíticos do 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 por meio de um ponto de extremidade de análise de SQL usando T-SQL.
Cenários
Examine esses cenários para obter ajuda para escolher 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 ou um lakehouse. Após a revisão dos detalhes na tabela anterior, os pontos de decisão primários 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. Pensando na equipe maior, os principais consumidores desses dados também são qualificados com ferramentas analíticas de SQL e SQL. 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 lakehouse e acessa as funcionalidades do data warehouse com o ponto de extremidade de análise de SQL do lakehouse. Usando o portal do Fabric, ela cria atalhos para as tabelas de dados externos e os coloca na pasta /Tables. Susan agora pode escrever consultas T-SQL que fazem referência a atalhos para consultar dados do Delta Lake no lakehouse. Os atalhos aparecem como tabelas automaticamente no ponto de extremidade da análise SQL e podem ser consultados com T-SQL usando nomes de três partes.
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 escrever instruções INSERT, UPDATE ou DELETE. Os desenvolvedores restantes se sentem 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, e eles 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, sem capacidade de código e volume de dados abaixo de 100 GB.
O 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 na equipe, eles percebem que os principais consumidores desses dados podem ser 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 é uma analista de negócios experiente no uso de Power BI para analisar gargalos da cadeia de fornecedores 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 ser usada para criar dashboards e relatórios que podem ser usados para tomar decisões de negócios. Os dados são provenientes de plantas, fornecedores, transportadoras 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 atualização rápida de dados 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 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 em 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 de tabelas transacionais e a flexibilidade dos níveis de isolamento de transações de serializáveis para instantâneos confirmados 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 warehouse e em eventos em tempo real em um Eventhouse. Cada banco de dados do Fabric inclui um ponto de extremidade de análise de SQL, para que os dados sejam acessados em tempo real do Spark ou com consultas do Power BI usando o modo DirectLake. Essas soluções de geração de relatórios poupam o banco de dados operacional primário da sobrecarga das 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.