Amazon Elastic MapReduce - массовая вставка от S3 до DynamoDB невероятно медленная

Мне нужно выполнить первоначальную загрузку примерно 130 миллионов элементов (всего 5+ Gb) в одну таблицу DynamoDB. После того, как я столкнулся с проблемами с загрузкой их с помощью API из своего приложения, я решил попробовать EMR.

Короче говоря, импорт этого очень среднего (для EMR) количества данных занимает много времени даже в самом мощном кластере, потребляя сотни часов с очень небольшим прогрессом (около 20 минут для обработки тестового бита данных 2 Мбит и didn не удается завершить тестовый файл 700 Мб за 12 часов).

Я уже связался с Amazon Premium Support, но пока они только сказали, что "по какой-то причине импорт DynamoDB медленный".

В сеансе интерактивного улья я пробовал следующие инструкции:

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;

Различные флаги, похоже, не имеют видимого эффекта. Попробовали следующие настройки вместо стандартных:

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;

Те же команды, запускаемые для HDFS вместо цели DynamoDB, были завершены за считанные секунды.

Это, кажется, простая задача, очень простой пример использования, и я действительно задаюсь вопросом, что я могу делать неправильно здесь.

Ответ 1

Вот ответ, который я наконец получил от поддержки AWS. Надежда, которая помогает кому-то в подобной ситуации:

Работники EMR в настоящее время реализуются как работники с одним потоком, где каждый рабочий записывает элементы один за другим (используя Put, а не BatchWrite). Поэтому каждая запись потребляет 1 блок записи (IOP).
Это означает, что вы устанавливаете множество соединений, которые в некоторой степени снижает производительность. Если BatchWrites были использованы, это означает, что вы можете зафиксировать до 25 строк за одну операцию, будет менее дорогостоящей работой (но то же самое цена, если я пойму это правильно). Это то, о чем мы знаем и, вероятно, реализовать в будущем в ЭМИ. Однако мы не можем предложить график.

Как уже говорилось ранее, основная проблема заключается в том, что ваша таблица в DynamoDB достигает обеспеченной пропускной способности, поэтому постарайтесь увеличить ее временно для импорта, а затем не стесняйтесь уменьшать его до независимо от уровня, который вам нужен.

Это может показаться немного удобным, но возникла проблема с когда вы делали это, поэтому вы никогда не получали оповещения. Проблема была исправлена с тех пор.