-
Notifications
You must be signed in to change notification settings - Fork 2k
[Enhancement] support alter hive/hudi catalog's properties #56212
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
[Enhancement] support alter hive/hudi catalog's properties #56212
Conversation
3da5910
to
9b405ab
Compare
a1e07bb
to
1bafcbe
Compare
catalog.getConfig().put("ranger.plugin.hive.service.name", serviceName); | ||
catalog.getConfig().putAll(properties); | ||
if (serviceName == null && !properties.isEmpty()) { | ||
LOG.info("Altering catalog properties (excluding `ranger.plugin.hive.service.name`) " + |
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 notion of restarting FE to enable newly added properties to take effect is not viable. Could you make these newly added properties take effect without restarting FE? I'm interested to talk about the design with you.
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.
These properties changes, if applied directly, would affect the in-memory state of the catalog's metadata cache or require re-establishing the connection with the metastore. On one hand, implementing such changes is prone to causing issues and complex, and on the other hand, they would immediately impact business queries with potential irrecoverable consequences. Therefore, i think it is preferable to apply these changes through a restart. This approach simplifies implementation and minimizes the impact on users.
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 agree that changing the state of the original catalog in place is error-prone. However, I think we can treat the catalog as immutable. Instead of modifying the state of the original catalog, we can create a new catalog with new properties and replace it atomically
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 we reuse the create catalog logic with alter properties, and repalce the connector object atomically?
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.
Solid suggestion. I'll carefully evaluate the feasibility and implications, then circle back with a detailed analysis.
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.
@DorianZheng @Youngwb please re review
fe/fe-core/src/main/java/com/starrocks/connector/ConnectorMgr.java
Outdated
Show resolved
Hide resolved
// recreate catalog | ||
reCreatCatalog(catalog, alterProperties, isReplay); | ||
} else { | ||
String catalogName = catalog.getName(); |
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.
Why do we need to handle the logic for Ranger separately? Can't we reuse the logic reCreatCatalog?
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.
Rebuilding a catalog is a heavyweight operation. Therefore, we handle it in two scenarios: we avoid rebuilding when unnecessary to prevent any impact on queries.
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 operation of alter catalog is rarely performed. I don't think it's worth increasing the complexity of the code logic for 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.
ok
fe/fe-core/src/main/java/com/starrocks/sql/analyzer/CatalogAnalyzer.java
Outdated
Show resolved
Hide resolved
fe/fe-core/src/main/java/com/starrocks/sql/analyzer/CatalogAnalyzer.java
Outdated
Show resolved
Hide resolved
eadceeb
to
3ad7e8a
Compare
newConnector = connectorMgr.createHiddenConnector( | ||
new ConnectorContext(catalogName, type, newProperties), isReplay); | ||
if (null == newConnector) { | ||
throw new DdlException("create hidden connector failed"); |
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.
throw new DdlException("create hidden connector failed"); | |
throw new DdlException("alter catalog failed", e); |
user should not known the hidden connector, and they need error message to change their alter command
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.
get
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 will catch this exception at line 209 and throw a new DdlException with the message 'ALTER operation failed: Connector creation error'. This will explicitly inform users that:
- Their ALTER command failed
- The failure reason is connector creation issue."
Can this solution resolve the problem?
line 209: throw new DdlException(String.format("Alter catalog failed, msg: [%s]", e.getMessage()), e);
// replace old connector with new connector | ||
connectorMgr.addConnector(catalogName, newConnector); | ||
|
||
String serviceName = newProperties.get("ranger.plugin.hive.service.name"); |
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.
If user first alter ranger.plugin.hive.service.name
, then alter other properties, the AccessControl will be reset to RangerStarRocksAccessController or NativeAccessController
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.
get
@haiboself Do you have a need to cp to branch-3.2? I think branch 3.3 is sufficient |
Signed-off-by: haiboself <[email protected]>
Signed-off-by: haiboself <[email protected]>
Signed-off-by: haiboself <[email protected]>
Signed-off-by: haiboself <[email protected]>
Signed-off-by: haiboself <[email protected]>
Signed-off-by: haiboself <[email protected]>
Signed-off-by: haiboself <[email protected]>
|
|
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[FE Incremental Coverage Report]✅ pass : 46 / 51 (90.20%) file detail
|
[BE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
@DorianZheng @Youngwb please review and merge |
@Mergifyio backport branch-3.3 |
@Mergifyio backport branch-3.4 |
✅ Backports have been created
|
✅ Backports have been created
|
Signed-off-by: haiboself <[email protected]> (cherry picked from commit 1acf89f) # Conflicts: # fe/fe-core/src/main/java/com/starrocks/server/CatalogMgr.java
Signed-off-by: haiboself <[email protected]> (cherry picked from commit 1acf89f)
…56212) (#56854) Co-authored-by: bo.hai <[email protected]>
…#56212) Signed-off-by: haiboself <[email protected]>
…#56212) Signed-off-by: haiboself <[email protected]>
…56212) (#56870) Signed-off-by: haiboself <[email protected]>
…#56212) Signed-off-by: haiboself <[email protected]> Signed-off-by: crossoverJie <[email protected]>
Why I'm doing:
When the Hive metastore address changes, we need to modify the Hive catalog's properties accordingly.
What I'm doing:
This PR adds support for modifying Hive/Hudi catalog properties, but requires restarting all FE nodes for the changes to take effect.
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check: