Re: IntervalJoin is stucked in rocksdb'seek for too long time in flink-1.6.2
The IntervalJoin is actually the DataStream-level implementation of the SQL time-windowed join.
To ensure the completeness of the join results, we have to cache all the records (from both sides) in the most recent time interval. That may lead to state backend problems when huge streams flooding in.
One benefit of SQL is that the optimizer will help to reduce the join inputs as much as possible (e.g., via predicate pushdown), but that should be done manually in DataStream programs. Thus, I suggest you to 1) try increasing the parallelism (and number of nodes if possible); 2) filter out some records or reduce the number of fields in advance.
> On Nov 21, 2018, at 2:06 AM, liujiangang <liujiangangpeng@xxxxxxxxx> wrote:
> I am using IntervalJoin function to join two streams within 10 minutes. As
> .between(Time.milliseconds(0), Time.milliseconds(600000))
> .process(new processFunction())
> labelStream and adLogStream are proto-buf class that are keyed by Long id.
> Our two input-streams are huge. After running about 30minutes, the output to
> kafka go down slowly, like this:
> When data output begins going down, I use jstack and pstack sevaral times to
> get these:
> It seems the program is stucked in rockdb's seek. And I find that some
> rockdb's srt file are accessed slowly by iteration.
> I have tried several ways:
> 1)Reduce the input amount to half. This works well.
> 2)Replace labelStream and adLogStream with simple Strings. This way, data
> amount will not change. This works well.
> 3)Use PredefinedOptions like SPINNING_DISK_OPTIMIZED and
> SPINNING_DISK_OPTIMIZED_HIGH_MEM. This still fails.
> 4)Use new versions of rocksdbjni. This still fails.
> Can anyone give me some suggestions? Thank you very much.
> Sent from: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/