GZ到ORC文件的性能改进

Question

请告诉我有没有更快的方法直接将（* .gz）移动到ORC表。

1）另一个想法，从* .gz文件到NON分区表，而不是创建外部表并将gz文件数据转储到外部表。有没有其他方法可以更快地从Gz加载到外部表。我们正在考虑其他两种方法，例如我们可以使用ADF和Custom .exe解压缩* .gz文件并上传到Azure Blob。

例如：如果* .Gz文件为10 GB且未压缩文件为120 GB，则解压缩所需的时间为40分钟，我们如何将此未压缩的120 GB数据文件上载到Azure Blob。我们是否需要使用Azure Blob SDK进行上载，或者将ADF执行.exe存储在存在数据的位置，即恰好位于包含Blob数据的群集中。 （如果ADF在Azure Blob存储数据中心的群集中执行.exe，则不会有网络成本，没有网络延迟和上传时间，上传未压缩数据将会非常少）。那ADF有可能吗？这是正确的方法吗？

1. 如果上述方法不起作用，如果我们创建MR解决方案，其中Mapper将解压缩Gz文件并上传到Azure Blob存储，是否会有任何性能改进，因为我只需要创建外部表指向到未压缩的文件。 MR将在Azure Blob存储位置执行。

2. 我们看到ORC和ORC与Partition的表现相同（有时我们看到最小差异b / w ORC分区和没有分区的ORC）。 ORC与分区的性能是否优于ORC。 ORC与分区存储的性能是否优于ORC分区？我看到每个ORC分区文件接近50-100 MB和ORC与分区（每个文件大小30-50 MB）。

**注意：120 GB的未压缩数据被压缩为17 GB的ORC文件格式

Answer 1

我知道从gz迁移到ORC文件格式的唯一方法是编写Hive查询。使用压缩格式将始终较慢，因为它需要在转换之前解压缩。您可能想要使用here所示的这些参数来查看它是否加速从gz移动到orc。

对于上面的问题＃1，您可能需要跟进Azure Data Factory团队。

对于问题＃3，我没有尝试过，但对未压缩数据进行计算应该比使用压缩数据更快。

对于＃4，取决于您要分区的字段。确保您的密钥未被分区（即导致分区太少）。还要确保添加排序依据以添加辅助分区键。有关详细信息，请参阅this链接。

Answer 2

Hive原生支持压缩格式，包括GZIP，BZIP2和deflate。因此，您可以将.gz文件上载到Azure Blob并直接使用这些文件创建外部表。然后您可以使用ORC创建表并在那里加载数据。通常，Hive使用压缩文件运行得更快，有关详细信息，请参阅Compression in Hadoop by MSIT。