Github user squito commented on a diff in the pull request:

    https://github.com/apache/spark/pull/8760#discussion_r42008413
  
    --- Diff: 
core/src/main/scala/org/apache/spark/scheduler/BlacklistStrategy.scala ---
    @@ -0,0 +1,134 @@
    +/*
    + * 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 scala.collection.mutable
    +
    +import org.apache.spark.Logging
    +import org.apache.spark.SparkConf
    +import org.apache.spark.util.SystemClock
    +
    +/**
    + * The interface to determine executor blacklist and node blacklist.
    + */
    +trait BlacklistStrategy {
    +  val expireTimeInMillisecond: Long
    +
    +  // Return executors in blacklist which are related to given TaskId
    +  def getExecutorBlacklist(
    +      executorIdToFailureStatus: mutable.HashMap[String, FailureStatus],
    +      taskId: Long): Set[String]
    +
    +  // Return all nodes in blacklist
    +  def getNodeBlacklist(
    +      executorIdToFailureStatus: mutable.HashMap[String, FailureStatus]): 
Set[String]
    +
    +  // Default implementation to remove failure executors from HashMap based 
on given time period.
    +  def expireExecutorsInBlackList(
    +      executorIdToFailureStatus: mutable.HashMap[String, FailureStatus]): 
Unit = {
    +    val now = new SystemClock().getTimeMillis()
    +    executorIdToFailureStatus.retain((executorid, failureStatus) => {
    +      (now - failureStatus.updatedTime) < expireTimeInMillisecond
    +    })
    +  }
    +}
    +
    +/**
    + * This strategy is simply based on given threshold and is taskId 
unrelated. An executor will be
    + * in blacklist, if it failed more than "maxFailureTaskNumber" times. A 
node will be in blacklist,
    + * if there are more than "maxBlackExecutorNumber" executors on it in 
executor blacklist.
    + *
    + * In this case, provided taskId will be ignored. The benefit for taskId 
unrelated strategy is that
    + * different taskSets can learn experience from other taskSet to avoid 
allocating tasks on
    + * problematic executors.
    + */
    +class SimpleStrategy(
    +    maxFailureTaskNumber: Int,
    +    maxBlackExecutorNumber: Int,
    +    val expireTimeInMillisecond: Long
    +  )extends BlacklistStrategy {
    +
    +  private def getSelectedExecutorMap(
    +      executorIdToFailureStatus: mutable.HashMap[String, FailureStatus]) = 
{
    +    executorIdToFailureStatus.filter{
    +      case (id, failureStatus) => failureStatus.totalNumFailures > 
maxFailureTaskNumber
    +    }
    +  }
    +
    +  // As this is a taskId unrelated strategy, the input taskId will be 
ignored
    +  def getExecutorBlacklist(
    +      executorIdToFailureStatus: mutable.HashMap[String, FailureStatus],
    +      taskId: Long): Set[String] = {
    +    getSelectedExecutorMap(executorIdToFailureStatus).keys.toSet
    +  }
    +
    +  def getNodeBlacklist(
    +      executorIdToFailureStatus: mutable.HashMap[String, FailureStatus]): 
Set[String] = {
    +    getSelectedExecutorMap(executorIdToFailureStatus)
    +      .groupBy{case (id, failureStatus) => failureStatus.host}
    +      .filter {case (host, executorIdToFailureStatus) =>
    +        executorIdToFailureStatus.size > maxBlackExecutorNumber}
    +      .keys.toSet
    +  }
    +}
    +
    +/**
    + * This strategy is applied as default to keep the same semantics as 
original. It's an taskId
    + * related strategy. If an executor failed running "task A", then we think 
this executor is
    + * blacked for "task A". And we think the executor is still healthy for 
other task. node blacklist
    + * is always empty.
    + *
    + * It was the standard behavior before spark 1.6
    + */
    +class DefaultStrategy(val expireTimeInMillisecond: Long) extends 
BlacklistStrategy {
    +  def getExecutorBlacklist(
    +      executorIdToFailureStatus: mutable.HashMap[String, FailureStatus],
    +      taskId: Long): Set[String] = {
    +    executorIdToFailureStatus.filter{
    +      case (_, failureStatus) => 
failureStatus.numFailuresPerTask.keySet.contains(taskId)
    +    }.keys.toSet
    +  }
    +
    +  def getNodeBlacklist(
    +      executorIdToFailureStatus: mutable.HashMap[String, FailureStatus]): 
Set[String] =
    +        Set.empty[String]
    +}
    +
    +/**
    + * Create BlacklistStrategy instance according to SparkConf
    + */
    +object BlacklistStrategy {
    +  def apply(sparkConf: SparkConf): BlacklistStrategy = {
    +    val timeout = 
sparkConf.getLong("spark.scheduler.executorTaskBlacklistTime", 0L)
    +    sparkConf.get("spark.scheduler.blacklist.strategy", "default") match {
    +      case "default" =>
    +        new DefaultStrategy(timeout)
    +      case "threshold" =>
    +        new SimpleStrategy(
    +            
sparkConf.getInt("spark.scheduler.blacklist.threshold.maxFailureTaskNumber", 3),
    +            
sparkConf.getInt("spark.scheduler.blacklist.threshold.maxBlackExecutorNumber", 
3),
    +            timeout)
    +      case "strict" =>
    +        // A special case of SimpleStrategy: Once task failed  at executor,
    +        // put the executor and its node into blacklist.
    +        new SimpleStrategy(0, 0, timeout)
    --- End diff --
    
    I don't really see the point of adding "strict" -- do you think it will be 
a very common use case?  Otherwise its just another thing to document and might 
confuse users a bit.
    
    I'd also like to think of better names for the other strategies as well.  
It seems the key difference is whether or not they are task-specific, which 
isn't very clear from "default" and "threshold".  I'm terrible at naming myself 
... something like "singleTask" and "completeExecutor"?


---
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

Reply via email to