Partilhar via

Política de particionamento

  • Artigo

Aplica-se a: ✅Microsoft Fabric✅Azure Data Explorer

A política de particionamento define se e como extensões (fragmentos de dados) devem ser particionadas para uma tabela específica ou uma exibição 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 regestão de dados das extensões de origem e a produção de extensões homogéneas, em que todos os valores da coluna designada como a chave de partição residir numa única partição.

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

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 há necessidade de definir uma política de particionamento de dados.

Cenários suportados

A seguir estão os únicos cenários em que a configuração de uma política de particionamento de dados é recomendada. Em todos os outros cenários, definir a política não é aconselhável.

  • Filtros frequentes numa coluna de cardinalidade média ou alta string ou guid:
    • Por exemplo: soluções multilocatárias ou uma tabela de métricas em que a maioria ou todas as consultas são filtradas 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 hash como a coluna string ou guid e defina a propriedade PartitionAssignmentMode como uniform.
  • Agregações ou junções frequentes numa coluna de string de cardinalidade elevada ou guid:
    • Por exemplo, informações de IoT de muitos sensores diferentes ou registros acadêmicos de muitos alunos diferentes.
    • Alta cardinalidade é de pelo menos 1.000.000 valores distintos, onde a distribuição de valores na coluna é aproximadamente par.
    • Nesse caso, defina a chave de partição de hash como sendo a coluna frequentemente agrupada por ou unida e defina a propriedade PartitionAssignmentMode como ByPartition.
  • 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 datetime específica que representa o tempo de criação de dados e é comumente usada para filtrar dados. Isso pode ser devido a um preenchimento de arquivos de origem heterogêneos que incluem valores de data/hora em um grande período de tempo.
    • Nesse caso, defina a chave de partição datetime do intervalo uniforme como a coluna datetime.
    • Se você precisar de políticas de retenção e cache para alinhar com os valores datetime na coluna, em vez de alinhar com a hora da ingestão, defina a propriedade OverrideCreationTime como true.

Atenção

  • Não há limites codificados definidos para o número de tabelas com a política de particionamento definida. Mas, cada tabela adicional adiciona sobrecarga ao processo de particionamento de dados em segundo plano. A definição de uma política em mais tabelas resultará em mais recursos sendo usados e em custos mais altos devido às transações de armazenamento subjacentes. Para obter mais informações, consulte capacidade.
  • Não é recomendável definir uma política de particionamento se se espera que o tamanho compactado dos dados por partição seja inferior a 1 GB.
  • O processo de particionamento resulta em artefatos de armazenamento residuais 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 residuais seja excluída durante o processo de limpeza automática. Aumentar o valor da propriedade MaxPartitionCount 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, revise as recomendações para a política de particionamento de exibições materializadas.

Chaves de partição

Os seguintes tipos de chaves de partição são suportados.

Tipo Tipo de coluna Propriedades da partição Valor da partição
Hash string ou guid Function, MaxPartitionCount, Seed, PartitionAssignmentMode Function(ColumnName, MaxPartitionCount, Seed)
Gama 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 hash, todas as extensões homogêneas que pertencem à mesma partição serão atribuídas ao mesmo nó de dados.

Observação

A operação de particionamento de dados adiciona uma carga de processamento significativa. Recomendamos a aplicação de uma chave de partição hash em uma tabela somente nas 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 de grande dimensão (cardinalidade de 10M ou superior), como um device_ID, ou user_ID.
  • O padrão de uso das tabelas particionadas está em alta carga de consulta simultaneidade, como em aplicativos de monitoramento ou dashboarding.
  • 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 hash.
    • Não é necessário incluir a chave de partição 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 shuffle, e nas quais o shuffle key usado em join, summarize ou make-series é a chave de partição hash da tabela, tenham um desempenho melhor porque a quantidade de dados necessária para mover entre nós é reduzida.

Propriedades da partição

Propriedade Descrição Valor(es) suportado(s) 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 criar (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 e a um maior número 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 pós-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. 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 não são considerados. As extensões são atribuídas uniformemente aos nós.		 Se as consultas não se juntarem ou agregarem na chave de partição hash, use Uniform. Caso contrário, use ByPartition.

Exemplo de chave de partição hash

Uma chave de partição hash sobre uma coluna de string-typed chamada tenant_id. Ele usa a função de hash XxHash64, com MaxPartitionCount definido para o valor recomendado 128e o Seed padrão 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 coluna digitada por datetimeem uma tabela quando for improvável que os dados ingeridos na tabela sejam ordenados de acordo com esta coluna.

Nesses casos, você pode reorganizar os dados entre extensões para que cada extensão inclua registros de um intervalo de tempo limitado. Esse processo resulta em filtros na coluna datetime sendo 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 constante escalar timespan 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 isso pode resultar em que a tabela tenha um grande número de pequenas extensões que não podem ser mescladas.
Reference Uma constante escalar datetime 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 houver registros nos quais 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 de criação mínimos e máximos da extensão do resultado devem ou não ser substituídos pelo intervalo dos valores na chave de partição. O padrão é false. Defina como true se os dados não forem ingeridos por ordem de hora de chegada. Por exemplo, um único arquivo de origem pode incluir valores datetime distantes e/ou você pode querer 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 são perdidas se o tempo de criação for mais antigo do que o período de Lookback da política de mesclagem de Extensões da tabela. Para certificar-se de que as extensões são detetáveis, defina a propriedade Lookback como HotCache.

Exemplo de partição datetime de intervalo uniforme

O trecho mostra uma chave de partição de intervalo datetime uniforme em uma coluna datetime digitada chamada timestamp. Ele usa datetime(2021-01-01) como seu 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 político

Por padrão, a política de particionamento 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 particionamento de dados tem as seguintes propriedades principais:

  • PartitionKeys:

  • EffectiveDateTime:

    • A data/hora UTC a partir da qual a política entra em vigor.
    • Esta propriedade é opcional. Se não for especificada, a política entrará em vigor para os dados ingeridos após a aplicação da política.

Atenção

  • 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, recomenda-se 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 fazê-lo gradualmente, definindo o EffectiveDateTime para um datetime anterior 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 hash sobre uma coluna de string-typed chamada tenant_id.
    • Ele usa a função de hash XxHash64, com MaxPartitionCount definido para o valor recomendado 128e o Seed padrão de 1.
  2. Uma chave de partição de intervalo datetime uniforme sobre uma coluna de tipo datetime chamada timestamp.
    • Ele usa datetime(2021-01-01) como seu 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. Estas propriedades são opcionais e recomendamos que não as altere.

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 vir que as operações de particionamento consomem uma grande quantidade de memória ou CPU por operação. 0, com uma meta padrão de 5.000.000 de 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.
    • Espera-se que uma tabela continuamente ingerida tenha sempre uma "cauda" de dados que ainda não foram particionados (extensões não homogêneas).
  • O particionamento de dados é executado somente em extensões ativas, independentemente do valor da propriedade EffectiveDateTime na política.
    • Se for necessário particionar extensões frias, você precisará ajustar temporariamente a política de cache de .

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

Capacidade de particionamento

  • O processo de particionamento de dados resulta na criação de mais extensões. As extensões de capacidade de fusão podem aumentar gradualmente, de modo que o processo de de fusão 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 de capacidade de partição Extents pode aumentar gradualmente, de modo que o processo de particionamento de extensões possa acompanhar.

  • Para evitar o consumo excessivo de recursos, estes aumentos dinâmicos são limitados. Você pode ser obrigado a 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á dimensioná-lo /fora, manualmente ou habilitando o dimensionamento automático.

Limitações

  • As tentativas de particionar dados em um banco de dados que já tenha mais de 5.000.000 de extensões serão limitadas.
    • Nesses casos, a propriedade EffectiveDateTime 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.

Valores atípicos em colunas particionadas

  • As seguintes situações podem contribuir para a distribuição desequilibrada de dados entre nós e degradar o desempenho da consulta:
    • Se uma chave de partição hash incluir valores que são 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 grande o suficiente de valores que estão "longe" da maioria dos valores na coluna, a sobrecarga do processo de particionamento de dados é aumentada e pode levar a muitas pequenas extensões para manter o controle. Um exemplo de tal situação são os valores datetime do passado ou futuro distante.

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

Conteúdo relacionado