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

amazon-s3 hive

Question

Necesito realizar una carga inicial de aproximadamente 130 millones de elementos (5+ Gb en total) en una sola tabla de DynamoDB. Después de que tuve problems para cargarlos utilizando la API de mi aplicación, decidí probar EMR en su lugar.

En pocas palabras, la importación de esa cantidad muy promedio (para EMR) de datos lleva mucho tiempo, incluso en el clúster más poderoso, y consume cientos de horas con muy poco progreso (aproximadamente 20 minutos para procesar la prueba de bits de datos de 2Mb, y no se logró) Para finalizar con el archivo de prueba de 700Mb en 12 horas).

Ya me he contactado con el Soporte Premium de Amazon, pero hasta el momento solo dijeron que "por alguna razón, la importación de DynamoDB es lenta".

He intentado las siguientes instrucciones en mi sesión interactiva de colmena:

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;

Varias banderas no parecen tener ningún efecto visible. Han probado las siguientes configuraciones en lugar de las predeterminadas:

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 ejecutados para HDFS en lugar de DynamoDB se completaron en segundos.

Eso 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. Espero que ayude a alguien en una situación similar:

Actualmente, los trabajadores de EMR se implementan como trabajadores de un solo hilo, donde cada trabajador escribe los elementos uno por uno (utilizando 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 en cierta medida. Si se utilizara BatchWrites, significaría que podría realizar hasta 25 filas en una sola operación, lo que sería menos costoso en cuanto a rendimiento (pero el mismo precio si lo entiendo bien). Esto es algo de lo que somos conscientes y probablemente se implementará en el futuro en EMR. Sin embargo, no podemos ofrecer una línea de tiempo.

Como se indicó anteriormente, el principal problema aquí es que su tabla en DynamoDB está alcanzando el rendimiento aprovisionado, así que intente aumentarla temporalmente para la importación y luego siéntase libre de reducirla a cualquier nivel que necesite.

Esto puede sonar un poco conveniente, pero hubo un problema con las alertas cuando estaba haciendo esto, por lo que nunca recibió una alerta. El problema se ha solucionado desde entonces.