[GitHub] [hudi] rohan-uptycs commented on a diff in pull request #8503: [HUDI-6047] Clustering operation on consistent hashing index resulting in duplicate data

["rohan-uptycs (via GitHub)" <gi...@apache.org>]

rohan-uptycs commented on code in PR #8503:
URL: https://github.com/apache/hudi/pull/8503#discussion_r1181485921


##########
hudi-client/hudi-spark-client/src/main/java/org/apache/hudi/index/bucket/HoodieSparkConsistentBucketIndex.java:
##########
@@ -275,4 +280,49 @@ public Option<HoodieRecordLocation> getRecordLocation(HoodieKey key) {
       throw new HoodieIndexException("Failed to getBucket as hashing node has no file group");
     }
   }
+
+  /**
+   * Update default metadata file(00000000000000.hashing_meta) with the latest committed metadata file so that default file will be in sync
+   * with latest commit.
+   *
+   * @param table
+   */
+  public void updateArchivalDependentIndexMetadata(HoodieTable table,List<HoodieInstant> hoodieArchivalInstants) {
+    Map<String, Boolean> partitionVisiteddMap = new HashMap<>();
+    // Update metadata for replace commit which are going to get archived.
+    Stream<HoodieInstant> hoodieListOfReplacedInstants = hoodieArchivalInstants.stream().filter(instane -> instane.getAction().equals(REPLACE_COMMIT_ACTION));
+    hoodieListOfReplacedInstants.forEach(instant -> {
+      Option<Pair<HoodieInstant, HoodieClusteringPlan>> instantPlanPair =
+          ClusteringUtils.getClusteringPlan(table.getMetaClient(), HoodieTimeline.getReplaceCommitRequestedInstant(instant.getTimestamp()));
+      if (instantPlanPair.isPresent()) {
+        HoodieClusteringPlan plan = instantPlanPair.get().getRight();
+        List<Map<String, String>> partitionMapList = plan.getInputGroups().stream().map(HoodieClusteringGroup::getExtraMetadata).collect(Collectors.toList());
+        partitionMapList.stream().forEach(partitionMap -> {
+          String partition = partitionMap.get(SparkConsistentBucketClusteringPlanStrategy.METADATA_PARTITION_KEY);
+          if (!partitionVisiteddMap.containsKey(partition)) {
+            Option<HoodieConsistentHashingMetadata> hoodieConsistentHashingMetadataOption = loadMetadata(table, partition);
+            if (hoodieConsistentHashingMetadataOption.isPresent()) {

Review Comment:
   @danny0405 , There are consistency issues we might face if we try updating metadata after finishing clustering commit.
   What if underlying file system is down and updateMetadata fails to sync metadata, then there is no mechanism to bring it in sync with latest committed metadata, and archival will remove replace commit eventually and it will end up in an inconsistent state.
   On the other hand in archival process , it will be eventually in sync with committed metadata before replace commit getting archived.
   I think consistent hashing metadata has strong dependency on archival process, As it is dependent on active timeline replaced commit to load metadata.
   
   



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