[FLINK-39241][table] Fix MultiJoinStateViews by changing GenericRowData to BinaryRowData

[ldadima]

What is the purpose of the change

To fix FLINK-39241

Verifying this change

Run JoinITCase#testThreeWayMultiJoinWithoutPk

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): ( no)
• The serializers: (no)
• The runtime per-record code paths (performance sensitive): (no)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
• The S3 file system connector: (no)

Documentation

• Does this pull request introduce a new feature? ( no)
• If yes, how is the feature documented? (not applicable)

[flinkbot]

CI report:

• b37be41 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[ldadima]

Hi @gustavodemorais
Can you review, please?

[ldadima]

Hey @snuyanzin Could you review, please?

[snuyanzin]

Ideally would be great to follow new store restore test approach
would be great if you can do that instead

[ldadima]

@snuyanzin Thanks for review
This test, as in the previous PR with a similar problem, is only temporary. It was decided to expand this PR with the necessary tests.
Is it ok, what do you think?

[gustavodemorais]

Yeah, let's add also this one to the new suite. I'll take a look at the new suite next

[gustavodemorais]

Thanks for the contribution @ldadima. A few comments, mostly for consistency with #27508.

[ldadima]

Thanks for review @gustavodemorais .
Code changed according your comments

[gustavodemorais]

LGTM. Btw, it's usually easier to ping me on the Community Slack if I can help with something.

Also, @ldadima, thinking of next possible topics. How did you perform the benchmark comparison you shared in the last PR? It'd be nice to have an open source benchmark between the MultiJoin and regular Joins. Among other things, it'd be interesting to have numbers on the effects of the cardinality of the common join key. I know we have https://github.com/apache/flink-benchmarks but I haven't contributed to it yet

[ldadima]

Thanks @gustavodemorais , I will use this opportunity (Slack) if necessary.
I used this benchmark (https://github.com/nexmark/nexmark)
There is a prepared set of SQL queries. I took part of the set (significant queries with joins) and compared the results with multi-join optimization turned off and on. Also in the nexmark benchmarks, there is Q23 - a query with multiple joins, where the results of multi-join optimization can be seen.

Besides comparing performance, it is also worth noting that regular join supports Window and mini-batch improvements.

[gustavodemorais]

I know Q23 and it'd be nice to have some statistic on it for different type of data coming in. In the example of Q23, how does the performance progresses if "B.bidder" has only one record in each table, or 10 records, or 1000 records etc.

The same would be for a larger join, like 10 joins. Do you think https://github.com/apache/flink-benchmarks would be a good way to have this?

[ldadima]

I think a general performance comparison is beyond the scope of the task described. In the Jira ticket I created, I wanted to highlight the issue of multi-join with two inputs. I don't think it's necessary to consider the case where the multi-join rule generate multi-join with more than two inputs.

[gustavodemorais]

I think a general performance comparison is beyond the scope of the task described.

I wasn't referring to this PR or another jira you created. I'm talking about another possible new ticket. A general performance comparison considering some aspects would be great to share with the community. Wdyt?

[ldadima]

A general performance comparison considering some aspects would be great to share with the community. Wdyt?

Oh, sorry. I didn't understand you earlier. Indeed, it would be good to make smth like that
But we need to understand what we want to compare. There is Q23 (different data distributions) and flink-benchmarks
Maybe it's also worth creating a Jira ticket for this.

[gustavodemorais]

Sounds good. Anyway, this PR looks good. Thanks for the contribution, @ldadima.

[snuyanzin]

Thanks for the PR @ldadima
thanks for the review @gustavodemorais