As Append Delta Tables utilizam Range Clustering para organizar os dados. Por padrão, o Row_ID atua como chave de cluster e os buckets são alocados dinamicamente conforme o volume de dados aumenta. Ao especificar uma chave de cluster, um job de clustering em segundo plano executa o reclustering incremental, mantendo os dados ordenados sem bloquear operações de escrita.
Quando usar Append Delta Tables
As Append Delta Tables são ideais para os seguintes cenários:
Cargas de trabalho de anexação com alto throughput: Tabelas na camada Operational Data Store (ODS) que recebem escritas contínuas em streaming se beneficiam do desacoplamento no momento da escrita — os dados são gravados imediatamente, sem necessidade de ordenação prévia.
Colunas de filtro com alta cardinalidade: Cargas de trabalho que filtram colunas com muitos valores distintos obtêm os benefícios do clustering sem o custo de escrita associado às tabelas tradicionais de Range/Hash Cluster.
Dados com crescimento acelerado: Tabelas que escalam de terabytes para exabytes exigem uma estratégia de bucketing que se adapte automaticamente, eliminando a necessidade de reconfiguração manual conforme o volume de dados muda.
Tabelas propensas a skew de dados: Distribuições desiguais de dados tornam as contagens estáticas de buckets pouco confiáveis. O bucketing dinâmico elimina essa incerteza.
Aceleração de consultas na camada ODS: Quando tanto o desempenho da consulta quanto a atualidade dos dados são essenciais, o reclustering incremental oferece dados atualizados em nível de milissegundos, enquanto tarefas em segundo plano cuidam do clustering.
Como funciona
As Append Delta Tables combinam dois mecanismos para manter os dados organizados de forma eficiente:
Bucketing dinâmico — ajusta automaticamente o número de buckets conforme o volume de dados cresce, eliminando a necessidade de prever a quantidade de buckets no momento da criação da tabela.
Reclustering incremental — um serviço de dados em segundo plano reorganiza assincronamente os dados recém-gravados, desacoplando o desempenho de escrita da sobrecarga de clustering.
Juntos, esses mecanismos mantêm um equilíbrio dinâmico entre eficiência de armazenamento, atualidade dos dados e desempenho de consultas por meio de três tarefas em segundo plano: Merge, Compaction e Reclustering. O bucketing dinâmico também permite escalabilidade contínua de terabytes para exabytes através de políticas de Auto-Split/Merge.
Bucketing dinâmico
O problema das contagens estáticas de buckets
As tabelas tradicionais de Range/Hash Cluster exigem que você especifique uma contagem de buckets durante a criação da tabela. O MaxCompute então roteia os dados para os buckets com base na chave de cluster. Definir esse número incorretamente, para mais ou para menos, causa problemas:
Skew de dados: Poucos buckets em relação ao volume de dados faz com que buckets individuais cresçam excessivamente, reduzindo a eficácia do pruning de dados durante as consultas.
Fragmentação de dados: Muitos buckets em relação ao volume de dados deixa cada bucket com pouquíssimos dados, gerando diversos arquivos pequenos e fragmentados que prejudicam o desempenho das consultas.
Escolher a contagem correta de buckets requer conhecimento detalhado sobre o volume esperado de dados e o formato interno de tabelas do MaxCompute. Em migrações de dados em larga escala envolvendo milhares de tabelas, estimar a contagem adequada de buckets por tabela torna-se inviável. Mesmo quando a estimativa inicial é precisa, os volumes de dados de negócios mudam ao longo do tempo, tornando obsoleta uma configuração anteriormente correta.
Funcionamento do bucketing dinâmico
As Append Delta Tables alocam buckets automaticamente. Cada bucket é uma unidade de armazenamento logicamente contígua que armazena aproximadamente 500 MB de dados. Conforme você grava dados continuamente, novos buckets são criados conforme necessário, sem exigir nenhuma configuração. A contagem de buckets sempre reflete o volume real de dados, eliminando skew e fragmentação causados por provisionamento excessivo ou insuficiente.
O diagrama a seguir ilustra o fluxo de trabalho:
Reclustering incremental
O problema do clustering síncrono
O clustering acelera consultas ao ordenar e agrupar dados com base em uma chave de cluster específica. Quando uma consulta utiliza a chave de cluster, o MaxCompute aplica pushdown e pruning para reduzir o escopo de varredura dos dados.
O Range Clustering e o Hash Clustering tradicionais alcançam isso organizando e ordenando os dados durante o processo de escrita, produzindo um estado globalmente ordenado. O diagrama a seguir ilustra o mecanismo de pruning do Range Clustering / Hash Clustering:
Essa ordenação no momento da escrita gera dois problemas:
Problema 1: Alto custo para anexar dados
A ordenação durante a escrita restringe a forma como você carrega os dados. A escrita inicial deve ser concluída em uma única operação usando INSERT INTO ou INSERT OVERWRITE. Para anexar mais dados posteriormente, é necessário ler todos os dados existentes na tabela, combiná-los com os novos dados usando UNION e regravar todo o conjunto de dados. Isso torna as operações de anexação custosas e limitadas em termos de throughput.
Tabelas da camada ODS geralmente recebem escritas contínuas de pipelines de coleta externos, que exigem ingestão de baixa latência e alto throughput. O custo de amplificação de escrita das tabelas clusterizadas tradicionais impede a aplicação de clustering na camada ODS.
Problema 2: Latência na atualidade dos dados na camada de data warehouse
Para evitar a amplificação de escrita, o clustering é normalmente aplicado apenas na camada de data warehouse (DW), onde os dados provenientes do ODS são limpos e carregados em lotes estáveis. Isso introduz um atraso na atualidade: os dados da camada DW ficam sempre defasados em relação à camada ODS por pelo menos um ciclo de processamento.
Algumas cargas de trabalho exigem simultaneamente desempenho de consulta clusterizada e dados atualizados em tempo real. O clustering síncrono no momento da escrita não consegue atender a esse requisito.
Funcionamento do reclustering incremental
As Append Delta Tables desacoplam o clustering das escritas. Os dados são gravados diretamente no disco sem ordenação e alocados em buckets, maximizando o throughput de escrita e minimizando a latência. Como os dados recém-gravados ainda não estão clusterizados, os intervalos de dados dos novos buckets se sobrepõem aos dos buckets clusterizados existentes. O mecanismo SQL lida com isso de forma transparente: ele aplica pruning nos buckets clusterizados e varre os buckets incrementais durante a execução da consulta.
O diagrama a seguir ilustra o processo:
Um serviço de dados em segundo plano monitora continuamente a Profundidade de Sobreposição de Buckets. Quando a sobreposição atinge um determinado limiar, o serviço aciona o reclustering incremental nos buckets recém-gravados. A maior parte dos dados permanece ordenada o tempo todo, garantindo um desempenho geral estável nas consultas.
Essa abordagem alcança um equilíbrio ideal: as escritas ocorrem com latência mínima, as consultas executam sobre dados predominantemente ordenados e a lacuna entre a ingestão no ODS e o desempenho de consulta clusterizada é eliminada. O resultado é uma atualidade dos dados em nível de milissegundos na camada ODS, combinada com a aceleração de consultas clusterizadas.