Particionamento para tabelas Delta

A partição ao estilo colmeia divide uma tabela Delta em subdiretórios físicos com base nos valores de uma ou mais colunas de partição. Cada combinação única de valores de colunas de partição cria um diretório separado. Esta estrutura permite a eliminação de partições: o motor de execução ignora diretórios inteiros quando uma consulta filtra pela coluna de partição.

Quando usar particionamento

O principal caso de uso para particionar no Delta Lake é permitir operações de escrita concorrentes que não entram em conflito. O Delta Lake utiliza controlo de concorrência otimista, e duas operações que tocam nos mesmos ficheiros podem entrar em conflito. A partição permite que operações concorrentes visem conjuntos disjuntos de ficheiros ao operar em partições separadas.

Use particionamento quando:

• Tem escritores concorrentes que precisam de atualizar, eliminar ou fundir na mesma tabela sem conflitos — por exemplo, múltiplos pipelines a processar diferentes unidades de negócio ou regiões simultaneamente.
• A tua coluna de partição tem cardinalidade baixa a moderada (dezenas a centenas de valores distintos, não milhares). Nota: tabelas maiores podem acomodar mais partições. Procure ter pelo menos 1 GB de dados em cada partição.
• Os valores das partições alinham-se com os seus padrões de escrita — cada escritor naturalmente direciona 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 escritas concorrentes

A partição é o principal mecanismo no Delta Lake para evitar conflitos entre operações de escrita concorrentes. Quando uma tabela é particionada, operações que visam partições diferentes operam em conjuntos disjuntos de ficheiros e não entram em conflito entre si.

Por exemplo, duas operações concorrentes MERGE INTO numa tabela particionada por region não entram em conflito desde que cada uma tenha como alvo uma região diferente — desde que a coluna de partição esteja explicitamente incluída na condição de fusão:

-- 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 — estas mesmas operações poderiam entrar em conflito mesmo que modificassem logicamente linhas diferentes. A coluna de partição deve aparecer na condição de fusão em si, não apenas nos dados de origem. Sem ela, a Delta Lake não consegue determinar no momento da validação que as duas operações tocaram conjuntos de ficheiros disjuntos.

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

Dificuldades comuns

• Colunas de partição de alta cardinalidade (por exemplo, user_id com milhões de valores) criam milhares de pequenos diretórios e ficheiros, o que degrada tanto o desempenho de escrita como de leitura.
  • As colunas de data devem ser escolhidas com cautela. Para muitas tabelas, particionar por uma coluna de data resulta em partições demasiado pequenas. Procure ter 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 toda a tabela.
• O problema de ficheiros pequenos é comum com streaming ou adições frequentes a muitas partições, porque cada escrita cria pelo menos um ficheiro por partição.
• O particionamento e o agrupamento líquido são incompatíveis na mesma tabela. Tem de escolher uma estratégia.

Compare particionamento e agrupamento líquido

Conteúdo relacionado

• Controlo de concorrência
• Agrupamento de líquidos
• Z-Order
• Compactação de tabelas
• Salto de ficheiros
• Ordem V
• Manutenção da tabela Delta