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
KCLgestisce i metadati come i contratti di locazione e le metriche di utilizzo dei lavoratori. CPU KCLtiene traccia di questi metadati utilizzando le tabelle DynamoDB. Per ogni KCL applicazione Amazon Kinesis Data Streams, crea tre tabelle DynamoDB per gestire i metadati: lease table, worker metrics table e coordinator state table.
Nota
KCL3.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 consentire alle KCL applicazioni di creare e gestire tabelle di metadati in DynamoDB. Per informazioni dettagliate, consultare IAMautorizzazioni necessarie per le applicazioni destinate ai consumatori KCL.
KCLl'applicazione consumer non rimuove automaticamente queste tre tabelle di metadati DynamoDB. Assicurati di rimuovere queste tabelle di metadati DynamoDB create KCL dall'applicazione consumer 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 KCL consumer crea la propria tabella di leasing. KCLper impostazione predefinita, utilizza il nome dell'applicazione consumer per il nome della tabella di leasing. È possibile impostare un nome di tabella personalizzato utilizzando la configurazione. KCLcrea inoltre un indice secondario globale nella tabella di leasing con la chiave di partizione di leaseOwner per un'efficiente individuazione del lease. L'indice secondario globale rispecchia l' leaseKey attributo della tabella di leasing di base. Se la tabella di leasing per l'applicazione KCL consumer 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 KCL consumer 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 conKCL, è strutturato come.
account-id:StreamName:streamCreationTimestamp:ShardIdleaseKey è la chiave di partizione della tabella di leasing. Per ulteriori informazioni sull'elaborazione multi-stream, vedere. 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 contratto di locazione viene trasferita a un altro lavoratore.
-
leaseOwner: L'attuale lavoratore titolare del 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 si utilizza l'elaborazione multi-stream conKCL, 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 KCL per ogni applicazione e viene utilizzata per registrare i parametri di utilizzo CPU di ogni lavoratore. Queste metriche verranno utilizzate per eseguire assegnazioni di leasing efficienti KCL al fine di garantire un utilizzo equilibrato delle risorse tra i lavoratori. KCLutilizza KCLApplicationName-WorkerMetricStats per impostazione predefinita il nome della tabella delle metriche dei lavoratori.
Tabella degli stati del coordinatore
Una tabella di stato del coordinatore è una tabella Amazon DynamoDB unica KCL per ogni applicazione e viene utilizzata per archiviare 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 dalla 2.x alla 3.x. KCL KCL KCLutilizza KCLApplicationName-CoordinatorState per impostazione predefinita il nome della tabella degli stati del coordinatore.
Modalità di capacità DynamoDB per le tabelle di metadati create da KCL
Per impostazione predefinita, 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 CloudWatch parametri di Amazon.
-
Comprendi i requisiti di throughput medio e di picco.
-
-
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 KCL evitare che la tabella dei metadati 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 di metadati per KCL la tua applicazione consumer, devi aumentare la capacità di throughput assegnata della tabella DynamoDB. Se imposti un certo livello di unità di capacità di lettura (RCU) e 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 l'applicazione KCL consumer esegue controlli frequenti o funziona su uno stream con molti shard, potrebbero essere necessarie unità di capacità maggiore. 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.
Come assegna i contratti di locazione ai lavoratori e bilancia il carico KCL
KCLraccoglie e monitora continuamente le metriche di CPU utilizzo dagli host di elaborazione che utilizzano i worker per garantire una distribuzione uniforme del carico di lavoro. Queste metriche di CPU utilizzo sono memorizzate nella tabella delle metriche dei lavoratori in DynamoDB. Se KCL rileva che alcuni lavoratori mostrano tassi di CPU utilizzo più elevati rispetto ad altri, riassegnerà i contratti di locazione tra i lavoratori per ridurre il carico di lavoro sui lavoratori più utilizzati. L'obiettivo è bilanciare il carico di lavoro in modo più uniforme su tutto il parco di applicazioni destinate ai consumatori, evitando che un singolo lavoratore si sovraccarichi. Poiché l'CPUutilizzo viene KCL distribuito su 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 ridurre i costi.
Importante
KCLpuò raccogliere le metriche di CPU utilizzo dai lavoratori solo se vengono soddisfatti determinati prerequisiti. Per informazioni dettagliate, consultare Prerequisiti. Se KCL non è in grado di raccogliere i parametri di CPU utilizzo dai lavoratori, KCL ricorrerà alla produttività per lavoratore per assegnare i contratti di locazione e bilanciare il carico tra i lavoratori della flotta. KCLmonitorerà 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.
