Partilhar via

Compreender o armazenamento para modelos semânticos Direct Lake

  • Artigo

Este artigo apresenta os conceitos de armazenamento Direct Lake. Este documento descreve tabelas Delta e ficheiros 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

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

Observação

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 os dados em arquivos Parquet, que normalmente são armazenados num lakehouse que um modelo semântico Direct Lake utiliza para importar dados. No entanto, os arquivos Parquet também podem ser armazenados externamente. Os arquivos externos do Parquet podem ser referenciados usando um atalho 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 do Parquet consultando tabelas Delta. No entanto, os modelos semânticos Direct Lake normalmente carregam dados de coluna diretamente a partir de ficheiros Parquet otimizados no OneLake usando um processo conhecido como transcoding.

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 várias vezes num 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.

ID do Produto 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 (anexados).

  • 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 regista que 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 stock disponível de 4 é inserida. 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:
    • ProductID: A, B, C
    • StockOnHand : 1, 2, 3
  • Arquivo Parquet 2:
    • ProductID: D
    • StockOnHand : 4
  • Arquivo de link 1:
    • Contém a marca temporal de quando Parquet file 1 foi criado e regista que os dados foram adicionados.
  • Link do arquivo 2:
    • Contém o carimbo de data/hora quando Parquet file 2 foi criado e regista que os dados foram adicionados.

Neste ponto, uma consulta da tabela Delta retorna o seguinte resultado. Não importa que o resultado seja originado de vários ficheiros Parquet.

ID do Produto StockOnHand
A 1
B 2
C 3
D 4

Cada operação de inserção subsequente cria novos ficheiros Parquet e ficheiros de ligação. 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 para o produto D tem seu valor de estoque em mãos 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:
    • 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 a marca temporal de quando Parquet file 1 foi criado e regista que os dados foram acrescentados.
  • Link de arquivo 2:
    • Contém a marca temporal da criação de Parquet file 2 e regista que os dados foram acrescentados.
  • Arquivo de link 3:
    • Contém o carimbo de data/hora quando Parquet file 3 foi criado e regista que os dados foram atualizados.

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

ID do Produto StockOnHand
Um 1
B 2
C 10
D 4

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

Excluir operações

Agora, considere o que acontece quando ocorre uma operação de eliminação: a linha para o produto B é eliminada. 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 de Produto: 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 regista que os dados foram acrescentados.
  • Ficheiro de ligação 2:
    • Contém o timestamp de quando Parquet file 2 foi criado e regista 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 regista que os dados foram eliminados.

Observe que Parquet file 4 já não contém 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.

ID do Produto StockOnHand
A 1
C 10
D 4

Observação

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. Lembre-se de que cada licença de capacidade do Fabric tem limitações. 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. Esta 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;

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 deve estar no formato yyyyMMddHHmmssSSS. Você pode especificar uma versão após @ prefixando um v à 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 em função da viagem no tempo são determinadas por uma combinação do limite de retenção dos arquivos de log de transações e a frequência e a retenção especificada das operações VACUUM, como descrito 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

Enquadramento é uma operação Direct Lake que define a versão de uma tabela Delta que deve ser usada para carregar dados numa coluna de um 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 aplica o carimbo de data/hora/versão de cada tabela Delta nas tabelas do modelo semântico. A partir deste ponto, quando o modelo semântico precisa carregar dados de uma tabela Delta, a hora/versão associada à operação de enquadramento mais recente é usada para determinar os dados a 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 utilizadores encontrarão erros quando os ficheiros da tabela Delta precisarem ser acedidos pelo modelo e já tenham sido limpos ou eliminados pela carga de trabalho do produtor.

Para obter mais informações sobre o enquadramento, consulte a 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 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 num único conjunto de arquivos Parquet, para esse volume de dados não é o ideal para operações de leitura e gravação. Em vez disso, o desempenho pode ser melhorado distribuindo o biliã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 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 o seu próprio conjunto de ficheiros Parquet e ficheiros de link para manter o controlo do que retornar para um determinado timestamp 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 ficheiros de referência que precisam ser acedidos 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 períodos anteriores do calendário 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 endpoint de análise SQL , a melhor maneira de otimizar as partições das tabelas Delta é permitir que o Fabric gerencie automaticamente os arquivos Parquet para cada versão de uma tabela Delta. Deixar a gestão 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 escrita.

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.

Advertência

Se particionares com base numa coluna de alta cardinalidade, isso pode resultar num número excessivo de ficheiros Parquet. Esteja ciente de que cada licença de capacidade do Fabric tem limitações. 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.

Arquivos Parquet

O armazenamento subjacente para uma tabela Delta é um ou mais arquivos Parquet. O formato de arquivo Parquet é geralmente usado para aplicativos de de gravação única e 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.

Observação

Você pode acessar arquivos Parquet associados a tabelas Delta usando uma ferramenta, como 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 ficheiros Parquet e dos ficheiros de ligação baseados em JSON que permitem que motores de computação façam consultas aos ficheiros como se fossem 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.

Data ID do Produto StockOnHand
16-09-2024 Um 10
16-09-2024 B 11
17-09-2024 Um 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 soma da coluna StockOnHand agrupada por ProductID, apenas 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, 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-Order

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 mais rápido nas consultas porque menos memória precisa ser lida.

As tabelas Delta criadas e carregadas por itens do Fabric, como pipelines de dados , fluxos de dados e notebooks , aplicam automaticamente o V-Order. No entanto, os ficheiros Parquet carregados num armazém de dados 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.

Observação

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 a 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

Embora as tabelas Delta possam crescer para armazenar volumes extremamente grandes de dados, as limitações de capacidade do Fabric 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, pois 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 ocorre porque todas as colunas são compactadas e armazenadas pela 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.

Quando você usa tipos de dados numéricos aproximados (como flutuante e real ), considere valores de arredondamento e usando 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 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 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

Esteja ciente de que cada licença de capacidade de Fabric tem limites. Se o número de grupos de linhas de 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 tabela 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.

OTIMIZAR

Você pode usar OTIMIZE para otimizar uma tabela Delta para aglutinar 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. Apenas filtros que envolvem chaves de partição são suportados. 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 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.

VÁCUO

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. Toma cuidado para definir um período de retenção apropriado, caso contrário, podes ficar sem a capacidade de viajar no tempo e regressar a uma versão anterior ao quadro registado nas tabelas do 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 ficheiros para limpar dados excluídos logicamente, como quando elimina 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 Manage the Lakehouse with Microsoft Fabric REST API.

Dica

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

Conteúdo relacionado