有很多这样的问题，但似乎无济于事。我正在尝试将相当大的csv.gz文件隐藏起来，并不断出现诸如此类的错误
'Command failed with exit code 1'
或
An error occurred while calling o392.pyWriteDynamicFrame. Job aborted due to stage failure: Task 0 in stage 0.0 failed 4 times, most recent failure: Lost task 0.3 in stage 0.0 (TID 3, ip-172-31-5-241.eu-central-1.compute.internal, executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container marked as failed
。在指标监视中，我看不到太多的CPU或内存负载。有ETL数据移动，但是使用S3时应触发任何错误。
另一个问题是，这种作业在投掷前要运行4-5个小时。这是预期的行为吗？ CSV文件的大小约为30-40列。
我不知道该往哪个方向走。胶水可以整体处理这么大的文件吗？
答案 0 :(得分：2)
我认为问题不直接与DPU的数量有关。您的文件很大，并且正在使用无法拆分的GZIP格式，因此出现了此问题。
我建议将文件从GZIP转换为bzip2或lz4。另外，您应该考虑使用输出数据分区，以在将来获得更好的性能。
答案 1 :(得分：0)
您正在使用多少DPU。 article很好地概述了DPU容量规划。希望能有所帮助。 AWS没有提供明确的规则手册来说明处理特定大小需要多少DPU。