-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-45771][CORE] Enable spark.eventLog.rolling.enabled by default
#43638
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
Conversation
spark.eventLog.rolling.enabled by default
3798eb7 to
2aa7f1e
Compare
2aa7f1e to
be50e5d
Compare
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.
This is consistent with the existing function description.
spark/core/src/test/scala/org/apache/spark/deploy/history/EventLogTestHelper.scala
Line 35 in 5970d35
| * Get a SparkConf with event logging enabled. It doesn't enable rolling event logs, so caller |
be50e5d to
b918798
Compare
|
AppVeyor failure (SparkR) is irrelevant to this PR. Could you review this PR when you have some time, @viirya? |
| buildWriterAndVerify(conf, classOf[SingleEventLogFileWriter]) | ||
| buildWriterAndVerify(conf, classOf[RollingEventLogFilesWriter]) | ||
|
|
||
| conf.set(EVENT_LOG_ENABLE_ROLLING, true) |
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.
Is it redundant then?
| conf.set(EVENT_LOG_ENABLE_ROLLING, true) |
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.
Or we want to:
| conf.set(EVENT_LOG_ENABLE_ROLLING, true) | |
| conf.set(EVENT_LOG_ENABLE_ROLLING, false) | |
| buildWriterAndVerify(conf, classOf[SingleEventLogFileWriter]) |
| buildWriterAndVerify(conf, classOf[RollingEventLogFilesWriter]) | ||
|
|
||
| conf.set(EVENT_LOG_ENABLE_ROLLING, true) | ||
| buildWriterAndVerify(conf, classOf[RollingEventLogFilesWriter]) |
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.
| buildWriterAndVerify(conf, classOf[RollingEventLogFilesWriter]) |
| test("SPARK-31764: isBarrier should be logged in event log") { | ||
| val conf = new SparkConf() | ||
| conf.set(EVENT_LOG_ENABLED, true) | ||
| conf.set(EVENT_LOG_ENABLE_ROLLING, false) |
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.
Is it failed without setting to false?
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.
Yes, this test case tries to read the event log file.
|
Just for your confirmation. I keep the existing test structure. Do you mean to simplify like the following. |
|
Oh, got it, existing one looks good. From the diff, I cannot see it so I thought |
|
Thank you for your confirmation! Merged to master for Apache Spark 4.0.0. |
### What changes were proposed in this pull request? This PR aims to enable `spark.eventLog.rolling.enabled` by default for Apache Spark 4.0.0. ### Why are the changes needed? Since Apache Spark 3.0.0, we have been using event log rolling not only for **long-running jobs**, but also for **some failed jobs** to archive the partial event logs incrementally. - apache#25670 ### Does this PR introduce _any_ user-facing change? - No because `spark.eventLog.enabled` is disabled by default. - For the users with `spark.eventLog.enabled=true`, yes, `spark-events` directory will have different layouts. However, all 3.3+ `Spark History Server` can read both old and new event logs. I believe that the event log users are already using this configuration to avoid the loss of event logs for long-running jobs and some failed jobs. ### How was this patch tested? Pass the CIs. ### Was this patch authored or co-authored using generative AI tooling? No. Closes apache#43638 from dongjoon-hyun/SPARK-45771. Authored-by: Dongjoon Hyun <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]>
### What changes were proposed in this pull request? Add `Spark History Server` example. ### Why are the changes needed? Since Apache Spark 4.0, Spark rolls the event logs by default and compressed them by default. - apache/spark#43638 - apache/spark#43036 However, we still need more configurations to allow SHS manages the event log directories. This PR aims to provide an example of `Spark History Server` with the configuration. ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? Manual review. ### Was this patch authored or co-authored using generative AI tooling? No. Closes #249 from dongjoon-hyun/SPARK-52481. Authored-by: Dongjoon Hyun <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]>
…in `History Server`
### What changes were proposed in this pull request?
This PR aims to support `On-Demand Log Loading` in `History Server` by looking up the **rolling event log locations** even Spark listing didn't finish to load the event log files.
```scala
val EVENT_LOG_ROLLING_ON_DEMAND_LOAD_ENABLED =
ConfigBuilder("spark.history.fs.eventLog.rolling.onDemandLoadEnabled")
.doc("Whether to look up rolling event log locations on demand manner before listing files.")
.version("4.1.0")
.booleanConf
.createWithDefault(true)
```
Previously, Spark History Server will show `Application ... Not Found` page if a job is requested before scanning it even if the file exists in the correct location. So, this PR doesn't introduce any regressions because this aims to introduce a kind of fallback logic to improve error handling .
<img width="686" height="359" alt="Screenshot 2025-07-22 at 14 08 21" src="https://github.com/user-attachments/assets/fccb413c-5a57-4918-86c0-28ae81d54873" />
### Why are the changes needed?
Since Apache Spark 3.0, we have been using event log rolling not only for **long-running jobs**, but also for **some failed jobs** to archive the partial event logs incrementally.
- #25670
Since Apache Spark 4.0, event log rolling is enabled by default.
- #43638
On top of that, this PR aims to reduce storage cost at Apache Spark 4.1. By supporting `On-Demand Loading for rolled event logs`, we can use larger values for `spark.history.fs.update.interval` instead of the default `10s`. Although Spark History logs are consumed in various ways, It has a big benefit because most of successful Spark jobs's logs are not visited by the users.
### Does this PR introduce _any_ user-facing change?
No. This is a new feature.
### How was this patch tested?
Pass the CIs with newly added test case.
### Was this patch authored or co-authored using generative AI tooling?
No.
Closes #51604 from dongjoon-hyun/SPARK-52914.
Authored-by: Dongjoon Hyun <[email protected]>
Signed-off-by: Dongjoon Hyun <[email protected]>
What changes were proposed in this pull request?
This PR aims to enable
spark.eventLog.rolling.enabledby default for Apache Spark 4.0.0.Why are the changes needed?
Since Apache Spark 3.0.0, we have been using event log rolling not only for long-running jobs, but also for some failed jobs to archive the partial event logs incrementally.
Does this PR introduce any user-facing change?
spark.eventLog.enabledis disabled by default.spark.eventLog.enabled=true, yes,spark-eventsdirectory will have different layouts. However, all 3.3+Spark History Servercan read both old and new event logs. I believe that the event log users are already using this configuration to avoid the loss of event logs for long-running jobs and some failed jobs.How was this patch tested?
Pass the CIs.
Was this patch authored or co-authored using generative AI tooling?
No.