我想使用图形用户界面使用Azure Databricks AutoML来训练回归预测模型。训练数据非常广泛。除RESPONSE变量外的所有列都将用作功能。
要使用Databricks AutoML图形用户界面,我必须将数据作为表存储在配置单元元存储中。我有一个有40,000多列的大型DataFrame df
。
print((df.count(), len(df.columns)))
(33030, 45502)
这些数据是使用以下PySpark命令写入配置单元中的表的(我相信这是标准的):
df.write.mode('overwrite').saveAsTable("WIDE_TABLE")
不幸的是,这项工作没有在“可接受的”时间(10小时)内完成。我取消了,因此没有错误消息。
当我使用以下命令减少列数时
df.select(df.columns[:500]).write.mode('overwrite').saveAsTable("WIDE_TABLE")
它运行得更好,只需9.87分钟就能完成,所以这个方法应该是可行的。
这个问题能解决吗:
- 拥有更好的计算示例?
- 有了更好的剧本?
- 一点也不,如果是这样,还有其他方法吗?
[编辑以解决评论中的问题]
运行时和驱动程序摘要:2-16 Workers 112-896 GB Memory 32-256 Cores (Standard_DS5_v2)
1 Driver 56 GB Memory, 16 Cores (Same as worker)
Runtime10.4.x-scala2.12
为了给人留下一个时间安排的印象,我在下面添加了一个表格。
Columns|时间(分钟)
10|1.94
100|1.92
200|3.04
500|9.87
1000|25.91
5000|938.4
其余列的数据类型为Integer
。
据我所知,我是在与我正在工作的相同环境中编写表格的。数据流:Azure Blob CSV->数据读取和争论->PySpark DataFrame->Hive表。最后三个步骤位于同一台云计算机上。
希望这个能帮上忙!
1条答案
按热度按时间vzgqcmou1#
我认为你的案例与Spark资源配置或网络连接无关,它与Spark设计本身有关。
简而言之,Spark是为狭长的数据而设计的,而这与您的 Dataframe 正好相反。当您查看您的实验时,当您的列大小增加时,时间消耗呈指数增长。虽然这是关于读CSV而不是写表格,但你可以查看这篇文章来很好地解释为什么Spark不擅长处理宽 Dataframe :Spark csv reading speed is very slow although I increased the number of nodes
虽然我之前没有使用Azure AutoML,但基于DataSet来实现您的目标,我认为您可以尝试:
1.尝试使用PYTHONPandas Dataframe 和Hive连接库,看看是否有性能提升
1.在写入配置单元之前,将所有列连接到单个数组/向量中