Github user andreweduffy commented on a diff in the pull request: https://github.com/apache/spark/pull/15835#discussion_r87500313 --- Diff: sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetFileFormat.scala --- @@ -272,6 +275,83 @@ class ParquetFileFormat true } + override def getSplits(fileIndex: FileIndex, + fileStatus: FileStatus, + filters: Seq[Filter], + schema: StructType, + hadoopConf: Configuration): Seq[FileSplit] = { + if (filters.isEmpty) { + // Return immediately to save FileSystem overhead + super.getSplits(fileIndex, fileStatus, filters, schema, hadoopConf) + } else { + val filePath = fileStatus.getPath + val rootOption: Option[Path] = fileIndex.rootPaths + .find(root => filePath.toString.startsWith(root.toString)) + val metadataOption = rootOption.flatMap(getMetadataForPath(filePath, _, hadoopConf)) + // If the metadata exists, filter the splits. + // Otherwise, fall back to the default implementation. + metadataOption + .map(filterToSplits(fileStatus, _, rootOption.get, filters, schema, hadoopConf)) + .getOrElse(super.getSplits(fileIndex, fileStatus, filters, schema, hadoopConf)) + } + } + + private def filterToSplits(fileStatus: FileStatus, + metadata: ParquetMetadata, + metadataRoot: Path, + filters: Seq[Filter], + schema: StructType, + hadoopConf: Configuration): Seq[FileSplit] = { + val metadataBlocks = metadata.getBlocks + val parquetSchema = metadata.getFileMetaData.getSchema + val filter = FilterCompat.get(filters + .flatMap(ParquetFilters.createFilter(schema, _)) + .reduce(FilterApi.and)) + val filteredMetadata = + RowGroupFilter.filterRowGroups(filter, metadataBlocks, parquetSchema).asScala + filteredMetadata.flatMap(bmd => { + val bmdPath = new Path(metadataRoot, bmd.getPath) + val fsPath = fileStatus.getPath + if (bmdPath == fsPath) { + Some(new FileSplit(bmdPath, bmd.getStartingPos, bmd.getTotalByteSize, Array.empty)) + } else { + None + } + }) + } + + private def getMetadataForPath(filePath: Path, --- End diff -- I think this should be cacheable, as the lifetime of a `FileFormat` is tied to a particular `HadoopFsRelation`, which again is tied to a `Dataset`. Something may have changed about the API but from a quick look through the relevant classes I don't see anything to refute this. I don't see any written guarantees in the FileFormat API that concrete impls need to be stateless, but neither did I find any reference to caching/state in other implementations. Still I think it should be safe to cache on the ParquetFileFormat for this use case.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- --------------------------------------------------------------------- To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org For additional commands, e-mail: reviews-h...@spark.apache.org