Skip to content

[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

Merged

Conversation

haiboself
Copy link
Contributor

@haiboself haiboself commented Feb 24, 2025

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:

  • BugFix
  • Feature
  • Enhancement
  • Refactor
  • UT
  • Doc
  • Tool

Does this PR entail a change in behavior?

  • Yes, this PR will result in a change in behavior.
  • No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

  • Interface/UI changes: syntax, type conversion, expression evaluation, display information
  • Parameter changes: default values, similar parameters but with different default values
  • Policy changes: use new policy to replace old one, functionality automatically enabled
  • Feature removed
  • Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

  • I have added test cases for my bug fix or my new feature
  • This pr needs user documentation (for new or modified features or behaviors)
    • I have added documentation for my new feature or new function
  • This is a backport pr

Bugfix cherry-pick branch check:

  • I have checked the version labels which the pr will be auto-backported to the target branch
    • 3.4
    • 3.3
    • 3.2
    • 3.1
    • 3.0

@haiboself haiboself requested a review from a team as a code owner February 24, 2025 07:13
@CLAassistant
Copy link

CLAassistant commented Feb 24, 2025

CLA assistant check
All committers have signed the CLA.

@haiboself haiboself force-pushed the feature/support_alter_catalog_property branch from 3da5910 to 9b405ab Compare February 24, 2025 07:19
@haiboself haiboself changed the title [feature] support alter hive/hudi catalog's properties [Enhancement] support alter hive/hudi catalog's properties Feb 24, 2025
@haiboself haiboself force-pushed the feature/support_alter_catalog_property branch from a1e07bb to 1bafcbe Compare February 25, 2025 02:20
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`) " +
Copy link
Contributor

@DorianZheng DorianZheng Feb 25, 2025

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@DorianZheng DorianZheng Feb 25, 2025

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

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

@haiboself haiboself requested a review from a team as a code owner March 4, 2025 05:57
@haiboself haiboself requested review from DorianZheng and Youngwb March 4, 2025 05:58
// recreate catalog
reCreatCatalog(catalog, alterProperties, isReplay);
} else {
String catalogName = catalog.getName();
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

@haiboself haiboself force-pushed the feature/support_alter_catalog_property branch from eadceeb to 3ad7e8a Compare March 4, 2025 08:23
@haiboself haiboself requested a review from Youngwb March 4, 2025 09:58
newConnector = connectorMgr.createHiddenConnector(
new ConnectorContext(catalogName, type, newProperties), isReplay);
if (null == newConnector) {
throw new DdlException("create hidden connector failed");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get

Copy link
Contributor Author

@haiboself haiboself Mar 7, 2025

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");
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get

@haiboself haiboself requested a review from Youngwb March 7, 2025 02:19
@Youngwb
Copy link
Contributor

Youngwb commented Mar 7, 2025

@haiboself Do you have a need to cp to branch-3.2? I think branch 3.3 is sufficient

@haiboself
Copy link
Contributor Author

@haiboself Do you have a need to cp to branch-3.2? I think branch 3.3 is sufficien
@Youngwb Agreed, branch-3.3 should be sufficient for our current needs.

Copy link

sonarqubecloud bot commented Mar 7, 2025

@github-actions github-actions bot removed the 3.2 label Mar 7, 2025
Copy link

github-actions bot commented Mar 7, 2025

[Java-Extensions Incremental Coverage Report]

pass : 0 / 0 (0%)

Copy link

github-actions bot commented Mar 7, 2025

[FE Incremental Coverage Report]

pass : 46 / 51 (90.20%)

file detail

path covered_line new_line coverage not_covered_line_detail
🔵 com/starrocks/server/CatalogMgr.java 37 42 88.10% [181, 193, 194, 196, 208]
🔵 com/starrocks/sql/analyzer/CatalogAnalyzer.java 3 3 100.00% []
🔵 com/starrocks/connector/ConnectorMgr.java 6 6 100.00% []

Copy link

github-actions bot commented Mar 7, 2025

[BE Incremental Coverage Report]

pass : 0 / 0 (0%)

@haiboself
Copy link
Contributor Author

@DorianZheng @Youngwb please review and merge

@HangyuanLiu HangyuanLiu self-assigned this Mar 11, 2025
@DorianZheng DorianZheng enabled auto-merge (squash) March 12, 2025 09:36
@DorianZheng DorianZheng merged commit 1acf89f into StarRocks:main Mar 13, 2025
67 checks passed
Copy link

@Mergifyio backport branch-3.3

Copy link

@Mergifyio backport branch-3.4

Copy link
Contributor

mergify bot commented Mar 13, 2025

backport branch-3.3

✅ Backports have been created

Copy link
Contributor

mergify bot commented Mar 13, 2025

backport branch-3.4

✅ Backports have been created

mergify bot pushed a commit that referenced this pull request Mar 13, 2025
Signed-off-by: haiboself <[email protected]>
(cherry picked from commit 1acf89f)

# Conflicts:
#	fe/fe-core/src/main/java/com/starrocks/server/CatalogMgr.java
mergify bot pushed a commit that referenced this pull request Mar 13, 2025
haiboself added a commit to haiboself/starrocks that referenced this pull request Mar 13, 2025
haiboself added a commit to haiboself/starrocks that referenced this pull request Mar 13, 2025
dirtysalt pushed a commit that referenced this pull request Mar 13, 2025
crossoverJie pushed a commit to crossoverJie/starrocks that referenced this pull request Mar 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants