17

約 1 億 3000 万のアイテム (合計 5 Gb 以上) を単一の DynamoDB テーブルに最初にアップロードする必要があります。アプリケーションから API を使用してアップロードする際に問題が発生したため、代わりに EMR を試すことにしました。

簡単に言えば、非常に平均的な (EMR の場合) 量のデータのインポートには、最も強力なクラスターでも時間がかかり、ほとんど進行せずに数百時間かかります (テストの 2Mb データビットを処理するのに約 20 分、管理できませんでした)。 12 時間で 700Mb ファイルのテストを終了します)。

すでにAmazonプレミアムサポートに問い合わせましたが、今のところ「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;

DynamoDB ターゲットの代わりに HDFS に対して実行された同じコマンドは、数秒で完了しました。

これは単純なタスクであり、非常に基本的なユース ケースのように思えます。ここで何が間違っているのでしょうか。

4

2 に答える 2

15

最近、AWS サポートから最終的に得た回答は次のとおりです。同様の状況で誰かを助けることを願っています:

EMR ワーカーは現在、シングル スレッド ワーカーとして実装されており、各ワーカーは項目を 1 つずつ書き込みます (BatchWrite ではなく Put を使用)。したがって、書き込みごとに 1 つの書き込みキャパシティーユニット (IOP) が消費されます。

これは、パフォーマンスをある程度低下させる多くの接続を確立していることを意味します。BatchWrites を使用した場合、1 回の操作で最大 25 行をコミットできるため、パフォーマンスの面でコストが低くなります (ただし、正しく理解できれば同じ価格です)。これは私たちが認識していることであり、将来的に EMR で実装される可能性があります。ただし、タイムラインを提供することはできません。

前に述べたように、ここでの主な問題は、DynamoDB のテーブルがプロビジョニングされたスループットに達しているため、インポートのために一時的に増加させてから、必要なレベルまで自由に減少させることです。

これは少し便利に聞こえるかもしれませんが、これを行っているときにアラートに問題があったため、アラートを受信しなかったのです。その後、問題は修正されました。

于 2012-05-24T11:19:38.850 に答える