Spark+Parquet分片规则

之前提到parquet.block.size所控制的parquet row group大小是一个需要调优的spark参数。其中重要一点，就是控制任务的并发度。
在Hadoop里，任务的并发默认是以hdfs block为单位的，而Spark里多了一种选择，即以RowGroup为基本单位。
在调用HiveContext.read.parquet(path)时，会触发ParquetRelation2对象生成SqlNewHadoopRDD对象，并覆盖其中getPartitions()方法。

• Spark 1.4社区版
  该版本的SqlNewHadoopRDD.getPartitions()里，使用FilteringParquetRowInputFormat类，在spark.sql.parquet.cacheMetadata=true（默认）时，会使用cachedStatus和cachedFooters缓存，覆盖父类的listStatus()和getFooters()方法。后者会触发对parquet footers的扫描

// Overridden so we can inject our own cached files statuses.
        override def getPartitions: Array[SparkPartition] = {
          val inputFormat = if (cacheMetadata) {
            new FilteringParquetRowInputFormat {
              override def listStatus(jobContext: JobContext): JList[FileStatus] = cachedStatuses
              override def getFooters(jobContext: JobContext): JList[Footer] = cachedFooters
            }
          } else {
            new FilteringParquetRowInputFormat
          }
          val jobContext = newJobContext(getConf(isDriverSide = true), jobId)
          val rawSplits = inputFormat.getSplits(jobContext)
          Array.tabulate[SparkPartition](rawSplits.size) { i =>
            new SqlNewHadoopPartition(id, i, rawSplits(i).asInstanceOf[InputSplit with Writable])
          } 
        }

在默认配置时，是以hdfsBlock为单位，进行task调度的。但可以通过设置parquet.task.side.metadata=false，是以rowGroup为单位调度（当group太小时，会合并，保证满足minsize）。但即使采用task SideMeta，默认情况下，这时也读取了footers信息，而这是不必要的。但这时会产生一个问题，当默认情况下，一个rowGroup横跨多个splits时怎么办，即可能有多个executor都收到了RowGroup的处理请求，并分别逻辑持有一部分block数据。
当每个executor收到task对应的split信息是，读取所在文件的footer meta，拿到所有的rowGroups。用split指定的blocks range，去圈定应该自己处理的rowGroups，包括两种：

• 完全在blocks range里的，肯定是自己处理
• rowGroup中点在range里的，也是自己处理
  为什么采取中点呢，在合理设置的parquet.block.size和hdfs.block.size时，两者的值应该比较接近，那么当一个hdfs block持有row group中点时，它至少拥有一多半的数据。从而保证仅有一个task会处理该rowGroup。