Amazon Elastic MapReduce: la inserción masiva de S3 a DynamoDB es increíblemente lenta

Question

Necesito realizar una carga inicial de aproximadamente 130 millones de elementos (5+ Gb en total) en una sola tabla DynamoDB. Después de enfrentar problems con subirlos usando la API de mi aplicación, decidí probar EMR. En pocas palabras, la importación de esa cantidad de datos promedio (para EMR) lleva años incluso en el clúster más potente, consumiendo cientos de horas con muy poco progreso (aproximadamente 20 minutos para procesar bits de datos de 2Mb de prueba, y no logró terminar con el archivo 700Mb de prueba en 12 horas).

Ya me he puesto en contacto con el Soporte Premium de Amazon, pero hasta el momento solo han comentado que "por alguna razón, la importación de DynamoDB es lenta".

me han tratado las siguientes instrucciones en mi sesión de la colmena interactivo: no parece

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; 

banderas Varios tener ningún efecto visible. Han probado los siguientes ajustes en lugar de los valores por defecto:

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; 

los mismos comandos para ejecutar HDFS lugar de destino DynamoDB se completaron en cuestión de segundos.

Parece ser una tarea simple, un caso de uso muy básico, y realmente me pregunto qué puedo estar haciendo mal aquí.

Answer 1

Aquí está la respuesta que finalmente recibí del soporte de AWS recientemente. Esperamos que ayuda a alguien en una situación similar: los trabajadores

EMR se implementan actualmente como trabajadores de un solo subproceso, donde cada trabajador escribe artículos uno por uno (usando Put, no BatchWrite). Por lo tanto, cada escritura consume 1 unidad de capacidad de escritura (IOP).

Esto significa que está estableciendo muchas conexiones que disminuyen el rendimiento hasta cierto punto. Si se usaron BatchWrites, significaría que podría comprometer hasta 25 filas en una sola operación que sería menos costoso en cuanto al rendimiento (pero el mismo precio si entiendo es correcto). Esto es algo de lo que estamos conscientes y que probablemente implementará en el futuro en EMR. Sin embargo, no podemos ofrecer una línea de tiempo.

Como se ha dicho antes, el problema principal aquí es que la tabla de DynamoDB está alcanzando el rendimiento aprovisionado fin de tratar de aumentarlo temporal para la importación y luego se sienten libres para disminuirlo a cualquier nivel que necesita.

Esto puede sonar un poco conveniente, pero hubo un problema con las alertas cuando hacía esto y por eso nunca recibió una alerta . El problema ha sido arreglado desde entonces.