Thanks for drafting this. The overall direction of keeping this as a delta design over FIP-25 looks reasonable to me.
A few questions came to mind: 1. For the log-table path, should we still capture and persist the source Iceberg snapshot ID even though no KV bootstrap is required? It could serve as the historical read boundary and make the no-catch-up behavior explicit. 2. For mapping Iceberg identifier fields to Fluss primary keys, can we make the validation and failure semantics more explicit? Iceberg identifier fields are not enforced uniqueness constraints, so it would be good to define what happens if duplicate identifier values exist in the source snapshot. 3. Should the design explicitly reject unsupported Iceberg format versions or delete encodings, for example v3 deletion vectors, unless the selected Iceberg reader can guarantee correct snapshot-visible rows? I agree that delete-file handling should stay inside the Iceberg reader boundary. Fluss should not implement custom equality/position delete merging unless the Iceberg reader cannot provide correct snapshot-visible rows, in which case rejecting the table sounds safer for the first version. Best regards, Zhe Wang Yuxia Luo <[email protected]> 于2026年6月17日周三 10:44写道： > 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 > > >
