Github user squito commented on a diff in the pull request:
https://github.com/apache/spark/pull/8760#discussion_r42041212
--- Diff:
core/src/main/scala/org/apache/spark/scheduler/BlacklistTracker.scala ---
@@ -0,0 +1,243 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.spark.scheduler
+
+import java.util.concurrent.TimeUnit
+
+import scala.collection.mutable
+
+import org.apache.spark.SparkConf
+import org.apache.spark.Success
+import org.apache.spark.TaskEndReason
+import org.apache.spark.annotation.DeveloperApi
+import org.apache.spark.util.SystemClock
+import org.apache.spark.util.ThreadUtils
+import org.apache.spark.util.Utils
+
+
+/**
+ * BlacklistTracker is design to track problematic executors and node on
application level.
+ * It is shared by all TaskSet, so that once a new TaskSet coming, it
could be benefit from
+ * previous experience of other TaskSet.
+ *
+ * Once task finished, the callback method in TaskSetManager should update
+ * executorIdToFailureStatus Map.
+ */
+private[spark] class BlacklistTracker(sparkConf: SparkConf) extends
WithCache{
+ // maintain a ExecutorId --> FailureStatus HashMap
+ private val executorIdToFailureStatus: mutable.HashMap[String,
FailureStatus] = mutable.HashMap()
+
+ // Apply Strategy pattern here to change different blacklist detection
logic
+ private val strategy = BlacklistStrategy(sparkConf)
+
+ // A daemon thread to expire blacklist executor periodically
+ private val scheduler =
ThreadUtils.newDaemonSingleThreadScheduledExecutor(
+ "spark-scheduler-blacklist-expire-timer")
+
+ private val clock = new SystemClock()
+
+ private val enableBlacklistSpeculate = sparkConf.getBoolean(
+ "spark.scheduler.blacklist.speculate", false)
+
+ private val recoverPeriod = sparkConf.getLong(
+ "spark.scheduler.blacklist.recoverPeriod", 60L)
+
+ def start(): Unit = {
+ val scheduleTask = new Runnable() {
+ override def run(): Unit = {
+
Utils.logUncaughtExceptions(expireExecutorsInBlackList(executorIdToFailureStatus))
+ }
+ }
+ scheduler.scheduleAtFixedRate(scheduleTask, 0L, recoverPeriod,
TimeUnit.SECONDS)
+ }
+
+ def stop(): Unit = {
+ scheduler.shutdown()
+ scheduler.awaitTermination(10, TimeUnit.SECONDS)
+ }
+
+ // The actual implementation is delegated to strategy
+ private def expireExecutorsInBlackList(
+ executorIdToFailureStatus: mutable.HashMap[String, FailureStatus]):
Unit = synchronized {
+ strategy.expireExecutorsInBlackList(executorIdToFailureStatus)
+
+ invalidAllCache()
+ }
+
+ def updateFailureExecutors(info: TaskInfo, reason: TaskEndReason) : Unit
= synchronized {
+ reason match {
+ // If task succeeding, remove related record from
executorIdToFailureStatus
+ case Success =>
+ removeFailureExecutorsForTaskId(info.executorId, info.taskId)
+
+ // If task failing, update latest failure time and failedTaskIds
+ case _ =>
+ val executorId = info.executorId
+ executorIdToFailureStatus.get(executorId) match {
+ case Some(failureStatus) =>
+ failureStatus.updatedTime = clock.getTimeMillis()
+ val failedTimes =
failureStatus.numFailuresPerTask.getOrElse(info.taskId, 0) + 1
+ failureStatus.numFailuresPerTask.update(info.taskId,
failedTimes)
+ case None =>
+ val failedTasks = mutable.HashMap(info.taskId -> 1)
+ val failureStatus = new FailureStatus(
+ clock.getTimeMillis(),
+ info.host,
+ failedTasks)
+ executorIdToFailureStatus.update(executorId, failureStatus)
+ }
+ invalidAllCache()
+ }
+ }
+
+ // remove the executorId from executorIdToFailureStatus
+ def removeFailureExecutors(executorId: String) : Unit = synchronized {
+ executorIdToFailureStatus.remove(executorId)
+ invalidAllCache()
+ }
+
+ // remove the failure record related to given taskId from
executorIdToFailureStatus. If the
+ // number of records of given executorId becomes 0, remove the completed
executorId.
+ def removeFailureExecutorsForTaskId(
+ executorId: String,
+ taskId: Long) : Unit = synchronized {
+ executorIdToFailureStatus.get(executorId).map(fs => {
+ fs.numFailuresPerTask.remove(taskId)
+ if(fs.numFailuresPerTask.isEmpty){
+ executorIdToFailureStatus.remove(executorId)
+ }
+ invalidAllCache()
+ })
+ }
+
+ def executorIsBlacklisted(
+ executorId: String,
+ sched: TaskSchedulerImpl,
+ taskId: Long) : Boolean = {
+
+ executorBlacklist(sched, taskId).contains(executorId)
+ }
+
+ // If the node is in blacklist, all executors allocated on that node will
+ // also be put into executor blacklist.
+ // By default it's turned off, user can enable it in sparkConf.
+ private def speculationFailedExecutor(
+ sched: TaskSchedulerImpl): Set[String] = {
--- End diff --
I know we discussed this previously, but I still don't really get the point
of "speculation". I don't really see a strong use case, I feel like you'd
always want it to be `true`. It seems that speculation is mostly covered by
the "maxBlackExecutorNumber" conf. If you want to avoid blacklisting nodes,
then you set that value very high; if you want to blacklist nodes as soon as
you think its got back executors, you set it low. The distinction you get with
speculation, is that you would differentiate two different parts of node
blacklisting: (a) do you request new executors on those nodes? and (b) do you
schedule tasks on _existing_ executors on those nodes?
Do we really think that there is an important use case for updating one
without the other? Without a clear use case, I'm against it even just for the
difficulty in clearly documenting to the end user. The name "speculation" is
very confusing to me, but i dunno what else to call it.
Repeating myself again, but if you really want to leave the door open for
some future strategy to distinguish the two, you could change the api:
(a) `BlacklistStrategy.getNodeBlacklist()` is used only in requests to the
cluster manager when requesting new nodes. When scheduling tasks, the tracker
only calls `strategy.getExecutorBlacklist()`
(b) When `SimpleStrategy` adds a blacklisted node, it will also update its
set of blacklisted executors to go along with it (effectively turning on
"speculation") -- but that is now an internal implementation of that particular
strategy.
Then you could still have a different strategy without speculation if you
really wanted it, but again I wouldn't add that till there was a 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 [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
