Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Tabelle di metadati DynamoDB e bilanciamento del carico in KCL
KCL gestisce i metadati dei lavoratori, come i leasing e le metriche di utilizzo della CPU. KCL tiene traccia di questi metadati utilizzando le tabelle DynamoDB. Per ogni applicazione Amazon Kinesis Data Streams, KCL crea tre tabelle DynamoDB per gestire i metadati: lease table, worker metrics table e coordinator state table.
Nota
KCL 3.x ha introdotto due nuove tabelle di metadati: le metriche dei lavoratori e le tabelle degli stati dei coordinatori.
Importante
È necessario aggiungere le autorizzazioni appropriate per le applicazioni KCL per creare e gestire tabelle di metadati in DynamoDB. Per informazioni dettagliate, consultare Autorizzazioni IAM richieste per le applicazioni consumer KCL.
L'applicazione consumer KCL non rimuove automaticamente queste tre tabelle di metadati DynamoDB. Assicurati di rimuovere queste tabelle di metadati DynamoDB create dall'applicazione consumer KCL quando disattivi l'applicazione consumer per evitare costi inutili.
Tabella di leasing
Una tabella di lease è una tabella Amazon DynamoDB unica utilizzata per tenere traccia degli shard presi in leasing ed elaborati dagli scheduler dell'applicazione consumer KCL. Ogni applicazione consumer KCL crea la propria tabella di leasing. Per impostazione predefinita, KCL utilizza il nome dell'applicazione consumer per il nome della tabella di leasing. È possibile impostare un nome di tabella personalizzato utilizzando la configurazione. KCL crea anche un indice secondario globale sulla tabella di leasing con la chiave di partizione di LeaseOwner per un'efficiente individuazione del leasing. L'indice secondario globale rispecchia l'attributo LeaseKey della tabella di leasing di base. Se la tabella di leasing per l'applicazione consumer KCL non esiste all'avvio dell'applicazione, uno dei lavoratori crea la tabella di leasing per l'applicazione.
È possibile visualizzare la tabella di lease utilizzando la console Amazon DynamoDB mentre l'applicazione è in esecuzione.
Importante
-
Il nome di ogni applicazione consumer KCL deve essere univoco per evitare la duplicazione del nome della tabella di leasing.
-
Il tuo account sarà addebitato per i costi associati alla tabella DynamoDB, oltre ai costi associati al flusso di dati Kinesis stesso.
Ogni riga della tabella di leasing rappresenta uno shard che viene elaborato dagli scheduler dell'applicazione consumer. I campi chiave includono quanto segue:
-
LeaseKey: per l'elaborazione a flusso singolo, questo è l'ID dello shard. Per l'elaborazione multi-stream con KCL, è strutturata come.
account-id:StreamName:streamCreationTimestamp:ShardIdleaseKey è la chiave di partizione della tabella di leasing. Per ulteriori informazioni sull'elaborazione multi-stream, consulta. Elaborazione multi-stream con KCL -
checkpoint: il numero di sequenza di checkpoint più recente per lo shard.
-
checkpointSubSequenceNumero: quando si utilizza la funzione di aggregazione della Kinesis Producer Library, si tratta di un'estensione del checkpoint che tiene traccia dei record dei singoli utenti all'interno del record Kinesis.
-
LeaseCounter: utilizzato per verificare se un lavoratore sta attualmente elaborando attivamente il contratto di locazione. LeaseCounter aumenta se la proprietà del leasing viene trasferita a un altro lavoratore.
-
LeaseOwner: il lavoratore attuale che detiene questo contratto di locazione.
-
ownerSwitchesSinceCheckpoint: quante volte questo contratto di locazione ha cambiato lavoratori dall'ultimo checkpoint.
-
parentShardId: ID del genitore di questo shard. Si assicura che lo shard principale sia completamente elaborato prima che inizi l'elaborazione sugli shard secondari, mantenendo l'ordine di elaborazione dei record corretto.
-
childShardId: Elenco degli shard secondari IDs risultanti dalla divisione o dall'unione di questo shard. Utilizzato per tracciare la derivazione degli shard e gestire l'ordine di elaborazione durante le operazioni di resharding.
-
startingHashKey: Il limite inferiore dell'intervallo di chiavi hash per questo shard.
-
endingHashKey: Il limite superiore dell'intervallo di chiavi hash per questo shard.
Se utilizzi l'elaborazione multi-stream con KCL, nella tabella di leasing vengono visualizzati i due campi aggiuntivi seguenti. Per ulteriori informazioni, consulta Elaborazione multi-stream con KCL .
-
shardID: l'ID della partizione.
-
streamName: l'identificatore del flusso di dati nel seguente formato:.
account-id:StreamName:streamCreationTimestamp
Tabella delle metriche dei lavoratori
La tabella Worker Metrics è una tabella Amazon DynamoDB unica per ogni applicazione KCL e viene utilizzata per registrare i parametri di utilizzo della CPU di ogni lavoratore. Queste metriche verranno utilizzate da KCL per eseguire assegnazioni di leasing efficienti al fine di garantire un utilizzo equilibrato delle risorse tra i lavoratori. Per impostazione predefinita, KCL utilizza KCLApplicationName-WorkerMetricStats per il nome della tabella delle metriche dei lavoratori.
Tabella degli stati del coordinatore
Una tabella di stato del coordinatore è una tabella Amazon DynamoDB unica per ogni applicazione KCL e viene utilizzata per memorizzare informazioni sullo stato interno per i lavoratori. Ad esempio, la tabella degli stati del coordinatore memorizza i dati relativi all'elezione del leader o i metadati associati alla migrazione in atto da KCL 2.x a KCL 3.x. Per impostazione predefinita, KCL utilizza KCLApplicationName-CoordinatorState per il nome del coordinatore la tabella degli stati.
Modalità di capacità DynamoDB per le tabelle di metadati create da KCL
Per impostazione predefinita, la Kinesis Client Library (KCL) crea tabelle di metadati DynamoDB come la tabella di lease, la tabella delle metriche dei lavoratori e la tabella dello stato del coordinatore utilizzando la modalità di capacità su richiesta. Questa modalità ridimensiona automaticamente la capacità di lettura e scrittura per adattarsi al traffico senza richiedere la pianificazione della capacità. Ti consigliamo vivamente di mantenere la modalità di capacità come modalità on-demand per un funzionamento più efficiente di queste tabelle di metadati.
Se decidi di passare dalla tabella di leasing alla modalità di capacità assegnata, segui queste best practice:
-
Analizza i modelli di utilizzo:
-
Monitora i modelli e gli utilizzi di lettura e scrittura della tua applicazione (RCU, WCU) utilizzando i parametri di Amazon. CloudWatch
-
Comprendi i requisiti di velocità di picco e media.
-
-
Calcola la capacità richiesta:
-
Stima le unità di capacità di lettura (RCUs) e le unità di capacità di scrittura (WCUs) in base all'analisi.
-
Prendi in considerazione fattori come il numero di frammenti, la frequenza dei checkpoint e il numero di lavoratori.
-
-
Implementa il ridimensionamento automatico:
-
Utilizza la scalabilità automatica di DynamoDB per regolare automaticamente la capacità fornita e impostare limiti di capacità minimi e massimi appropriati.
-
La scalabilità automatica di DynamoDB ti aiuterà a evitare che la tabella di metadati KCL raggiunga il limite di capacità e venga limitata.
-
-
Monitoraggio e ottimizzazione regolari:
-
Monitora continuamente le CloudWatch metriche per
ThrottledRequests. -
Regola la capacità man mano che il carico di lavoro cambia nel tempo.
-
Se riscontri un problema ProvisionedThroughputExceededException nelle tabelle DynamoDB dei metadati per la tua applicazione consumer KCL, devi aumentare la capacità di throughput assegnata della tabella DynamoDB. Se imposti un certo livello di unità di capacità di lettura (RCU) e di unità di capacità di scrittura (WCU) quando crei per la prima volta l'applicazione consumer, potrebbe non essere sufficiente man mano che l'utilizzo aumenta. Ad esempio, se la tua applicazione consumer KCL esegue checkpoint frequenti o funziona su uno stream con molti shard, potresti aver bisogno di più unità di capacità. Per informazioni sulla velocità effettiva assegnata in DynamoDB, consulta la capacità di throughput di DynamoDB e l'aggiornamento di una tabella nella Amazon DynamoDB Developer Guide.
In che modo KCL assegna i contratti di locazione ai lavoratori e bilancia il carico
KCL raccoglie e monitora continuamente i parametri di utilizzo della CPU dagli host di elaborazione che eseguono i worker per garantire una distribuzione uniforme del carico di lavoro. Queste metriche di utilizzo della CPU sono memorizzate nella tabella delle metriche dei lavoratori in DynamoDB. Se KCL rileva che alcuni lavoratori mostrano tassi di utilizzo della CPU più elevati rispetto ad altri, riassegnerà i contratti di locazione tra i lavoratori per ridurre il carico sui lavoratori più utilizzati. L'obiettivo è bilanciare il carico di lavoro in modo più uniforme su tutto il parco di applicazioni consumer, evitando che ogni singolo lavoratore si sovraccarichi. Poiché KCL distribuisce l'utilizzo della CPU in tutto il parco di applicazioni consumer, è possibile dimensionare correttamente la capacità del parco di applicazioni consumer scegliendo il numero giusto di dipendenti o utilizzare la scalabilità automatica per gestire in modo efficiente la capacità di elaborazione e ottenere costi inferiori.
Importante
KCL può raccogliere i parametri di utilizzo della CPU dai lavoratori solo se vengono soddisfatti determinati prerequisiti. Per informazioni dettagliate, consultare Prerequisiti. Se KCL non è in grado di raccogliere i parametri di utilizzo della CPU dai lavoratori, KCL ricorrerà alla velocità effettiva per lavoratore per assegnare i contratti di locazione e bilanciare il carico tra i lavoratori della flotta. KCL monitorerà la produttività che ogni lavoratore riceve in un determinato momento e riassegnerà i leasing per assicurarsi che ogni lavoratore ottenga un livello di produttività totale simile dai leasing assegnati.
