You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Flink Iceberg connector sink is the tool to write data to an Iceberg table from a continuous Flink stream. The current Sink implementations emphasize throughput over flexibility. The main limiting factor is that the Iceberg Flink Sink requires static table structure. The table, the schema, the partitioning specification need to be constant. If one of the previous things changes the Flink Job needs to be restarted. This allows using optimal record serialization and good performance, but real life use-cases need to work around this limitation when the underlying table has changed. We need to provide a tool to accommodate these changes.
The following typical use cases are considered during this design:
Incoming Avro records schema changes (new columns are added, or other backward compatible changes happen). The Flink job is expected to update the table schema dynamically, and continue to ingest data with the new and the old schema without a job restart.
Incoming records define the target Iceberg table dynamically. The Flink job is expected to create the new table(s) and continue writing to them without a job restart.
The partitioning schema of the table changes. The Flink job is expected to update the specification and continue writing to the target table without a job restart.
Proposed Change
Flink Iceberg connector sink is the tool to write data to an Iceberg table from a continuous Flink stream. The current Sink implementations emphasize throughput over flexibility. The main limiting factor is that the Iceberg Flink Sink requires static table structure. The table, the schema, the partitioning specification need to be constant. If one of the previous things changes the Flink Job needs to be restarted. This allows using optimal record serialization and good performance, but real life use-cases need to work around this limitation when the underlying table has changed. We need to provide a tool to accommodate these changes.
The following typical use cases are considered during this design:
Proposal document
https://docs.google.com/document/d/1R3NZmi65S4lwnmNjH4gLCuXZbgvZV5GNrQKJ5NYdO9s
Specifications
The text was updated successfully, but these errors were encountered: