Amazon Elastic MapReduce - l'inserimento di massa da S3 a DynamoDB è incredibilmente lento

Question

Ho bisogno di eseguire un caricamento iniziale di circa 130 milioni di elementi (5+ Gb totali) in una singola tabella DynamoDB. Dopo aver affrontato problems caricandoli con l'API della mia applicazione, ho deciso di provare EMR.

Per farla breve, l'importazione di quella quantità di dati molto media (per EMR) impiega anni anche sul cluster più potente, consumando centinaia di ore con pochi progressi (circa 20 minuti per elaborare il bit di dati 2Mb e non è riuscito a finire con il file 700Mb di prova in 12 ore).

Ho già contattato Amazon Premium Support, ma finora mi hanno solo detto che "per qualche motivo l'importazione di DynamoDB è lenta".

ho provato le seguenti istruzioni nella mia sessione interattiva alveare:

CREATE EXTERNAL TABLE test_medium (
    hash_key string, 
    range_key bigint, 
    field_1 string, 
    field_2 string, 
    field_3 string, 
    field_4 bigint, 
    field_5 bigint, 
    field_6 string, 
    field_7 bigint 
) 
ROW FORMAT DELIMITED 
FIELDS TERMINATED BY '|' 
LOCATION 's3://my-bucket/s3_import/' 
; 

CREATE EXTERNAL TABLE ddb_target (
    hash_key string, 
    range_key bigint, 
    field_1 bigint, 
    field_2 bigint, 
    field_3 bigint, 
    field_4 bigint, 
    field_5 bigint, 
    field_6 string, 
    field_7 bigint 
) 
STORED BY 'org.apache.hadoop.hive.dynamodb.DynamoDBStorageHandler' 
TBLPROPERTIES (
    "dynamodb.table.name" = "my_ddb_table", 
    "dynamodb.column.mapping" = "hash_key:hash_key,range_key:range_key,field_1:field_1,field_2:field_2,field_3:field_3,field_4:field_4,field_5:field_5,field_6:field_6,field_7:field_7" 
) 
; 

INSERT OVERWRITE TABLE ddb_target SELECT * FROM test_medium; 

Diverse bandiere non sembrano avere alcun effetto visibile. Hanno provato le seguenti impostazioni al posto di quelli di default:

SET dynamodb.throughput.write.percent = 1.0; 
SET dynamodb.throughput.read.percent = 1.0; 
SET dynamodb.endpoint=dynamodb.eu-west-1.amazonaws.com; 
SET hive.base.inputformat=org.apache.hadoop.hive.ql.io.HiveInputFormat; 
SET mapred.map.tasks = 100; 
SET mapred.reduce.tasks=20; 
SET hive.exec.reducers.max = 100; 
SET hive.exec.reducers.min = 50; 

Gli stessi comandi correre per HDFS invece di bersaglio DynamoDB sono stati completati in pochi secondi.

Questo sembra essere un compito semplice, un caso d'uso molto basilare, e mi chiedo davvero cosa posso fare di sbagliato qui.

Answer 1

Ecco la risposta che ho ricevuto recentemente dal supporto AWS. Speranza che aiuta qualcuno in una situazione simile: lavoratori

EMR sono attualmente implementati come lavoratori a thread singolo, dove ogni lavoratore scrive articoli uno per uno (utilizzando Put, non BatchWrite). Pertanto, ogni scrittura consuma 1 unità capacità di scrittura (IOP).

Ciò significa che si stanno stabilendo molte connessioni che lo riduce in qualche modo le prestazioni. Se sono stati utilizzati BatchWrites, è significherebbe si potrebbe impegnarsi fino a 25 righe in una sola operazione, che sarebbe meno costosa prestazioni saggio (prezzo, ma lo stesso se ho capito bene ). Questo è qualcosa di cui siamo a conoscenza e che probabilmente implementeremo in futuro in EMR in . Tuttavia non possiamo offrire una cronologia.

Come detto prima, il problema principale è che il vostro tavolo in DynamoDB sta raggiungendo il throughput provisioning in modo da cercare di aumentarlo temporaneamente l'importazione e quindi sentitevi liberi di diminuirlo per qualsiasi livello si ha bisogno.

Questo può sembrare un po 'conveniente, ma c'era un problema con gli avvisi quando si stava facendo questo, motivo per cui non si è mai ricevuto un avviso . Il problema è stato risolto da allora.