我有一个用例，其中有3072个gz文件，我正在构建一个配置单元表。现在，每当我在这个表上运行一个查询时，查询都会生成3072个Map器，大约需要44分钟才能完成。此前，384个文件中存在相同的数据（即相同的数据大小）。同样的查询只花了大约9分钟。
我在网上搜索了一下，发现Map器的数量是由i/p数据的“拆分”数量决定的。因此，设置参数： mapreduce.input.fileinputformat.split.minsize 以及 mapreduce.input.fileinputformat.split.maxsize 如果设置为64MB这样的高值，则会导致每个Map器占用64MB的数据，即使这需要同一Map器处理多个文件也是如此。
但是，这个解决方案不适用于我的情况，因为gz文件是“不可拆分”的格式。因此，它们不能在多个Map器之间拆分，也不能由单个Map器进行合并处理。
有人也面临过这个问题吗？
对此可以有多种解决方案，比如解压缩gz文件，然后使用上述参数来减少Map器的数量，或者使用更高端的ec2示例来减少处理时间。但是，hadoop/hive/emr中有解决这个问题的内在解决方案吗？
提前感谢您的帮助！