Desenhar e implementar um esquema de particionamento de dados

A partição de dados afeta diretamente a eficiência com que as suas consultas correm e a quantidade de recursos computacionais que consome. Ao particionar uma tabela, divide os dados em segmentos discretos com base nos valores das colunas, permitindo que o motor de consulta leia apenas as partes relevantes do seu conjunto de dados. Esta abordagem, chamada poda de partições, pode reduzir drasticamente as varreduras de dados quando os filtros se alinham com os limites das partições.

Considere uma empresa de retalho a processar milhões de transações diárias de vendas. Os analistas consultam frequentemente os dados por intervalos de datas para gerar relatórios semanais, comparar tendências mês a mês e analisar padrões sazonais. Sem particionamento, cada consulta analisa todo o histórico das transações. Com uma partição adequada por data, as consultas para uma semana específica tocam apenas uma fração dos ficheiros armazenados.

Determinar quando a partição se aplica

O Databricks recomenda que não particione tabelas que contenham menos de 1 TB de dados. Para tabelas mais pequenas, a sobrecarga de gerir metadados de partições e a possibilidade de criar muitos ficheiros pequenos superam quaisquer benefícios de desempenho de consulta. Tabelas Delta não particionadas nas versões recentes do Databricks Runtime beneficiam automaticamente do clustering em tempo de ingestão de dados, que oferece vantagens semelhantes para consultas, sem necessidade de configuração explícita.

Quando as suas tabelas ultrapassam 1 TB, a partição torna-se uma técnica de otimização valiosa. Nesta escala, os benefícios de ler apenas segmentos de dados relevantes compensam significativamente os custos da gestão de partições. A partição também permite o processamento paralelo, já que o Spark pode distribuir diferentes partições entre nós do cluster para execução concorrente.

Para tabelas muito grandes, na ordem das centenas de terabytes, a partição traz benefícios ainda maiores. A esta escala, a poda de partições reduz drasticamente a quantidade de dados que o motor de consulta precisa de processar, melhorando tanto o desempenho como a eficiência de custos.

Escolha chaves de partição efetivas

A seleção da chave de partição exige que compreenda as características dos seus dados e padrões de consulta. Chaves de partição eficazes partilham características comuns que maximizam os benefícios de desempenho, evitando armadilhas comuns.

Colunas de baixa cardinalidade funcionam melhor

Escolha colunas com um número limitado de valores distintos. Colunas de datas, regiões geográficas, categorias de produtos e campos de estado são excelentes chaves de partição porque criam um número gerível de partições. Uma coluna com milhares ou milhões de valores únicos, como ID de cliente ou ID de transação, leva a uma sobrepartição e a um desempenho fraco.

Por exemplo, particionar uma tabela de vendas sale_date ao nível diário pode criar 365 partições por ano. Se cada dia contiver volume de dados suficiente, esta granularidade funciona bem. No entanto, particionar por sale_timestamp no segundo nível criaria milhões de partições, cada uma contendo dados mínimos.

Alinhar com padrões de consulta

A tua chave de partição deve corresponder às colunas onde os utilizadores filtram com mais frequência. Se os analistas consultarem consistentemente os dados de vendas por intervalos de datas, a partição por data permite uma poda eficiente. Se as consultas filtram principalmente por região, considera a região como a tua chave de partição.

Quando existem múltiplos padrões de filtro, priorize as consultas mais comuns ou mais críticas em termos de desempenho. Podes definir um esquema de particionamento por tabela, por isso escolhe colunas que beneficiem a maior parte da tua carga de trabalho. Para padrões de consulta significativamente diferentes, considere criar vistas materializadas otimizadas separadas ou tabelas de resumo para casos de uso específicos.

Considere o crescimento dos dados ao longo do tempo

Selecione um esquema de partição que escale adequadamente à medida que os seus dados crescem. Particionar por ano funciona bem no início, mas pode criar partições demasiado grandes ao longo do tempo. Por outro lado, particionar por hora pode funcionar para dados de alto volume, mas cria partições demasiado pequenas para volumes moderados.

Avalie a sua taxa de crescimento esperada de dados ao escolher a granularidade da partição. Um equilíbrio entre o tamanho da partição e o número de partições ajuda a manter um desempenho consistente das consultas à medida que o seu conjunto de dados se expande.

Considere também a distribuição dos dados entre partições. Tamanhos de partição severamente desiguais podem criar gargalos de processamento, uma vez que os nós que gerem partições maiores demoram mais tempo para concluir, enquanto outros permanecem inativos.

Implementar partições no Azure Databricks

Defines partições ao criar uma tabela usando a PARTITIONED BY cláusula no SQL ou o partitionBy método no PySpark. Depois de estabelecer as partições, o Azure Databricks encaminha automaticamente os dados recebidos para os diretórios de partições apropriados com base nos valores das colunas.

Criar uma tabela particionada com SQL

O exemplo seguinte cria uma tabela de transações de vendas particionada pela data da transação:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_id STRING,
    quantity INT,
    unit_price DECIMAL(10,2),
    total_amount DECIMAL(12,2),
    transaction_date DATE
)
PARTITIONED BY (transaction_date);

Quando consulta esta tabela com um filtro de datas, o motor de consulta lê apenas as partições que correspondem aos seus critérios de filtro:

SELECT product_id, SUM(total_amount) AS revenue
FROM sales.transactions
WHERE transaction_date BETWEEN '2024-01-01' AND '2024-01-31'
GROUP BY product_id;

Crie uma tabela particionada com o PySpark

Ao usar o PySpark, especifique a partição durante a operação de escrita:

df.write.format("delta") \
    .partitionBy("transaction_date") \
    .saveAsTable("sales.transactions")

Para escritas subsequentes, mantenha a consistência incluindo a mesma especificação de partição:

new_transactions_df.write.format("delta") \
    .mode("append") \
    .partitionBy("transaction_date") \
    .saveAsTable("sales.transactions")

Use colunas geradas para maior flexibilidade de partição

As colunas geradas fornecem uma forma de derivar valores de partição a partir de colunas existentes sem armazenar dados redundantes. Esta abordagem é útil quando os seus dados de origem contêm marcadores temporais, mas pretende particionar por data.

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_id STRING,
    quantity INT,
    unit_price DECIMAL(10,2),
    total_amount DECIMAL(12,2),
    transaction_timestamp TIMESTAMP,
    transaction_date DATE GENERATED ALWAYS AS (CAST(transaction_timestamp AS DATE))
)
PARTITIONED BY (transaction_date);

Evitar erros comuns de particionamento

Compreender o que evitar é tão importante quanto saber o que fazer. Vários erros comuns podem degradar significativamente o desempenho e complicar a gestão de dados.

O excesso de particionamento cria pequenos problemas de ficheiros

Criar demasiadas partições, cada uma contendo dados insuficientes, leva a problemas com ficheiros pequenos. Quando as partições contêm ficheiros menores do que o tamanho alvo do ficheiro, o desempenho das consultas sofre devido a operações excessivas de metadados e redução da eficiência de leitura. Procura partições com pelo menos 1 GB de dados.

Sinais de sobreparticionamento incluem desempenho lento das consultas apesar da poda das partições, um grande número de ficheiros pequenos em diretórios de partições e longos tempos de otimização de tabelas. Se observar estes sintomas, considere escolher uma granularidade de partição mais grossa.

A partição em colunas de alta cardinalidade falha

Colunas com muitos valores únicos são chaves de partição pobres. A partição por ID de cliente, ID de transação ou outras colunas de alta cardinalidade cria milhões de partições que degradam em vez de melhorar o desempenho. Reserve a otimização de colunas de alta cardinalidade para outras técnicas concebidas para este fim.

Mudar de partições requer reescrever os dados

As colunas de partição fazem parte da estrutura da tabela. Alterar a sua estratégia de particionamento requer reescrever toda a tabela para um novo local com limites de partição diferentes. Esta operação consome recursos computacionais significativos e tempo para tabelas grandes.

Planeie cuidadosamente a sua estratégia de particionamento antes de carregar dados em escala. Considere padrões futuros de consultas e crescimento de dados para evitar reestruturações dispendiosas mais tarde.

Decisões de particionamento de documentos

Regista as escolhas das tuas chaves de partição e a razão por detrás delas. Esta documentação ajuda os membros da equipa a compreender as oportunidades de otimização de consultas e previne alterações acidentais que possam afetar o desempenho. Inclua informações sobre os tamanhos esperados das partições, padrões de consulta que beneficiem do esquema e quaisquer restrições que tenham influenciado as suas decisões.

Considere o agrupamento líquido como alternativa

Quando se deparam com desafios de partição — especialmente com colunas de alta cardinalidade como carimbos temporais ou quando os padrões de consulta são incertos — o agrupamento líquido oferece uma alternativa moderna. Ao contrário do particionamento tradicional, o agrupamento líquido oferece:

• Flexibilidade para ajustar estratégias de otimização sem reescrever dados
• Manutenção automática à medida que as tabelas crescem
• Redução da sobrecarga de gestão de partições

A agrupação líquida é a abordagem recomendada para novas tabelas onde restrições de partição limitariam o desempenho ou criariam uma carga excessiva de manutenção. É particularmente eficaz para tabelas que excedem 1 TB e que exigem filtragem em colunas que criariam demasiadas partições usando abordagens tradicionais.

Para detalhes de implementação, sintaxe e estratégias de otimização, consulte a unidade de Projeto e implementação de estratégia de clustering mais adiante neste módulo.