GZ 到 ORC 文件的性能改进

Question

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

1)另一种想法，从 *.gz 文件到非分区表，而不是创建外部表并将 gz 文件数据转储到外部表。有没有其他方法可以更快地从 Gz 加载到外部表。我们正在考虑其他 2 种方法，例如我们可以使用带有自定义 .exe 的 ADF 来解压缩 *.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 的性能相同（有时我们看到黑白 ORC 分区和不带分区的 ORC 的差异很小）。 ORC With Partition 会比 ORC 表现更好。 ORC With Partition Bucketing 会比 ORC Partition 表现更好吗？我看到每个 ORC 分区文件接近 50-100 MB 并且 ORC 没有分区（每个文件大小 30-50 MB）。

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

Answer 1

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

对于上述问题 #1，您可能需要跟进 Azure 数据工厂团队。

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

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

Answer 2

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