topic Re: Accessing Unity Catalog's MLFlow model registry from outside Databricks in Machine Learning

Accessing Unity Catalog's MLFlow model registry from outside Databricks

rahuja — Fri, 31 May 2024 12:31:11 GMT

Hello Everyone

We are integrating Unity Catalog in our Organisation's Databricks. In our case we are planning to move our inference from Databricks to Kubernetes. In order to make the inference code use the latest registered model we need to query the model registry from outside Databricks. So I wanted to ask:
1. Is the model registry exposed via a public api?

2. If not how can we do this?

Thanks in advance for your time.

Re: Accessing Unity Catalog's MLFlow model registry from outside Databricks

mhiltner — Fri, 31 May 2024 16:30:51 GMT

Hey @rahuja,

If you register your models in Unity Catalog (and they effectively appear on your Catalog Explorer) you could use Delta sharing for your models. https://docs.databricks.com/en/data-sharing/index.html

Also, curious about the decision. Databricks serving capabilities are quite good, what are the benefits that you are looking for with this migration?

Re: Accessing Unity Catalog's MLFlow model registry from outside Databricks

rahuja — Wed, 03 Jul 2024 05:21:51 GMT

Hello @mhiltner

Currently we are contemplating whether to do this or not. In my organisation this decision is based due to cost. We already have a managed Kubernetes cluster that we are paying for.

Re: Accessing Unity Catalog's MLFlow model registry from outside Databricks

p4pratikjain — Fri, 12 Jul 2024 05:42:53 GMT

I have used glue in the past to score models that are registered in Databricks mlflow registry. You need to configure MLFlow on Kubernetes to access your model registry.
You can use something like this -
https://docs.databricks.com/en/mlflow/access-hosted-tracking-server.html

Re: Accessing Unity Catalog's MLFlow model registry from outside Databricks

bajdwobaht — Wed, 05 Feb 2025 15:48:01 GMT

You can use the MLflow client (in various language specific SDKs) to download model artifacts. For example, see here: https://docs.databricks.com/en/mlflow/models.html#download-model-artifacts

We leverage this pattern to serve models in our K8s stack for similar reasons to what you stated (existing clusters, cost / performance, network latency benefits, etc.). I've also used Databricks Model Serving extensively, including in the original "CPU only on Spark clusters" version, and I much prefer the self-managed route if it's something your team has capacity to support.