As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Tabelas de metadados do DynamoDB e balanceamento de carga no KCL
KCLgerencia metadados, como locações e métricas de CPU utilização dos trabalhadores. KCLrastreia esses metadados usando tabelas do DynamoDB. Para cada KCL aplicativo do Amazon Kinesis Data Streams, cria três tabelas do DynamoDB para gerenciar os metadados: tabela de lease, tabela de métricas de trabalhadores e tabela de estado do coordenador.
nota
KCLA 3.x introduziu duas novas tabelas de metadados: métricas do trabalhador e tabelas de estado do coordenador.
Importante
Você deve adicionar as permissões adequadas para que os KCL aplicativos criem e gerenciem tabelas de metadados no DynamoDB. Para obter detalhes, consulte IAMpermissões necessárias para aplicativos de KCL consumo.
KCLo aplicativo do consumidor não remove automaticamente essas três tabelas de metadados do DynamoDB. Certifique-se de remover essas tabelas de metadados do DynamoDB criadas KCL pelo aplicativo consumidor ao descomissionar seu aplicativo consumidor para evitar custos desnecessários.
Tabela de locação
A tabela de lease é uma tabela exclusiva do Amazon DynamoDB usada para rastrear os fragmentos que estão sendo alugados e processados pelos programadores do aplicativo consumidor. KCL Cada aplicativo KCL do consumidor cria sua própria tabela de leasing. KCLusa o nome do aplicativo do consumidor como nome da tabela de leasing por padrão. Você pode definir um nome de tabela personalizado usando a configuração. KCLtambém cria um índice secundário global na tabela de leasing com a chave de partição de leaseOwner para uma descoberta eficiente do leasing. O índice secundário global reflete o leaseKey atributo da tabela básica de locação. Se a tabela de concessão do seu aplicativo KCL consumidor não existir quando o aplicativo for inicializado, um dos trabalhadores criará a tabela de concessão para seu aplicativo.
É possível visualizar a tabela usando o console do Amazon DynamoDB enquanto a aplicação de consumo está em execução.
Importante
-
Cada nome de aplicativo do KCL consumidor deve ser exclusivo para evitar a duplicação do nome da tabela de leasing.
-
Sua conta é cobrada pelos custos associados à tabela do DynamoDB, além dos custos associados ao próprio Kinesis Data Streams.
Cada linha na tabela de concessão representa um fragmento que está sendo processado pelos agendadores do seu aplicativo consumidor. Os principais campos incluem o seguinte:
-
leaseKey: para processamento de fluxo único, esse é o ID do fragmento. Para processamento de vários fluxos comKCL, ele é estruturado como
account-id:StreamName:streamCreationTimestamp:ShardId. leaseKey é a chave de partição da tabela de leasing. Para obter mais informações sobre o processamento de vários fluxos, consulteProcessamento em vários fluxos com KCL . -
checkpoint: número de sequência do ponto de verificação mais recente do fragmento.
-
checkpointSubSequenceNúmero: ao usar o recurso de agregação da Kinesis Producer Library, essa é uma extensão do ponto de verificação que rastreia registros individuais de usuários dentro do registro do Kinesis.
-
leaseCounter: usado para verificar se um trabalhador está processando ativamente a concessão no momento. leaseCounter aumenta se a propriedade do arrendamento for transferida para outro trabalhador.
-
leaseOwner: O trabalhador atual que está detendo esse contrato.
-
ownerSwitchesSincePonto de controle: Quantas vezes esse contrato mudou de trabalhadores desde o último posto de controle.
-
parentShardId: ID do pai desse fragmento. Garante que o fragmento principal seja totalmente processado antes do início do processamento dos fragmentos secundários, mantendo a ordem correta de processamento do registro.
-
childShardId: Lista de fragmentos secundários IDs resultantes da divisão ou mesclagem desse fragmento. Usado para rastrear a linhagem de fragmentos e gerenciar a ordem de processamento durante as operações de refragmentação.
-
startingHashKey: o limite inferior do intervalo de chaves de hash desse fragmento.
-
endingHashKey: o limite superior do intervalo de chaves de hash desse fragmento.
Se você usar o processamento de vários fluxos comKCL, verá os dois campos adicionais a seguir na tabela de leasing. Para obter mais informações, consulte Processamento em vários fluxos com KCL .
-
shardID: o ID do fragmento.
-
streamName: O identificador do fluxo de dados no seguinte formato:
account-id:StreamName:streamCreationTimestamp.
Tabela de métricas de trabalhadores
A tabela de métricas do trabalhador é uma tabela exclusiva do Amazon DynamoDB para KCL cada aplicativo e é usada para CPU registrar as métricas de utilização de cada trabalhador. Essas métricas serão usadas KCL para realizar atribuições de locação eficientes para resultar em uma utilização equilibrada dos recursos entre os trabalhadores. KCLusa KCLApplicationName-WorkerMetricStats o nome da tabela de métricas do trabalhador por padrão.
Tabela estadual do coordenador
A tabela de estado do coordenador é uma tabela exclusiva do Amazon DynamoDB para KCL cada aplicativo e é usada para armazenar informações de estado internas para os trabalhadores. Por exemplo, a tabela de estados do coordenador armazena dados sobre a eleição do líder ou metadados associados à migração local de KCL 2.x para 3.x. KCL KCLusa KCLApplicationName-CoordinatorState o nome da tabela de estados do coordenador por padrão.
Modo de capacidade do DynamoDB para tabelas de metadados criadas por KCL
Por padrão, a Kinesis Client Library (KCL) cria tabelas de metadados do DynamoDB, como tabela de lease, tabela de métricas de trabalhadores e tabela de estados do coordenador usando o modo de capacidade sob demanda. Esse modo dimensiona automaticamente a capacidade de leitura e gravação para acomodar o tráfego sem exigir planejamento de capacidade. É altamente recomendável que você mantenha o modo de capacidade como modo sob demanda para uma operação mais eficiente dessas tabelas de metadados.
Se você decidir mudar a tabela de leasing para o modo de capacidade provisionada, siga estas melhores práticas:
-
Analise os padrões de uso:
-
Monitore os padrões de leitura e gravação e os usos do seu aplicativo (RCU,WCU) usando CloudWatch métricas da Amazon.
-
Entenda os requisitos de produtividade de pico e médio.
-
-
Calcule a capacidade necessária:
-
Estime as unidades de capacidade de leitura (RCUs) e as unidades de capacidade de gravação (WCUs) com base em sua análise.
-
Considere fatores como o número de fragmentos, a frequência dos pontos de verificação e o número de trabalhadores.
-
-
Implemente o escalonamento automático:
-
Use o auto scaling do DynamoDB para ajustar automaticamente a capacidade provisionada e definir limites de capacidade mínima e máxima apropriados.
-
O auto scaling do DynamoDB ajudará a KCL evitar que sua tabela de metadados atinja o limite de capacidade e seja limitada.
-
-
Monitoramento e otimização regulares:
-
Monitore continuamente CloudWatch as métricas de
ThrottledRequests. -
Ajuste a capacidade à medida que sua carga de trabalho muda com o tempo.
-
Se você tiver experiência ProvisionedThroughputExceededException com tabelas de metadados do DynamoDB para KCL seu aplicativo consumidor, deverá aumentar a capacidade de taxa de transferência provisionada da tabela do DynamoDB. Se você definir um determinado nível de unidades de capacidade de leitura (RCU) e unidades de capacidade de gravação (WCU) ao criar seu aplicativo consumidor pela primeira vez, isso pode não ser suficiente à medida que seu uso aumenta. Por exemplo, se seu aplicativo KCL consumidor faz verificações frequentes ou opera em um stream com muitos fragmentos, talvez você precise de mais unidades de capacidade. Para obter informações sobre a taxa de transferência provisionada no DynamoDB, consulte a capacidade de taxa de transferência do DynamoDB e a atualização de uma tabela no Amazon DynamoDB Developer Guide.
Como KCL atribui arrendamentos aos trabalhadores e equilibra a carga
KCLcoleta e monitora continuamente as métricas de CPU utilização dos hosts de computação que executam os trabalhadores para garantir uma distribuição uniforme da carga de trabalho. Essas métricas CPU de utilização são armazenadas na tabela de métricas do trabalhador no DynamoDB. Se KCL detectar que alguns trabalhadores estão apresentando taxas de CPU utilização mais altas em comparação com outros, ele reatribuirá os arrendamentos entre os trabalhadores para reduzir a carga de trabalhadores altamente usados. O objetivo é equilibrar a carga de trabalho de forma mais uniforme em toda a frota de aplicativos de consumo, evitando que um único funcionário fique sobrecarregado. À medida que KCL distribui a CPU utilização em toda a frota de aplicativos de consumo, você pode dimensionar corretamente a capacidade da frota de aplicativos de consumo escolhendo o número certo de trabalhadores ou usar o escalonamento automático para gerenciar com eficiência a capacidade de computação a fim de obter custos mais baixos.
Importante
KCLpode coletar métricas CPU de utilização dos trabalhadores somente se determinados pré-requisitos forem atendidos. Para obter detalhes, consulte Pré-requisitos. Se KCL não puder coletar métricas de CPU utilização dos trabalhadores, KCL voltará a usar a produtividade por trabalhador para atribuir arrendamentos e equilibrar a carga entre os trabalhadores da frota. KCLmonitorará a produtividade que cada trabalhador recebe em um determinado momento e reatribuirá os arrendamentos para garantir que cada trabalhador obtenha um nível de produtividade total semelhante a partir dos arrendamentos atribuídos.
