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 come i leasing e le metriche di utilizzo della CPU dei lavoratori. KCL tiene traccia di questi metadati utilizzando le tabelle DynamoDB. Per ogni applicazione Amazon Kinesis Data Streams, KCL 3.x crea tre tabelle DynamoDB di default per gestire i metadati: tabella dei lease, tabella delle metriche dei lavoratori e tabella dello stato del coordinatore. A partire da KCL 3.5, puoi utilizzare il formato a tabella singola per consolidare tutti i metadati nella tabella di leasing. Per ulteriori informazioni, consulta Formato a tabella singola per KCL.
Nota
KCL 3.x ha introdotto due nuove tabelle di metadati: le metriche dei lavoratori e le tabelle dello stato dei coordinatori. A partire da KCL 3.5, puoi consolidare queste tabelle nella tabella di locazione utilizzando il formato a tabella singola.
Importante
È necessario aggiungere le autorizzazioni appropriate per le applicazioni KCL per creare e gestire tabelle di metadati in DynamoDB. Per informazioni dettagliate, vedi 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 leasing è una tabella unica di Amazon DynamoDB utilizzata per tracciare i frammenti 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'efficace individuazione dei leasing. L'indice secondario globale rispecchia l'attributo LeaseKey della tabella di leasing di base. Se la tabella di lease per l'applicazione consumer KCL non esiste all'avvio dell'applicazione, uno dei lavoratori crea la tabella di lease 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 che il nome della tabella di leasing venga duplicato.
-
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 lease rappresenta un frammento che viene elaborato dagli scheduler della tua 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, è strutturato come
account-id:StreamName:streamCreationTimestamp:ShardId. LeaseKey è la chiave di partizione della tabella di leasing. Per ulteriori informazioni sull'elaborazione multi-stream, vedere. Multi-stream elaborazione con KCL -
checkpoint: il numero di sequenza di checkpoint più recente per lo shard.
-
checkpointSubSequenceNumber: quando si utilizza la funzionalità 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 leasing. LeaseCounter aumenta se la proprietà del leasing viene trasferita a un altro lavoratore.
-
LeaseOwner: il lavoratore attuale titolare del contratto di locazione.
-
proprietarioSwitchesSinceCheckpoint: quante volte questo contratto di locazione ha cambiato lavoratore dall'ultimo checkpoint.
-
genitoreShardId: ID del genitore di questo frammento. Si assicura che lo shard principale sia completamente elaborato prima che l'elaborazione inizi sugli shard secondari, mantenendo il corretto ordine di elaborazione dei record.
-
childShardId: elenco degli ID degli shard secondari risultanti dalla divisione o dall'unione di questo shard. Utilizzato per tracciare la discendenza degli shard e gestire l'ordine di elaborazione durante le operazioni di resharding.
-
avvioHashKey: il limite inferiore dell'intervallo di chiavi hash per questo shard.
-
fineHashKey: il limite superiore dell'intervallo di chiavi hash per questo shard.
Se usi l'elaborazione multi-stream con KCL, vedi i seguenti due campi aggiuntivi nella tabella di leasing. Per ulteriori informazioni, consulta Multi-stream elaborazione 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 delle metriche dei lavoratori è una tabella Amazon DynamoDB unica per ogni applicazione KCL e viene utilizzata per registrare i parametri di utilizzo della CPU di ciascun lavoratore. Queste metriche verranno utilizzate da KCL per eseguire assegnazioni di leasing efficienti per ottenere un utilizzo equilibrato delle risorse tra i lavoratori. Per impostazione predefinita, KCL utilizza KCLApplicationName-WorkerMetricStats il nome della tabella delle metriche dei lavoratori.
Tabella dello stato del coordinatore
Una tabella di stato del coordinatore è una tabella Amazon DynamoDB univoca per ogni applicazione KCL e viene utilizzata per archiviare informazioni interne sullo stato dei lavoratori. Ad esempio, la tabella dello stato del coordinatore memorizza i dati relativi all'elezione del leader o i metadati associati alla migrazione sul posto da KCL 2.x a KCL 3.x. Per impostazione predefinita, KCL utilizza il nome della tabella KCLApplicationName-CoordinatorState di stato del coordinatore.
La 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 dei lease, la tabella delle metriche dei lavoratori e la tabella dello stato dei coordinatori utilizzando la modalità di capacità su richiesta. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/on-demand-capacity-mode.html 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à capacità come modalità su richiesta 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 dell'applicazione (RCU, WCU) utilizzando le metriche di Amazon. CloudWatch
-
Comprendi i requisiti di throughput medio e di picco.
-
-
Calcola la capacità richiesta:
-
Stima le unità di capacità di lettura (RCU) e le unità di capacità di scrittura (WCU) in base alla tua analisi.
-
Considera fattori come il numero di frammenti, la frequenza dei checkpoint e il numero di lavoratori.
-
-
Implementa il ridimensionamento automatico:
-
Usa il ridimensionamento automatico di DynamoDB per regolare automaticamente la capacità assegnata e impostare limiti di capacità minimi e massimi appropriati.
-
Il ridimensionamento automatico 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 CloudWatch le metriche per
ThrottledRequests. -
Regola la capacità in base alle variazioni del carico di lavoro nel tempo.
-
Se riscontri una ProvisionedThroughputExceededException tabella DynamoDB con metadati per la tua applicazione consumer KCL, devi aumentare la capacità di throughput assegnata alla 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 il tuo utilizzo aumenta. Ad esempio, se la tua applicazione consumer KCL esegue controlli frequenti o funziona su uno stream con molti frammenti, potresti aver bisogno di più unità di capacità. Per informazioni sul throughput assegnato in DynamoDB, consulta la capacità di throughput di DynamoDB e l'aggiornamento di una tabella nella Amazon DynamoDB Developer Guide. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.Basics.html#WorkingWithTables.Basics.UpdateTable
In che modo KCL assegna i contratti di locazione ai lavoratori e bilancia il carico
KCL raccoglie e monitora continuamente le metriche di utilizzo della CPU dagli host di calcolo che eseguono i lavoratori per garantire una distribuzione uniforme del carico di lavoro. Queste metriche di utilizzo della CPU sono archiviate 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 molto utilizzati. L'obiettivo è bilanciare il carico di lavoro in modo più uniforme nell'intero 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, puoi ridimensionare correttamente la capacità del parco di applicazioni consumer scegliendo il giusto numero di lavoratori o utilizzare il ridimensionamento automatico per gestire in modo efficiente la capacità di elaborazione e ottenere costi inferiori.
Importante
KCL può raccogliere le metriche sull'utilizzo della CPU dai lavoratori solo se vengono soddisfatti determinati prerequisiti. Per informazioni dettagliate, vedi Prerequisiti. Se KCL non è in grado di raccogliere le metriche sull'utilizzo della CPU dai lavoratori, KCL ricorrerà all'utilizzo del throughput per lavoratore per assegnare i contratti di locazione e bilanciare il carico tra i lavoratori della flotta. KCL monitorerà il rendimento 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 contratti di locazione assegnati.
