[GitHub] [hudi] zhangyue19921010 commented on pull request #3509: [HUDI-2338] Hoodie update reject clustering using SparkRejectClusteringStrategy

[GitBox <gi...@apache.org>]

zhangyue19921010 commented on pull request #3509:
URL: https://github.com/apache/hudi/pull/3509#issuecomment-919678701


   @satishkotha @vinothchandar Thanks for your attention. Let me explain in more detail :
   First of all this rejectClustering strategy will do clustering validation three times : 
   
   1. Before clustering performed, checking xxx.replacement.request.reject.
   2. After clustering finished, checking xxx.replacement.inflight.reject.
   3. Before clustering committing which will create clustering commit file
   
   There's actually a race condition that reject file could be created **during clustering committing**. This step will create a clustering commit file and I believe it's a quick move.
   ```
         table.getActiveTimeline().transitionReplaceInflightToComplete(replaceCommitInflightInstant,
             Option.of(metadata.toJsonString().getBytes(StandardCharsets.UTF_8)));
   ```
   
   Also Thanks for @satishkotha reminding, I add another validation after clustering commit created, if reject file created during clustering committing, and there's a reject file remainder after clustering committed. We has to throws an exception here to avoid losing update data.
   
   In short this reject clustering strategy can reject request clustering, inflight clustering and finished but not committed clustering. Although when clustering is committing, we can't reject it anymore and have to throw exception.
   
   
   > Anyway, my high level thought is that it is better to find a way to integrate this with Multi-writer conflict resolution mentioned here https://cwiki.apache.org/confluence/display/HUDI/RFC+-+22+%3A+Snapshot+Isolation+using+Optimistic+Concurrency+Control+for+multi-writers#RFC22:SnapshotIsolationusingOptimisticConcurrencyControlformultiwriters-OptimisticConcurrencyusingatomicrenameswithConflictResolution
   > 
   > If we integrate with multi-writer, this can be done in a generic for any two operations (instead of adding very specific strategy for clustering.) Some changes may be needed in multi-writer implementation to enforce priority of operations (clustering is lower priority than ingestion). But this is better long term IMO. Happy to discuss more details/other alternatives.
   
   I strongly agree that multi-write can solve this conflict more completely. But the disadvantage of this solution is that Introduced external dependencies like ZooKeeper. As the data lake becomes larger, ZooKeeper or something else maybe become the bottleneck which needs to maintain and tune.
   
   So that maybe just introduce a new strategy is more convenient to use. 
   Anyway, each solution has its own advantages and disadvantages :)
   
   


-- 
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: commits-unsubscribe@hudi.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org