我们有以下要求:
从1990年到2018年的年度XML文件(大小为15-20 GB)
每周XML文件(大小为3-6 GB)，其中包含更新的XML记录到1990年至2018年的任何年度数据
我们需要运行ETL作业以在S3中合并每周和每年的数据，并以API为前提将集成的数据公开给下游应用程序
我们采用的途径是用于ETL合并的AWS Glue和可能用于为下游应用程序提供SQL查询结果的Athena
我正在尝试使用Pyspark使用AWS Glue在S3中ETL合并一些XML(插入/更新)-确切地说，我正在执行以下步骤:
1)从Glue目录中创建动态数据框(一些XML源数据)
[共有3个文件，总计约10gb]
对于每年的数据，执行
2)将动态数据框转换为Spark数据框
3)使用Join(leftanti)和Union方法以合并数据
4)写出JSON文件(每年合并为一个文件)
作业从日志运行2个小时-我认为这太长了。
我们需要将文件大小扩展到大约400 + gb，并且我不确定是否以正确的方式对其进行编码。
一种)
我注意到以下陈述在2小时的大部分时间内都出现了
18/02/24 22:46:56 INFO客户端:application_1519512218639_0001的应用程序报告(状态:正在运行)
18/02/24 22:46:56调试客户端:
客户 token :N / A
诊断:N / A
ApplicationMaster主机:172.31.58.135
ApplicationMaster RPC端口:0
队列:默认
开始时间:1519512404681
最终状态: undefined
跟踪网址:http://ip-172-31-62-4.ec2.internal:20888/proxy/application_1519512218639_0001/
用户:root
这是否意味着该作业实际上正在运行，并且需要花费一些时间来处理(或者)它是否在等待资源？
b)在我的代码中，我还尝试使用.cache()假定它将执行内存中的逻辑。但是，它对所花费的时间没有影响。
c)日志表明数据已复制到hdfs节点并执行了任务。与在EMR上执行类似代码有何不同？
d)还有什么其他建议可用来提高绩效？
最佳答案
您是否尝试增加DPU的数量。 DPU的当前配置是什么？请访问aws.amazon.com/glue/faqs网站以扩展大小并改善AWS Glue ETL作业的性能？他们提到了增加DPU的建议。请注意，可用于ETL / DEV终端的DPU数量有限制，超出此限制您需要联系AWS支持。
关于aws-glue - AWS Glue Job运行太慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48993578/