[SUPPORT]Performance degrade for migrating from Hudi 0.7 to Hudi 0.14 about hudi HOT 10 CLOSED

hoodie.simple.index.parallelism can be modified to adjust the parallelism of stage 121, but it may cause the parallelism of stage 120 to decrease. You can give it a try.

from hudi.

Hi @KnightChess Thanks for commenting. But my major doubt is why shuffle write is nearly doubled in hudi 0.14? And that is leading to issues in step 121

from hudi.

@bibhu107 if next parallelism is too bigger, shuffle data will grow. And the mayjor reason is task is too much because high, spark need to scheduler too mush task.

from hudi.

@bibhu107 and why shuffle data grow, I haven't looked at the code in detail; the following is just my guess. you have too much reducer, so the shuffle data may be need more meta. And on the other head, 0.7 -> 0.14, may be the shuffle's java object attr has change, this alse can cause diff. But I think parallelism is the major problem.

from hudi.

@bibhu107 does it can work for you? I misread the stack trace, so this parameter hasn't taken effect in the question stage. The parameter that needs to be set is a different one. If you are insert, try to set hoodie.insert.shuffle.parallelism, if upsert, set hoodie.upsert.shuffle.parallelism

from hudi.

Slack Thread https://apache-hudi.slack.com/archives/C4D716NPQ/p1718122404452279

from hudi.

Hello @KnightChess, thank you for your suggestions.

Initially, the Adaptive Query Execution (AQE) feature was disabled for the jobs because we were explicitly setting spark.sql.shuffle.partitions . Later, we enabled it using the following configuration:

spark.sql.adaptive.coalescePartitions.enabled=true
spark.sql.adaptive.skewJoin.enabled=true

Additionally, we removed the spark.sql.shuffle.partitions configuration. This change resulted in better job performance. However, we have not yet conducted any load/pressure testing.

We will share the results once we perform load testing. For now, we have moved back to Hudi 0.8 and using Spark3.3.1.

Thank you for raising the PR.

from hudi.

I have one query: Why do we need this PR? I expected Hudi to automatically take the deduced parallelism from Hudi 0.13.

As mentioned in the documentation for hoodie.upsert.shuffle.parallelism, it states:

From version 0.13.0 onwards, Hudi by default automatically uses the parallelism deduced by Spark based on the source data.

from hudi.

@bibhu107 hi, this pr is target to imporve the deduced parallelism and more user friendly, in hudi side, AQE can not effort because use rdd directly

from hudi.

I am closing this Issue. Thanks for support @KnightChess

from hudi.