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
