Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
Flink Autoscaling with the Kubernetes Operator relies on a set of metrics to scale up and down the sources. The algorithm currently works well with the Kafka sources since it provides metrics that track backlog and the maximum source parallelism.
Users also need efficient autoscaling for other sources like Iceberg. However, pendingRecords
is currently only reported by the SourceReader
and doesn’t cover the case for sources that only the SourceEnumerator
can calculate those metrics e.g. bounded split implementations like Iceberg.
Another challenge is obtaining the maximum parallelism. For the Kafka sources, the autoscaling implementation uses a Kafka specific metric to determine the upper limit for scaling. Flink already provides a metric unassignedSplits
that give a signal of the remaining splits to assign but it is missing the number of currently assigned splits to obtain the total splits.
Public Interfaces
This FLIP requires changes to SplitEnumeratorMetricGroup
, adding methods to set two metrics for pendingRecords
and assignedSplits
.
@PublicEvolving public interface SplitEnumeratorMetricGroup extends OperatorCoordinatorMetricGroup { <G extends Gauge<Long>> G setUnassignedSplitsGauge(G unassignedSplitsGauge); /** new addition */ void setPendingRecordsGauge(Gauge<Long> pendingRecordsGauge); /** new addition */ void setAssignedSplitsGauge(Gauge<Long> assignedSplitsGauge); }
Proposed Changes
Core Flink
- Add the setters
setPendingRecordsGauge
andsetAssignedSplitsGauge
in theSplitEnumeratorMetricGroup
. - Implement those setters in the InternalSplitEnumeratorMetricGroup.
Flink Kubernetes Operator
- Support retrieving pendingRecords metrics that comes from the enumerator.
- Generalize the logic to determine the upper limit for source parallelism.
Compatibility, Deprecation, and Migration Plan
Just like the other standardized connector metrics, these are opt-in and will not cause any backward incompatible behavior as such. Autoscaling will still work for sources without these metrics by relying on the busyness metrics and will not work as efficiently until they opt-in to reporting these metrics.
Test Plan
Unit tests in Core Flink and Flink Kubernetes Operator repos.
Rejected Alternatives
- Unify where the pendingRecords metric is reported (enumerator vs reader).
For unbounded splits like Kafka/Pulsar partitions, it would be difficult to calculate these outside of the readers--thus requiring additional RPCs to communicate this to the enumerator if we wanted to unify. We would also need to introduce configuration to emit these events periodically, complicating the design.
For bounded splits like File/Iceberg splits, the individual readers have no context about what remains.
Thus, I propose to report this metric from enumerator and reader in the way that is easiest for the specific connector and handle both metricGroups in the autoscaling implementation.