读取时,Spark中的排序文件是否忽略了实木复合地板摘要文件(_metadata)?

时间:2019-01-21 16:13:01

标签: apache-spark hadoop parquet

我有一个具有不同列和ID的排序数据集。数据集已排序(也已使用镶木地板工具验证): 例如:

file 1: ID 1-10
file 2: ID 10-12
file 3: ID 12-33
....

我还生成并写入了_metadata和_common_metadata文件。我尝试使用过滤器查询(很大)数据集

val mydata=spark.read.parquet("s3a://.../mylocation")
val result = mydata.filter(mydata("id") === 11)
result.explain(true)

说明告诉我:

== Parsed Logical Plan ==
Filter (id#14L = 11)
+- Relation[fieldA#12, fieldB#13,id#14L] parquet

== Analyzed Logical Plan ==
fieldA: int, fieldB: string, id: bigint
Filter (id#14L = 11)
+- Relation[fieldA#12, fieldB#13,id#14L] parquet

== Optimized Logical Plan ==
Filter (isnotnull(id#14L) && (id#14L = 11))
+- Relation[fieldA#12, fieldB#13,id#14L] parquet

== Physical Plan ==
*(1) Project [fieldA#12, fieldB#13,id#14L]
+- *(1) Filter (isnotnull(id#14L) && (id#14L = 11))
   +- *(1) FileScan parquet [fieldA#12,fieldB#13,id#14L] Batched: true, Format: Parquet, Location: InMemoryFileIndex[s3a://mybucket/path/to/data], PartitionFilters: [], PushedFilters: [IsNotNull(id), EqualTo(id,11)], ReadSchema: struct<fieldA:int,fieldB:string,id:bigint>

我还启用了日志记录功能,并且可以看到读取了多个文件以获取每个文件的元数据。我在s3的此“目录”中有10000个文件,因此从文件中检索所有元数据需要花费很多时间

为什么spark无法从_metadata文件获取元数据?是否有启用此功能的选项?我已经尝试了以下选项:

spark.conf.set("parquet.summary.metadata.level","ALL")
spark.conf.set("parquet.filter.statistics.enabled","true")
spark.conf.set("parquet.filter.dictionary.enabled","true")
spark.conf.set("spark.sql.parquet.filterPushdown","true")
spark.conf.set("spark.sql.hive.convertMetastoreParquet","true")
spark.conf.set("spark.sql.parquet.respectSummaryFiles","true")
spark.conf.set("spark.sql.parquet.mergeSchema","false")
spark.conf.set("spark.sql.hive.convertMetastoreParquet.mergeSchema","false")
spark.conf.set("spark.sql.optimizer.metadataOnly", "true")

1 个答案:

答案 0 :(得分:1)

实木复合地板摘要文件被认为实际上是无用的,并且在SPARK-15719中已禁用对其的写支持。 JIRA 建议中提到的推理是,摘要文件仅用于读取架构,而不用于其他元数据(例如最小值/最大值统计信息),这些元数据可用于过滤。我无法确定是否确实如此,但这是该推理的摘录:

  

自今天以来,实木复合地板摘要文件不再特别有用

     
      
  1. 禁用模式合并时,我们假定所有Parquet部件文件的方案都是相同的,因此我们可以从任何部件文件中读取页脚。
  2.   
  3. 启用模式合并后,无论如何我们都需要读取所有文件的页脚以进行合并。
  4.   

根据此摘录,启用schema merging也可能导致需要读取每个文件页脚,尽管如果摘要文件实际上仅用于架构,那么我认为必须读取文件页脚无论如何。

如果按ID查询是您的常用操作,则可以考虑按ID对表进行分区,以避免不必要地读取文件。