Uh oh!
There was an error while loading. Please reload this page.
[SPARK-16596] [SQL] Refactor DataSourceScanExec to do partition discovery at execution instead of planning time - #14241
[SPARK-16596] [SQL] Refactor DataSourceScanExec to do partition discovery at execution instead of planning time#14241ericl wants to merge 23 commits into
Conversation
rxin
commented
Jul 17, 2016
This doesn't actually give us a way to add additional filter constraints in the physical operator, does it? |
SparkQA
commented
Jul 17, 2016
Test build #62438 has finished for PR 14241 at commit
|
You should be able to add additional filter constraints in buildScan(), e.g. in FileDataSourceStrategy. I don't think it matters too much whether that code is located within buildScan(), or in the operator itself. |
rxin
commented
Jul 19, 2016
| // Metadata keys | ||
| val INPUT_PATHS = "InputPaths" | ||
| val PUSHED_FILTERS = "PushedFilters" | ||
| private def genCodeColumnVector(ctx: CodegenContext, columnVar: String, ordinal: String, |
There was a problem hiding this comment.
All these functions below were moved verbatim.
SparkQA
commented
Jul 20, 2016
Test build #62619 has finished for PR 14241 at commit
|
SparkQA
commented
Jul 20, 2016
Test build #62623 has finished for PR 14241 at commit
|
SparkQA
commented
Jul 20, 2016
Test build #62624 has finished for PR 14241 at commit
|
SparkQA
commented
Jul 20, 2016
Test build #62625 has finished for PR 14241 at commit
|
SparkQA
commented
Jul 20, 2016
Test build #62627 has finished for PR 14241 at commit
|
SparkQA
commented
Jul 21, 2016
Test build #62691 has finished for PR 14241 at commit
|
| override val outputPartitioning: Partitioning, | ||
| override val metadata: Map[String, String], | ||
| outputSchema: StructType, | ||
| partitionFilters: Seq[Expression], |
There was a problem hiding this comment.
can you add classdoc documenting what partitionFilters and dataFilters do? It's a little bit confusing because they are both filters, but have different types.
There was a problem hiding this comment.
BTW in order to make this more dynamic, we'd need to make these mutable.
SparkQA
commented
Jul 25, 2016
Test build #62845 has finished for PR 14241 at commit
|
SparkQA
commented
Jul 26, 2016
Test build #62847 has finished for PR 14241 at commit
|
| val agged = spark.table("bucketed_table").groupBy("i").count() | ||
| val error = intercept[RuntimeException] { | ||
| val error = intercept[Exception] { |
There was a problem hiding this comment.
NIT: we cannot catch the proper exception?
There was a problem hiding this comment.
It's a nested exception, which is quite hard to match. The following assert checks for the right error message, which is the important bit I think.
hvanhovell
commented
Jul 27, 2016
This looks pretty good. I have left a few comments. |
| /** Physical plan node for scanning data from a batched relation. */ | ||
| private[sql] case class BatchedDataSourceScanExec( | ||
| /** | ||
| * Physical plan node for scanning data from files. |
SparkQA
commented
Jul 28, 2016
Test build #62979 has finished for PR 14241 at commit
|
| } | ||
| // Ignore rdd when checking results | ||
| override def sameResult(plan: SparkPlan): Boolean = plan match { |
davies
commented
Aug 2, 2016
LGTM |
SparkQA
commented
Aug 2, 2016
Test build #63139 has finished for PR 14241 at commit
|
SparkQA
commented
Aug 3, 2016
Test build #63141 has finished for PR 14241 at commit
|
davies
commented
Aug 3, 2016
@hvanhovell Have you finished your round of review? |
hvanhovell
commented
Aug 3, 2016
LGTM |
davies
commented
Aug 3, 2016
Merging this into master, thanks! |
What changes were proposed in this pull request?
Partition discovery is rather expensive, so we should do it at execution time instead of during physical planning. Right now there is not much benefit since ListingFileCatalog will read scan for all partitions at planning time anyways, but this can be optimized in the future. Also, there might be more information for partition pruning not available at planning time.
This PR moves a lot of the file scan logic from planning to execution time. All file scan operations are handled by
FileSourceScanExec, which handles both batched and non-batched file scans. This requires some duplication withRowDataSourceScanExec, but is probably worth it so thatFileSourceScanExecdoes not need to depend on an input RDD.TODO: In another pr, move DataSourceScanExec to it's own file.
How was this patch tested?
Existing tests (it might be worth adding a test that catalog.listFiles() is delayed until execution, but this can be delayed until there is an actual benefit to doing so).