@Kezhu Wang <kez...@gmail.com> 你的说法大概懂。不过改造成本有点高,本身复写个算子不难。但是貌似这个地方考虑点太多了。比如我放个接口允许reduce的时候支持一个RichReduceFunction2。相当于对于每个record,要经过默认的reduceFunc,再经过我的RichReduceFunction2,然后窗口触发再去windowFunc。 这样可能我还需要调整emitWindowContent那部分,想办法将RichReduceFunction2中自定义的状态内容也丢进 windowFunc的参数中去。
赵一旦 <hinobl...@gmail.com> 于2021年1月29日周五 下午12:34写道: > 不是,flink是提供了richReduce,但不支持基于window的richReduce。 > > 基于window的reduce只支持简单reduce,具体需要做自定义状态计算的,按照注释要求使用windowFunction和ProcessWindowFunction去做呀。 > > 一直都是这样,1.12也是的哈。 > > Kezhu Wang <kez...@gmail.com> 于2021年1月29日周五 上午11:40写道: > >> reduceFunction 是和 ReducingStateDescriptor 配合的, 并不是 >> “window的”。“WindowOperator” 的 function 是 “InternalWindowFunction”,这个可以是 >> “RichFunction”。 >> >> Flink 中的 state 除了可以绑定 key,也可以绑定 namespace,只是 namespace >> 并没有直接暴露给用户。如果需要的话,可以自己写个 WindowOperator,暴露个 WindowFunction。 >> >> Interface WindowFunction { >> // You could do incremental aggregation here. >> void processElement(Context context, Window window, Element element); >> >> void fireWindow(Context context, Window window); >> } >> >> interface WindowedRuntimeContext { >> State getWindowedState(StateDescriptor descriptor). >> } >> >> 把所有 window concepts 交给 WindowOperator,WindowFunction 作具体业务。 >> >> On January 28, 2021 at 20:26:47, 赵一旦 (hinobl...@gmail.com) wrote: >> >> 问题如title,当然当前Flink的API还是可以实现RichReduceFunction的效果的,就是基于windowFunction或者processWindowFuntion。 >> >> 但是,windowFunc和reduceFunc最大的区别在于windowFunc是窗口触发操作,而reduce是实时的增量操作。 >> 如果说我的窗口计算对于每个record的到来都需要一个极复杂的操作,我更希望在reduce中完成,而不是windowFunc中完成,因为那样会导致整个窗口所有key的数据几乎在同一时刻触发,这回导致压力变高。 >> >> >>