将数百万个小文件从Azure Data Lake Store加载到数据砖

Question

我在Azure Data Lake Store中有一个分区文件夹结构，其中包含大约600万个json文件（大小为kb到2 mb）。我正在尝试使用Data Bricks中的Python代码从这些文件中提取一些字段。

目前我正在尝试以下方法：

spark.conf.set("dfs.adls.oauth2.access.token.provider.type", "ClientCredential")
spark.conf.set("dfs.adls.oauth2.client.id", "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx")
spark.conf.set("dfs.adls.oauth2.credential", "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")
spark.conf.set("dfs.adls.oauth2.refresh.url", "https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/oauth2/token")

df = spark.read.json("adl://xxxxxxx.azuredatalakestore.net/staging/filetype/category/2017/*/")

此示例甚至只读取部分文件，因为它指向“staging / filetype / category / 2017 /”。它似乎工作，当我运行这些命令时，有一些工作开始。这很慢。

Job 40索引所有子文件夹并且速度相对较快

作业41检查一组文件，似乎有点快到真

然后是工作42，这就是缓慢开始的地方。它似乎与工作41做同样的活动，只是......慢

我觉得我和this thread有类似的问题。但是工作41的速度让我怀疑。有更快的方法吗？

Answer 1

加入Jason的回答：

我们在Azure Data Lake中运行了一些测试作业，使用U-SQL运行大约170万个文件，并且能够在大约20个小时内完成10个AU的处理。这项工作产生了数千个提取顶点，因此有了更多的AU，它可以在很短的时间内完成。

我们尚未测试过600万个文件，但如果您愿意尝试，请告诉我们。

在任何情况下，我都同意Jason的建议，即减少数量并使文件更大。

Answer 2

我们使用Azure函数按小时合并文件，这大大降低了文件处理速度。因此，在将文件发送到ADB群集进行处理之前，请尝试合并文件。如果不这样做-要么您的工作节点数量很多，否则可能会增加成本。

Answer 3

我认为您需要在处理之前考虑合并文件。既增加大小又减少文件数量。最佳文件大小约为250mb。有很多方法可以做到这一点，也许最简单的方法是使用azure数据湖分析工作，甚至使用spark来迭代文件的子集