用于查询优化的排序镶木地板文件

Question

问题目的

对 parquet 文件进行排序有很多好处：

• 使用文件元数据进行更有效的过滤
• 更有效的压缩率

这样做可能还有其他好处。互联网上对此有很多讨论。正因为如此，这个问题的讨论并不是关于排序的原因。相反，这个问题的目的是谈论如何排序，这是在所有互联网链接中以最少解释（大约30％）提及的，而数据排序的挑战根本没有提及。这个问题的目的是希望得到该领域的专家和经验丰富的朋友的帮助，并确定最佳的排序方法（基于成本和收益）。

关于Apache parquet库的简要说明

在开始讨论 Spark 之前，我将解释一下用于生成 parquet 文件的工具。当我们创建 parquet 文件时，该parquet-mr库（例如我使用 Java，但它可能可以扩展到其他语言）会同时写入磁盘和内存。这个库还有一个功能叫做getDataSize()在磁盘上完全关闭后返回文件的准确最终大小，因此我们在写入parquet文件时可以使用它来实现以下两个条件：

• 不要制作小尺寸的 parquet 文件（这对查询引擎不利）
• 所有 parquet 文件都可以生成特定的最小大小或固定大小（例如，每个文件 1 GB）

由于这个库同时写入磁盘和内存，所以它不允许数据排序，除非所有数据先在内存中排序，然后交给库。（但这对于大量数据来说是不可能的。）我们还隐含地假设数据是作为我们打算存储的流生成的。（在数据固定的情况下，本题所陈述的问题将毫无意义，因为可以说整个数据一劳永逸地排列好了，问题就结束了。但是我们假设数据是有流动的，在这种情况下，采用最佳方式对数据进行排序非常重要）

上面提到的 Apache parquet 库的优点之一是我们可以确定输出 parquet 文件的确切大小。我认为这是一个优点。因为，例如，如果我知道 Hadoop 块的大小等于 128 MB，而 parquet 行组的大小为 128 MB，我可以将 parquet 文件大小固定为 1 GB。然后我知道所有镶木地板文件将有 8 个块，并且 HDFS 存储将得到最好的利用，并且所有镶木地板文件将相同。（因为在HDFS中，当块大小为128 MB时，较小的文件将占用相同的空间）这可能不是每个人的优势，如果需要的话，我们很乐意有经验的人批评它。

Parquet 文件排序挑战

在我们开始之前的一点是，我们正在寻找永久数据排序，因为我们将在接下来的数千个查询中使用它。几乎到目前为止，上面的描述已经确定了排序的一些挑战，但我将在下面描述所有挑战：

1. Parquet 工具不允许您写入排序数据。因此一种方法是将所有数据保存在内存中，排序后将其交给 parquet 库写入 parquet 文件中。这种方法有两个缺点：1）不可能将所有数据保存在内存中。2) 因为所有数据都在内存中，所以 parquet 文件的大小未知，并且写入后可能小于或大于 1 GB 或任何数量，并且失去了固定 parquet 大小的优势。
2. 假设我们想在并行过程中进行排序，而不是实时和流式进行。这样，如果我们想使用parquet库，我们仍然会遇到必须将整个数据带到内存中进行排序的问题，这是不可能的。假设我们使用 Spark 这样的工具进行排序。本节我们给出的一个具体成本是集群资源用于排序，实际中每个数据都被写入两次。（一次 parquet 写入时间和一次排序）下一点是，即使我们跳过这两种情况，在对数据进行排序后，根据 parquet 文件中的其他列，该特定列的 parquet 压缩量和整个数据可能会发生变化、增加或减少。因此，在写入parquet文件后，可能会创建小文件或者固定大小（例如1GB）可能发生变化。不幸的是，Spark并没有提供控制文件大小的方法（实际中可能无法实现），因此如果我们想要恢复固定的文件大小，我们可能需要使用上面提到的链接之类的方法，这不会空闲（导致除了消耗集群资源之外还要多次写入文件，并且确切的文件大小不会固定）：How do you control the size of the output file

也许没有其他办法，唯一的办法就是上面提到的办法。在这种情况下，我很高兴专家能表达这个说明，以便其他人知道目前没有其他办法。

挑战总结

因此，我们在这些解决方案中通常观察到两类问题：

1. 如何以合理的成本和时间进行排序（在流中）
2. 如何保持镶木地板文件的大小固定

为此，虽然到处都说排序很好（而且网上和我自己的调查结果都表明它确实有用），但对它的方法和挑战却只字不提。我请这个领域有经验和专家的朋友在这个方向上帮助我（希望对其他人也有帮助），如果这个解释中遗漏了方法或要点，请指出。

由于我的英语水平较差，如果某些部分有错别字，请见谅。谢谢。