Amazon Elastic MapReduce - 从 S3 到 DynamoDB 的大量插入非常慢

Posted 2023-03-22

【中文标题】Amazon Elastic MapReduce - 从 S3 到 DynamoDB 的大量插入非常慢

【英文标题】：Amazon Elastic MapReduce - mass insert from S3 to DynamoDB is incredibly slow

【发布时间】：2012-05-27 19:53:21

【问题描述】：

我需要将大约 1.3 亿个项目（总共 5+ Gb）初始上传到单个 DynamoDB 表中。在我遇到 problems 使用我的应用程序中的 API 上传它们之后，我决定尝试使用 EMR。

长话短说，即使在最强大的集群上，导入该非常平均（对于 EMR）的数据量也需要很长时间，花费数百小时而几乎没有进展（大约 20 分钟来处理测试 2Mb 数据位，并且没有'无法在 12 小时内完成测试 700Mb 文件）。

我已经联系了 Amazon Premium Support，但到目前为止他们只告诉“由于某种原因 DynamoDB 导入速度很慢”。

我在交互式 hive 会话中尝试了以下说明：

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 目标运行的相同命令在几秒钟内完成。

这似乎是一个简单的任务，一个非常基本的用例，我真的想知道我在这里做错了什么。

【问题讨论】：

你在同一个过程中比我领先一步，我不喜欢我在这里看到的东西.. 有没有人在这里分享一个成功的故事（大数据导入到发电机）？跨度>

我已经联系了 Amazon Premium Support，他们只是确认了这个问题并承认“DynamoDB 中存在某种问题”，差不多一周就没有了 :( 如果知道更多，我会更新。所以到目前为止，我切换到本地数据库。

我还尝试在不同的区域运行场景，并且还从脚本而不是从交互会话运行它。没有区别。

嗨，Dan，请在下面查看我自己发布的答案（我从 AWS 支持部门获得了一些反馈）。

【参考方案1】：

这是我最近从 AWS 支持那里得到的答案。希望对遇到类似情况的人有所帮助：

EMR 工作人员目前被实现为单线程工作人员， 每个工作人员一个接一个地写入项目（使用 Put，而不是 BatchWrite）。 因此，每次写入消耗 1 个写入容量单位 (IOP)。

这意味着您正在建立大量的连接 在一定程度上降低了性能。如果使用了 BatchWrites，它 这意味着您可以在单个操作中提交多达 25 行 性能方面的成本会更低（但如果我理解的话，价格相同 对的）。这是我们知道并且可能会 将来在 EMR 中实施。但我们无法提供时间表。

如前所述，这里的主要问题是您在 DynamoDB 中的表 正在达到预置的吞吐量，因此请尝试增加它 暂时用于导入，然后随意将其减少到 您需要的任何级别。

这听起来可能有点方便，但存在问题 执行此操作时发出警报，这就是为什么您从未收到过 警报。此后问题已得到解决。

【讨论】：

+1 跟进这个奇怪的问题 - 谢谢！这是否意味着您现在已经设法通过相应地临时增加预置写入吞吐量来加速导入？

老实说，我还没有尝试过，因为我正忙于实施基于本地托管数据库的替代解决方案 :( 这对我来说不再是正确的方法，但会无论如何都要尽快进行测试，并将考虑在未来的项目中使用。

我搁置它的另一个原因是，即使以我当前的吞吐量（400 个单位）添加样本 60K 记录过去需要一个小时，根据那个解释和我的了解如何应用 DynamoDB 阈值。

@Yuriy 如果你的 hashkey 分布不均匀或种类不够多，也会造成 IO 瓶颈。 DynamoDB 使用 hashkey 进行分区。

"因此，每次写入消耗 1 个写入容量单位 (IOP)。" - 只是为了澄清一条记录并不一定意味着 1 个单位的写入吞吐量。它也基于记录大小。见：docs.aws.amazon.com/amazondynamodb/latest/developerguide/…

【参考方案2】：

上周我也遇到了同样的问题。 我做了一些注释来缩短在 DynamoDB 中写入数据的时间

查找输入文件，如果它们被压缩，Hive 不能拆分超过文件数量，您将减少可能的映射器数量。

将 reducer 的数量设置为 1 或 -1，看起来它们并没有使用太多，它会为映射器打开插槽。

在 dynamodb 中，如果您使用提供的容量，则需要设置要使用的 wcu 数量。请记住，hive 将尽量不消耗超过 dynamodb.throughput.write.percent 中的百分比。如果您使用自动缩放，请将 write.percent 设置为最高目标百分比以保证它会缩放。或者随叫随到，不用担心这个，但它更贵。

您可以更改实例的内存配置以尝试获取更多映射器，在上面的页面中可以查看默认配置，使其更改 mapreduce.map.memory.mb 和 mapreduce.reduce.memory.mb。请注意这里可能会出现内存不足错误。 https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hadoop-task-config.html

一些相关的链接

http://cloudsqale.com/2018/10/22/tez-internals-1-number-of-map-tasks/

https://github.com/awslabs/emr-dynamodb-connector

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EMRforDynamoDB.PerformanceTuning.Mappers.html