我正在尝试查询有很多零件文件(avro(的hdfs。最近，我们进行了一项更改，以降低并行性，因此零件文件的大小增加了，每个零件文件的尺寸在750MB到2GB之间(我们使用火花流以10分钟的间隔将日期写入hdfs，因此这些文件的大小取决于我们从上游处理的数据量(。零件文件的数量大约为500个。我想知道这些零件文件的大小/零件文件的数量是否会对spark SQL的性能起到任何作用？
如果需要，我可以提供更多信息。
HDFS、Map Reduce和SPARK更喜欢较大的文件，而不是许多较小的文件。S3也存在问题。我不确定你在这里指的是HDFS还是S3。
将较小的文件重新划分为较少数量的较大文件将允许SPARK或MR处理较少但较大的数据块，从而通过减少读取这些数据所需的映射任务数量来提高作业速度，并由于较少的浪费和名称节点争用问题而降低存储成本，而无需了解所有细节。
总而言之，小文件的问题有很多值得阅读的地方。https://www.infoworld.com/article/3004460/application-development/5-things-we-hate-about-spark.html.需要明确的是，我是星火迷。
通常，文件越少、越大越好，
一个问题是文件是否可以拆分，以及如何拆分。
- 使用.gz压缩的文件无法拆分：您必须从开始到结束进行读取，因此一次最多只能为一个工作人员分配一个文件(除非在查询接近结束时&推测可能会触发第二个文件(。使用像snappy一样的压缩，一切都很好
- 由于启动/提交开销占主导地位，非常小的文件效率低下
- 在HDFS上，小文件会在namenode上加载，因此操作团队可能会不高兴