Forum Discussion
Any integration or tutorials for Spark Connect?
Hi dbeavon3 ,
Based on my understanding, since Spark connect requires remote connectivity, it needs a hostname which would be the IP address of the Spark Context. And since there is no authentication mechanism invovled with Spark-connect unless you manually setup a re-direction URL mechanism (authentication proxy), I don't believe Fabric will allow that level of configuration in their cloud system.
Using Managed Virtual networks with Fabric, you might get the URL of the Spark context and use it, but again this is just my assumption and as you said, there is no documentation, it is difficult to validate unless we do a PoC.
The following seems true after I read the description from MS site and Spark site.
Maybe someone copy/pasted from the OSS docs for Apache Spark.
Hi dbeavon3,
Well, the reason I said it is cluster because you can have a high-concurrency cluster to which you can attach multiple notebooks and run them parallely. The reason clusters don't have separate monitoring for cost is everything is included in a single billing which Fabric capacity used per second.
You can think of this as a game card that you buy in a mall and you have preloaded points that you can spend on various games. Some games cost you higher than other games and it is upto you how you spend that preloaded points.
In the same way, F2 capacity has 7200 CU-seconds per hour. So, let's say you spin up a standard cluster and assume it costs about 5000 CU seconds every hour. You can attach only one notebook at a time to it. Let's say you spin up a high-concurrency cluster with same size (so same 5000 CU seconds every hour). Now you can attach multiple notebooks to that cluster and run them. But there might be a performance difference depending on the compute requirements of the notebook. If multiple notebooks run with same performanceas standard cluster ( which means standard cluster wasunderutilized) , then there would be a cost-saving. So it would be cluster usage rather than notebook level.
You said:
>> So, let's say you spin up a standard cluster and assume it costs about 5000 CU seconds every hour.
I think there are some bad assumptions here. Do you have any supporting links to say that a given-sized "cluster" has a fixed CU cost per hour? I have not found that because I don't think it exists in Fabric. (It would be true in all the other Spark platforms but it is not true in Fabric.)
I suspect the information you have is wrong, and/or it is subject to change. It is probably something that was told to you verbally by a Microsoft salesperson...
First of all the word "cluster" in Fabric is replaced with "pool" which is presented to users as metadata, rather than a physical entity. The subtle change in terminology will create ambiguity and that works in Microsoft's favor. Secondly there is no management console for a "cluster" in Fabric. If CU costs could truly be optimized in the way that you described then having a management console would be a very high priority. There is such a console in the Synapse and Databricks and HDI platforms. But in Fabric there is NOT likely to be one soon, since it is NOT directly relevant to Fabric cost-management, and since Microsoft wants their platform to be "easy", and don't want users to concern themselves with these superfluous implementation details.
Thirdly, the CU meters for Spark notebooks are NEVER presented in the terms that you described ("CU seconds per hour per cluster"). As I said, the accounting is decrementing CU's is based on notebook-hours, or notebook-compute-hours. You can visualize this in their "Capacity Metrics App" (... such as it is, given that it seems to be the only administration tool available for Spark in Fabric). See below.
We can probably agree that optimization is accomplished by reducing the length of time that notebooks run, and using fewer/smaller executors for the synapse notebooks. Doing these things will allow us to see the positive changes in the "capacity metrics app".
Where we don't agree is when you say that there is a fixed cost at the "cluster" level, and that customers can optimize our workloads at that level. There is no way for us to get operating leverage, by way of a fixed cluster cost; because Fabric billing does not happen that way. The billing happens exclusively via the variable costs per notebook-hour.