Compartilhar via

Entender o armazenamento para modelos semânticos Direct Lake

  • Artigo

Este artigo apresenta os conceitos de armazenamento do Direct Lake. Descreve tabelas Delta e arquivos Parquet. Ele também descreve como você pode otimizar tabelas Delta para modelos semânticos do Direct Lake e como você pode mantê-las para ajudar a fornecer desempenho de consulta confiável e rápido.

Tabelas do Delta

As tabelas delta existem no OneLake. Eles organizam dados baseados em arquivos em linhas e colunas e estão disponíveis para mecanismos de computação do Microsoft Fabric, como notebooks, Kusto e lakehouse e warehouse. Você pode consultar tabelas Delta usando DAX (Data Analysis Expressions), MDX (Expressões Multidimensionais), T-SQL (Transact-SQL), Spark SQL e até Python.

Observação

Delta — ou Delta Lake— é um formato de armazenamento de software livre. Isso significa que o Fabric também pode consultar tabelas Delta criadas por outras ferramentas e fornecedores.

As tabelas delta armazenam seus dados em arquivos Parquet, que normalmente são armazenados em um lakehouse que um modelo semântico do Direct Lake usa para carregar dados. No entanto, os arquivos Parquet também podem ser armazenados externamente. Os arquivos Parquet externos podem ser referenciados usando um atalho do OneLake, que aponta para um local de armazenamento específico, como Azure Data Lake Storage (ADLS) Gen2, contas de armazenamento do Amazon S3 ou Dataverse. Em quase todos os casos, os mecanismos de computação acessam os arquivos Parquet consultando tabelas Delta. No entanto, normalmente, os modelos semânticos do Direct Lake carregam dados de coluna diretamente de arquivos Parquet otimizados no OneLake usando um processo conhecido como transcodificação.

Controle de versão de dados

As tabelas delta compreendem um ou mais arquivos Parquet. Esses arquivos são acompanhados por um conjunto de arquivos de link baseados em JSON, que rastreiam a ordem e a natureza de cada arquivo Parquet associado a uma tabela Delta.

É importante entender que os arquivos Parquet subjacentes são incrementais por natureza. Daí o nome Delta como uma referência à modificação de dados incremental. Sempre que uma operação de gravação em uma tabela Delta ocorre, como quando os dados são inseridos, atualizados ou excluídos, novos arquivos Parquet são criados que representam as modificações de dados como uma versão. Os arquivos Parquet são, portanto, imutáveis, o que significa que nunca são modificados. Portanto, é possível que os dados sejam duplicados muitas vezes em um conjunto de arquivos Parquet para uma tabela Delta. A estrutura Delta depende de arquivos de link para determinar quais arquivos Parquet físicos são necessários para produzir o resultado correto da consulta.

Considere um exemplo simples de uma tabela Delta que este artigo usa para explicar diferentes operações de modificação de dados. A tabela tem duas colunas e armazena três linhas.

ProductID StockOnHand
Um 1
B 2
C 3

Os dados da tabela Delta são armazenados em um único arquivo Parquet que contém todos os dados e há um único arquivo de link que contém metadados sobre quando os dados foram inseridos (acrescentados).

  • Arquivo Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Arquivo de link 1:
    • Contém o carimbo de data/hora quando Parquet file 1 foi criado e registra que os dados foram acrescentados.

Inserir operações

Considere o que acontece quando ocorre uma operação de inserção: uma nova linha para C de produto com um valor de estoque à mão de 4 é inserida. Essas operações resultam na criação de um novo arquivo Parquet e arquivo de link, portanto, agora há dois arquivos Parquet e dois arquivos de link.

  • Arquivo Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Arquivo Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Arquivo de link 1:
    • Contém o carimbo de data/hora quando Parquet file 1 foi criado e registra que os dados foram acrescentados.
  • Arquivo de link 2:
    • Contém o carimbo de data/hora quando Parquet file 2 foi criado e registra que os dados foram acrescentados.

Neste ponto, uma consulta da tabela Delta retorna o resultado a seguir. Não importa se o resultado é originado de vários arquivos Parquet.

ProductID StockOnHand
Um 1
B 2
C 3
D 4

Cada operação de inserção subsequente cria novos arquivos Parquet e arquivos de link. Isso significa que o número de arquivos Parquet e arquivos de link cresce a cada operação de inserção.

Operações de atualização

Agora considere o que acontece quando ocorre uma operação de atualização: a linha do produto D tem seu valor de estoque alterado para 10. Essas operações resultam na criação de um novo arquivo parquet e arquivo de link, portanto, agora há três arquivos Parquet e três arquivos de link.

  • Arquivo Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Arquivo Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Arquivo Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • Arquivo de link 1:
    • Contém o carimbo de data/hora quando Parquet file 1 foi criado e registra que os dados foram acrescentados.
  • Arquivo de link 2:
    • Contém o carimbo de data/hora quando Parquet file 2 foi criado e registra que os dados foram acrescentados.
  • Arquivo de link 3:
    • Contém o carimbo de data/hora quando Parquet file 3 foi criado e registra que os dados foram atualizados.

Neste ponto, uma consulta da tabela Delta retorna o resultado a seguir.

ProductID StockOnHand
Um 1
B 2
C 10
D 4

Os dados do produto C agora existem em vários arquivos Parquet. No entanto, as consultas à tabela Delta combinam os arquivos de link para determinar quais dados devem ser usados para fornecer o resultado correto.

Operações de exclusão

Agora considere o que acontece quando ocorre uma operação de exclusão: a linha do produto B é excluída. Essa operação resulta em um novo arquivo Parquet e arquivo de link, portanto, agora há quatro arquivos Parquet e quatro arquivos de link.

  • Arquivo Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Arquivo Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • Arquivo Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • Arquivo Parquet 4:
    • ProductID: A, C, D
    • StockOnHand: 1, 10, 4
  • Arquivo de link 1:
    • Contém o carimbo de data/hora quando Parquet file 1 foi criado e registra que os dados foram acrescentados.
  • Arquivo de link 2:
    • Contém o carimbo de data/hora quando Parquet file 2 foi criado e registra que os dados foram acrescentados.
  • Arquivo de link 3:
    • Contém o carimbo de data/hora quando Parquet file 3 foi criado e registra que os dados foram atualizados.
  • Arquivo de link 4:
    • Contém o carimbo de data/hora quando Parquet file 4 foi criado e registra que os dados foram excluídos.

Observe que Parquet file 4 não contém mais dados para o produto B, mas ele contém dados para todas as outras linhas na tabela.

Neste ponto, uma consulta da tabela Delta retorna o resultado a seguir.

ProductID StockOnHand
Um 1
C 10
D 4

Observação

Este exemplo é simples porque envolve uma tabela pequena, apenas algumas operações e apenas pequenas modificações. Tabelas grandes que experimentam muitas operações de gravação e que contêm muitas linhas de dados gerarão mais de um arquivo Parquet por versão.

Importante

Dependendo de como você define as tabelas Delta e a frequência das operações de modificação de dados, isso pode resultar em muitos arquivos Parquet. Lembre-se de que cada licença de capacidade do Fabric tem guardrails. Se o número de arquivos Parquet para uma tabela Delta exceder o limite de sua SKU, as consultas retornarão ao DirectQuery, o que pode resultar em um desempenho de consulta mais lento.

Para gerenciar o número de arquivos Parquet, consulte manutenção da tabela Delta posteriormente neste artigo.

Viagem no tempo do Delta

Os arquivos de link habilitam a consulta de dados a partir de um ponto anterior no tempo. Essa funcionalidade é conhecida como viagem no tempo Delta. O ponto anterior no tempo pode ser um carimbo de data/hora ou uma versão.

Considere os exemplos de consulta a seguir.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

Dica

Você também pode consultar uma tabela usando a sintaxe abreviada @ para especificar o carimbo de data/hora ou a versão como parte do nome da tabela. O carimbo de data/hora precisa estar no formato yyyyMMddHHmmssSSS. Você pode especificar uma versão após @, incluindo v no início da versão.

Aqui estão os exemplos de consulta anteriores reescritos com sintaxe abreviada.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Importante

As versões de tabela acessíveis com viagem no tempo são determinadas por uma combinação do limite de retenção para arquivos de log de transações e a frequência e a retenção especificada para operações VACUUM (descrita posteriormente na seção de manutenção da tabela Delta). Se você executar o VACUUM diariamente com os valores padrão, sete dias de dados estarão disponíveis para viagem no tempo.

Enquadramento

O Enquadramento é uma operação do Direct Lake que define a versão de uma tabela Delta que deve ser usada para carregar dados em uma coluna de modelo semântico. Igualmente importante, a versão também determina o que deve ser excluído quando os dados são carregados.

Uma operação de enquadramento carimba o carimbo de data/versão de cada tabela Delta nas tabelas de modelo semântico. Nesse ponto, quando o modelo semântico precisa carregar dados de uma tabela Delta, o carimbo de data/hora/versão associado à operação de enquadramento mais recente é usado para determinar quais dados carregar. Todas as modificações de dados subsequentes que ocorrem para a tabela Delta desde a operação de enquadramento mais recente são ignoradas (até a próxima operação de enquadramento).

Importante

Como um modelo semântico emoldurado faz referência a uma determinada versão da tabela Delta, a origem deve garantir que ela mantenha a versão da tabela Delta até que o enquadramento de uma nova versão seja concluído. Caso contrário, os usuários encontrarão erros quando os arquivos da tabela Delta precisarem ser acessados pelo modelo e tiverem sido aspirados ou excluídos pela carga de trabalho do produtor.

Para obter mais informações sobre o enquadramento, consulte visão geral do Direct Lake.

Particionamento de tabela

As tabelas delta podem ser particionadas para que um subconjunto de linhas seja armazenado em conjunto em um único conjunto de arquivos Parquet. As partições podem acelerar as consultas, bem como as operações de gravação.

Considere uma tabela Delta que tenha um bilhão de linhas de dados de vendas por um período de dois anos. Embora seja possível armazenar todos os dados em um único conjunto de arquivos Parquet, para esse volume de dados não é ideal para operações de leitura e gravação. Em vez disso, o desempenho pode ser melhorado espalhando o bilhão de linhas de dados em várias séries de arquivos Parquet.

Uma chave de partição deve ser definida ao configurar o particionamento de tabela. A chave de partição determina quais linhas armazenar em qual série. Para tabelas Delta, a chave de partição pode ser definida com base nos valores distintos de uma coluna (ou colunas) especificada, como uma coluna mês/ano de uma tabela de data. Nesse caso, dois anos de dados seriam distribuídos entre 24 partições (2 anos x 12 meses).

Os mecanismos de computação de malha não estão cientes das partições de tabela. À medida que inserem novos valores de chave de partição, novas partições são criadas automaticamente. No OneLake, você encontrará uma subpasta para cada valor de chave de partição exclusivo e cada subpasta armazena seu próprio conjunto de arquivos Parquet e arquivos de link. Pelo menos um arquivo Parquet e um arquivo de link devem existir, mas o número real de arquivos em cada subpasta pode variar. À medida que as operações de modificação de dados ocorrem, cada partição mantém seu próprio conjunto de arquivos Parquet e arquivos de link para acompanhar o que retornar para um determinado carimbo de data/hora ou versão.

Se uma consulta de uma tabela Delta particionada for filtrada apenas para os três meses mais recentes de dados de vendas, o subconjunto de arquivos Parquet e arquivos de link que precisam ser acessados poderá ser identificado rapidamente. Em seguida, isso permite ignorar muitos arquivos Parquet completamente, resultando em um melhor desempenho de leitura.

No entanto, as consultas que não filtram na chave de partição podem nem sempre ter um desempenho melhor. Esse pode ser o caso quando uma tabela Delta armazena todos os dados em um único conjunto grande de arquivos Parquet e há fragmentação de grupo de arquivos ou linhas. Embora seja possível paralelizar a recuperação de dados de vários arquivos Parquet em vários nós de cluster, muitos arquivos parquet pequenos podem afetar negativamente a E/S do arquivo e, portanto, o desempenho da consulta. Por esse motivo, é melhor evitar o particionamento de tabelas Delta na maioria dos casos, a menos que as operações de gravação ou extração, transformação e carregamento (ETL) se beneficiem claramente dela.

Os benefícios de particionamento inserem, atualizam e excluem operações também, pois a atividade de arquivo só ocorre em subpastas que correspondem à chave de partição das linhas modificadas ou excluídas. Por exemplo, se um lote de dados for inserido em uma tabela Delta particionada, os dados serão avaliados para determinar quais valores de chave de partição existem no lote. Em seguida, os dados são direcionados apenas para as pastas relevantes para as partições.

Entender como as tabelas Delta usam partições pode ajudá-lo a criar cenários ETL ideais que reduzem as operações de gravação que precisam ocorrer ao atualizar tabelas Delta grandes. O desempenho de gravação melhora reduzindo o número e o tamanho de todos os novos arquivos Parquet que devem ser criados. Para uma tabela Delta grande particionada por mês/ano, conforme descrito no exemplo anterior, novos dados adicionam apenas novos arquivos Parquet à partição mais recente. As subpastas dos meses anteriores do calendário permanecem intocadas. Se quaisquer dados de meses de calendário anteriores precisarem ser modificados, somente as pastas de partição relevantes receberão novos arquivos de partição e link.

Importante

Se a principal finalidade de uma tabela Delta for servir como uma fonte de dados para modelos semânticos (e, em segundo lugar, outras cargas de trabalho de consulta), geralmente é melhor evitar o particionamento em preferência para otimizar a carga de colunas na memória.

Para modelos semânticos do Direct Lake ou o ponto de extremidade de análise de SQL, a melhor maneira de otimizar partições de tabela Delta é permitir que o Fabric gerencie automaticamente os arquivos Parquet para cada versão de uma tabela Delta. Deixar o gerenciamento para o Fabric deve resultar em alto desempenho de consulta por meio da paralelização, no entanto, pode não fornecer necessariamente o melhor desempenho de gravação.

Se você precisar otimizar para operações de gravação, considere usar partições para otimizar operações de gravação em tabelas Delta com base na chave de partição. No entanto, lembre-se de que o particionamento de uma tabela Delta pode afetar negativamente o desempenho de leitura. Por esse motivo, recomendamos que você teste o desempenho de leitura e gravação com cuidado, talvez criando várias cópias da mesma tabela Delta com configurações diferentes para comparar intervalos.

Aviso

Se você particionar em uma coluna de alta cardinalidade, isso poderá resultar em um número excessivo de arquivos Parquet. Lembre-se de que cada licença de capacidade do Fabric tem guardrails. Se o número de arquivos Parquet para uma tabela Delta exceder o limite de sua SKU, as consultas retornarão ao DirectQuery, o que pode resultar em um desempenho de consulta mais lento.

Arquivos Parquet

O armazenamento subjacente para uma tabela Delta é um ou mais arquivos Parquet. O formato de arquivo Parquet geralmente é usado para aplicativos write-once, read-many. Novos arquivos Parquet são criados sempre que os dados em uma tabela Delta são modificados, seja por uma operação de inserção, atualização ou exclusão.

Observação

Você pode acessar arquivos Parquet associados a tabelas Delta usando uma ferramenta, como o Explorador de Arquivos do OneLake. Os arquivos podem ser baixados, copiados ou movidos para outros destinos tão facilmente quanto mover outros arquivos. No entanto, é a combinação de arquivos Parquet e os arquivos de link baseados em JSON que permitem que os mecanismos de computação emitam consultas nos arquivos como uma tabela Delta.

Formato de arquivo Parquet

O formato interno de um arquivo Parquet difere de outros formatos comuns de armazenamento de dados, como CSV, TSV, XMLA e JSON. Esses formatos organizam dados por linhas, enquanto Parquet organiza dadospor colunas . Além disso, o formato de arquivo Parquet difere desses formatos porque organiza linhas de dados em um ou mais grupos de linhas.

A estrutura de dados interna de um modelo semântico do Power BI é baseada em coluna, o que significa que os arquivos Parquet compartilham muito em comum com o Power BI. Essa semelhança significa que um modelo semântico do Direct Lake pode carregar dados com eficiência dos arquivos Parquet diretamente na memória. Na verdade, volumes muito grandes de dados podem ser carregados em segundos. Contraste essa funcionalidade com a atualização de um modelo semântico de importação que deve recuperar blocos ou dados de origem, em seguida, processar, codificar, armazenar e, em seguida, carregá-lo na memória. Uma operação de atualização semântica de importação de modelo também pode consumir quantidades significativas de computação (memória e CPU) e levar um tempo considerável para ser concluída. No entanto, com tabelas Delta, a maior parte do esforço para preparar os dados adequados para o carregamento direto em um modelo semântico ocorre quando o arquivo Parquet é gerado.

Como os arquivos Parquet armazenam dados

Considere o seguinte conjunto de dados de exemplo.

Data ProductID StockOnHand
2024-09-16 Um 10
2024-09-16 B 11
2024-09-17 Um 13
…

Quando armazenado no formato de arquivo Parquet, conceitualmente, esse conjunto de dados pode ser semelhante ao texto a seguir.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

Os dados são compactados substituindo chaves de dicionário por valores comuns e aplicando RLE (codificação de comprimento de execução). O RLE se esforça para compactar uma série dos mesmos valores em uma representação menor. No exemplo a seguir, um mapeamento de dicionário de chaves numéricas para valores é criado no cabeçalho e os valores de chave menores são usados no lugar dos valores de dados.

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Quando o modelo semântico do Direct Lake precisa de dados para calcular a soma da coluna StockOnHand agrupada por ProductID, somente o dicionário e os dados associados às duas colunas são necessários. Em arquivos grandes que contêm muitas colunas, partes substanciais do arquivo Parquet podem ser ignoradas para ajudar a acelerar o processo de leitura.

Observação

O conteúdo de um arquivo Parquet não é legível por humanos e, portanto, não é adequado para abrir em um editor de texto. No entanto, há muitas ferramentas de software livre disponíveis que podem abrir e revelar o conteúdo de um arquivo Parquet. Essas ferramentas também podem permitir que você inspecione metadados, como o número de linhas e grupos de linhas contidos em um arquivo.

V-Order

O Fabric dá suporte a uma otimização adicional chamada V-Order. V-Order é uma otimização de tempo de gravação para o formato de arquivo Parquet. Depois que a Ordem V é aplicada, ela resulta em um arquivo menor e, portanto, mais rápido para leitura. Essa otimização é especialmente relevante para um modelo semântico do Direct Lake porque prepara os dados para carregamento rápido na memória e, portanto, faz menos demandas sobre os recursos de capacidade. Isso também resulta em um desempenho de consulta mais rápido porque menos memória precisa ser verificada.

Tabelas delta criadas e carregadas por itens do Fabric, como pipelines de dados, fluxos de dados e notebooks, aplicam automaticamente a Ordem V. No entanto, os arquivos Parquet carregados em um lakehouse do Fabric ou referenciados por um atalho, podem não ter essa otimização aplicada. Embora os arquivos Parquet não otimizados ainda possam ser lidos, o desempenho de leitura provavelmente não será tão rápido quanto um arquivo Parquet equivalente que teve a ordem V aplicada.

Observação

Os arquivos Parquet que têm a ordem V aplicada ainda estão em conformidade com o formato de arquivo Parquet de software livre. Portanto, eles podem ser lidos por ferramentas que não são do Fabric.

Para obter mais informações, consulte Otimização de tabela do Delta Lake e V-Order.

Otimização de tabela delta

Esta seção descreve vários tópicos para otimizar tabelas Delta para modelos semânticos.

Volume de dados

Embora as tabelas Delta possam crescer para armazenar volumes extremamente grandes de dados, os guardrails de capacidade do Fabric impõem limites a modelos semânticos que os consultam. Quando esses limites forem excedidos, as consultas retornarão ao DirectQuery, o que pode resultar em um desempenho de consulta mais lento.

Portanto, considere limitar a contagem de linhas de uma tabela de fatos grande aumentando sua granularidade (armazenar dados resumidos), reduzindo a dimensionalidade ou armazenando menos histórico.

Além disso, verifique se a Ordem V é aplicada porque resulta em um arquivo menor e, portanto, mais rápido para leitura.

Tipo de dados da coluna

Esforce-se para reduzir a cardinalidade (o número de valores exclusivos) em cada coluna de cada tabela Delta. Isso ocorre porque todas as colunas são compactadas e armazenadas usando codificação de hash. A codificação de hash requer otimização V-Order para atribuir um identificador numérico a cada valor exclusivo contido na coluna. É o identificador numérico, então, que é armazenado, exigindo uma pesquisa de hash durante o armazenamento e a consulta.

Quando você usa tipos de dados numéricos aproximados (como float e real), considere arredondar valores e usar uma precisão mais baixa.

Colunas desnecessárias

Assim como acontece com qualquer tabela de dados, as tabelas Delta devem armazenar apenas as colunas necessárias. No contexto deste artigo, isso significa exigido pelo modelo semântico, embora possa haver outras cargas de trabalho analíticas que consultam as tabelas Delta.

As tabelas delta devem incluir colunas exigidas pelo modelo semântico para filtragem, agrupamento, classificação e resumo, além de colunas que dão suporte a relações de modelo. Embora as colunas desnecessárias não afetem o desempenho da consulta semântica do modelo (porque elas não serão carregadas na memória), elas resultam em um tamanho de armazenamento maior e, portanto, exigem mais recursos de computação para carregar e manter.

Como os modelos semânticos do Direct Lake não dão suporte a colunas calculadas, você deve materializar essas colunas nas tabelas Delta. Observe que essa abordagem de design é um antipadrão para modelos semânticos de Importação e DirectQuery. Por exemplo, se você tiver colunas FirstName e LastName e precisar de uma coluna FullName, materialize os valores dessa coluna ao inserir linhas na tabela Delta.

Considere que alguns resumos de modelo semântico podem depender de mais de uma coluna. Por exemplo, para calcular as vendas, a medida no modelo soma o produto de duas colunas: Quantity e Price. Se nenhuma dessas colunas for usada de forma independente, seria mais eficiente materializar o cálculo de vendas como uma única coluna do que armazenar seus valores de componente em colunas separadas.

Tamanho do grupo de linhas

Internamente, um arquivo Parquet organiza linhas de dados em vários grupos de linhas em cada arquivo. Por exemplo, um arquivo Parquet que contém 30.000 linhas pode particioná-las em três grupos de linhas, cada uma com 10.000 linhas.

O número de linhas em um grupo de linhas influencia a rapidez com que o Direct Lake pode ler os dados. Um número maior de grupos de linhas com menos linhas provavelmente afetará negativamente o carregamento de dados de coluna em um modelo semântico devido ao excesso de E/S.

Geralmente, não recomendamos que você altere o tamanho do grupo de linhas padrão. No entanto, você pode considerar alterar o tamanho do grupo de linhas para tabelas Delta grandes. Certifique-se de testar o desempenho de leitura e gravação com cuidado, talvez criando várias cópias das mesmas tabelas Delta com configurações diferentes para comparar os intervalos.

Importante

Lembre-se de que cada licença de capacidade do Fabric tem guardrails. Se o número de grupos de linhas de uma tabela Delta exceder o limite de sua SKU, as consultas retornarão ao DirectQuery, o que pode resultar em um desempenho de consulta mais lento.

Manutenção de tabela Delta

Com o tempo, conforme as operações de gravação ocorrem, as versões da tabela Delta se acumulam. Eventualmente, você pode chegar a um ponto em que um impacto negativo no desempenho de leitura se torna perceptível. Pior, se o número de arquivos Parquet por tabela ou grupos de linhas por tabela ou linhas por tabela exceder os guardrails para sua capacidade, as consultas retornarão ao DirectQuery, o que pode resultar em um desempenho de consulta mais lento. Portanto, é importante que você mantenha tabelas Delta regularmente.

OPTIMIZE

Você pode usar OPTIMIZE para otimizar uma tabela Delta para unir arquivos menores em arquivos maiores. Você também pode definir a cláusula WHERE para direcionar apenas um subconjunto filtrado de linhas que correspondem a um determinado predicado de partição. Há suporte apenas para filtros que envolvem chaves de partição. O comando OPTIMIZE também pode aplicar v-order para compactar e reescrever os arquivos Parquet.

Recomendamos que você execute esse comando em tabelas Delta grandes e frequentemente atualizadas regularmente, talvez todos os dias, quando o processo de ETL for concluído. Balancee a compensação entre melhor desempenho de consulta e o custo de uso de recursos necessário para otimizar a tabela.

VACUUM

Você pode usar VACUUM para remover arquivos que não são mais referenciados e/ou que são mais antigos do que um limite de retenção definido. Tome cuidado para definir um período de retenção apropriado, caso contrário, você poderá perder a capacidade de viagem no tempo de volta para uma versão mais antiga do que o quadro carimbado em tabelas de modelo semântico.

Importante

Como um modelo semântico emoldurado faz referência a uma determinada versão da tabela Delta, a origem deve garantir que ela mantenha a versão da tabela Delta até que o enquadramento de uma nova versão seja concluído. Caso contrário, os usuários encontrarão erros quando os arquivos da tabela Delta precisarem ser acessados pelo modelo e tiverem sido aspirados ou excluídos pela carga de trabalho do produtor.

REORG TABLE

Você pode usar REORG TABLE para reorganizar uma tabela Delta reescrevendo arquivos para limpar dados excluídos suavemente, como quando você descarta uma coluna usando ALTER TABLE DROP COLUMN.

Automatizar a manutenção da tabela

Para automatizar as operações de manutenção de tabela, você pode usar a API lakehouse. Para obter mais informações, consulte Gerenciar o Lakehouse com a API REST do Microsoft Fabric.

Dica

Você também pode usar o recurso de manutenção tabela lakehouse no portal do Fabric para simplificar o gerenciamento de suas tabelas Delta.

Conteúdo relacionado