Política de criação de partições

  • Artigo

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

A política aciona um processo em segundo plano adicional que ocorre após a criação de extensões, após a ingestão de dados. Este processo inclui a reposiçã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 numa única partição.

O principal objetivo da política de criação de partições é melhorar o desempenho das consultas em cenários suportados específicos.

Nota

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

Cenários suportados

Seguem-se os únicos cenários em que é recomendada a definição de uma política de criação de partições de dados. Em todos os outros cenários, a definição da política não é aconselhada.

  • Filtros frequentes numa cardinalidade stringguid ou coluna média ou alta:
    • Por exemplo: soluções multi-inquilino ou uma tabela de métricas onde a maioria ou todas as consultas filtram numa coluna do tipo string ou , como ou TenantId .MetricIdguid
    • A cardinalidade média é, pelo menos, 10 000 valores distintos.
    • Defina a chave de partição hash como a string coluna ou guid e defina a PartitionAssigmentMode propriedade como uniform.
  • Agregações frequentes ou associações numa cardinalidade string ou guid coluna elevada:
    • Por exemplo, informações de IoT de muitos sensores diferentes ou registos académicos de muitos estudantes diferentes.
    • A cardinalidade elevada é, pelo menos, 1000 000 valores distintos, em que a distribuição de valores na coluna é aproximadamente igual.
    • Neste caso, defina a chave de partição hash para ser a coluna frequentemente agrupada ou associada e defina a propriedade PartitionAssigmentModecomo ByPartition.
  • Ingestão de dados fora de ordem:
    • Os dados ingeridos numa tabela podem não ser ordenados e particionados em extensões (partições horizontais) de acordo com uma coluna específica datetime que representa o tempo de criação de dados e é normalmente utilizado para filtrar dados. Tal pode dever-se a um backfill de ficheiros de origem heterogéneos que incluem valores datetime durante um grande intervalo de tempo.
    • Neste caso, defina a chave de partição datetime do intervalo uniforme como a datetime coluna.
    • Se precisar de políticas de retenção e colocação em cache para alinhar com os valores datetime na coluna, em vez de alinhar com a hora da ingestão, defina a OverrideCreationTime propriedade como true.

Atenção

  • Não existem limites hard-coded definidos no número de tabelas com a política de criação de partições definida. No entanto, cada tabela adicional adiciona overhead ao processo de criação de partições de dados em segundo plano que é executado nos nós do cluster. Definir uma política em mais tabelas resultará na utilização de mais recursos de cluster e num custo mais elevado devido às transações de armazenamento subjacentes. Para obter mais informações, veja Capacidade.
  • Não é recomendado definir uma política de criação de partições se o tamanho comprimido dos dados por partição for inferior a 1 GB.
  • O processo de criação de partições resulta em artefactos de armazenamento residuais para todas as extensões substituídas durante o processo de criação de partições e durante o processo de intercalação. Espera-se que a maioria dos artefactos de armazenamento residuais sejam eliminados durante o processo de limpeza automática. Aumentar o valor da MaxPartitionCount propriedade aumenta o número de artefactos de armazenamento residuais e pode reduzir o desempenho da limpeza.
  • Antes de aplicar uma política de criação de partições numa vista materializada, reveja as recomendações para a política de criação de partições de vistas materializadas.

Chaves de partição

São suportados 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 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.

Nota

A operação de criação de partições de dados adiciona uma carga de processamento significativa. Recomendamos que aplique uma chave de partição hash numa tabela apenas nas seguintes condições:

  • Se a maioria das consultas utilizar filtros de igualdade (==, in()).
  • A maioria das consultas agrega/associa numa coluna específica do tipo string ou guid que é de grande dimensão (cardinalidade de 10 M ou superior), como , device_IDou user_ID.
  • O padrão de utilização das tabelas particionadas está numa carga de consulta de elevada simultaneidade, como na monitorização ou no dashboard de aplicações.
  • É utilizada uma função hash-módulo para particionar os dados.
  • Os dados em extensões homogéneas (particionadas) são ordenados pela chave de partição hash.
  • Espera-se que as consultas que utilizam a estratégia aleatória e, nas quais a shuffle key utilizada em join, summarize ou make-series seja a chave de partição hash da tabela, funcionem melhor porque a quantidade de dados necessários a mover através dos nós do cluster é reduzida.

Propriedades da partição

Propriedade Descrição Valores suportados Valor recomendado
Function O nome de uma função hash-módulo a utilizar. XxHash64
MaxPartitionCount O número máximo de partições a criar (o argumento módulo para a função hash-módulo) por período de tempo. No intervalo (1,2048]. Os valores mais elevados levam a uma maior sobrecarga do processo de criação de partições de dados nos nós do cluster e a um maior número de extensões para cada período de tempo. O valor recomendado é 128. Os valores mais elevados aumentarão significativamente a sobrecarga da criação de partições dos dados após a ingestão de dados e o tamanho dos metadados, pelo que não são recomendados.
Seed Utilize para o valor hash ser aleatório. Um número inteiro positivo. 1, que também é o valor predefinido.
PartitionAssignmentMode O modo utilizado 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 ignorados. As extensões são atribuídas uniformemente aos nós do cluster.		 Se as consultas não forem associadas ou agregadas na chave de partição hash, utilize Uniform. Caso contrário, utilize ByPartition.

Exemplo de chave de partição hash

Uma chave de partição hash sobre uma coluna te tipo string chamada tenant_id. Utiliza a função hash XxHash64, com MaxPartitionCount definido como o valor 128 recomendado e o Seed predefinido de 1.

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

Chave de partição datetime de intervalo uniforme

Nota

Aplicar apenas uma chave de partição datetime de intervalo uniforme numa datetimecoluna -typed numa tabela quando é pouco provável que os dados ingeridos na tabela sejam ordenados de acordo com esta coluna.

Nestes casos, pode remodelar os dados entre extensões para que cada extensão inclua registos de um intervalo de tempo limitado. Este processo faz com que os filtros na datetime coluna sejam mais eficazes no momento da consulta.

A função de partição utilizada é 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, porque pode fazer com que a tabela tenha um grande número de pequenas extensões que não podem ser intercaladas.
Reference Uma datetime constante escalar que indica um ponto fixo no tempo, de acordo com o qual as partições datetime estão alinhadas. Comece com 1970-01-01 00:00:00. Se existirem registos em que a chave de partição datetime tem null valores, o valor da partição é 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 do resultado devem ou não ser substituídos pelo intervalo dos valores na chave de partição. A predefinição é false. Definido como true se os dados não forem ingeridos por ordem de hora de chegada. Por exemplo, um único ficheiro de origem pode incluir valores datetime distantes e/ou pode querer impor retenção ou colocação em cache com base nos valores datetime em vez da hora da ingestão.

Quando OverrideCreationTime está definido como true, as extensões podem ser perdidas no processo de intercalação. As extensões são perdidas se o tempo de criação for superior ao Lookback período da política de intercalação Extensões da tabela. Para se certificar de que as extensões são detetáveis, defina a Lookback propriedade como HotCache.

Exemplo de partição datetime do intervalo uniforme

O fragmento mostra uma chave de partição de intervalo de datetime uniforme sobre uma datetime coluna com o nome timestamp. datetime(2021-01-01) Utiliza 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 predefinição, a política de criação de partições de dados de uma tabela é null, caso em que os dados na tabela não serão reparticionados depois de ingeridos.

A política de criação de partições de dados tem as seguintes propriedades principais:

  • PartitionKeys:

  • EffectiveDateTime:

    • O datetime UTC a partir do qual a política é eficaz.
    • Esta propriedade é opcional. Se não for especificado, a política entrará em vigor para os dados ingeridos após a aplicação da política.

Atenção

  • Pode definir um valor datetime no passado e partição de dados já ingeridos. No entanto, esta prática pode aumentar significativamente os recursos utilizados no processo de criação de partições.
  • Na maioria dos casos, recomenda-se ter apenas dados ingeridos recentemente particionados e evitar a criação de partições de grandes quantidades de dados históricos.
  • Se optar por criar partições de dados históricos, considere fazê-lo gradualmente ao definir o EffectiveDateTime para um anterior datetime em passos de até alguns dias sempre que alterar a política.

Exemplo de criação de partições de dados

Objeto de política de criação de partições de dados com duas chaves de partição.

  1. Uma chave de partição hash sobre uma coluna te tipo string chamada tenant_id.
    • Utiliza a função hash XxHash64, com MaxPartitionCount definido como o valor 128 recomendado e o Seed predefinido de 1.
  2. Uma chave de partição de intervalo de datetime uniforme sobre uma datetime coluna de tipo com o nome timestamp.
    • datetime(2021-01-01) Utiliza 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 seguintes propriedades podem ser definidas como parte da política. Estas propriedades são opcionais e recomendamos que não as altere.

Propriedade Descrição Valor recomendado Valor predefinido
MinRowCountPerOperation Destino mínimo para a soma da contagem de linhas das extensões de origem de uma única operação de criação de partições 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 criação de partições de dados. Defina um valor inferior a 5M se vir que as operações de criação de partições consomem uma grande quantidade de memória ou CPU por operação. 0, com um destino predefinido de 5000 000 registos.
MaxOriginalSizePerOperation Destino máximo para a soma do tamanho original (em bytes) das extensões de origem de uma única operação de criação de partições de dados. Se as operações de criação de partições consumirem uma grande quantidade de memória ou CPU por operação, defina um valor inferior a 5 GB. 0, com um destino predefinido de 5.368.709.120 bytes (5 GB).

O processo de criação de partições de dados

  • A criação de partições de dados é executada como um processo em segundo plano pós-ingestão no cluster.
    • Espera-se que uma tabela que é continuamente ingerida em tenha sempre uma "cauda" de dados que ainda está por particionar (extensões nonhomogéneas).
  • A criação de partições de dados é executada apenas em extensões frequentes, independentemente do valor da EffectiveDateTime propriedade na política.

Pode monitorizar o estado de criação de partições de tabelas com políticas definidas numa base de dados através do comando .show database extents partitioning statistics (.show database extents partitioning statistics ).

Capacidade de criação de partições

  • O processo de criação de partições de dados resulta na criação de mais extensões. O cluster pode aumentar gradualmente a capacidade de intercalação de extensões, para que o processo de intercalação possa manter-se.
  • Se existir um débito de ingestão elevado ou um número suficientemente grande de tabelas com uma política de criação de partições definida, o cluster poderá aumentar gradualmente a capacidade de partição Extensões, para que o processo de extensões de criação de partições possa manter-se.
  • Para evitar consumir demasiados recursos, estes aumentos dinâmicos são limitados. Poderá ser necessário auscá-los gradualmente e linearmente para além da tampa, se estiverem totalmente utilizados.
    • Se aumentar as capacidades causar um aumento significativo na utilização dos recursos do cluster, pode aumentar/ verticalmente ocluster, quer manualmente, quer ao ativar o dimensionamento automático.

Limitações

  • As tentativas de partição de dados numa base de dados que já tenha mais de 5000 000 extensões serão limitadas.
    • Nesses casos, a EffectiveDateTime propriedade das políticas de criação de partições de tabelas na base de dados será automaticamente adiada por várias horas, para que possa reavaliar a configuração e as políticas.

Valores atípicos em colunas particionadas

  • As seguintes situações podem contribuir para a distribuição desequilibrada de dados nos nós do cluster e para degradar o desempenho das consultas:
    • Se uma chave de partição hash incluir valores muito mais predominantes do que outros, por exemplo, uma cadeia vazia ou um valor genérico (como null ou N/A).
    • Os valores representam uma entidade (como tenant_id) que é mais predominante no conjunto de dados.
  • Se uma chave de partição datetime de intervalo uniforme tiver uma percentagem suficientemente grande de valores que estão "longe" da maioria dos valores na coluna, a sobrecarga do processo de criação de partições de dados é aumentada e poderá levar a muitas pequenas extensões que o cluster terá de controlar. Um exemplo de tal situação são os valores datetime do passado ou futuro distantes.

Em ambos os casos, "corrija" os dados ou filtre quaisquer registos irrelevantes nos dados antes ou no momento da ingestão, para reduzir a sobrecarga da criação de partições de dados no cluster. Por exemplo, utilize uma política de atualização.

Conteúdo relacionado