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á.
A KCL gerencia metadados, como concessões e métricas de utilização da CPU dos trabalhadores. A KCL rastreia esses metadados usando tabelas do DynamoDB. Para cada aplicativo do Amazon Kinesis Data Streams, a KCL 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
A KCL 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 aos aplicativos KCL para criar e gerenciar tabelas de metadados no DynamoDB. Para obter detalhes, consulte Permissões do IAM necessárias para aplicativos de consumo da KCL.
O aplicativo de consumidor KCL não remove automaticamente essas três tabelas de metadados do DynamoDB. Certifique-se de remover essas tabelas de metadados do DynamoDB criadas pelo aplicativo consumidor KCL ao descomissionar seu aplicativo consumidor para evitar custos desnecessários.
Tabela de locação
Uma 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 da KCL. Cada aplicativo de consumidor da KCL cria sua própria tabela de leasing. A KCL usa o nome do aplicativo do consumidor como nome da tabela de concessão por padrão. Você pode definir um nome de tabela personalizado usando a configuração. A KCL também cria um índice secundário global na tabela de leasing com a chave de partição do LeaseOwner para uma descoberta eficiente do leasing. O índice secundário global reflete o atributo leaseKey da tabela básica de leasing. Se a tabela de concessão do seu aplicativo consumidor KCL 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 consumidor da KCL 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 com KCL, ele é estruturado como.
account-id:StreamName:streamCreationTimestamp:ShardIdleaseKey é a chave de partição da tabela de lease. Para obter mais informações sobre o processamento de vários fluxos, consulteProcessamento de 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 o leasing no momento. O LeaseCounter aumenta se a propriedade do leasing for transferida para outro trabalhador.
-
LeaseOwner: O trabalhador atual que está mantendo 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 com o KCL, verá os dois campos adicionais a seguir na tabela de leasing. Para obter mais informações, consulte Processamento de 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 cada aplicativo KCL e é usada para registrar as métricas de utilização da CPU de cada trabalhador. Essas métricas serão usadas pela KCL para realizar atribuições de locação eficientes para resultar em uma utilização equilibrada dos recursos entre os trabalhadores. O KCL usa KCLApplicationName-WorkerMetricStats o nome da tabela de métricas do trabalhador por padrão.
Tabela estadual do coordenador
Uma tabela de estado do coordenador é uma tabela exclusiva do Amazon DynamoDB para cada aplicativo KCL e é usada para armazenar informações de estado internas para trabalhadores. Por exemplo, a tabela de estados do coordenador armazena dados sobre a eleição do líder ou metadados associados à migração local do KCL 2.x para o KCL 3.x. O KCL usa KCLApplicationName-CoordinatorState o nome da tabela de estados do coordenador por padrão.
Modo de capacidade do DynamoDB para tabelas de metadados criadas pela 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 estado do coordenador usando o modo de capacidade sob demanda. Esse modo escala 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 e usos de leitura e gravação do seu aplicativo (RCU, WCU) usando métricas da Amazon. CloudWatch
-
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 evitar que sua tabela de metadados KCL 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 uma tabela de ProvisionedThroughputExceededException metadados do DynamoDB para seu aplicativo consumidor KCL, 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 consumidor da KCL 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 a KCL atribui arrendamentos aos trabalhadores e equilibra a carga
A KCL coleta e monitora continuamente as métricas de utilização da CPU dos hosts de computação que executam os trabalhadores para garantir uma distribuição uniforme da carga de trabalho. Essas métricas de utilização da CPU são armazenadas na tabela de métricas do trabalhador no DynamoDB. Se a KCL detectar que alguns trabalhadores estão apresentando taxas de utilização da CPU mais altas em comparação com outros, ela reatribuirá as concessões entre os trabalhadores para reduzir a carga dos trabalhadores mais usados. O objetivo é equilibrar a carga de trabalho de forma mais uniforme em toda a frota de aplicativos de consumo, evitando que um único trabalhador fique sobrecarregado. À medida que a KCL distribui a utilização da CPU 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
A KCL pode coletar métricas de utilização da CPU dos trabalhadores somente se determinados pré-requisitos forem atendidos. Para obter detalhes, consulte Pré-requisitos. Se a KCL não conseguir coletar métricas de utilização da CPU dos trabalhadores, a KCL voltará a usar a produtividade por trabalhador para atribuir concessões e equilibrar a carga entre os trabalhadores da frota. A KCL monitorará 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 dos arrendamentos atribuídos.
