beyond1920 opened a new pull request, #10373: URL: https://github.com/apache/hudi/pull/10373
### Change Logs After apply [HUDI-6941](https://issues.apache.org/jira/browse/HUDI-6941) in the internal HUDI version(based on 0.14.0 version), there is a frequent occurrence of the execution plan selecting "broadcast hash join" to broadcast a large HUDI data source. <img width="1084" alt="image" src="https://github.com/apache/hudi/assets/1525333/80a6e1e6-393a-4719-9914-90b89b4f40d9";> I tried to investigate the cause of this issue. In those cases, using`HadoopFsRelation` to read HUDI source, and Spark `JoinSelection` would call `HadoopFsRelation#sizeInBytes` to estimate the relation size to decide whether use broadcast join or not. And `HadoopFsRelation#sizeInBytes` would call `HoodieFileIndex#sizeInBytes`. But at the moment, no partitions are loaded because using default lazy Hudi's file-index implementation's file listing mode. So `FileIndex#cachedAllInputFileSlices` is an empty map, then `HadoopFsRelation#sizeInBytes` returns 0, it caused the suboptimal join plan. After apply [HUDI-6941](https://issues.apache.org/jira/browse/HUDI-6941), more cases could enabled lazy list mode by default, so the issue has become more frequent. The pr aims to fix the issue. ### Impact NA ### Risk level (write none, low medium or high below) NA ### Documentation Update NA ### Contributor's checklist - [ ] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [ ] Change Logs and Impact were stated clearly - [ ] Adequate tests were added if applicable - [ ] CI passed -- 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]
