Partilhar via

Compreender o armazenamento para modelos semânticos Direct Lake

  • Artigo

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

Tabelas delta

Existem tabelas delta 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, lakehouse e warehouse. Você pode consultar tabelas Delta usando Data Analysis Expressions (DAX), Multidimensional Expressions (MDX), T-SQL (Transact-SQL), Spark SQL e até mesmo Python.

Nota

Delta — ou Delta Lake — é um formato de armazenamento de código aberto. 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 uma casa de lago que um modelo semântico Direct Lake usa para carregar dados. No entanto, os arquivos Parquet também podem ser armazenados externamente. Os arquivos externos do Parquet podem ser referenciados usando um atalho do OneLake, que aponta para um local de armazenamento específico, como o 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 do Parquet consultando tabelas Delta. No entanto, normalmente os modelos semânticos 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 incremental de dados. Sempre que ocorre uma operação de gravação em uma tabela Delta, como quando os dados são inseridos, atualizados ou excluídos, novos arquivos do 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 físicos do Parquet são necessários para produzir o resultado de consulta correto.

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
A 1
N 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 (anexados).

  • Arquivo Parquet 1:
    • ID do produto: 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 o produto C com um valor de estoque em mãos é inserida 4 . Esta operação resulta na criação de um novo arquivo Parquet e arquivo de link, então agora há dois arquivos Parquet e dois arquivos de link.

  • Arquivo Parquet 1:
    • ID do produto: A, B, C
    • StockOnHand: 1, 2, 3
  • Arquivo Parquet 2:
    • ID do produto: 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 seguinte resultado. Não importa que o resultado seja originado de vários arquivos Parquet.

ProductID StockOnHand
A 1
N 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 disponível alterado para 10. Esta operação resulta na criação de um novo arquivo Parquet e arquivo de link, então agora existem três arquivos Parquet e três arquivos de link.

  • Arquivo Parquet 1:
    • ID do produto: A, B, C
    • StockOnHand: 1, 2, 3
  • Arquivo Parquet 2:
    • ID do produto: D
    • StockOnHand: 4
  • Arquivo Parquet 3:
    • ID do produto: 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 seguinte resultado.

ProductID StockOnHand
A 1
N 2
C 10
D 4

Os dados para o 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 eliminação

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

  • Arquivo Parquet 1:
    • ID do produto: A, B, C
    • StockOnHand: 1, 2, 3
  • Arquivo Parquet 2:
    • ID do produto: D
    • StockOnHand: 4
  • Arquivo Parquet 3:
    • ID do produto: C
    • StockOnHand: 10
  • Arquivo Parquet 4:
    • ID do produto: 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 contém dados para todas as outras linhas da tabela.

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

ProductID StockOnHand
A 1
C 10
D 4

Nota

Este exemplo é simples porque envolve uma pequena tabela, 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 suas tabelas Delta e da frequência das operações de modificação de dados, isso pode resultar em muitos arquivos Parquet. Esteja ciente de que cada licença de capacidade de malha tem guarda-corpos. Se o número de arquivos Parquet para uma tabela Delta exceder o limite para 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 mais adiante neste artigo.

Viagem no tempo Delta

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

Considere os seguintes exemplos de consulta.

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

Gorjeta

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 deve estar no yyyyMMddHHmmssSSS formato. Você pode especificar uma versão depois @ antecipando a v para a versão.

Aqui estão os exemplos de consulta anteriores reescritos com sintaxe taquigráfica.

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 retenção especificada para operações VACUUM (descritas mais adiante 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 viagens no tempo.

Enquadramento

O enquadramento é uma operação 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/hora/versão de cada tabela Delta nas tabelas de modelo semântico. A partir deste 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. Quaisquer modificações de dados subsequentes que ocorram para a tabela Delta desde a última operação de enquadramento são ignoradas (até a próxima operação de enquadramento).

Importante

Como um modelo semântico enquadrado faz referência a uma versão específica da tabela Delta, a fonte deve garantir que ela mantenha essa 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 de 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 enquadramento, consulte Visão geral do Direct Lake.

Criação de partições 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 consultas, bem como operações de gravação.

Considere uma tabela Delta que tenha um bilhão de linhas de dados de vendas para 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 os bilhões de linhas de dados em várias séries de arquivos Parquet.

Uma chave de partição deve ser definida ao configurar o particionamento da 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 de mês/ano de uma tabela de data. Neste caso, dois anos de dados seriam distribuídos em 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 manter o controle do 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 pode ser rapidamente identificado. Isso permite pular muitos arquivos do Parquet, resultando em um melhor desempenho de leitura.

No entanto, as consultas que não filtram a chave de partição nem sempre têm um desempenho melhor. Esse pode ser o caso quando uma tabela Delta armazena todos os dados em um único grande conjunto de arquivos Parquet e há fragmentação de arquivos ou grupos de 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 de arquivos e, portanto, o desempenho da consulta. Por esse motivo, é melhor evitar o particionamento de tabelas Delta na maioria dos casos, a menos que operações de gravação ou processos de extração, transformação e carregamento (ETL) se beneficiem claramente disso.

O particionamento também beneficia as operações de inserção, atualização e exclusão, porque a atividade do arquivo só ocorre em subpastas correspondentes à 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. Os dados são então direcionados apenas para as pastas relevantes para as partições.

Compreender como as tabelas Delta usam partições pode ajudá-lo a projetar cenários de 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 do Parquet que devem ser criados. Para uma grande tabela Delta particionada por mês/ano, conforme descrito no exemplo anterior, novos dados apenas adicionam novos arquivos Parquet à partição mais recente. As subpastas dos meses do calendário anterior permanecem inalteradas. Se algum dado de meses anteriores precisar ser modificado, somente as pastas de partição relevantes receberão novos arquivos de partição e link.

Importante

Se o objetivo principal de uma tabela Delta é servir como uma fonte de dados para modelos semânticos (e, secundariamente, outras cargas de trabalho de consulta), geralmente é melhor evitar o particionamento em vez de otimizar a carga de colunas na memória.

Para modelos semânticos Direct Lake ou o ponto de extremidade de análise 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 de 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 o uso de partições para otimizar as operações de gravação em tabelas Delta com base na chave de partição. No entanto, esteja ciente de que o particionamento excessivo 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 cuidadosamente, talvez criando várias cópias da mesma tabela Delta com configurações diferentes para comparar temporizações.

Aviso

Se você particionar em uma coluna de cardinalidade alta, isso pode resultar em um número excessivo de arquivos Parquet. Lembre-se de que todas as licenças de capacidade de malha têm guarda-corpos. Se o número de arquivos Parquet para uma tabela Delta exceder o limite para sua SKU, as consultas retornarão ao DirectQuery, o que pode resultar em um desempenho de consulta mais lento.

Ficheiros Parquet

O armazenamento subjacente para uma tabela Delta é um ou mais arquivos Parquet. O formato de arquivo Parquet é geralmente usado para aplicativos de gravação uma vez, leitura múltipla . Novos arquivos do 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.

Nota

Você pode acessar arquivos Parquet associados a tabelas Delta usando uma ferramenta, como o explorador de arquivos OneLake. Os arquivos podem ser baixados, copiados ou movidos para outros destinos tão facilmente quanto mover quaisquer 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 os dados por linhas, enquanto o Parquet organiza os dados por 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 colunas, o que significa que os arquivos do Parquet compartilham muito em comum com o Power BI. Essa semelhança significa que um modelo semântico Direct Lake pode carregar eficientemente dados dos arquivos Parquet diretamente na memória. Na verdade, grandes volumes de dados podem ser carregados em segundos. Compare esse recurso com a atualização de um modelo semântico Import, que deve recuperar blocos ou dados de origem e, em seguida, processá-los, codificá-los, armazená-los e carregá-los na memória. Uma operação de atualização do modelo semântico de importação também pode consumir quantidades significativas de computação (memória e CPU) e levar tempo considerável para ser concluída. No entanto, com tabelas Delta, a maior parte do esforço para preparar os dados adequados para carregamento direto em um modelo semântico ocorre quando o arquivo Parquet é gerado.

Como os arquivos Parquet armazenam dados

Considere o seguinte exemplo de conjunto de dados.

Date ProductID StockOnHand
2024-09-16 A 10
2024-09-16 N 11
2024-09-17 A 13
…

Quando armazenado no formato de arquivo Parquet, conceitualmente, esse conjunto de dados pode se parecer com o 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 codificação de comprimento de execução (RLE). RLE se esforça para comprimir uma série de 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 Direct Lake precisa de dados para calcular a StockOnHand soma da coluna 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.

Nota

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, existem muitas ferramentas de código aberto 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-Ordem

O Fabric suporta uma otimização adicional chamada V-Order. V-Order é uma otimização de tempo de gravação para o formato de arquivo Parquet. Uma vez que V-Order é aplicado, resulta em um arquivo menor e, portanto, mais rápido de ler. Essa otimização é especialmente relevante para um modelo semântico Direct Lake porque prepara os dados para carregamento rápido na memória e, portanto, exige menos recursos de capacidade. Isso também resulta em um desempenho de consulta mais rápido porque menos memória precisa ser verificada.

As tabelas delta criadas e carregadas por itens de malha, como pipelines de dados, fluxos de dados e blocos de anotações, aplicam automaticamente o V-Order. No entanto, os arquivos Parquet carregados em uma casa de lago Fabric, ou que são 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 tenha aplicado o V-Order.

Nota

Os arquivos Parquet que têm V-Order aplicado ainda estão em conformidade com o formato de arquivo Parquet de código aberto. Portanto, eles podem ser lidos por ferramentas que não são de malha.

Para obter mais informações, consulte Otimização da tabela 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

Enquanto as tabelas Delta podem crescer para armazenar volumes extremamente grandes de dados, as proteções de capacidade de malha impõem limites aos modelos semânticos que as 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, certifique-se de que V-Order seja aplicado porque resulta em um arquivo menor e, portanto, mais rápido de ler.

Tipo de dados de coluna

Esforce-se para reduzir a cardinalidade (o número de valores exclusivos) em cada coluna de cada tabela Delta. Isso porque todas as colunas são compactadas e armazenadas usando codificação de hash. A codificação de hash requer otimização de ordem V 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.

Ao usar tipos de dados numéricos aproximados (como float e real), considere arredondar valores e usar uma precisão menor.

Colunas desnecessárias

Como em 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 filtrar, agrupar, classificar e resumir, além de colunas que suportam relações de modelo. Embora as colunas desnecessárias não afetem o desempenho da consulta do modelo semântico (porque 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 Direct Lake não suportam colunas calculadas, você deve materializar essas colunas nas tabelas Delta. Observe que essa abordagem de design é um antipadrão para modelos semânticos Import e DirectQuery. Por exemplo, se você tiver FirstName e LastName colunas, e precisar de uma FullName coluna, materialize os valores para esta coluna ao inserir linhas na tabela Delta.

Considere que alguns resumos de modelos semânticos 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 independentemente, seria mais eficiente materializar o cálculo de vendas como uma única coluna do que armazenar os valores de seus componentes em colunas separadas.

Tamanho do grupo de linhas

Internamente, um arquivo Parquet organiza linhas de dados em vários grupos de linhas dentro de cada arquivo. Por exemplo, um arquivo Parquet que contém 30.000 linhas pode dividi-las em três grupos de linhas, cada um 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 padrão do grupo de linhas. 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 cuidadosamente, talvez criando várias cópias das mesmas tabelas Delta com configurações diferentes para comparar temporizações.

Importante

Lembre-se de que todas as licenças de capacidade de malha têm guarda-corpos. Se o número de grupos de linhas para uma tabela Delta exceder o limite para sua SKU, as consultas retornarão ao DirectQuery, o que pode resultar em um desempenho de consulta mais lento.

Manutenção de mesa delta

Com o tempo, à medida que 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 percetível. Pior, se o número de arquivos do 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 as tabelas Delta regularmente.

OPTIMIZE

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

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

VACUUM

Você pode usar o 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ê pode perder a capacidade de viajar no tempo de volta para uma versão mais antiga do que o quadro estampado em tabelas de modelo semântico.

Importante

Como um modelo semântico enquadrado faz referência a uma versão específica da tabela Delta, a fonte deve garantir que ela mantenha essa 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 de tabela Delta precisarem ser acessados pelo modelo e tiverem sido aspirados ou excluídos pela carga de trabalho do produtor.

TABELA DE REORGANIZAÇÃO

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

Automatize a manutenção de tabelas

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

Gorjeta

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

Conteúdos relacionados