Particionamento para tabelas Delta

O particionamento no estilo Hive divide uma tabela Delta em subdiretórios físicos com base nos valores de uma ou mais colunas de partição. Cada combinação exclusiva de valores de coluna de partição cria um diretório separado. Esse layout permite a poda de partição: o mecanismo ignora diretórios inteiros quando uma consulta filtra pela coluna de partição.

Quando usar particionamento

O principal caso de uso do particionamento no Delta Lake é permitir operações de gravação simultâneas que não entrem em conflito. O Delta Lake usa controle de simultaneidade otimista e duas operações que tocam os mesmos arquivos podem entrar em conflito. O particionamento possibilita que operações simultâneas direcionem conjuntos de arquivos desarticulados operando em partições separadas.

Use particionamento quando:

• Você tem gravadores concorrentes que precisam atualizar, excluir ou mesclar na mesma tabela sem entrar em conflito — por exemplo, vários pipelines processando diferentes unidades de negócios ou regiões simultaneamente.
• Sua coluna de partição tem cardinalidade baixa a moderada (dezenas a centenas de valores distintos, não milhares). Observação: tabelas maiores podem acomodar mais partições. Direcione pelo menos 1 GB de dados em cada partição.
• Os valores de partição se alinham aos padrões de gravação, cada gravador naturalmente tem como destino uma partição específica.

Criar uma tabela particionada

CREATE TABLE sales.orders (
    order_id BIGINT,
    order_date DATE,
    region STRING,
    amount DECIMAL(10,2)
)
USING DELTA
PARTITIONED BY (region)

from delta.tables import DeltaTable

DeltaTable.create(spark) \
    .tableName("sales.orders") \
    .addColumn("order_id", "BIGINT") \
    .addColumn("order_date", "DATE") \
    .addColumn("region", "STRING") \
    .addColumn("amount", "DECIMAL(10,2)") \
    .partitionedBy("region") \
    .execute()

import io.delta.tables.DeltaTable

DeltaTable.create(spark)
    .tableName("sales.orders")
    .addColumn("order_id", "BIGINT")
    .addColumn("order_date", "DATE")
    .addColumn("region", "STRING")
    .addColumn("amount", "DECIMAL(10,2)")
    .partitionedBy("region")
    .execute()

Particionamento e gravações simultâneas

O particionamento é o principal mecanismo no Delta Lake para evitar conflitos entre operações de gravação simultâneas. Quando uma tabela é particionada, as operações direcionadas a partições diferentes operam em conjuntos de arquivos não conflituosos e não entram em conflito entre si.

Por exemplo, duas operações simultâneas MERGE INTO em uma tabela particionada por region não entram em conflito, desde que cada uma direcione uma região diferente, desde que a coluna de partição esteja explicitamente incluída na condição de mesclagem:

-- Pipeline A: processes North America only
MERGE INTO sales.orders AS target
USING staged_orders AS source
ON target.order_id = source.order_id
    AND target.region = 'NA'
    AND source.region = 'NA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

spark.sql("""
MERGE INTO sales.orders AS target
USING staged_orders AS source
ON target.order_id = source.order_id
    AND target.region = 'NA'
    AND source.region = 'NA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

spark.sql("""
MERGE INTO sales.orders AS target
USING staged_orders AS source
ON target.order_id = source.order_id
    AND target.region = 'NA'
    AND source.region = 'NA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

Sem particionamento — ou sem incluir a coluna de partição na condição de operação — essas mesmas operações podem entrar em conflito mesmo se modificarem logicamente linhas diferentes. A coluna de partição deve aparecer na própria condição de mesclagem, não apenas nos dados de origem. Sem ele, o Delta Lake não pode determinar no momento da validação que as duas operações tocaram em conjuntos de arquivos desarticulados.

Para obter um guia completo sobre tipos de conflito e estratégias de resolução, consulte Controle de concorrência.

Armadilhas comuns

• Colunas de partição de alta cardinalidade (por exemplo, user_id com milhões de valores) criam milhares de pequenos diretórios e arquivos, o que degrada o desempenho de gravação e leitura.
  • As colunas de data devem ser escolhidas com cuidado. Para muitas tabelas, o particionamento por uma coluna de data resulta em muitas partições pequenas. Direcione pelo menos 1 GB de dados em cada partição.
• As colunas de partição não podem ser alteradas após a criação da tabela sem reescrever a tabela inteira.
• Problema de arquivos pequenos é comum em streaming ou em anexações frequentes em muitas partições, pois cada gravação cria pelo menos um arquivo por partição.
• O particionamento e o clustering líquido são incompatíveis na mesma tabela. Você deve escolher uma estratégia.

Comparar particionamento e clusterização líquida

Conteúdo relacionado

• Controle de concorrência
• Agrupamento líquido
• Ordem Z
• Compactação de tabela
• Ignorar arquivo
• Ordem V
• Manutenção de tabela delta