[WIP] hudi cluster write path poc#2082
Conversation
bvaradar
left a comment
There was a problem hiding this comment.
Yet to finish up a pass. Adding comments so far.
Once REPLACE action (@satishkotha) changes are coalesced with this change (#2048), this would simplify.
The naming "cluster" vs "clustering" needs to be standardized.
|
|
||
| @Override | ||
| protected void addPendingClusteringOperations(Stream<Pair<String, ClusteringOperation>> operations) { | ||
| // TODO |
There was a problem hiding this comment.
This TODO and others are needed for incremental filesystem view syncing.
| return fileIdToPendingCompaction; | ||
| } | ||
|
|
||
| protected Map<HoodieFileGroupId, Pair<String, ClusteringOperation>> createFileIdToPendingClusteringMap( |
There was a problem hiding this comment.
It would be a good idea to rebase this with #2048 as it is almost ready.
| } else { | ||
| return HoodieTimeline.makeCommitFileName(timestamp); | ||
| } | ||
| } else if (HoodieTimeline.CLUSTERING_ACTION.equals(action)) { |
There was a problem hiding this comment.
I am assuming this would be changed to REPLACE_ACTION from the other PR.
| .collect(Collectors.toSet()); | ||
| List<HoodieClusteringOperation> operations = jsc.parallelize(partitionPaths, partitionPaths.size()).map((Function<String, ClusteringOperation>) partitionPath -> { | ||
| Stream<FileSlice> fileSliceStream = fileSystemView.getLatestFileSlices(partitionPath); | ||
| List<HoodieBaseFile> baseFiles = fileSliceStream.filter(slice -> (!fgIdsInPendingClusterings.contains(slice.getFileGroupId()) && !fgIdsPendingCompactions.contains(slice.getFileGroupId()))) |
There was a problem hiding this comment.
For COW table, pending compactions would not be present.
There was a problem hiding this comment.
Some of the code seems common with Compaction handling. Any chance of moving to common helper functions ?
There was a problem hiding this comment.
thanks, will reuse these code
| } | ||
|
|
||
| @Override | ||
| public int compare(HoodieClusteringOperation op1, HoodieClusteringOperation op2) { |
There was a problem hiding this comment.
This can be moved to separate comparator class ?
| String partitionPath = partitionStat.getKey(); | ||
| String fileId = updateLocEntry.getKey(); | ||
| if (partitionFileIdPairs.contains(Pair.of(partitionPath, fileId))) { | ||
| LOG.error("Not allowed to update the clustering files, partition: " + partitionPath + ", fileID " + fileId + ", please use other strategy."); |
There was a problem hiding this comment.
"please use other strategy" => Reword ? FOr pending clustering operations, we are not going to support update for now right ?
There was a problem hiding this comment.
yes, first step will not support update when clustering
| * See the License for the specific language governing permissions and | ||
| * limitations under the License. | ||
| */ | ||
| { |
There was a problem hiding this comment.
Are we going to reuse Replace metadata or this one ?
| INFLIGHT_DELTA_COMMIT_EXTENSION, REQUESTED_DELTA_COMMIT_EXTENSION, SAVEPOINT_EXTENSION, | ||
| INFLIGHT_SAVEPOINT_EXTENSION, CLEAN_EXTENSION, REQUESTED_CLEAN_EXTENSION, INFLIGHT_CLEAN_EXTENSION, | ||
| INFLIGHT_COMPACTION_EXTENSION, REQUESTED_COMPACTION_EXTENSION, INFLIGHT_RESTORE_EXTENSION, RESTORE_EXTENSION)); | ||
| INFLIGHT_COMPACTION_EXTENSION, REQUESTED_COMPACTION_EXTENSION, INFLIGHT_RESTORE_EXTENSION, RESTORE_EXTENSION, |
There was a problem hiding this comment.
Are we going to reuse REPLACE action here ?
| return fileIdToPendingCompaction; | ||
| } | ||
|
|
||
| protected Map<HoodieFileGroupId, Pair<String, ClusteringOperation>> createFileIdToPendingClusteringMap( |
There was a problem hiding this comment.
Assuming we are going to reuse REPLACE, many of these changes should go away ?
| public HoodieWriteMetadata clustering(JavaSparkContext jsc, String compactionInstantTime) { | ||
| return new RunClusteringActionExecutor(jsc, config, this, compactionInstantTime).execute(); | ||
| } | ||
|
|
There was a problem hiding this comment.
Need to ensure small file handling doesn't toe-step clustering. In other words, we should employ update rejection policy for small file handling too.
There was a problem hiding this comment.
Thanks, Will pay attention to this
Sure, considering I am a little busy these days, it is wonderful if you @satishkotha would take over the PR and land it. Thanks |
@leesf @satishkotha what is your process? i am intrested to take this and land it. Thanks |
@lw309637554 I've already started working on this. Perhaps, you could help with one of the followup tasks of #2048? These are tracked as subtasks here https://issues.apache.org/jira/browse/HUDI-868? Subtasks 2,4 are easy to get started. But, feel free to pick others too? @vinothchandar Maybe we can close this PR to avoid confusion? I'll open new PR when i'm ready and run some basic tests. |
@satishkotha ok, i can take some sub task in https://issues.apache.org/jira/browse/HUDI-868 |
|
Closing this , since we have the actual PR now from @satishkotha |
Tips
What is the purpose of the pull request
(For example: This pull request adds quick-start document.)
Brief change log
(for example:)
Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)
Committer checklist
Has a corresponding JIRA in PR title & commit
Commit message is descriptive of the change
CI is green
Necessary doc changes done or have another open PR
For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.