Política de particionamento

  • Artigo

A política de particionamento define se e como as extensões (fragmentos de dados) devem ser particionadas para uma tabela específica ou uma exibição materializada.

A política dispara um processo adicional em segundo plano que ocorre após a criação de extensões, após a ingestão de dados. Esse processo inclui a redimensão de dados das extensões de origem e a produção de extensões homogêneas , nas quais todos os valores da coluna designada como chave de partição residem em uma única partição.

O objetivo principal da política de particionamento é aprimorar o desempenho da consulta em cenários com suporte específicos.

Observação

Por padrão, quando uma política de particionamento de dados não é definida (é null), as extensões são particionadas por tempo de criação (ingestão). Na maioria dos casos, não é necessário definir uma política de particionamento de dados.

Cenários com suporte

Veja a seguir os únicos cenários em que é recomendável definir uma política de particionamento de dados. Em todos os outros cenários, não é recomendável definir a política.

  • Filtros frequentes em uma cardinalidade string ou coluna média ou guid alta:
    • Por exemplo: soluções multilocatário ou uma tabela de métricas em que a maioria ou todas as consultas filtram em uma coluna do tipo string ou guid, como o TenantId ou o MetricId.
    • A cardinalidade média é de pelo menos 10.000 valores distintos.
    • Defina a chave de partição de hash como a string coluna ou guid e defina a PartitionAssigmentMode propriedade como uniform.
  • Agregações ou junções frequentes em uma coluna ou guid cardinalidade string alta:
    • Por exemplo, informações de IoT de muitos sensores diferentes ou registros acadêmicos de muitos alunos diferentes.
    • A alta cardinalidade é de pelo menos 1.000.000 valores distintos, em que a distribuição de valores na coluna é aproximadamente uniforme.
    • Nesse caso, defina a chave de partição de hash como sendo a coluna agrupada com frequência por ou unida e defina a PartitionAssigmentMode propriedadeByPartitioncomo .
  • Ingestão de dados fora de ordem:
    • Os dados ingeridos em uma tabela podem não ser ordenados e particionados em extensões (fragmentos) de acordo com uma coluna específica datetime que representa o tempo de criação de dados e é comumente usado para filtrar dados. Isso pode ser devido a um backfill de arquivos de origem heterogêneos que incluem valores de datetime em um grande período de tempo.
    • Nesse caso, defina a chave de partição datetime de intervalo uniforme como a datetime coluna.
    • Se você precisar de políticas de retenção e cache para se alinhar com os valores de datetime na coluna, em vez de se alinhar com a hora da ingestão, defina a OverrideCreationTime propriedade truecomo .

Cuidado

  • Não há limites embutidos em código definidos no número de tabelas com a política de particionamento definida. Porém, cada tabela adicional adiciona sobrecarga ao processo de particionamento de dados em segundo plano executado nos nós do cluster. Definir uma política em mais tabelas resultará em mais recursos de cluster sendo usados e um custo mais alto devido a transações de armazenamento subjacentes. Para obter mais informações, consulte capacidade.
  • Não é recomendável definir uma política de particionamento se o tamanho compactado dos dados por partição for menor que 1 GB.
  • O processo de particionamento resulta em artefatos de armazenamento residual para todas as extensões substituídas durante o processo de particionamento e durante o processo de mesclagem. Espera-se que a maioria dos artefatos de armazenamento residual seja excluída durante o processo de limpeza automática. Aumentar o valor da MaxPartitionCount propriedade aumenta o número de artefatos de armazenamento residual e pode reduzir o desempenho da limpeza.
  • Antes de aplicar uma política de particionamento em uma exibição materializada, examine as recomendações para a política de particionamento de exibições materializadas.

Chaves de partição

Há suporte para os seguintes tipos de chaves de partição.

Tipo Tipo de coluna Propriedades da partição Valor da partição
Hash string ou guid Function, MaxPartitionCount, Seed, PartitionAssignmentMode Function(ColumnName, MaxPartitionCount, Seed)
Intervalo uniforme datetime RangeSize, Reference, OverrideCreationTime bin_at(ColumnName, RangeSize, Reference)

Chave de partição de hash

Se a política incluir uma chave de partição de hash, todas as extensões homogêneas que pertencem à mesma partição serão atribuídas ao mesmo nó de dados no cluster.

Observação

A operação de particionamento de dados adiciona uma carga de processamento significativa. É recomendável aplicar uma chave de partição de hash em uma tabela somente sob as seguintes condições:

  • Se a maioria das consultas usar filtros de igualdade (==, in()).
  • A maioria das consultas agrega/une em uma coluna específica do tipo string ou guid que é de dimensão grande (cardinalidade de 10M ou superior), como um device_IDou user_ID.
  • O padrão de uso das tabelas particionadas está em alta carga de consulta de simultaneidade, como em aplicativos de monitoramento ou painéis.
  • Uma função hash-modulo é usada para particionar os dados.
  • Os dados em extensões homogêneas (particionadas) são ordenados pela chave de partição de hash.
    • Você não precisa incluir a chave de partição de hash na política de ordem de linha, se uma estiver definida na tabela.
  • Espera-se que as consultas que usam a estratégia de ordem aleatória e em que o shuffle key usado em joinou summarizemake-series seja a chave de partição de hash da tabela sejam executadas melhor porque a quantidade de dados necessários para mover entre nós de cluster é reduzida.

Propriedades da partição

Propriedade Descrição Valores com suporte Valor recomendado
Function O nome de uma função hash-modulo a ser usada. XxHash64
MaxPartitionCount O número máximo de partições a serem criadas (o argumento modulo para a função hash-modulo) por período de tempo. No intervalo (1,2048]. Valores mais altos levam a uma maior sobrecarga do processo de particionamento de dados nos nós do cluster e a um número maior de extensões para cada período de tempo. O valor recomendado é 128. Valores mais altos aumentarão significativamente a sobrecarga de particionamento dos dados após a ingestão e o tamanho dos metadados e, portanto, não são recomendados.
Seed Use para randomizar o valor de hash. Um número inteiro positivo. 1, que também é o valor padrão.
PartitionAssignmentMode O modo usado para atribuir partições a nós no cluster. ByPartition: todas as extensões homogêneas (particionadas) que pertencem à mesma partição são atribuídas ao mesmo nó.
Uniform: os valores de partição de uma extensão são desconsiderados. As extensões são atribuídas uniformemente aos nós do cluster.		 Se as consultas não unirem ou agregarem na chave de partição de hash, use Uniform. Caso contrário, use ByPartition.

Exemplo de chave de partição de hash

Uma chave de partição de hash em uma stringcoluna tipada como tenant_id. Ele usa a XxHash64 função de hash, com definido como MaxPartitionCount o valor 128recomendado e o padrão Seed de 1.

{
  "ColumnName": "tenant_id",
  "Kind": "Hash",
  "Properties": {
    "Function": "XxHash64",
    "MaxPartitionCount": 128,
    "Seed": 1,
    "PartitionAssignmentMode": "Uniform"
  }
}

Chave de partição datetime de intervalo uniforme

Observação

Aplique apenas uma chave de partição datetime de intervalo uniforme em uma datetimecoluna com tipo em uma tabela quando os dados ingeridos na tabela não forem ordenados de acordo com essa coluna.

Nesses casos, você pode reembaralhar os dados entre extensões para que cada extensão inclua registros de um intervalo de tempo limitado. Esse processo faz com que os filtros na datetime coluna sejam mais eficazes no momento da consulta.

A função de partição usada é bin_at() e não é personalizável.

Propriedades da partição

Propriedade Descrição Valor recomendado
RangeSize Uma timespan constante escalar que indica o tamanho de cada partição datetime. Comece com o valor 1.00:00:00 (um dia). Não defina um valor mais curto, pois isso pode fazer com que a tabela tenha um grande número de pequenas extensões que não podem ser mescladas.
Reference Uma datetime constante escalar que indica um ponto fixo no tempo, de acordo com o qual as partições datetime estão alinhadas. Inicie com 1970-01-01 00:00:00. Se houver registros em que a chave de partição datetime tenha null valores, seu valor de partição será definido como o valor de Reference.
OverrideCreationTime Um bool que indica se os tempos mínimos e máximos de criação da extensão de resultado devem ou não ser substituídos pelo intervalo dos valores na chave de partição. Assume o padrão de false. Defina como true se os dados não forem ingeridos em ordem de chegada. Por exemplo, um único arquivo de origem pode incluir valores datetime distantes e/ou talvez você queira impor retenção ou cache com base nos valores datetime em vez da hora da ingestão.

Quando OverrideCreationTime é definido como true, as extensões podem ser perdidas no processo de mesclagem. As extensões serão perdidas se o tempo de criação for mais antigo do que o Lookback período da política de mesclagem Extents da tabela. Para garantir que as extensões sejam detectáveis, defina a Lookback propriedade como HotCache.

Exemplo de partição de datetime de intervalo uniforme

O snippet mostra uma chave de partição de intervalo de datetime uniforme em uma datetime coluna tipada chamada timestamp. Ele usa datetime(2021-01-01) como ponto de referência, com um tamanho de 7d para cada partição, e não substitui os tempos de criação das extensões.

{
  "ColumnName": "timestamp",
  "Kind": "UniformRange",
  "Properties": {
    "Reference": "2021-01-01T00:00:00",
    "RangeSize": "7.00:00:00",
    "OverrideCreationTime": false
  }
}

O objeto de política

Por padrão, a política de particionamento de dados de uma tabela é null, nesse caso, os dados na tabela não serão reparticionados após serem ingeridos.

A política de particionamento de dados tem as seguintes propriedades de main:

Cuidado

  • Você pode definir um valor datetime no passado e particionar dados já ingeridos. No entanto, essa prática pode aumentar significativamente os recursos usados no processo de particionamento.
  • Na maioria dos casos, é recomendável ter apenas dados recém-ingeridos particionados e evitar o particionamento de grandes quantidades de dados históricos.
  • Se você optar por particionar dados históricos, considere fazer isso gradualmente, definindo EffectiveDateTime como um anterior datetime em etapas de até alguns dias cada vez que alterar a política.

Exemplo de particionamento de dados

Objeto de política de particionamento de dados com duas chaves de partição.

  1. Uma chave de partição de hash em uma stringcoluna tipada como tenant_id.
    • Ele usa a XxHash64 função de hash, com definido como MaxPartitionCount o valor 128recomendado e o padrão Seed de 1.
  2. Uma chave de partição de intervalo de datetime uniforme sobre uma datetime coluna de tipo chamada timestamp.
    • Ele usa datetime(2021-01-01) como ponto de referência, com um tamanho de 7d para cada partição.
{
  "PartitionKeys": [
    {
      "ColumnName": "tenant_id",
      "Kind": "Hash",
      "Properties": {
        "Function": "XxHash64",
        "MaxPartitionCount": 128,
        "Seed": 1,
        "PartitionAssignmentMode": "Uniform"
      }
    },
    {
      "ColumnName": "timestamp",
      "Kind": "UniformRange",
      "Properties": {
        "Reference": "2021-01-01T00:00:00",
        "RangeSize": "7.00:00:00",
        "OverrideCreationTime": false
      }
    }
  ]
}

Propriedades adicionais

As propriedades a seguir podem ser definidas como parte da política. Essas propriedades são opcionais e recomendamos não alterá-las.

Propriedade Descrição Valor recomendado Valor padrão
MinRowCountPerOperation Destino mínimo para a soma da contagem de linhas das extensões de origem de uma única operação de particionamento de dados. 0
MaxRowCountPerOperation Destino máximo para a soma da contagem de linhas das extensões de origem de uma única operação de particionamento de dados. Defina um valor inferior a 5M se você vir que as operações de particionamento consomem uma grande quantidade de memória ou CPU por operação. 0, com um destino padrão de 5.000.000 registros.
MaxOriginalSizePerOperation Destino máximo para a soma do tamanho original (em bytes) das extensões de origem de uma única operação de particionamento de dados. Se as operações de particionamento consumirem uma grande quantidade de memória ou CPU por operação, defina um valor inferior a 5 GB. 0, com um destino padrão de 5.368.709.120 bytes (5 GB).

O processo de particionamento de dados

  • O particionamento de dados é executado como um processo em segundo plano pós-ingestão no cluster.
    • Espera-se que uma tabela ingerida continuamente em sempre tenha uma "cauda" de dados que ainda está para ser particionada (extensões não independentes).
  • O particionamento de dados é executado somente em extensões frequentes, independentemente do valor da EffectiveDateTime propriedade na política.
    • Se for necessário particionar extensões a frio, você precisará ajustar temporariamente a política de cache.

Você pode monitorar o particionamento status de tabelas com políticas definidas em um banco de dados usando o comando .show database extents partitioning statistics.

Capacidade de particionamento

  • O processo de particionamento de dados resulta na criação de mais extensões. O cluster pode aumentar gradualmente sua capacidade de mesclagem de extensões, para que o processo de mesclagem de extensões possa acompanhar.
  • Se houver uma alta taxa de transferência de ingestão ou um número grande o suficiente de tabelas que tenham uma política de particionamento definida, o cluster poderá aumentar gradualmente sua capacidade de partição extents, para que o processo de extensões de particionamento possa acompanhar.
  • Para evitar consumir muitos recursos, esses aumentos dinâmicos são limitados. Talvez seja necessário aumentá-los gradual e linearmente além do limite, se eles forem totalmente usados.
    • Se o aumento das capacidades causar um aumento significativo no uso dos recursos do cluster, você poderá escalar o cluster/ manualmente ou habilitando o dimensionamento automático.

Limitações

  • As tentativas de particionar dados em um banco de dados que já tem mais de 5.000.000 extensões serão limitadas.
    • Nesses casos, a EffectiveDateTime propriedade de políticas de particionamento de tabelas no banco de dados será automaticamente atrasada por várias horas, para que você possa reavaliar sua configuração e políticas.

Exceções em colunas particionadas

  • As seguintes situações podem contribuir para a distribuição desequilibrada de dados entre os nós do cluster e degradar o desempenho da consulta:
    • Se uma chave de partição de hash incluir valores muito mais prevalentes do que outros, por exemplo, uma cadeia de caracteres vazia ou um valor genérico (como null ou N/A).
    • Os valores representam uma entidade (como tenant_id) que é mais prevalente no conjunto de dados.
  • Se uma chave de partição datetime de intervalo uniforme tiver uma porcentagem suficiente de valores "distantes" da maioria dos valores na coluna, a sobrecarga do processo de particionamento de dados será aumentada e poderá levar a muitas pequenas extensões que o cluster precisará acompanhar. Um exemplo dessa situação são os valores datetime do passado ou futuro distantes.

Em ambos os casos, "corrija" os dados ou filtre todos os registros irrelevantes nos dados antes ou no momento da ingestão, para reduzir a sobrecarga do particionamento de dados no cluster. Por exemplo, use uma política de atualização.

Conteúdo relacionado