镶木地板内部构件

Question

我有一个数据帧，它是由运行特定日期的每日批处理创建的，然后保存在HDFS（Azure Data Lake Gen 2）中。

它是用这样的东西保存的

TradesWritePath="abfss://refined@"+datalakename+".dfs.core.windows.net/curated/clientscoredata/clientscoredatainput/Trades/" + TradeDatedt + "/Trades_" + tradedateInt + ".parquet"
tradesdf.write.mode("overwrite").parquet(TradesWritePath)

如您所见，我没有对数据帧进行分区，因为它只包含一个日期。

例如，第一天的第一个文件将存储在文件夹中

交易/2019/08/25

然后第二天，它就会在文件夹里

贸易/2019/08/26

问题是，当所有数据都放好后，日期上的过滤器谓词是否仍会被按下，HDFS是否会知道在哪里查找数据，而不是进行完全扫描？

或者，即使我保存了一天，我仍然必须使用分区选项进行编写，只是为了让Spark在阅读时理解并将其推送到HDFS，HDFS也知道在哪里可以找到它（而不是全扫描）？

问题的下一部分是：

当我查看存储拼花文件的文件夹时，我看到了很多小的“部分-****. snappy.parquet文件。我通过阅读这里的一些论坛问题了解到，如果我必须减少文件的数量，我必须使用“重新分区”选项。但问题是——有必要吗？我读到太多的小文件当然会影响性能，所以一种选择是将其保存在128 MB的块中（如果我不确定数据将如何用于下游，即目前哪些列），这样HDFS中的NameNode就不会负担过重，我们也不会有太大的文件。这也适用于这些“时髦的镶木地板分区文件”吗？

太多的概念，我仍在努力寻找最好的解决方案，将这些数据帧存储为拼花，因此任何见解都将不胜感激。

Answer 1

您不应该创建自己的目录。

在编写拼花地板时，使用分区来按日期进行分区。它将自动处理目录创建，并且在读取时不会扫描整个表。

对于问题的第二部分，是的，我们的想法是将每个分区保持在128MB左右，但老实说，这不会花费太多，您可以将默认分区保持在200。

Answer 2

如果数据存储为

root/    
   date=ddmmyy/
   date=dd1mm1yy1/
...

符号很重要。谓词下推不能使用任意目录结构。必须采用上述格式。

在你的例子中

您需要存储以下内容

  root/
      Trades=2019/08/25
      Trades=2019/08/26

Spark利用hive分区发现机制来检测表中的分区。Hive分区需要以特定方式放置数据。

进入问题的下一部分。无论文件的类型如何，将小文件保存在HDFS中都是非常糟糕的。是的，对于snappy分区文件来说确实如此。您应该使用重新分区或coalesce函数来保持文件大小接近128

namenode的职责是跟踪HDFS中的所有文件。HDFS中的块大小为128