xushiyan commented on code in PR #17827: URL: https://github.com/apache/hudi/pull/17827#discussion_r2898926654
########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,332 @@ + <!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> +# RFC-103: Hudi LSM tree layout + +## Proposers + +- @zhangyue19921010 +- @xushiyan + +## Approvers + +- @danny0405 +- @vinothchandar + +## Status + +Main issue: https://github.com/apache/hudi/issues/14310 + +## Background + +LSM Trees (Log-Structured Merge-Trees) are data structures optimized for write-intensive workloads and are widely used in modern database systems such as LevelDB, RocksDB, Cassandra, etc. They offer higher write performance typically compared to traditional B+Tree structures. + +Systems like Paimon, adopt the LSM structure for data lake workloads as well, with a tiered merge (compaction) mechanism, they offer some valid tradeoffs in terms of: + +- Lower memory requirements to merge logs compared to hash merge algorithms; efficient compaction +- Layout sorted by keys within each file group, that can be faster for point lookup + +## Goal + +This RFC proposes applying LSM-inspired principles (**sorted writes + N-way merges**) to improve the data organization protocol for Hudi tables, and favoring native Parquet log file format over log format in Avro or embedded Parquet log block, to achieve improvements on the performance and stability of MOR compaction, and point lookup efficiency. + +Comparing to Avro log format or log file with embedded Parquet log block, using native Parquet log format further achieves read performance improvements on native predicate pushdown, stats pruning, and better compression. + +## Design Overview + + + +The core idea is to treat, **within each file group**: + +- **Log files** as **Level-0 (L0)** of an LSM tree +- The only **Base file** as **Level-1 (L1)** + +The file naming formats for base and log files should retain unchanged. + +To realize this layout: + +- Records inside **log and base files must be sorted by record key(s)** (**Core Feature 1**) +- Records should be deduplicated before writing to any log file, i.e., no dups within a log file. Duplicates can be seen across log files. +- Existing services should implement **sorted merge-based compaction**: + - **log-compaction** handles **L0 compaction** + - **compaction table service** handles **L0 → L1 compaction** + - both use a **sorted merge algorithm** (**Core Feature 2**) + +## Considerations + +### Table configs + +The layout should be enforced by a table property, for e.g. `hoodie.table.storage.layout=default|lsm_tree` (default value: `default`, which is current base/log file organization). The layout applies to both COW and MOR table. + +### Engine-agnostic + +The layout should be engine-agnostic. Writer engines can make use of shared implementation and add specific logic or design to comform to the layout. + +For example, Flink writers use buffer sort, the Flink sink must flush sorted records into a single file to guarantee file-level ordering. + +### Write operations + +Write operations should remain semantically unchanged when the layout is enabled. + +In MOR tables, when **small file handling** occurs, inserts may be bin-packed into file slices without log files, creating a new base file, the **sorted write** needs to be applied. A `SortedCreateHandle` would be needed, similar to `SortedMergeHandle`. + +For MOR tables, the most performant writer setup for LSM tree layout will be bucket index + bulk insert, which best utilizes sorted merging. The downside would be that small files may proliferate, which can be mitigated by doing log compaction. + +### Indexes + +Writer indexes should still function as is under this layout. Same for reader indexes. + +### Clustering + +Clustering will be restricted to **record key sorting** only. Review Comment: just to clarify: this is about using LSM tree layout at file group level and supporting flexible clustering fields for existing file groups? yup it's doable. Question is how much the yield of this impl would be? when a user decides to apply lsm tree layout for a table, it's already meant to be sorted by keys -- 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]
