You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@spark.apache.org by GitBox <gi...@apache.org> on 2022/03/15 05:21:58 UTC
[GitHub] [spark] abhishekd0907 opened a new pull request #35858: [SPARK-] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
abhishekd0907 opened a new pull request #35858:
URL: https://github.com/apache/spark/pull/35858
<!--
Thanks for sending a pull request! Here are some tips for you:
1. If this is your first time, please read our contributor guidelines: https://spark.apache.org/contributing.html
2. Ensure you have added or run the appropriate tests for your PR: https://spark.apache.org/developer-tools.html
3. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP][SPARK-XXXX] Your PR title ...'.
4. Be sure to keep the PR description updated to reflect all changes.
5. Please write your PR title to summarize what this PR proposes.
6. If possible, provide a concise example to reproduce the issue for a faster review.
7. If you want to add a new configuration, please read the guideline first for naming configurations in
'core/src/main/scala/org/apache/spark/internal/config/ConfigEntry.scala'.
8. If you want to add or modify an error type or message, please read the guideline first in
'core/src/main/resources/error/README.md'.
-->
### What changes were proposed in this pull request?
Yarn Cluster Manager Provides information on available resources (VCores / Memory) in the Cluster via AM-RM heartbeat. This change Sends Available VCores and Memory information from Yarn AM-RM heartbeat response to Spark Driver
<!--
Please clarify what changes you are proposing. The purpose of this section is to outline the changes and how this PR fixes the issue.
If possible, please consider writing useful notes for better and faster reviews in your PR. See the examples below.
1. If you refactor some codes with changing classes, showing the class hierarchy will help reviewers.
2. If you fix some SQL features, you can provide some references of other DBMSes.
3. If there is design documentation, please add the link.
4. If there is a discussion in the mailing list, please add the link.
-->
### Why are the changes needed?
This change is needed for [SPARK-38447](https://issues.apache.org/jira/browse/SPARK-38447). This change will send available resources information to Spark Driver which will be useful in deciding target executors by Dynamic Allocation.
<!--
Please clarify why the changes are needed. For instance,
1. If you propose a new API, clarify the use case for a new API.
2. If you fix a bug, you can clarify why it is a bug.
-->
### Does this PR introduce _any_ user-facing change?
No
<!--
Note that it means *any* user-facing change including all aspects such as the documentation fix.
If yes, please clarify the previous behavior and the change this PR proposes - provide the console output, description and/or an example to show the behavior difference if possible.
If possible, please also clarify if this is a user-facing change compared to the released Spark versions or within the unreleased branches such as master.
If no, write 'No'.
-->
### How was this patch tested?
New Unit Test added and all existing Unit Tests should pass
<!--
If tests were added, say they were added here. Please make sure to add some test cases that check the changes thoroughly including negative and positive cases if possible.
If it was tested in a way different from regular unit tests, please clarify how you tested step by step, ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future.
If tests were not added, please describe why they were not added and/or why it was difficult to add.
If benchmark tests were added, please run the benchmarks in GitHub Actions for the consistent environment, and the instructions could accord to: https://spark.apache.org/developer-tools.html#github-workflow-benchmarks.
-->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] abhishekd0907 edited a comment on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
abhishekd0907 edited a comment on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1075221525
@tgravescs @mridulm
Let me know your thoughts, For my system where the latency of adding a new node is of the order of a few minutes (~2-5 mins), it makes sense to account for the scale-up latency and number of nodes immediately available before requesting new executors to avoid wasted scale-ups. I can share some statistics on how it helps in my system. But if you guys think I am discussing a rare scenario and environments where people generally run Spark don't have such high latencies, I can drop this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] tgravescs commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
tgravescs commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1070981659
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] AmplabJenkins commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
AmplabJenkins commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1068006020
Can one of the admins verify this patch?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] mridulm commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
mridulm commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1069673078
Whether to acquire more resources or not is a policy decision at resource manager, not at the application level.
Spark modulates the outstanding requests for containers based on the progress of its jobs - it does not know apriori what the expected runtime of a task is. If more tasks complete quickly, the outstanding container requests will go down, - or go up as the number of pending tasks increase.
Resource manager will be factoring in a variety of policy decisions - quota enforcement, acquisition of resources, preemption of existing containers, etc in order to satisfy resource asks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] abhishekd0907 commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
abhishekd0907 commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1072285103
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] mridulm commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
mridulm commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1070319149
+CC @tgravescs
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] abhishekd0907 commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
abhishekd0907 commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1068737949
> Why does spark driver need to be aware of what the cluster size is ? It should ask for the resources it requires to run the application, and it is for the resource manager to handle cross application/cluster wide requirements.
@mridulm
In Yarn Clusters, starting a new executor container on an already existing node has very small latency (a few seconds) but bringing up a new node might take more time (order of few hundred seconds). Dynamic Allocation can factor in this information while requesting executors from resource manager. For example, if spark is running on a single one-core executor and there is one active stage, with 100 pending tasks, and average task time of tasks completed so far is 1 second, then expected time to complete the stage with single executor will be 100 seconds. If the latency to bring up a new node is 2 minutes (120 seconds), then it doesn't make sense to request executors because all tasks will be finished before the second executor is added. However, if there is a free node already present in the cluster, a new executor can be started on that node immediately, and some of the pending tasks can be scheduled on the new executor.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] abhishekd0907 commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
abhishekd0907 commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1072285103
> Yeah, the resources available on a large cluster can change very rapidly and it should not be relied upon. I guess your proposal here is to specifically request hosts? In some ways this is like the locality requests, but there is no way to guarantee what YARN told you was available in one heartbeat will still be available in the next one. Spark can figure out what it wants for requirements - locality for data, networks, etc.. but seems very perilous to try to assume we can know what YARN is doing. Even with likely data locality, generally you have 3 replicas and request 3 hosts and it only tries to get those for a limited amount of time. I have seen way to many times we request specific hosts and jobs take longer because of it vs just running on what is available (which YARN decides).
>
> In the end what is your end goal by making these changes?
@tgravescs @mridulm
In most of the Yarn Cluster setups, starting a new executor container on an already existing node has very small latency (a few seconds) but bringing up a new node might take more time (order of few hundred seconds). Currently, Dynamic Allocation doesn't know the number of nodes immediately available and it just requests executors based on the parallelism requirement of active stages. So the requested executors may be a) allocated immediately (if there are free nodes in Yarn cluster) or b) requested executors may be allocated with a few mins of delay (if there are no free nodes and Yarn needs to request new nodes). However, if no nodes are immediately available in the cluster and the latency to add a new node is high, it may not make sense to request for more executors since all the tasks in the active stage may finish off before a new executor can get allocated. Hence the cluster scale up is wasted. For example, if spark application is running on a single one-core executor and t
here is one active stage, with 100 pending tasks, and average task time of tasks completed so far is 1 second, then expected time to complete the stage with single executor will be 100 seconds. If the latency to bring up a new node is 2 minutes (120 seconds), then it doesn't make sense to request executors because all tasks will be finished before the second executor is added. However, if there is a free node already present in the cluster, a new executor can be started on that node immediately, and some of the pending tasks can be scheduled on the new executor.
I agree with your assessment that resources available on a large cluster can change very rapidly and there is no way to guarantee what YARN told you was available in one heartbeat will still be available in the next one, especially if there are multiple applications running on the cluster and all of them are dynamically requesting for resources. However, we can write a best effort self-correcting dynamic allocation logic which can avoid the wasted scaleups discussed above. If the information provided by Yarn is incorrect, Dynamic Allocation can request for more executors in the next iteration. Moreover, since the Dynamic Allocation logic will be configurable, user can choose to use it only for workloads where it works best, for example where single application runs on Spark cluster at a time and information of immediately available resources provided by Yarn is relatively more reliable.
Let me know your thoughts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] abhishekd0907 commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
abhishekd0907 commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1075221525
@tgravescs @mridulm
Let me know your thoughts, For my system where the latency of adding a new node is of the order of a few minutes (~2-5 mins), it makes sense to account for the scale-up latency and number of nodes immediately available before requesting new executors to avoid wasted scale-ups. I can share some statistics on how it helps in my system. But if you guys think I am discussing a rare scenario and it will not help Spark users in general, I can drop this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] mridulm commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
mridulm commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1068665753
Why does spark driver need to be aware of what the cluster size is ? It should ask for the resources it requires to run the application, and it is for the resource manager to handle cross application/cluster wide requirements.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] tgravescs commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
tgravescs commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1070981659
Yeah, the resources available on a large cluster can change very rapidly and it should not be relied upon. I guess your proposal here is to specifically request hosts? In some ways this is like the locality requests, but there is no way to guarantee what YARN told you was available in one heartbeat will still be available in the next one. Spark can figure out what it wants for requirements - locality for data, networks, etc.. but seems very perilous to try to assume we can know what YARN is doing. Even with likely data locality, generally you have 3 replicas and request 3 hosts and it only tries to get those for a limited amount of time. I have seen way to many times we request specific hosts and jobs take longer because of it vs just running on what is available (which YARN decides).
In the end what is your end goal by making these changes?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] tgravescs commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
tgravescs commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1072423356
> all the tasks in the active stage may finish off before a new executor can get allocated
This means application master has to know task times so be able to judge this, if it judges wrong you just wasted time waiting to allocate as well. it has to know the time to get new node and time of other applications to release containers. Yes I'm sure there are cases it makes sense but there are a lot of factors that come into play.
> and Yarn needs to request new nodes
Are you running in some environment where yarn cluster grows dynamically? normally yarn doesn't get new nodes, you have a set of nodes and it allocates containers on them. I don't understand why starting a container on one would take much longer then another other then downloading artifacts, which the majority should be in distributed cache and overhead should be small.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] mridulm edited a comment on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
mridulm edited a comment on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1070319149
+CC @tgravescs. If you have thoughts on it Tom.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
[GitHub] [spark] abhishekd0907 commented on pull request #35858: [SPARK-38448] [YARN] [CORE] Sending Available Resources in Yarn Cluster Information to Spark Driver
Posted by GitBox <gi...@apache.org>.
abhishekd0907 commented on pull request #35858:
URL: https://github.com/apache/spark/pull/35858#issuecomment-1070358079
> Whether to acquire more resources or not is a policy decision at resource manager, not at the application level. Spark modulates the outstanding requests for containers based on the progress of its jobs - it does not know apriori what the expected runtime of a task is. If more tasks complete quickly, the outstanding container requests will go down, - or go up as the number of pending tasks increase.
>
> Resource manager will be factoring in a variety of policy decisions - quota enforcement, acquisition of resources, preemption of existing containers, etc in order to satisfy resource asks.
I believe there is some merit in estimating the expected completion time of a stage based on run times of already completed tasks of the same stage. I agree this estimation will not be correct always, especially in cases where task times are skewed. But I believe we can come up with a best effort, data-driven, self-correcting logic and leverage it while requesting new executors. New Dynamic allocation logic will incorporate three key pieces of information, a) estimated completion time of active stages, b) nodes immediately available, and c) latency in adding new nodes. We can also make this new Dynamic Allocation logic configurable by leveraging the Resource Profiles framework and user can configure to use it only for workloads where it works better than DefaultResourceProfile.
Let me know your thoughts @mridulm and let me know if I am missing some points.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org