Installing Databricks Connect breaks pyspark local cluster mode
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-02-2024 11:14 PM
Hi, It seems that when databricks-connect is installed, pyspark is at the same time modified so that it will not anymore work with local master node. This has been especially useful in testing, when unit tests for spark-related code without any remote session.
Without databricks-connect this code works fine to initialize local spark session:
spark = SparkSession.Builder().master("local[1]").getOrCreate()
However, when databricks-connect python package is installed that same code fails with
> RuntimeError: Only remote Spark sessions using Databricks Connect are supported. Could not find connection parameters to start a Spark remote session.
Question: Why does it work like this? Also, is this documented somewhere? I do not see it mentioned in Databricks Connect Troubleshooting or Limitations documentation pages. Same issue has been asked at Running pytest with local spark session · Issue #1152 · databricks/databricks-vscode · GitHub.
- Labels:
-
Spark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-15-2024 11:51 PM
I got the error mentioned in the original post due to the installation of Databricks Connect.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2024 09:01 AM
I think in case you're deliberately installing databricks-connect, then you need to handle the local spark session creation.
My issue is that I'm using databricks-dlt package which installs databricks-connect as a dependency. In the latest package version 0.3.0, this breaks pyspark.sql SparkSession creation, forcing me to use DatabricksSparkSession.
To solve this I need to hard code databricks-dlt to previous release version which is not ideal, in case next releases bring new features that I would like to use.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-14-2025 08:45 AM - edited 02-14-2025 08:48 AM
I use databricks-connect for local IDE-based (pycharm) development of databrick-jobs. New databricks-connect with DatabricksSession made me a lot of trouble, since I needed to maintain two separate import system for local development, and for job execution on databricks. And this messy solution was suggested by databricks here.
I think i found a workaround to this issue. I haven't tested it deeply, but basic functionality seems to be working.
With this I can create and use SparkSession from my IDE, connecting to remote databricks cluster with DBR15.4 (with Apache Spark 3.5.0).
So my solution is the next:
I've removed databricks-connect package and installed pyspark 3.5.0 instead. To access my remote databricks cluster I use spark-connect and its SPARK_REMOTE env variable, which looks something like this:
SPARK_REMOTE=sc://blahlbah.cloud.databricks.com:443/;token=mytoken;x-databricks-cluster-id=myclusterid
I built the value of the variable is based on this documentation.
After configuring the env var for a python script execution I can use SparkSession as before:
from pyspark.sql import SparkSession
spark = SparkSession.builder.getOrCreate()
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-08-2025 01:46 PM - edited 03-08-2025 01:48 PM
This issue is very bizarre and was very cumbersome to deal with.. but i think i found a solution i can live with
For me, using 2 venv just complicates to project in a way i an not willing to maintain.
Spark Connect, although promising, lacks in a lot of ares compared to the databricks connect, to name a few:
- session needs to be rolled every hour due to the token going bad,
- some cluster lifecycles are just not recognized by a regular Spark Connect, like when the cluster is warming up, databricks will wait for the cluster to be ready, while spark connect will raise an exception. One CAN map the different scenarios and build handling logic, but why would he?
As I need this specifically for unit-testing, an I use pytest, I downloaded the original pyspark to a directory on my root folder with:
pip install --target pyspark_unpatched pyspark==X.Y.Z
i created this conftest.py in the root of the project:
def override_databricks_spark() -> None:
repo_root = Path(__file__).parent.resolve()
unpatched_pyspark_dir = os.path.expanduser(repo_root / "pyspark_unpatched")
sys.path.insert(0, unpatched_pyspark_dir)
import pyspark as unpatched_pyspark
sys.path.remove(unpatched_pyspark_dir)
sys.modules["pyspark"] = unpatched_pyspark
print(f"Overridden pyspark with module from {unpatched_pyspark_dir}")
override_databricks_spark()
Because conftest loads first, It allows you do make sure the the unpatched version of pytest loads first, letting you test peacefully
The main drawback of this is you must use the `pyspark` import statement, using Databricks will break the tests (not that it matters, at least i think it doesn't). and obvoiusly, downloading pyspark, but considering the alternatives, i am willing to bite that bullet.
This was my ref from stack overflow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-14-2025 04:41 AM
I agree with most of the comments above, that the current approach of databricks-connect is not great (it sucks to be frankly). Its an issue that was bugging me since more than 2 years now.
By the way, i checked how this could be done with poetry and uv. In poetry i got something somewhat working since this PR was merged: https://github.com/python-poetry/poetry/pull/9553
With uv I still don't have an acceptable solution. In fact the uv devs seem to claim, that there is no way to solve this with the current python packaging specifications: https://github.com/astral-sh/uv/issues/10238#issuecomment-2575893989


- « Previous
-
- 1
- 2
- Next »