majin1102 opened a new issue, #1865: URL: https://github.com/apache/amoro/issues/1865
### Search before asking - [X] I have searched in the [issues](https://github.com/NetEase/arctic/issues?q=is%3Aissue) and found no similar issues. ### What would you like to be improved? Right now, when we want to declare a table optimized by some optimizer group, we have two clear ways: 1. set default optimizer group of a catalog, and don't declare optimizer group in table properties:  2. declare a property of 'self-optimizing.group' in table properties (in create table or alter table statement):  In practice, using default optimizer group has better experience while not flexible in case that multiple groups are necessary in one catalog. Using table property provides more flexibility but sacrifice user experience and security, imagine that every table(user) needs to know the resources behind AMS and has the authority to allocate resources, this could be a disaster. It does't seem a big deal of this because in many cases there's only one external/default optimizer group without considerations for security and isolation. But it would be never late to have a better way to provide user experience, isolation and security for self-optimizing ### How should we improve? **Better user experience** users only declare relationships in one place and use them everywhere. It's a bad idea to define a property in table which means table owner must know the concepts and instances. It's a good idea of declaring properties in optimizer group and use an extendable rule like regex **Better security** Relationships of table and resource should be certain and can not be modified without the permission of the owner of resources. It is clear that declaring properties in optimizer group fulfills this criterion **Better isolation** when we declare relationships of table and resources or modify them, the rules must be mutually exclusive In conclusion, I proposed that declaring regex rules in optimizer group defines relationships of table and resources. For example: > catalog1.db1.* > catalog2.*.* leads to a clear definition that this optimizer groups could be used in these tables and only used by them. ### Are you willing to submit PR? - [x] Yes I am willing to submit a PR! ### Subtasks _No response_ ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
