vinothchandar commented on code in PR #17827: URL: https://github.com/apache/hudi/pull/17827#discussion_r2692542782
########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** Review Comment: ```suggestion - **Layout sorted by keys within each file group, that can be faster for point access** ``` ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** Review Comment: How exactly is the read path optimized? AFAIK, sort merging has lower memory overhead vs hash merging (what we do currently), but the k-way comparison is actually more expensive than a single hash map look up, right? ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,233 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## Design Overview + + + +The core idea is to treat, **within each file group**: + +- **Log files** as **Level-0 (L0)** of an LSM tree +- **Base file** as **Level-1 (L1)** + +To realize this layout: + +- Records inside **log and base files must be sorted** (**Core Feature 1**) +- 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.lsm_tree.layout.enabled=true` (default `false`): + +- The config is not allowed to be set to `true` for an existing table +- The config is allowed to be set to `false` for an existing table + +The layout is only applicable to MOR table, and not applicable to COW. When setting the layout config for a COW table, the persisted config for the layout will always be false. Review Comment: This is effectively writing a new `HoodieSortMergeHandle` that does sorted merge of base file and incoming records to be merged. Let's not overload that here. lets track that as a separate CoW writer side feature. ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** Review Comment: What are the tiers? ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: Review Comment: ```suggestion 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 : ``` ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** Review Comment: higher relative to? because there is now overhead to sort before writing? I think we are conflating LSM write performance claims from systems like rocksDB, measured against B+Trees (e.g innodb) -- with what systems like Paimon claim. Lets please get this section to accurately baseline . I've left suggestions to this end. ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: Review Comment: I would love for the 1 and 3 to be clearly substantiated with the why. All we are doing here is sorting by key fields in layout. Why would that improve pushdown? If you are taking specifically about point lookups, lets qualify that. ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): Review Comment: Instead of inventing `base_log`, please just call it `default`. and the new one `lsm_tree` ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**Core Feature 1**) Review Comment: sorted by? ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** Review Comment: ```suggestion - **Lower memory requirements to merge logs compared to hash merge algorithms** ``` ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: Review Comment: ```suggestion This RFC proposes applying LSM-inspired principles (**sorted writes + tiered N-way merges**) to improve the data organization protocol for **Hudi MOR tables**, and favoring **Parquet** over **Avro** as the on-disk format for individual log files, to achieve: ``` ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files Review Comment: same. why would compression improve? just the avro to parquet in logs? Thats an orthogonal issue right. Can we separate it out from the LSM discussion ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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. Review Comment: super! ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): + +- The config is not allowed to be set to `lsm_tree` for an existing table +- The config is allowed to be set to `base_log` for an existing table + +The layout is only applicable to MOR table, and not applicable to COW. When setting the layout config for a COW table, the persisted config for the layout will always be false. + +When an LSM-tree layout enabled MOR table is migrated to COW, the layout config will automatically set to `false`. + +### 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. + +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. + +For **MOR + bucket index** setup, clustering is typically not needed. + +## Core Feature 1: Sorted Write + +All writes are sorted. That is, within any written file (**base or log**), records are fully sorted by key(s). + +### Initial support (v1) + +- `bulk_insert` +- `insert_overwrite` +- with **bucket index** + +### Future support + +- `insert`, `upsert` +- other index types + +### Example: Flink Streaming Write Pipeline + + + +The write pipeline mainly consists of four core stages: + +- **Repartitioning** +- **Sorting** +- **Deduplication** +- **I/O** + +Optimizations: + +1. **Asynchronous processing architecture** Review Comment: do you have some micro benchmarks for this ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): + +- The config is not allowed to be set to `lsm_tree` for an existing table +- The config is allowed to be set to `base_log` for an existing table + +The layout is only applicable to MOR table, and not applicable to COW. When setting the layout config for a COW table, the persisted config for the layout will always be false. + +When an LSM-tree layout enabled MOR table is migrated to COW, the layout config will automatically set to `false`. + +### 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. Review Comment: Don't we already have `SortCreateHandle` or some sort? ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): + +- The config is not allowed to be set to `lsm_tree` for an existing table +- The config is allowed to be set to `base_log` for an existing table + +The layout is only applicable to MOR table, and not applicable to COW. When setting the layout config for a COW table, the persisted config for the layout will always be false. + +When an LSM-tree layout enabled MOR table is migrated to COW, the layout config will automatically set to `false`. + +### 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. + +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. Review Comment: I'd like to see how we accomplish the sort merging impl, on top of the FileGroupReader abstraction. ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): + +- The config is not allowed to be set to `lsm_tree` for an existing table +- The config is allowed to be set to `base_log` for an existing table Review Comment: if config is not set, it will use `default` ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: Review Comment: All writes on the lake storage is already sequential. i.e there is no random write on object storage. for e.g ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): + +- The config is not allowed to be set to `lsm_tree` for an existing table +- The config is allowed to be set to `base_log` for an existing table + +The layout is only applicable to MOR table, and not applicable to COW. When setting the layout config for a COW table, the persisted config for the layout will always be false. + +When an LSM-tree layout enabled MOR table is migrated to COW, the layout config will automatically set to `false`. + +### 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. + +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: This is a serious limitation. Philosophically one the main reasons, I think Paimon and the LSM approach are not right for the lake workloads.. ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** Review Comment: This is purely just algorithm complexities. right? ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): + +- The config is not allowed to be set to `lsm_tree` for an existing table +- The config is allowed to be set to `base_log` for an existing table + +The layout is only applicable to MOR table, and not applicable to COW. When setting the layout config for a COW table, the persisted config for the layout will always be false. + +When an LSM-tree layout enabled MOR table is migrated to COW, the layout config will automatically set to `false`. + +### 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. + +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. + +For **MOR + bucket index** setup, clustering is typically not needed. + +## Core Feature 1: Sorted Write + +All writes are sorted. That is, within any written file (**base or log**), records are fully sorted by key(s). + +### Initial support (v1) + +- `bulk_insert` +- `insert_overwrite` +- with **bucket index** + +### Future support + +- `insert`, `upsert` +- other index types + +### Example: Flink Streaming Write Pipeline + + + +The write pipeline mainly consists of four core stages: + +- **Repartitioning** +- **Sorting** +- **Deduplication** +- **I/O** + +Optimizations: + +1. **Asynchronous processing architecture** + Introduce a **Disruptor ring buffer** within the sink operator to decouple production and consumption, significantly improving throughput and handling cases where the producer outpaces the consumer. + +2. **Efficient memory management** + Integrate Flink’s built-in **MemorySegmentPool** with **BinaryInMemorySortBuffer** to enable fine-grained memory control and efficient sorting, greatly reducing GC pressure and sorting overhead. + +## Core Feature 2: Sorted Merge Read / Compaction + + + +During read and compaction, merging is performed using a **sorted merge algorithm** (e.g., **loser-tree** for k-way merge). + +- Resulting **log files** contain fully sorted records +- Resulting **base files** contain fully sorted records +- File group reads reuse the same sorted merge logic, with **predicate pruning** applied when present + +### Implementation tasks + +- Implement sorted merge: **Loser tree** for **k-way merge** +- Reuse existing **Record Merger APIs** +- Update the following components to use sorted merge: + - Log compaction + - Compaction runner (L0 → L1) + - File group reader + +--- + +## Additional (Orthogonal) Features + +These features amplify the benefits of the LSM layout but are not strictly required by the layout itself but can optimize the performance and user experience of LSM. + +### 1) Parquet as Log File Format + +**Benefits** + +- Vectorized processing +- Better compression than Avro +- Support pruning during reads + +Switching log file format from Avro to Parquet requires the following changes: + +0. Parquet log file naming format should remain consistent with existing Avro logs to ensure compatibility with existing MOR tables +1. **Writer changes**: Block append operations are no longer supported. During writes, input data is sorted and deduplicated, then written directly to new Parquet files using a Create handler: + - For **Spark**: reuse the bulk insert write logic + - For **Flink**: refactor the upsert write logic. Data preparation, metadata field addition, and sorting logic can be reused, but the final write should use the Parquet Create Handler to write new Parquet log files +2. **Reader changes**: When reading Parquet log files, skip the logic for handling delete blocks and damaged blocks. Read data directly using the Parquet Log Reader, enabling optimizations such as vectorized reads and column pruning +3. **Markers**: Implement a new MOR marker write mechanism. Create markers are written during writes, similar to COW create markers +4. **Rollback**: Handle both Marker-Based Rollback and Listing-Based Rollback scenarios: + - For MOR Parquet logs, damaged files are deleted directly (similar to COW) +5. **Cleaning**: MOR Parquet log file cleaning directly deletes the corresponding Parquet log files (similar to COW Parquet) + + +**Behavior changes** + +- MOR **rollback** deletes Parquet log files directly, instead of appending a delete block. +- For **cleaning**, Parquet log files are deleted. + +### 2) File-Group Granular Compaction + +Introduce a new compaction strategy that combines: + +- **Log compaction (L0)** Review Comment: Do we need new compaction strategy? All this is doing is just change "how" compaction executes right. i.e hash merge vs sort merge? ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): + +- The config is not allowed to be set to `lsm_tree` for an existing table +- The config is allowed to be set to `base_log` for an existing table + +The layout is only applicable to MOR table, and not applicable to COW. When setting the layout config for a COW table, the persisted config for the layout will always be false. + +When an LSM-tree layout enabled MOR table is migrated to COW, the layout config will automatically set to `false`. + +### 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. + +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. + +For **MOR + bucket index** setup, clustering is typically not needed. + +## Core Feature 1: Sorted Write + +All writes are sorted. That is, within any written file (**base or log**), records are fully sorted by key(s). + +### Initial support (v1) + +- `bulk_insert` +- `insert_overwrite` +- with **bucket index** + +### Future support Review Comment: I'd like to cover all write operations cleanly.. It's not too hard to support right. ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): + +- The config is not allowed to be set to `lsm_tree` for an existing table +- The config is allowed to be set to `base_log` for an existing table + +The layout is only applicable to MOR table, and not applicable to COW. When setting the layout config for a COW table, the persisted config for the layout will always be false. + +When an LSM-tree layout enabled MOR table is migrated to COW, the layout config will automatically set to `false`. + +### 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. + +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. + +For **MOR + bucket index** setup, clustering is typically not needed. + +## Core Feature 1: Sorted Write + +All writes are sorted. That is, within any written file (**base or log**), records are fully sorted by key(s). + +### Initial support (v1) + +- `bulk_insert` +- `insert_overwrite` +- with **bucket index** + +### Future support + +- `insert`, `upsert` +- other index types + +### Example: Flink Streaming Write Pipeline + + + +The write pipeline mainly consists of four core stages: + +- **Repartitioning** +- **Sorting** +- **Deduplication** +- **I/O** + +Optimizations: + +1. **Asynchronous processing architecture** + Introduce a **Disruptor ring buffer** within the sink operator to decouple production and consumption, significantly improving throughput and handling cases where the producer outpaces the consumer. + +2. **Efficient memory management** + Integrate Flink’s built-in **MemorySegmentPool** with **BinaryInMemorySortBuffer** to enable fine-grained memory control and efficient sorting, greatly reducing GC pressure and sorting overhead. + +## Core Feature 2: Sorted Merge Read / Compaction + + + +During read and compaction, merging is performed using a **sorted merge algorithm** (e.g., **loser-tree** for k-way merge). Review Comment: I actually prototypes k-way merge long long ago. https://github.com/vinothchandar/hudi/tree/parallel-parquet-merging it ended up being more computationally expensive when you have lots of log files.. i.e k is large. Any pointers to the algorithm we'd use and how it overcomes those? ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): + +- The config is not allowed to be set to `lsm_tree` for an existing table +- The config is allowed to be set to `base_log` for an existing table + +The layout is only applicable to MOR table, and not applicable to COW. When setting the layout config for a COW table, the persisted config for the layout will always be false. + +When an LSM-tree layout enabled MOR table is migrated to COW, the layout config will automatically set to `false`. + +### 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. + +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. + +For **MOR + bucket index** setup, clustering is typically not needed. + +## Core Feature 1: Sorted Write + +All writes are sorted. That is, within any written file (**base or log**), records are fully sorted by key(s). + +### Initial support (v1) + +- `bulk_insert` +- `insert_overwrite` +- with **bucket index** + +### Future support + +- `insert`, `upsert` +- other index types + +### Example: Flink Streaming Write Pipeline + + + +The write pipeline mainly consists of four core stages: + +- **Repartitioning** +- **Sorting** +- **Deduplication** +- **I/O** + +Optimizations: + +1. **Asynchronous processing architecture** + Introduce a **Disruptor ring buffer** within the sink operator to decouple production and consumption, significantly improving throughput and handling cases where the producer outpaces the consumer. + +2. **Efficient memory management** + Integrate Flink’s built-in **MemorySegmentPool** with **BinaryInMemorySortBuffer** to enable fine-grained memory control and efficient sorting, greatly reducing GC pressure and sorting overhead. + +## Core Feature 2: Sorted Merge Read / Compaction + + + +During read and compaction, merging is performed using a **sorted merge algorithm** (e.g., **loser-tree** for k-way merge). + +- Resulting **log files** contain fully sorted records +- Resulting **base files** contain fully sorted records +- File group reads reuse the same sorted merge logic, with **predicate pruning** applied when present + +### Implementation tasks + +- Implement sorted merge: **Loser tree** for **k-way merge** +- Reuse existing **Record Merger APIs** +- Update the following components to use sorted merge: + - Log compaction + - Compaction runner (L0 → L1) + - File group reader + +--- + +## Additional (Orthogonal) Features + +These features amplify the benefits of the LSM layout but are not strictly required by the layout itself but can optimize the performance and user experience of LSM. + +### 1) Parquet as Log File Format + +**Benefits** + +- Vectorized processing +- Better compression than Avro +- Support pruning during reads + +Switching log file format from Avro to Parquet requires the following changes: + +0. Parquet log file naming format should remain consistent with existing Avro logs to ensure compatibility with existing MOR tables +1. **Writer changes**: Block append operations are no longer supported. During writes, input data is sorted and deduplicated, then written directly to new Parquet files using a Create handler: + - For **Spark**: reuse the bulk insert write logic + - For **Flink**: refactor the upsert write logic. Data preparation, metadata field addition, and sorting logic can be reused, but the final write should use the Parquet Create Handler to write new Parquet log files +2. **Reader changes**: When reading Parquet log files, skip the logic for handling delete blocks and damaged blocks. Read data directly using the Parquet Log Reader, enabling optimizations such as vectorized reads and column pruning +3. **Markers**: Implement a new MOR marker write mechanism. Create markers are written during writes, similar to COW create markers +4. **Rollback**: Handle both Marker-Based Rollback and Listing-Based Rollback scenarios: + - For MOR Parquet logs, damaged files are deleted directly (similar to COW) +5. **Cleaning**: MOR Parquet log file cleaning directly deletes the corresponding Parquet log files (similar to COW Parquet) + + +**Behavior changes** + +- MOR **rollback** deletes Parquet log files directly, instead of appending a delete block. +- For **cleaning**, Parquet log files are deleted. + +### 2) File-Group Granular Compaction + +Introduce a new compaction strategy that combines: + +- **Log compaction (L0)** +- **Log → base compaction (L0 → L1)** + +The compaction plan tracks individual **file groups** and determines whether each group needs: + +- L0 compaction only, or +- L0 → L1 compaction + +**Benefits** + +- More granular control of file sizes +- Skewed file groups can receive more compaction +- Choose between L0 vs L0→L1 compaction based on file stats (count, size, etc.) + +--- + +## Configuration + +The LSM tree layout can be enabled using a table config: + +```properties +# default "base_log" Review Comment: `default` ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: + +1. Improve the **read performance**, **write performance**, and **overall stability** of MOR tables—especially for **wide tables**—in scenarios such as: + - predicate pushdown + - point lookups + - column/data pruning +2. Improve the **performance** and **stability** of MOR **compaction** +3. Increase the **compression ratio** of log files + +## 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** (**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=base_log|lsm_tree` (default `base_log`, which is current base/log file organization): + +- The config is not allowed to be set to `lsm_tree` for an existing table +- The config is allowed to be set to `base_log` for an existing table + +The layout is only applicable to MOR table, and not applicable to COW. When setting the layout config for a COW table, the persisted config for the layout will always be false. + +When an LSM-tree layout enabled MOR table is migrated to COW, the layout config will automatically set to `false`. + +### 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. + +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. + +For **MOR + bucket index** setup, clustering is typically not needed. + +## Core Feature 1: Sorted Write + +All writes are sorted. That is, within any written file (**base or log**), records are fully sorted by key(s). + +### Initial support (v1) + +- `bulk_insert` +- `insert_overwrite` +- with **bucket index** + +### Future support + +- `insert`, `upsert` +- other index types + +### Example: Flink Streaming Write Pipeline + + + +The write pipeline mainly consists of four core stages: + +- **Repartitioning** +- **Sorting** +- **Deduplication** +- **I/O** + +Optimizations: + +1. **Asynchronous processing architecture** + Introduce a **Disruptor ring buffer** within the sink operator to decouple production and consumption, significantly improving throughput and handling cases where the producer outpaces the consumer. + +2. **Efficient memory management** + Integrate Flink’s built-in **MemorySegmentPool** with **BinaryInMemorySortBuffer** to enable fine-grained memory control and efficient sorting, greatly reducing GC pressure and sorting overhead. + +## Core Feature 2: Sorted Merge Read / Compaction + + + +During read and compaction, merging is performed using a **sorted merge algorithm** (e.g., **loser-tree** for k-way merge). + +- Resulting **log files** contain fully sorted records +- Resulting **base files** contain fully sorted records +- File group reads reuse the same sorted merge logic, with **predicate pruning** applied when present + +### Implementation tasks + +- Implement sorted merge: **Loser tree** for **k-way merge** +- Reuse existing **Record Merger APIs** +- Update the following components to use sorted merge: + - Log compaction + - Compaction runner (L0 → L1) + - File group reader + +--- + +## Additional (Orthogonal) Features + +These features amplify the benefits of the LSM layout but are not strictly required by the layout itself but can optimize the performance and user experience of LSM. Review Comment: We have this already right.. What are the net new changes? ########## rfc/rfc-103/rfc-103.md: ########## @@ -0,0 +1,246 @@ + <!-- + 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 Paimon, LevelDB, RocksDB, Cassandra, etc. By leveraging sequential writes and a tiered merge (compaction) mechanism, they offer clear advantages in: + +- **High write throughput** +- **Efficient, tiered compaction** +- **Optimized read paths** + +## Goal + +This RFC proposes applying LSM-inspired principles (**sequential writes + tiered merges**) to improve the data organization protocol for **Hudi MOR tables**, and replacing **Avro** with **Parquet** as the on-disk format for individual log files, to achieve: Review Comment: We already support parquet in log. -- 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]
