Hi, Liting Thanks a lot for this FIP, and apologies for the late reply. A note first: the content, interfaces, and implementation of FIP-25 may still change, but the overall direction should stay roughly the same. Building Iceberg support on top of FIP-25 is a great starting point.
I have a couple of small questions: 1: Partition mapping. Iceberg supports transform-based partitioning, e.g. day(ts). How do we plan to map this onto Fluss partitions? It'd be good to clarify how transform partitions (and possibly partition spec evolution) are handled. 2: Bucket configuration. For an Iceberg primary-key table, there isn't an explicit bucket concept like in Paimon. But a Fluss primary-key table needs a bucket count. Wha would the bucket count be for the resulting Fluss primary-key table? Looking forward to your reply. On 2026/05/21 06:18:47 "Liting Liu (litiliu) via dev" wrote: > Hi community, > > I drafted a design for supporting create_from_lake on existing Iceberg tables: > > https://docs.google.com/document/d/1REmpQ2r5W12OvW2CU9tNjDWjpkFJegiTZnE1IZbBH_U/edit?tab=t.0 > > The proposal follows the existing Paimon create_from_lake design as much as > possible, and only introduces Iceberg-specific deltas where needed. > > The main difference is how the target Fluss table type is derived from > Iceberg metadata: > > * Iceberg format v1 tables are mapped to Fluss log tables. > * Iceberg format v2 tables without identifier fields are mapped to Fluss > log tables. > * Iceberg format v2 tables with non-empty identifier fields are mapped to > Fluss primary-key tables and reuse the existing bootstrap flow. > > For primary-key tables, the design reuses the same coordinator lifecycle, > single holdPartition model, Tiering Service bootstrap pipeline, snapshot > commit flow, partition activation, and recovery behavior from the Paimon > design. The Iceberg-specific part is mainly metadata extraction and using the > Iceberg reader to read snapshot-visible rows during bootstrap. > > Could you please help review the draft and share feedback, especially on: > > * Whether the table type mapping based on Iceberg format version and > identifier fields is reasonable. > * Whether relying on the Iceberg reader for equality/position delete > handling during bootstrap is the right boundary. > * Whether there are any Iceberg-specific cases missing from the current > design. > > Thanks >
