zhangwl9 opened a new issue, #4207:
URL: https://github.com/apache/amoro/issues/4207
Thank you for contributing to Amoro!
## What would you like to be improved?
Currently, orphan files cleaning is implemented as a standalone scheduler
task (`OrphanFilesCleaningExecutor`) that runs independently from other table
processes. This approach has several limitations:
1. **Inconsistent architecture**: Other table processes (like
`SnapshotsExpiringProcess`) use the `ProcessFactory` plugin system, but orphan
files cleaning uses a separate scheduler, making the codebase inconsistent
2. **Limited flexibility**: The current implementation cannot leverage the
unified process management, execution engine selection, or plugin configuration
system
3. **Duplication of logic**: Scheduling, state tracking, and execution logic
are duplicated between orphan files cleaning and other table processes
4. **Hard to extend**: Adding new features like custom execution engines or
advanced triggering strategies requires modifying the core scheduler
## How should we improve?
Refactor orphan files cleaning to use the `ProcessFactory` plugin system,
following the same pattern as `SnapshotsExpiringProcess`:
### Implementation Plan
1. **Create `OrphanFilesCleaningProcess`**
- Implement `TableProcess` and `LocalProcess` interfaces
- Add to `IcebergProcessFactory` with proper trigger strategy
- Support configuration: `clean-orphan-files.enabled` and
`clean-orphan-files.interval`
2. **Remove standalone scheduler**
- Delete `OrphanFilesCleaningExecutor` from `InlineTableExecutors`
- Remove registration from `AmoroServiceContainer`
3. **Add configuration options**
- `clean-orphan-files.enabled` (default: true)
- `clean-orphan-files.interval` (default: 1 day)
- Configure via `process-factories.yaml` plugin config
4. **Enhance state tracking**
- Use `TableRuntimeCleanupState` to track last orphan files clean time
- Support fluent builder pattern for state updates
5. **Update execution engine config**
- Add `pool.orphan-files-cleaning.thread-count` to `execute-engines.yaml`
### Benefits
- **Consistency**: Aligns with existing table process architecture
- **Flexibility**: Can use different execution engines (local, Flink, Spark)
- **Configurability**: Plugin-based configuration system
- **Maintainability**: Reduces code duplication, easier to extend
- **Better resource management**: Integrated with unified process pool
management
### Backward Compatibility
The change is backward compatible:
- Configuration can be migrated from `AmoroManagementConf` to plugin config
- Behavior remains the same (periodic orphan files cleaning)
- Existing tables will continue to work without changes
--
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]
