yihua opened a new pull request, #20070: URL: https://github.com/apache/hudi/pull/20070
### Describe the issue this Pull Request addresses closes #20066 part of #20064 `HoodieWriteConfig` ships in every write and table service task, and each of its nested configs holds its own copy of all the write config props, so Java serialization writes the same entries about thirteen times: a default write config is 74 KB while its props alone are 21 KB. ### Summary and Changelog `HoodieConfig` gains `writeObject`/`readObject` and `defaultWriteObjectSharingProps`; `HoodieWriteConfig` opts in, so each nested config whose props mostly repeat the write config props is written as the entries that differ from one snapshot of them. Deserialization rebuilds each nested config with its own props, so contents, isolation and getters are unchanged. `serialVersionUID` of `HoodieConfig` is pinned to its previously computed value so older streams still read. Tests cover the size bound, the pinned UID, a full getter round trip after driver-side divergence, and the delta cases in `HoodieConfig`. ### Impact Default write config 74,090 to 30,136 bytes; `HoodieSparkTable` through Spark's `JavaSerializer` 80,628 to 36,503 bytes, and per-task deserialization of the table about 379 to 275 us. No public API or config change. A write config serialized by this version cannot be read by an older jar (it fails with `ClassNotFoundException` for `HoodieConfig$PropertiesDelta`). Kryo paths are unchanged and do not get the savings yet. ### Risk Level low. Only Java serialization of configs nested in a `HoodieWriteConfig` changes; configs whose props are unrelated, shared or of a `TypedProperties` subclass are written as before. Covered by the new tests and the existing config and write suites. ### Documentation Update none ### Contributor's checklist - [ ] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [ ] Enough context is provided in the sections above - [ ] Adequate tests were added if applicable -- 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]
