-
Notifications
You must be signed in to change notification settings - Fork 28.9k
[SPARK-14467][SQL] Interleave CPU and IO better in FileScanRDD. #12243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -17,10 +17,14 @@ | |
|
|
||
| package org.apache.spark.sql.execution.datasources | ||
|
|
||
| import scala.concurrent.{Await, ExecutionContext, Future} | ||
| import scala.concurrent.duration.Duration | ||
|
|
||
| import org.apache.spark.{Partition, TaskContext} | ||
| import org.apache.spark.rdd.{RDD, SqlNewHadoopRDDState} | ||
| import org.apache.spark.sql.SQLContext | ||
| import org.apache.spark.sql.catalyst.InternalRow | ||
| import org.apache.spark.util.ThreadUtils | ||
|
|
||
| /** | ||
| * A single file that should be read, along with partition column values that | ||
|
|
@@ -46,37 +50,80 @@ case class PartitionedFile( | |
| */ | ||
| case class FilePartition(index: Int, files: Seq[PartitionedFile]) extends Partition | ||
|
|
||
| object FileScanRDD { | ||
| private val ioExecutionContext = ExecutionContext.fromExecutorService( | ||
| ThreadUtils.newDaemonCachedThreadPool("FileScanRDD", 16)) | ||
| } | ||
|
|
||
| class FileScanRDD( | ||
| @transient val sqlContext: SQLContext, | ||
| readFunction: (PartitionedFile) => Iterator[InternalRow], | ||
| @transient val filePartitions: Seq[FilePartition]) | ||
| extends RDD[InternalRow](sqlContext.sparkContext, Nil) { | ||
|
|
||
| /** | ||
| * To get better interleaving of CPU and IO, this RDD will create a future to prepare the next | ||
| * file while the current one is being processed. `currentIterator` is the current file and | ||
| * `nextFile` is the future that will initialize the next file to be read. This includes things | ||
| * such as starting up connections to open the file and any initial buffering. The expectation | ||
| * is that `currentIterator` is CPU intensive and `nextFile` is IO intensive. | ||
| */ | ||
| val asyncIO = sqlContext.conf.filesAsyncIO | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we mark |
||
|
|
||
| case class NextFile(file: PartitionedFile, iter: Iterator[Object]) | ||
|
|
||
| override def compute(split: Partition, context: TaskContext): Iterator[InternalRow] = { | ||
| val iterator = new Iterator[Object] with AutoCloseable { | ||
| private[this] val files = split.asInstanceOf[FilePartition].files.toIterator | ||
| // TODO: do we need to close this? | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what does this todo mean? |
||
| private[this] var currentIterator: Iterator[Object] = null | ||
|
|
||
| private[this] var nextFile: Future[NextFile] = if (asyncIO) prepareNextFile() else null | ||
|
|
||
| def hasNext = (currentIterator != null && currentIterator.hasNext) || nextIterator() | ||
| def next() = currentIterator.next() | ||
|
|
||
| /** Advances to the next file. Returns true if a new non-empty iterator is available. */ | ||
| private def nextIterator(): Boolean = { | ||
| if (files.hasNext) { | ||
| val nextFile = files.next() | ||
| logInfo(s"Reading File $nextFile") | ||
| SqlNewHadoopRDDState.setInputFileName(nextFile.filePath) | ||
| currentIterator = readFunction(nextFile) | ||
| hasNext | ||
| val file = if (asyncIO) { | ||
| if (nextFile == null) return false | ||
| // Wait for the async task to complete | ||
| Await.result(nextFile, Duration.Inf) | ||
| } else { | ||
| SqlNewHadoopRDDState.unsetInputFileName() | ||
| false | ||
| if (!files.hasNext) return false | ||
| val f = files.next() | ||
| NextFile(f, readFunction(f)) | ||
| } | ||
|
|
||
| // This is only used to evaluate the rest of the execution so we can safely set it here. | ||
| SqlNewHadoopRDDState.setInputFileName(file.file.filePath) | ||
| currentIterator = file.iter | ||
|
|
||
| if (asyncIO) { | ||
| // Asynchronously start the next file. | ||
| nextFile = prepareNextFile() | ||
| } | ||
|
|
||
| hasNext | ||
| } | ||
|
|
||
| override def close() = { | ||
| SqlNewHadoopRDDState.unsetInputFileName() | ||
| } | ||
|
|
||
| def prepareNextFile() = { | ||
| if (files.hasNext) { | ||
| Future { | ||
| val file = files.next() | ||
| val it = readFunction(file) | ||
| // Read something from the file to trigger some initial IO. | ||
| it.hasNext | ||
| NextFile(file, it) | ||
| }(FileScanRDD.ioExecutionContext) | ||
| } else { | ||
| null | ||
| } | ||
| } | ||
| } | ||
|
|
||
| // Register an on-task-completion callback to close the input stream. | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should set this to the total number of task slots on the executors, shouldn't we?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't it be the total number of cores the user is willing to dedicate to a single Job? This looks to be similar to an issue in ParquetRelation where a
parallelizecall can end up tying up all of the cores (defaultParallelism) on a single Job. While this PR should allow better progress to be made during that kind of blocking, I'm thinking that what we really need is to implement what was suggested a while ago in the scheduling pools: a max cores limit in addition to the current min cores. With that in place and the max cores value exposed to these large IO operations, users who care about not blocking concurrent Jobs can use pools that neither consume all the available cores nor oversubscribe the cores that the pool does have.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's difficult to model this as the total number of cores because what this is intended to do is background IO and use very little CPU. The async io will still use some CPU resources but expected to be very low, a small fraction of a core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you choose 16? Why not 8? Why not 32?
Would it be better to leave decision points in a comment?