You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hudi.apache.org by "ChiehFu (via GitHub)" <gi...@apache.org> on 2023/11/16 04:37:14 UTC
[I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
ChiehFu opened a new issue, #10115:
URL: https://github.com/apache/hudi/issues/10115
**_Tips before filing an issue_**
- Have you gone through our [FAQs](https://hudi.apache.org/learn/faq/)?
- Join the mailing list to engage in conversations and get faster support at dev-subscribe@hudi.apache.org.
- If you have triaged this as a bug, then file an [issue](https://issues.apache.org/jira/projects/HUDI/issues) directly.
**Describe the problem you faced**
Hello, Recently we migrated our datasets from Hudi 0.8 to Hudi 0.12.3 and started experiencing slowness in indexing stage in some tables during upserts.
After looking into spark steps, we found out that there was one particular stage where Hudi set a very low value parallelism for a indexing stage (stage 32 in the screenshoot) and ended up causing long duration and shuffle spill which further slowdown the stage. We set `hoodie.bloom.index.parallelism=2000` however, it doesn't seem to affect the parallelism of that particular stage.
In Hudi 0.8, Hudi used to use the value we set in `hoodie.upsert.shuffle.parallelism` for parallelism for this stage, however it seems in Hudi 0.12, the parallelism is being calculated dynamically.
Can you please help us understand if there is any Hudi configuration we should use to increase the parallelism for the stage?
We also tried setting `hoodie.copyonwrite.record.size.estimate` to a very small value as it seems help forcing Hudi to use a larger parallelism for indexing initially, but it's very inconsistent as we still see small values being set for the stage across upsert jobs.
**Environment Description**
* Hudi version : 0.12.3
* Spark version : 3.1.3
* Hive version : 3.1.3
* Hadoop version : 3.3.3
* Storage (HDFS/S3/GCS..) : S3
* Running on Docker? (yes/no) : no
* EMR: 6.10.0
**Additional context**
Hudi configs
```
hoodie.metadata.enable: true
hoodie.metadata.validate: true
hoodie.cleaner.commits.retained: 72
hoodie.keep.min.commits: 100
hoodie.keep.max.commits: 150
hoodie.datasource.write.payload.class: org.apache.hudi.common.model.DefaultHoodieRecordPayload
hoodie.index.type: BLOOM
hoodie.bloom.index.parallelism: 2000
hoodie.copyonwrite.record.size.estimate: 1
hoodie.metadata.enable: true
hoodie.datasource.write.table.type: COPY_ON_WRITE
hoodie.insert.shuffle.parallelism: 1500
hoodie.datasource.write.operation: upsert
hoodie.datasource.hive_sync.partition_extractor_class: org.apache.hudi.hive.MultiPartKeysValueExtractor
hoodie.datasource.write.keygenerator.class: org.apache.hudi.keygen.ComplexKeyGenerator
```
<img width="2313" alt="Screenshot 2023-11-15 at 8 20 39 PM" src="https://github.com/apache/hudi/assets/11819388/e0381e62-0690-4bce-8fe3-15f6590870bb">
<img width="2297" alt="Screenshot 2023-11-15 at 8 32 48 PM" src="https://github.com/apache/hudi/assets/11819388/3a481bb8-c6ff-456d-baca-b60b22788abf">
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "ad1happy2go (via GitHub)" <gi...@apache.org>.
ad1happy2go commented on issue #10115:
URL: https://github.com/apache/hudi/issues/10115#issuecomment-1815118619
Great! @ChiehFu So closing this issue then. We will discuss the slowness issue on the other ticket. Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "ChiehFu (via GitHub)" <gi...@apache.org>.
ChiehFu commented on issue #10115:
URL: https://github.com/apache/hudi/issues/10115#issuecomment-1815044211
@ad1happy2go got it, thanks for the clarification.
I tried repartitioning the input df by 100 and observed the parallelism of both tagging and indexing stages were set to 100 as well which significantly speeded up the indexing performance.
I submitted another issue where slowness was observed in writing stage with S3 storage with Hudi 0.12.3, could you please take a look when you have a chance? https://github.com/apache/hudi/issues/10121
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "ad1happy2go (via GitHub)" <gi...@apache.org>.
ad1happy2go commented on issue #10115:
URL: https://github.com/apache/hudi/issues/10115#issuecomment-1813990007
@ChiehFu In older versions of hudi we do use the configs but it newer versions we derive it from input DataFrame. Your two files are 115 MB so they ideally make those number of partition (2-3) only as block size is 128 MB.
You can try setting `sql.files.maxPartitionBytes` to a lower value so that it can make more partitions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "ad1happy2go (via GitHub)" <gi...@apache.org>.
ad1happy2go commented on issue #10115:
URL: https://github.com/apache/hudi/issues/10115#issuecomment-1813816561
@ChiehFu Do you know if any particular reason why it's taking only 3 tasks. Can you paste the full UI for one of the job. Need to check how many tasks it create for Tagging stage.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "ChiehFu (via GitHub)" <gi...@apache.org>.
ChiehFu commented on issue #10115:
URL: https://github.com/apache/hudi/issues/10115#issuecomment-1813946952
@ad1happy2go I see. In this case there were only 2 tsv files with a total size of 115.7 MiB.
<img width="498" alt="image" src="https://github.com/apache/hudi/assets/11819388/da21e2b8-4061-455d-bdd2-d9a33ebba051">
Is repartitioning by 10000 something we could apply universally to all our tables regardless of input data size? Or it would be better to derive the value based on some factor like input size and would it cause any harm to upsert performance if we over re-partition?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "ad1happy2go (via GitHub)" <gi...@apache.org>.
ad1happy2go commented on issue #10115:
URL: https://github.com/apache/hudi/issues/10115#issuecomment-1813912870
@ChiehFu The tasks in tagging step depends n how many partitions are there in input DataFrame.
By any chance are you getting large zipped files in source? You can do repartition before write to hudi.
`df.repartition(10000).write.format....`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "ChiehFu (via GitHub)" <gi...@apache.org>.
ChiehFu commented on issue #10115:
URL: https://github.com/apache/hudi/issues/10115#issuecomment-1813967637
@ad1happy2go Those two files were plain tsv files without compression.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "codope (via GitHub)" <gi...@apache.org>.
codope closed issue #10115: [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3
URL: https://github.com/apache/hudi/issues/10115
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "ChiehFu (via GitHub)" <gi...@apache.org>.
ChiehFu commented on issue #10115:
URL: https://github.com/apache/hudi/issues/10115#issuecomment-1813954024
@ad1happy2go I see, thanks for the explanation. Let me double check on the file format and get back to you.
In addition, we has this table running in Hudi 0.8 for over a year and this didn't seem to be an issue (low parallelism) until we upgraded the table to Hudi 0.12. Was it because the way how parallelism is derived was changed in Hudi 0.12?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "ChiehFu (via GitHub)" <gi...@apache.org>.
ChiehFu commented on issue #10115:
URL: https://github.com/apache/hudi/issues/10115#issuecomment-1813862633
@ad1happy2go I am not sure why it only had 3 tasks. This particular upsert job upserted 328,550 records.
<img width="2319" alt="Screenshot 2023-11-15 at 10 24 14 PM" src="https://github.com/apache/hudi/assets/11819388/4826e4b8-9a90-4973-b040-6decb711fda2">
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3 [hudi]
Posted by "ad1happy2go (via GitHub)" <gi...@apache.org>.
ad1happy2go commented on issue #10115:
URL: https://github.com/apache/hudi/issues/10115#issuecomment-1813949629
@ChiehFu We should derive based on input data size. Too many partitions will create extra tasks and create extra overhead time. Are those 2 tsv files gzipped. If yes that is causing the job only have 3 tasks. gzip is unsplittable format.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org