-
Notifications
You must be signed in to change notification settings - Fork 137
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
[#378] feat: introduce storage manager selector #621
Conversation
Codecov Report
@@ Coverage Diff @@
## master #621 +/- ##
============================================
+ Coverage 60.90% 63.02% +2.11%
- Complexity 1799 1810 +11
============================================
Files 214 204 -10
Lines 12381 10528 -1853
Branches 1042 1056 +14
============================================
- Hits 7541 6635 -906
+ Misses 4437 3547 -890
+ Partials 403 346 -57
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
PTAL @jerqi @xianjingfeng . This is a remaining improvement for #378 |
server/src/main/java/org/apache/uniffle/server/buffer/ShuffleBufferManager.java
Outdated
Show resolved
Hide resolved
server/src/test/java/org/apache/uniffle/server/storage/MultiStorageManagerTest.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/apache/uniffle/server/storage/multi/DefaultStorageManagerSelector.java
Outdated
Show resolved
Hide resolved
@@ -671,7 +671,7 @@ public ShuffleTaskInfo getShuffleTaskInfo(String appId) { | |||
|
|||
private void triggerFlush() { | |||
synchronized (this.shuffleBufferManager) { | |||
this.shuffleBufferManager.flushIfNecessary(); | |||
this.shuffleBufferManager.flushIfNecessary(this::getPartitionDataSize); |
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.
I can get you intention.. But I believe passing the getPartitionDataSize
method ref around is adding a lot of interface change and it's adding maintenance overhead.
How about make ShuffleTaskManager a private field of ShuffleBufferManager? Then all this interface change is unnecessary.
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.
Got it
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.
The shuffleTaskManager
is initialized after creating the instance of ShuffleBufferManager
, emm, we'd better to pass the ShuffleServer
into ShuffleBufferManager
. But it still looks unclear, especially for the dependency of different managers. I have no idea on this.
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.
The shuffleTaskManager is initialized after creating the instance of ShuffleBufferManager, emm, we'd better to pass the ShuffleServer into ShuffleBufferManager. But it still looks unclear, especially for the dependency of different managers. I have no idea on this.
For impl purpose:
ShuffleBufferManager
should expose a setTaskManager
method, and in the construction of ShuffleTaskManager
, it could call shuffleBufferManager.setTaskManager(this)
But I do think the BufferManager
, 'TaskManagerand
FlushManager`'s dependency is unclear and should be refactored in later PRs.
Hi @zuston could you rebase/merge you branch with the latest master branch? I'd like to check whether the CI workflow for operator is worked as expected or not. |
Done |
Thanks. The ci workflow of operator is skipped as expected. |
@@ -76,7 +78,12 @@ public class ShuffleBufferManager { | |||
// appId -> shuffleId -> shuffle size in buffer | |||
protected Map<String, Map<Integer, AtomicLong>> shuffleSizeMap = Maps.newConcurrentMap(); | |||
|
|||
public ShuffleBufferManager(ShuffleServerConf conf, ShuffleFlushManager shuffleFlushManager) { | |||
public ShuffleBufferManager(ShuffleServerConf conf, ShuffleServer shuffleServer) { | |||
this(conf, shuffleServer.getShuffleFlushManager(), shuffleServer.getShuffleTaskManager()); |
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.
I believe shuffleTaskManager should be lazily accessed. It't not initialized yet in https://github.com/apache/incubator-uniffle/pull/621/files#diff-1a1a029f5533bd7f4722cefdc586b5658ca9521bfcc8e817138aa7695c4a4e75R197
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. Fixed
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.
LGTM, except one minor comment
.enumType(StorageManagerSelector.ColdStoragePreferredFactor.class) | ||
.defaultValue(StorageManagerSelector.ColdStoragePreferredFactor.HUGE_EVENT) | ||
.withDescription("The cold storage preferred factor for multiple storage manager. Only the value is " | ||
+ StorageManagerSelector.ColdStoragePreferredFactor.HUGE_EVENT + ", the conf of " |
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 description is a bit hard to read. Would you mind do some rewording here.
I believe we should also update the doc about this new configuration.
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.
Got it.
@@ -263,6 +264,15 @@ public class ShuffleServerConf extends RssBaseConf { | |||
.defaultValue(64L * 1024L * 1024L) | |||
.withDescription("For multistorage, the event size exceed this value, flush data to cold storage"); | |||
|
|||
public static final ConfigOption<StorageManagerSelector.ColdStoragePreferredFactor> | |||
MULTISTORAGE_SELECTOR_COLD_STORAGE_PREFER = ConfigOptions | |||
.key("rss.server.multistorage.cold.storage.preferred.factor") |
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.
Could you give this config option a better name? It is more like a strategy in our system.
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.
WDYT?
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.
rss.server.multistorage.selector.strategy
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 has been discussed in above conversation. #621 (comment). If you prefer, I will refactor it.
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 better to refactor ... it's more clear.
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.
LGTM
…ategy (apache#621) ### What changes were proposed in this pull request? 1. Introduce storage manager selector to support more selector strategy for `MultiStorageManager` 2. Introduce the conf of `rss.server.multistorage.manager.selector.class` to support different flush strategy, like I hope huge partition directly flushed to HDFS and normal partition could be flushed to DISK when single buffer flush is enabled. ### Why are the changes needed? Solving the problem mentioned in apache#378 (comment). In current codebase, when encountering huge partition, if single buffer flush is enabled, the normal partition data will be flush to HDFS(I don't hope so, because the local disk is free and the flushing speed is faster than HDFS). But if disable single flush buffer, the huge partition event before marking as huge partition may be big, which cause the slow flushing and then cause requiring allocated buffer failed. Based on above problems, this PR is to make single event carrying with 100 mb flushed into HDFS or local file leveraging the conf of `rss.server.multistorage.manager.selector.class` ### Does this PR introduce _any_ user-facing change? Yes. Doc will be updated later. ### How was this patch tested? 1. UTs
…ategy (apache#621) ### What changes were proposed in this pull request? 1. Introduce storage manager selector to support more selector strategy for `MultiStorageManager` 2. Introduce the conf of `rss.server.multistorage.manager.selector.class` to support different flush strategy, like I hope huge partition directly flushed to HDFS and normal partition could be flushed to DISK when single buffer flush is enabled. ### Why are the changes needed? Solving the problem mentioned in apache#378 (comment). In current codebase, when encountering huge partition, if single buffer flush is enabled, the normal partition data will be flush to HDFS(I don't hope so, because the local disk is free and the flushing speed is faster than HDFS). But if disable single flush buffer, the huge partition event before marking as huge partition may be big, which cause the slow flushing and then cause requiring allocated buffer failed. Based on above problems, this PR is to make single event carrying with 100 mb flushed into HDFS or local file leveraging the conf of `rss.server.multistorage.manager.selector.class` ### Does this PR introduce _any_ user-facing change? Yes. Doc will be updated later. ### How was this patch tested? 1. UTs
What changes were proposed in this pull request?
MultiStorageManager
rss.server.multistorage.cold.storage.preferred.factor
to support different flush strategy, like I hope huge partition directly flushed to HDFS and normal partition could be flushed to DISK when single buffer flush is enabled.Why are the changes needed?
Solving the problem mentioned in #378 (comment).
In current codebase, when encountering huge partition, if single buffer flush is enabled, the normal partition data will be flush to HDFS(I don't hope so, because the local disk is free and the flushing speed is faster than HDFS). But if disable single flush buffer, the huge partition event before marking as huge partition may be big, which cause the slow flushing and then cause requiring allocated buffer failed.
Based on above problems, this PR is to make single event carrying with 100 mb flushed into HDFS or local file leveraging the conf of
rss.server.multistorage.cold.storage.preferred.factor
Does this PR introduce any user-facing change?
Yes. Doc will be updated later.
How was this patch tested?