Todos os produtos
Search
Central de documentação

MaxCompute:Delta Table

Última atualização: Aug 21, 2026

A Delta Table é um formato de tabela de alto desempenho no MaxCompute, projetado para conjuntos de dados analíticos em grande escala. Existem dois tipos: a Append Delta Table, para tabelas sem chave primária, e a PK Delta Table, para tabelas com chave primária. Este tópico descreve os recursos básicos e as operações das Delta Tables.

Visão geral

A Delta Table é um formato de tabela de alto desempenho no Alibaba Cloud MaxCompute. Ela oferece suporte a recursos como transações ACID (atomicidade, consistência, isolamento e durabilidade), consultas incrementais, time travel, bucketing dinâmico de cluster, atualizações de dados em tempo real e evolução de schema. Com as capacidades nativas de data lakehouse e computação quase em tempo real do MaxCompute, use SQL padrão para criar, atualizar e consultar Delta Tables. Não é necessário gerenciar o armazenamento subjacente complexo nem os metadados. O MaxCompute mantém e otimiza esses elementos automaticamente, proporcionando equilíbrio entre facilidade de uso e custo-benefício.

Recursos

Categoria

Recurso

Append Delta Table

PK Delta Table

DML básico

Insert, Update, Delete e Merge Into.

Suportado

Suporte

Transações ACID

Read Committed/Snapshot Isolation.

Para mais informações, consulte ACID transaction management.

Suportado

Suportado

Chave primária

Define uma chave primária.

Não suportado

Suporta atualizações parciais de colunas

Evolução de schema

Adicionar, excluir, renomear, reordenar e alterar o tipo de dados das colunas.

Para mais informações, consulte ALTER TABLE.

Suportado

Suportado

Importação de dados

  • Suporta gravações via streaming para importação incremental de dados escalável e de alta concorrência, usando ferramentas como Write data to MaxCompute with Flink, integração de dados do DataWorks e DataHub.

  • Permite gravações em lote incrementais e completas.

Upload via Stream/Batch

Os dados ficam visíveis imediatamente após um upload via stream.

Upsert

Time travel

Permite consultar snapshots históricos por ponto no tempo ou número de versão para reproduzir resultados ou realizar análises de auditoria.

Para mais informações, consulte Time Travel.

Suportado

Suportado

Computação incremental

Delta Live Materialized View (MV) e Leitura Incremental.

Para mais informações, consulte Incremental computing e Incremental queries.

Suportado

(A materialized view incremental está em adaptação.)

Suportado

Otimização da organização de dados

Mantém automaticamente arquivos de dados incrementais, incluindo otimizações como mesclagem de arquivos pequenos, COMPACTION multinível e ordenação de dados, mantendo o armazenamento e a computação em um estado estável e eficiente.

Para mais informações, consulte Optimize data organization for Append Delta Tables e Data organization optimization for PK Delta tables.

Suportado

Não é necessário configurar o número de buckets. O Dynamic Bucketing se adapta automaticamente à distribuição dos dados.

Suportado

Otimização do desempenho de consulta

Estatísticas no nível de partição e arquivo (como Min/Max), partition pruning, column pruning e predicate pushdown.

Suportado

Suportado

Segurança e conformidade

Storage encryption / Dynamic data masking / Row-level access control.

Suportado

Suportado

Recuperação de desastres e backup

Table snapshots / Backup and restoration / Zone disaster recovery.

Suporte

Suporte

Custo

Compressão column-store AliORC e armazenamento em camadas.

Suportado

Suporte

Experiência do usuário

Atualizações de dados em tempo real para service em tempo real

As Delta Tables suportam gravações e atualizações de dados em tempo real (upserts) por meio de Stream Upload. Os dados tornam-se visíveis imediatamente após a gravação. Para equilibrar o desempenho em tempo real das gravações com o desempenho das consultas, o MaxCompute utiliza uma estratégia de armazenamento em camadas e otimização:

  • Garantir gravações em tempo real: Novos dados são gravados rapidamente em buckets não clusterizados, sem ordenação. Esse processo assegura baixa latência e alto throughput para as gravações de dados.

  • Melhorar o desempenho de consultas SQL: O service de Incremental Reclustering em segundo plano reorganiza e otimiza assincronamente os dados incrementais em buckets clusterizados e ordenados. Ao executar uma consulta, o mecanismo pode podar eficientemente os dados base ordenados e varrer apenas uma pequena quantidade de dados incrementais. Essa abordagem equilibra a atualização dos dados com a eficiência da consulta.

Processamento e análise eficientes de dados incrementais

Com base em suas capacidades subjacentes de leitura e gravação incremental de dados, o MaxCompute oferece um conjunto rico de recursos de alto nível para melhorar a tempestividade da análise de dados ponta a ponta. Combine recursos avançados, como Incremental computing e Delta Live Materialized View (Delta Live MV) (Invitational Preview), para construir pipelines eficientes de processamento de dados em tempo real e acelerar a transformação de dados em insights de negócios.

Adaptação ao crescimento dos negócios e superação dos limites de formatos de tabela anteriores

  1. Alocação dinâmica de buckets: As Append Delta Tables suportam alocação dinâmica de buckets. Não é necessário especificar o número de buckets na instrução DDL (Data Definition Language). Também não é preciso estimar o volume futuro de dados de cada partição para definir um número adequado de buckets. Conforme você grava mais dados, o service de Dynamic Bucketing divide automaticamente os buckets existentes ou cria novos. Esse recurso se adapta dinamicamente às mudanças no volume de dados comerciais e resolve problemas como skew de dados e fragmentação, causados por buckets muito grandes ou muito pequenos.

  2. Evolução de Schema: As Delta Tables suportam evolução de schema para atender aos requisitos comerciais em constante mudança de ajuste de campos de dados e melhoria da precisão dos dados. Este recurso suporta adding, deleting, modifying, and renaming columns, oferece compatibilidade total com versões anteriores e evita exclusão ou perda acidental de dados.

  3. Superação das limitações das tabelas tradicionais: Uma única Delta Table suporta operações como INSERT INTO, UPDATE, DELETE e MERGE INTO, além de clustering e armazenamento ordenado em uma única tabela. Tabelas particionadas tradicionais, tabelas clusterizadas e Transaction Tables não conseguem suportar todas essas capacidades simultaneamente.

  4. Suporte a computação multimotor, incluindo MaxCompute SQL, MaxFrame e Spark on MaxCompute. Motores open source como Flink, Spark e StarRocks também podem acessar Delta Tables através da Spark Connector e APIs de armazenamento aberto.

Equilíbrio entre desempenho e confiabilidade

  1. As Delta Tables são adequadas para gerenciar volumes massivos de dados, de terabytes a petabytes. Mesmo com volumes extremamente grandes, as operações de metadados permanecem rápidas. As consultas oferecem suporte a recursos como partition pruning, column pruning e predicate pushdown para evitar varreduras desnecessárias de dados.

  2. Gerenciamento de transações ACID: As Delta Tables usam controle de concorrência otimista para suportar operações simultâneas de vários gravadores. Conflitos de gravação são detectados e tentados novamente para garantir a consistência dos dados.

  3. Segurança e conformidade: As Delta Tables atendem aos requisitos de segurança e conformidade de dados. Elas suportam criptografia de armazenamento, listas de controle de acesso (ACLs) no nível de tabela e coluna, permissões no nível de linha e mascaramento dinâmico de dados.

  4. Backup e rollback: O mecanismo de backup e rollback versionado, que utiliza um modo de lixeira, garante que, em caso de corrupção de dados ou exclusão acidental, você possa reverter rapidamente a tabela para um estado íntegro anterior. Isso reduz os riscos de operação e manutenção (O&M) e gerenciamento.

Operações SQL

DDL

Criar uma Append Delta Table

-- Create an Append Delta Table
CREATE TABLE <table_name> (
  <col_name <data_type> [NOT NULL] [DEFAULT <default_value>] [comment <col_comment>], ...   
) 
[comment <table_comment>]
[RANGE CLUSTERED BY (<col_name> [, <col_name>, ...]) ]
TBLPROPERTIES (
  "table.format.version"="2" 
  ["acid.data.retain.hours"="hours"...]
)
[LIFECYCLE <days>];

A tabela a seguir descreve os parâmetros TBLPROPERTIES.

Parâmetro

Obrigatório

Descrição

Observações

"table.format.version"="2"

Sim

Declara o formato da tabela como Delta Table.

acid.data.retain.hours

Não

O valor padrão é 24. O intervalo de valores é [24, 168].

O intervalo de tempo, em horas, durante o qual estados históricos de dados podem ser consultados usando Time Travel.

  • Um valor de 0 indica que estados históricos de dados não são retidos e consultas Time Travel não são suportadas.

  • Se um estado histórico de dados existir por mais tempo que o valor deste parâmetro, ele poderá ser excluído ou compactado.

  • Se uma consulta Time Travel especificar um horário anterior ao valor deste parâmetro, um erro será relatado. Por exemplo, se este parâmetro estiver definido como 72 horas, um erro será relatado se você tentar consultar um estado histórico de dados de mais de 72 horas atrás.

acid.incremental.query.out.of.time.range.enabled

Não

O valor padrão é false.

Se definido como true, o endTimestamp especificado em uma consulta incremental pode ser posterior ao horário de commit mais recente da tabela. Se o endTimestamp for posterior ao horário atual, várias consultas poderão retornar resultados diferentes porque novos dados podem ser inseridos.

É possível modificar o valor deste parâmetro para uma tabela.

Criar uma PK Delta Table

-- Create a PK Delta Table
CREATE TABLE <table_name> (
  <col_name <data_type> [NOT NULL] [DEFAULT <default_value>] [comment <col_comment>], ...   
  PRIMARY KEY (<pk_col_name>[, <pk_col_name2>, ...] )
) 
[comment <table_comment>]
TBLPROPERTIES (
  "table.format.version"="2" 
  [, "write.bucket.num" = "N", "acid.data.retain.hours"="hours"...]
)
[LIFECYCLE <days>];

Os parâmetros são descritos da seguinte forma:

  • PRIMARY KEY (PK): Obrigatório. Especifique este parâmetro ao criar uma PK Delta Table. A chave primária pode conter uma ou mais colunas, e a combinação de valores nessas colunas deve ser única dentro da tabela. A sintaxe segue a sintaxe padrão de chave primária SQL. As colunas de chave primária devem ser definidas como NOT NULL e não podem ser modificadas.

    Após definir a chave primária, os dados na tabela são deduplicados com base nas colunas da chave primária. A restrição de unicidade é efetiva dentro de uma única partição ou para toda uma tabela não particionada.

  • A tabela a seguir descreve os parâmetros TBLPROPERTIES.

Parâmetro

Obrigatório

Descrição

Observações

"table.format.version"="2"

Sim

Declara o formato da tabela como Delta Table.

  • Anteriormente, as PK Delta Tables eram declaradas definindo "transactional"="true" e especificando uma PRIMARY KEY.

  • Agora, você pode declará-las definindo "table.format.version"="2" e especificando uma PRIMARY KEY.

write.bucket.num

Não

O valor padrão é 16. O intervalo de valores é (0, 4096].

O número de buckets para cada partição ou para uma tabela não particionada. Isso também indica o número de nós concorrentes para gravação de dados. Modifique este parâmetro para tabelas particionadas; a alteração entra em vigor para novas partições por padrão. Não é possível modificar este parâmetro para tabelas não particionadas. Considere as seguintes sugestões ao usar este parâmetro:

  • Se importar dados usando Tunnel, este parâmetro especifica o número de nós Tunnel concorrentes. A configuração afeta o tráfego de importação e é restrita pelo número máximo de nós Tunnel concorrentes.

  • Ao gravar dados usando SQL, este parâmetro especifica o grau de paralelismo dos Reducers que gravam os dados. Ele é restrito pelo número máximo de nós Reducer concorrentes.

  • Recomenda-se que o tamanho dos dados gravados em cada bucket seja de cerca de 500 MB. Por exemplo, se o tamanho estimado da partição for 500 GB, o número de buckets deve ser definido como aproximadamente 1.000. Isso torna o tamanho médio de cada bucket cerca de 500 MB. Para tabelas muito grandes, o limite de 500 MB pode ser excedido. Um tamanho de bucket de cerca de 2 GB a 3 GB é mais apropriado.

acid.data.retain.hours

Não

O valor padrão é 24. O intervalo de valores é [24, 168].

O intervalo de tempo, em horas, durante o qual estados históricos de dados podem ser consultados usando Time Travel.

  • Um valor de 0 indica que estados históricos de dados não são retidos e consultas Time Travel não são suportadas.

  • Se um estado histórico de dados existir por mais tempo que o valor deste parâmetro, ele poderá ser excluído ou compactado.

  • Se uma consulta Time Travel especificar um horário anterior ao valor deste parâmetro, um erro será relatado. Por exemplo, se este parâmetro estiver definido como 72 horas, um erro será relatado se você tentar consultar um estado histórico de dados de mais de 72 horas atrás.

acid.incremental.query.out.of.time.range.enabled

Não

O valor padrão é false.

Se definido como true, o endTimestamp especificado em uma consulta incremental pode ser posterior ao horário de commit mais recente da tabela. Se o endTimestamp for posterior ao horário atual, várias consultas poderão retornar resultados diferentes porque novos dados podem ser inseridos.

É possível modificar o valor deste parâmetro para uma tabela.

acid.write.precombine.field

Não

Especifique o nome de uma coluna.

Se um nome de coluna for especificado, o sistema deduplica os dados com base nas colunas de chave primária (PK) e na coluna especificada durante o processamento de arquivos para o mesmo commit. Isso garante a unicidade e a consistência dos dados.

Nota

Se o volume de dados de um único commit exceder 128 MB, vários arquivos serão gerados. Este parâmetro não se aplica a múltiplos arquivos.

acid.partial.fields.update.enable

Não

Quando definido como true, use SQL ou Tunnel para executar partial column updates em uma Delta Table.

Defina este parâmetro ao criar a tabela. Você não pode modificá-lo após a criação da tabela.

Observações

Item

Append Delta Table

PK Delta Table

Tabela clusterizada

Número de buckets

Não é necessário especificar write.bucket.num. O número de buckets muda dinamicamente com base no volume real de dados.

Especifique o número de buckets na instrução DDL. O valor padrão é 16.

/

Política de organização de dados

RANGE CLUSTERED BY. CLUSTERED BY não é suportado. Não é necessário especificar um campo SORT BY. Os dados dentro de um bucket são ordenados por padrão com base nos campos especificados em RANGE CLUSTERED BY.

Não é possível definir CLUSTERED BY. Por padrão, um hash cluster é criado com base na chave primária.

CLUSTERED BY

Ciclo de vida

Deve ser maior ou igual ao ciclo de vida da consulta Time Travel. Ou seja, lifecycle >= acid.data.retain.hours / 24. Isso é verificado quando a tabela é criada. Um erro será relatado se a condição não for atendida.

/

/

  1. Não é possível converter diretamente uma tabela padrão existente em uma Delta Table.

  2. As PK Delta Tables não suportam evolução de schema para colunas de chave primária (PK).

  3. Atualmente, as PK Delta Tables não suportam o tipo de dados JSON.

  4. CREATE TABLE AS não é suportado.

DML

As Delta Tables suportam sintaxe DML (Data Manipulation Language) como Insert or overwrite data (INSERT INTO | INSERT OVERWRITE), UPDATE | DELETE e MERGE INTO.

DQL

As Delta Tables suportam análise de consulta de uso geral. Para mais informações, consulte DQL operations (SELECT).

Importação de dados

  • Como as Append Delta Tables não possuem chave primária, elas não suportam operações upsert ou delete durante a importação de dados. Elas suportam importação de dados usando uploads de dados em lote (Upload) e uploads de dados via stream (Stream Upload).

  • As PK Delta Tables suportam gravação de dados usando a API Tunnel Upsert/Delete. Se uma chave primária não existir, uma operação upsert insere uma nova linha. Se ela existir, o upsert atualiza os campos que não são de chave primária.

Otimização da organização de dados

  • Uma Append Delta Table usa uma estrutura subjacente de Range Clustering para organização de dados. Para mais informações sobre essa otimização, consulte Optimize data organization for Append Delta Tables. Por padrão, Row_ID é usado como chave de clustering, e o número de buckets é alocado dinamicamente conforme o volume de dados cresce. Após especificar uma Cluster Key, um job de clustering em segundo plano executa reclustering incremental nos dados para manter sua ordem geral.

  • Para obter informações sobre a estrutura de organização de dados de uma PK Delta Table, consulte Data organization optimization for PK Delta tables. A tabela usa uma estrutura subjacente de Hash Clustering para permitir gravações e atualizações eficientes de dados através do hash-bucketing do campo de chave primária (PK).