02-08-2023 02:12 PM
Hi there,
I read data from Azure Event Hub and after manipulating with data I write the dataframe back to Event Hub (I use this connector for that):
#read data
df = (spark.readStream
.format("eventhubs")
.options(**ehConf)
.load()
)
#some data manipulation
#write data
ds = df \
.select("body", "partitionKey") \
.writeStream \
.format("eventhubs") \
.options(**output_ehConf) \
.option("checkpointLocation", "/checkpoin/eventhub-to-eventhub/savestate.txt") \
.trigger(processingTime='1 seconds') \
.start()
In this case, I get high storage costs, which far exceed my computational costs (4 times). The expense is caused by a large number of transactions to the storage:
I tried to reduce the number of transactions by using processingTime as a trigger, but it didn't bring any significant result (for me, a minimal delay is critical).
Question: am I using structured streaming correctly, and if so, how can I optimize storage costs?
Thank you for your time!
02-09-2023 09:19 PM
Hi, Could you please refer https://www.databricks.com/blog/2022/10/18/best-practices-cost-management-databricks.html and let us know if this helps?
02-10-2023 10:42 AM
Debayan, thanks for your recommendation, I read this article, but it does not answer my question.
I'm just learning how to work with Databricks, and perhaps these costs are normal for structured stream processing?
02-12-2023 10:50 PM
Hi @Serhii Dovhanich
Hope all is well! Just wanted to check in if you were able to resolve your issue and would you be happy to share the solution or mark an answer as best? Else please let us know if you need more help.
We'd love to hear from you.
Thanks!
08-31-2023 06:22 AM
Hi,
I ran into the same problem today. The core of my problem was with an aggregation and join, my stream does not generate massive amounts of data but it still used 200 shuffle partitions. After scaling this down to 2 (you have to clear checkpoints to take effect) my transactions went down significantly. Hope this helps!
08-31-2023 07:02 AM
I had the same problem when starting with databricks. As outlined above, it is the shuffle partitions setting that results in number of files equal to number of partitions. Thus, you are writing low data volume but get taxed on the amount of write (and subsequent sequentialread) operations. Lowering amount of shuffle partitions helps solve this. On top of that, consider using spark.sql.streaming.noDataMicroBatches.enabled so that empty microbatches are ignored.
Join a Regional User Group to connect with local Databricks users. Events will be happening in your city, and you won’t want to miss the chance to attend and share knowledge.
If there isn’t a group near you, start one and help create a community that brings people together.
Request a New Group