Databricks Marketplace: Daten und Modelle einfacher beziehen
Die Kernaussagen auf einen Blick.
- Der Databricks Marketplace ist die Discovery- und Distributions-Schicht über Delta Sharing, mit Listings für Daten, Foundation-Modelle und Lösungs-Notebooks.
- Bezogene Listings landen über Delta Sharing direkt im Unity Catalog des Empfängers, die Lizenz- und Update-Mechanik bleibt beim Provider.
- Der Marketplace ist Beschaffungs-Pfad, kein Garant für Datenqualität oder Lizenz-Rechtssicherheit, und Compute beim Konsumenten ist die häufig übersehene Rechnung.
- Empfehlenswert ist, den Marketplace als ersten Anlaufpunkt für externe Daten- und Modellbedarfe zu prüfen, bilaterales Sharing für spezifische Partner-Topologien gezielt einzusetzen und eigene Listings nur als bewusste Datenprodukt-Entscheidung zu veröffentlichen.
Inhaltsverzeichnis
Ein Provider-Vertrag ist erst der Anfang
Für ein neues Forecasting-Modell werden Wetterdaten gesucht. Die fachliche Frage ist in zwei Stunden geklärt: stündliche Werte für drei Länder, fünf Jahre Historie, tägliches Update. Die Beschaffung dauert dann acht Wochen. Drei Provider schicken Sample-Files, jeder mit eigener Lieferform: einer baut einen S3-Bucket auf, der zweite einen SFTP-Drop, der dritte eine REST-API mit Rate-Limit. Jeder hat einen eigenen Lizenz-Text, eine eigene Update-Frequenz, eine eigene Vertragsklausel zu personenbezogenen Daten. Am Ende braucht es einen ETL-Job pro Quelle, einen Schedule pro Quelle, ein Monitoring pro Quelle. Die Wetterdaten sind im Lakehouse, und die Plattform hat einen weiteren Lieferpfad zu pflegen.
Dasselbe Bild wiederholt sich bei Branchendaten, Geo-Daten, Demografie, Adressdaten, Wirtschafts-Indikatoren. Jede externe Quelle wird einzeln verhandelt, einzeln angebunden, einzeln betrieben. Und parallel kommt der Wunsch nach Foundation-Modellen: der eine Anwendungsfall verlangt Llama, der nächste Anthropic, ein dritter ein Open-Source-Embedding-Modell. Soll man das alles selbst hosten? Über separate APIs anbinden? Über die Modell-Registry kuratieren?
Im Plattform-Alltag wiederholen sich die typischen Fragen:
Welche externen Quellen lohnen den Beschaffungs-Aufwand und welche nicht? Wo entstehen die Lieferpfade, die in zwei Jahren niemand mehr pflegen will? Was ist eigentlich die Update-Garantie der Quelle, und was passiert, wenn der Provider aussteigt? Können eigene Daten als Datenprodukt für andere Konzern-Töchter oder Partner verfügbar werden, ohne dass ein eigener Sharing-Stack aufgebaut wird? Lohnt der Bezug eines Foundation-Modells über einen Katalog, oder bleibt der direkte API-Pfad zu Anbieter X die bessere Wahl?
Der Databricks Marketplace setzt an dieser Stelle an. Er ist nicht der Datenstrategie-Ersatz und nicht der Garant für Qualität. Er ist der Versuch, die Beschaffungs- und Distributions-Schicht zu standardisieren: ein Katalog, in dem Daten-, Modell- und Lösungs-Listings auffindbar sind, ein einheitlicher Bezug über Delta Sharing, ein einheitlicher Landeplatz im Unity Catalog. Das ist der eigentliche Hebel.
Was ist der Databricks Marketplace?
Der Databricks Marketplace ist ein offener Katalog von Listings für Daten, Modelle und Lösungen, der auf dem Delta-Sharing-Protokoll aufsetzt. Der Vendor selbst beschreibt ihn als offenen Marktplatz für Daten, Analytics und KI, betrieben über den Open-Source-Standard Delta Sharing. Daraus folgen zwei Eigenschaften, die die Architektur-Entscheidung tragen.
Die erste Eigenschaft ist die Discovery-Schicht. Listings werden in einem zentralen UI auffindbar, mit Metadaten, Sample-Daten, Lizenz-Text, Update-Frequenz und Provider-Profil. Bisher liefen Anreicherungs-Quellen über Vendor-Listen, Salesgespräche und private Kontakte; ein Katalog mit Filter, Vorschau und Provider-Identität ersetzt die Vertrags-Verhandlung nicht und beschleunigt die Vorauswahl um Wochen.
Die zweite Eigenschaft ist die Distributions-Schicht. Sobald ein Listing abonniert wird, läuft der Bezug über Delta Sharing in den Unity Catalog des Empfängers. Es entfällt der eigene Lieferpfad, die eigene Integrations-Schicht und die eigene Authentifizierungs-Mechanik pro Provider. Das standardisiert das, was beim klassischen Datenkauf jede Quelle individuell verlangt hat.
Zur Einordnung: Der Marketplace ist die Distributions-Schicht. Die Daten selbst liefert er nicht; sie stammen vom Lieferanten, der seine Tabellen, Volumes, Notebooks oder Modelle als Listing veröffentlicht. Der Marketplace katalogisiert diese Listings und vermittelt zwischen Anbieter und Empfänger. In Suchen taucht dafür auch der vom Anbieter geprägte Begriff „Delta Marketplace“ auf. Gemeint ist derselbe Databricks Marketplace und kein eigenes Produkt rund um Delta Lake. Wie das Format darunter funktioniert, klären wir im Überblick zu Delta Lake.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Daten, Foundation Models und Lösungsbausteine
Im Databricks Marketplace lassen sich drei zentrale Listing-Typen unterscheiden, dazu Dashboards als vierte, seltenere Kategorie. Sie adressieren unterschiedliche Bedarfe und folgen jeweils einer eigenen Beschaffungslogik, sind aber über denselben Marketplace auffindbar und gelangen über Delta Sharing in den Unity Catalog des Empfängers.
Daten-Listings sind der klassische Anwendungsfall. Anbieter stellen Tabellen oder Volumes als Share bereit, die nach dem Abonnieren direkt im Unity Catalog als Shared Catalog verfügbar werden. Typische Beispiele sind Wetter- und Klimadaten, Geo- und Kartendaten, Wirtschafts- und Branchenindikatoren, demografische Daten, Adress- und Firmendaten, Finanzdaten sowie Mobilitäts- und Verkehrsdaten. Der Vorteil für Unternehmen liegt darin, externe Datenquellen ohne aufwendige Schnittstellenprojekte in bestehende SQL-Workloads, Notebooks oder Datenpipelines einzubinden. Je nach Listing werden neben Tabellen auch Dateien, Beispiel-Notebooks oder zusätzliche Einstiegshilfen bereitgestellt.
Foundation-Model-Listings gewinnen zunehmend an Bedeutung. Über den Marketplace werden offene Modelle wie Llama- oder Mistral-Varianten, Embedding-Modelle sowie ausgewählte proprietäre Modelle auffindbar und für den eigenen Workspace nutzbar gemacht. Der Bezug erfolgt dabei innerhalb der Databricks-Umgebung und kann über die Foundation-Model-Funktionen von Databricks angebunden werden. Das ergänzt den direkten Zugriff auf externe Anbieter wie Anthropic oder OpenAI und unterscheidet sich von offenen Modellplattformen wie Hugging Face vor allem dadurch, dass die Nutzung stärker in Governance, Workspace-Strukturen und bestehende Databricks-Prozesse eingebettet ist.
Lösungs- und Notebook-Listings bilden die dritte Kategorie. Hier veröffentlichen Anbieter vorkonfigurierte Lösungsbausteine für konkrete Szenarien, zum Beispiel Customer Churn, Fraud Detection oder ESG Reporting. Häufig bestehen diese Listings aus Beispieltabellen, vorbereiteten Notebooks und einfachen Pipeline- oder Analysebausteinen. Ihr Wert liegt vor allem darin, einen schnellen fachlichen und technischen Einstieg in ein Thema zu ermöglichen. Für den produktiven Einsatz sollten diese Inhalte jedoch nicht ungeprüft übernommen werden. Code-Review, Anpassung an eigene Datenmodelle, Security-Vorgaben und Betriebsstandards bleiben zwingend notwendig.
Die Reifegrade unterscheiden sich je nach Listing-Typ deutlich. Daten-Listings sind der etablierteste Bereich und in unterstützten Regionen breit verfügbar. Foundation-Model-Listings entwickeln sich dynamisch weiter; der verfügbare Modellbestand verändert sich regelmäßig. Lösungs-Listings sind weit verbreitet, hängen in Qualität und Aktualität aber stark vom jeweiligen Anbieter ab. Vor einer Nutzung oder Beschaffung lohnt deshalb immer ein Blick auf Aktualität, Dokumentation, Region, Lizenzmodell und den letzten Update-Zeitpunkt des Listings.
Wie landet ein Listing im eigenen Catalog?
Der Beschaffungs-Pfad ist mechanisch trivial, und genau das ist der Punkt. Ein Listing wird im Marketplace ausgewählt, eine Anfrage zur Aktivierung an den Provider geschickt (bei freien Listings sofort, bei kommerziellen mit Vertrags- oder Abrechnungsschritt), und der Provider erstellt einen Delta-Sharing-Recipient für den Empfänger. Ab dem Moment landet das Listing als Shared Catalog im Unity Catalog des Empfängers, lesbar wie jeder andere Catalog.
Zwei Empfänger-Pfade sind möglich. Databricks-zu-Databricks-Sharing ist der natürliche Pfad: zwei Databricks-Workspaces mit Unity Catalog und Authentifizierung über Metastore-Identitäten ohne Token-Übergabe. Open Sharing ist der zweite Pfad: das Listing kann auch von Empfängern bezogen werden, die keinen Databricks-Workspace betreiben, über das offene Delta-Sharing-Protokoll mit Bearer-Token. Damit erlaubt der Marketplace auch Konsumenten-Pfade in Snowflake, Fabric, Pandas, Spark oder anderen Plattformen mit Delta-Sharing-Client. Wie der Transport-Layer darunter mechanisch funktioniert, klären wir im Überblick zu Delta Sharing auf Databricks.
Im Unity Catalog des Empfängers erscheint das Listing als Read-Only-Catalog mit den vom Provider freigegebenen Schemas und Tabellen. Berechtigungen auf der Empfänger-Seite werden wie für jeden anderen UC-Catalog vergeben, Lineage auf Empfänger-Seite läuft mit, Audit-Logs sind sichtbar. Sobald jemand im Empfänger-Workspace eine Query gegen die bezogene Tabelle schickt, fließen Bytes vom Provider-Storage und Compute läuft auf der Empfänger-Seite. Diese Trennung ist die Mechanik, die Lizenz- und Kostenfragen verständlich macht: Listing-Lizenz beim Provider, Compute beim Konsumenten. Wie die Governance darüber hängt, klären wir im Überblick zu Unity Catalog auf Databricks.
Lizenz, SLA, Aktualität und Anbieterqualität
Ein Listing im Databricks Marketplace sieht auf den ersten Blick aus wie ein Produkt in einem App Store: Titel, Beschreibung, Screenshots, Bewertungen und ein klarer Call-to-Action. Für Unternehmen ist die Entscheidung aber keine einfache Tool-Auswahl. Es geht um Daten, Modelle oder Lösungsbausteine, die in eigene Prozesse, Analysen und KI-Anwendungen eingebunden werden. Deshalb sollte jedes Listing strukturiert bewertet werden, unabhängig davon, ob es kostenlos oder kommerziell angeboten wird.
Lizenz und Nutzungsrechte stehen an erster Stelle. Entscheidend ist nicht nur, ob ein Listing verfügbar ist, sondern wofür es genutzt werden darf. Darf der Datensatz nur intern analysiert werden? Darf er in Kundenprodukte einfließen? Darf er für Modelltraining, Scoring oder GenAI-Anwendungen verwendet werden? Gilt die Lizenz für den gesamten Konzern oder nur für eine bestimmte Einheit? Gerade bei personenbezogenen Daten, Finanzdaten oder Foundation Models müssen Nutzungsrechte, Datenschutzvorgaben und mögliche Einschränkungen für Outputs genau geprüft werden. Ein kostenloses Listing ist nicht automatisch frei von Bedingungen.
Update-Frequenz und SLA bestimmen, ob ein Listing für produktive Use Cases geeignet ist. Für explorative Analysen reicht oft ein einmaliger oder unregelmäßig gepflegter Datensatz. Für Forecasting, operative Dashboards oder automatisierte Entscheidungsprozesse braucht es dagegen klare Aussagen zur Aktualisierung, Verfügbarkeit und Datenqualität. Ein Wetterdaten-Listing, das in ein Prognosemodell einfließt, benötigt andere Zusicherungen als ein historischer Referenzdatensatz. Fehlen konkrete Angaben zur Aktualität oder wird nur „best effort“ geliefert, sollte das im Zielbild und Risikoprofil berücksichtigt werden.
Provider-Identität und Anbieterreife sind ebenfalls zentral. Hinter einem Listing kann ein etabliertes Datenhaus, ein spezialisiertes Startup, ein Reseller oder auch ein Unternehmen mit potenziellen Interessenkonflikten stehen. Für die Bewertung zählt deshalb neben dem Listing selbst auch der Anbieter dahinter: Marktposition, Referenzen, Support-Fähigkeit, Vertragsmodell, Datenschutzverständnis und langfristige Verlässlichkeit. Bei kommerziellen Listings sollte der Provider-Check denselben Stellenwert haben wie bei jedem klassischen Daten-, Software- oder Modellanbieter.
Sample-Daten und fachliche Prüfung sind der beste Weg, Versprechen zu verifizieren. Vor einer produktiven Nutzung sollte getestet werden, ob Schema, Detailgrad, Historie, Aktualität, Abdeckung und Datenqualität zum geplanten Use Case passen. Gerade für Fachbereiche zählt, ob die Daten tatsächlich die relevanten Fragen beantworten, über die rein technische Verfügbarkeit hinaus. Listings ohne aussagekräftige Vorschau oder Testmöglichkeit erhöhen das Beschaffungsrisiko, weil eine Entscheidung ohne ausreichende Validierung getroffen wird.
Am Ende reduziert der Marketplace vor allem den technischen Anbindungsaufwand. Die fachliche, rechtliche und kommerzielle Bewertung bleibt bestehen. Unternehmen sollten Listings deshalb wie externe Daten-, Modell- oder Softwareprodukte behandeln: mit klarer Use-Case-Prüfung, Provider-Bewertung, Lizenzprüfung und einem realistischen Blick auf Betriebsfähigkeit.
Databricks Marketplace vs. Snowflake Marketplace, AWS Data Exchange und Microsoft Fabric
Die Wahl eines Daten- oder Modell-Marktplatzes ist vor allem eine Architekturentscheidung, weniger eine reine Produktfrage. Entscheidend ist, wo die Daten genutzt werden sollen, welche Plattform bereits im Unternehmen verankert ist und wie stark Daten, Modelle oder Lösungsbausteine in bestehende Workloads integriert werden müssen.
| Marktplatz | Empfänger-Bindung | Transport | Typische Listing-Typen | Plattformübergreifende Nutzung |
|---|---|---|---|---|
| Databricks Marketplace | Databricks-Workspace empfohlen, offener Zugriff möglich | Delta Sharing | Daten, Foundation Models, Volumes, Lösungs- und Notebook-Listings | ja, über Delta Sharing |
| Snowflake Marketplace | Snowflake-Konto erforderlich | Snowflake Secure Data Sharing | Daten, Services, Native Apps | primär Snowflake-intern |
| AWS Data Exchange | AWS-Konto erforderlich | S3, APIs, Redshift-Sharing | Datenprodukte, APIs, Dateien, Tabellen | primär AWS-intern |
| Microsoft Fabric / Real-Time Hub | Fabric-Workspace erforderlich | OneLake, Eventstreams | Daten in OneLake, Echtzeit-Streams, operative Events | primär Fabric-Ökosystem |
Daraus ergeben sich drei praktische Konsequenzen.
Erstens: Der richtige Marktplatz hängt vom Zielsystem ab. Wenn Daten, Modelle oder Lösungsbausteine überwiegend in Databricks genutzt werden, ist der Databricks Marketplace der naheliegende Einstieg. In einer Snowflake-zentrierten Architektur wird der Snowflake Marketplace häufig besser in bestehende Prozesse passen. Für AWS-native Umgebungen ohne ausgeprägte Lakehouse-Architektur kann AWS Data Exchange der pragmatischere Weg sein. Fabric wiederum ist besonders relevant, wenn Datenprodukte und Echtzeit-Streams direkt in das Microsoft-Ökosystem eingebunden werden sollen.
Zweitens: Databricks hat mit Delta Sharing einen stärkeren Open-Sharing-Ansatz. Der Databricks Marketplace bleibt nicht auf Databricks-Workspaces beschränkt; über Delta Sharing kann er Datenprodukte auch für andere Empfänger zugänglich machen. Das ist besonders relevant, wenn Daten mit Partnern, Kunden oder Fachbereichen geteilt werden sollen, die nicht zwingend auf derselben Plattform arbeiten. Für Unternehmen, die Datenprodukte plattformübergreifend bereitstellen möchten, ist dieser offene Sharing-Ansatz ein wichtiger Unterschied.
Drittens: Die Tiefe der Listings unterscheidet sich deutlich. Databricks kombiniert Daten, Foundation Models, Volumes und Lösungsbausteine stärker mit dem Lakehouse-Kontext. Snowflake erweitert den Marktplatz über Native Apps in Richtung anwendungsnaher Funktionen. AWS Data Exchange ist stärker auf den Bezug externer Datenprodukte, APIs und Dateien ausgerichtet. Fabric verknüpft Daten, OneLake und Echtzeit-Streams enger mit dem Microsoft-Analytics-Ökosystem.
Daraus folgt eine klare Reihenfolge: Am Anfang steht die Frage, wo der konkrete Use Case betrieben wird, erst danach der Marktplatz. Welche Plattform nutzen Data Engineering, Analytics, BI und KI heute? Wo liegen Governance, Berechtigungen und Betriebsprozesse? Und sollen Daten nur intern konsumiert oder auch extern geteilt werden?
Der Marktplatz ist am Ende der Beschaffungskanal. Die eigentliche Entscheidung fällt vorher: in der Zielarchitektur, im Integrationsmodell und im geplanten Nutzen für Fachbereiche, Kunden und Partner.
Foundation Models im Databricks Marketplace vs. APIs und Hugging Face
Bei Foundation Models gibt es drei typische Bezugswege, die unterschiedliche Stärken haben.
Marketplace-Listings sind der Databricks-nahe Pfad. Modelle werden kuratiert bereitgestellt, lassen sich über die Databricks Foundation Model APIs in den eigenen Workspace einbinden und passen besser zu Governance, Lineage und Lakehouse-nahen Workloads. Für produktive Szenarien, in denen Daten, Modelle und Berechtigungen eng zusammenspielen sollen, ist das meist der sauberste Weg.
Direkte Provider-APIs wie OpenAI oder Anthropic sind schnell nutzbar und ideal für Prototypen oder proprietäre Modelle, die nicht im Marketplace verfügbar sind. Der Nachteil: Daten verlassen den eigenen Plattformkontext, was bei produktiven oder regulierten Use Cases gesondert bewertet werden muss.
Hugging Face ist der offene Modell-Hub mit maximaler Auswahl und starkem Entwickler-Ökosystem. Für Recherche, Experimente und Modellvergleiche ist das sehr wertvoll. Für produktive Nutzung müssen Unternehmen den Lade-, Hosting-, Versionierungs- und Governance-Pfad jedoch selbst aufbauen.
Die praktische Einordnung ist daher einfach: Hugging Face eignet sich für Exploration, direkte APIs für schnellen Zugriff auf proprietäre Modelle und Marketplace-Listings für kuratierte, governance-nahe Nutzung im Databricks-Umfeld.
Eigene Daten im Databricks Marketplace anbieten
Der Databricks Marketplace dient nicht allein dem Bezug externer Daten oder Modelle. Unternehmen können dort auch eigene Datenprodukte bereitstellen: intern, für Partner oder kommerziell.
Intern im Konzern kann ein Listing helfen, zentrale Daten wie Stammdaten, Produktdaten oder Bewegungsdaten für mehrere Tochtergesellschaften bereitzustellen. Ein Datenprodukt wird dabei einmal als Listing veröffentlicht (Provider-Onboarding) und gezielt für berechtigte Empfänger freigegeben, ohne dass jede Verbindung einzeln aufgebaut werden muss.
Für Partnernetzwerke eignet sich der Marketplace, wenn Daten regelmäßig und standardisiert geteilt werden sollen. Beispiele sind Logistikpartner, Lieferanten, Finanzdienstleister oder Forschungsverbünde. Das Listing schafft einen klaren Zugangspunkt und reduziert individuelle Abstimmungen.
Als kommerzielles Datenprodukt kann ein Listing ein neuer Vertriebskanal sein. Das ist jedoch deutlich anspruchsvoller: Dann braucht es klare Lizenzen, verlässliche Updates, Datenqualität, Support und ein tragfähiges Preismodell.
Vor dem Start sollten vier Punkte geklärt sein: Wer pflegt das Listing? Welche Nutzung ist erlaubt? Wie oft werden die Daten aktualisiert? Und wie wird die Qualität gesichert?
Der Marketplace vereinfacht die Verteilung von Daten. Er ersetzt aber nicht die Verantwortung für ein sauberes, verlässliches Datenprodukt.
Marketplace vs. Delta Sharing vs. Clean Rooms
Im Sharing-Kontext werden Marketplace, Delta Sharing und Clean Rooms oft vermischt. Dabei erfüllen sie unterschiedliche Aufgaben.
Delta Sharing ist das technische Protokoll. Es regelt, wie Daten von einem Provider freigegeben und von einem Empfänger gelesen werden können.
Der Marketplace ist die Discovery- und Distributionsschicht darüber. Er macht Datenprodukte, Modelle oder Lösungsbausteine auffindbar und verbindet Anbieter mit Empfängern. Für den eigentlichen Zugriff nutzt er Delta Sharing. Wie die einzelnen Bausteine zusammenspielen, erklären wir im Überblick zu Data Sharing auf Databricks.
Clean Rooms lösen ein anderes Problem: Mehrere Parteien können Daten gemeinsam auswerten, ohne ihre Rohdaten vollständig offenzulegen oder auszutauschen. Das ist relevant für Datenpartnerschaften, Audience-Analysen, Forschungskooperationen oder Szenarien mit besonders sensiblen Daten. Wann sich Clean Rooms lohnen, behandeln wir separat.
Die Kurzform: Marketplace bedeutet Auffinden und Verteilen. Delta Sharing ist der technische Transport. Clean Rooms sind für kontrollierte, gemeinsame Analysen gedacht.
Für klassische Datenanbindung startet man meist im Marketplace. Für direkte bilaterale Freigaben reicht oft Delta Sharing. Für gemeinsame Analysen mit sensiblen Daten ist ein Clean Room der passendere Weg.
Grenzen des Databricks Marketplace
Der Databricks Marketplace vereinfacht den Zugang zu Daten, Modellen und Lösungsbausteinen. Er nimmt Unternehmen aber nicht die fachliche, rechtliche und operative Prüfung ab. Vor einer produktiven Nutzung sollten deshalb einige Grenzen klar sein.
Datenqualität bleibt Provider-Verantwortung. Ein Marketplace-Listing ist kein Qualitätssiegel. Vor dem produktiven Einsatz sollten Sample-Daten geprüft werden: Aktualität, Vollständigkeit, Schema, Abdeckung und fachliche Eignung für den geplanten Use Case.
Kosten entstehen nicht allein durch das Listing. Auch kostenlose Listings verursachen Aufwand und Kosten, zum Beispiel durch Abfragen, Compute, Speicherung von Zwischenergebnissen oder Integration in bestehende Pipelines. Bei großen Tabellen oder häufigen Abfragen kann der Konsumenten-Compute schnell relevanter werden als der eigentliche Listing-Preis.
Verfügbarkeit hängt von Cloud, Region und Listing ab. Nicht jedes Listing ist in jeder Cloud und Region verfügbar. Vor der Auswahl sollte deshalb geprüft werden, ob das Datenprodukt im eigenen Setup tatsächlich nutzbar ist.
Kommerzielle Modelle sind nicht immer einheitlich. Preise, Vertragslogik und Abrechnungsmodelle können je nach Provider unterschiedlich sein. Für FinOps, Kostenstellen und Budgetplanung braucht es daher eine eigene Sicht auf Nutzung, Abfragen und Folgekosten.
Rechtliche Sicherheit liegt im Vertrag. Die Listing-Beschreibung ersetzt keine Prüfung durch Legal, Datenschutz oder Compliance. Besonders bei personenbezogenen Daten, Finanzdaten, Modellnutzung oder Weiterverarbeitung müssen Lizenz, Nutzungsrechte und Haftung sauber geklärt werden.
Eigene Listings brauchen Datenprodukt-Reife. Wer selbst Daten im Marketplace anbietet, wird zum Provider. Damit entstehen Pflichten rund um Qualität, Aktualisierung, Lizenz, Support und Kommunikation. Ohne klare Verantwortlichkeiten kann ein Listing dem Vertrauen in die eigenen Daten eher schaden als helfen.
Der Marketplace reduziert den technischen Anbindungsaufwand. Die Verantwortung für Qualität, Kosten, Rechte und Betrieb bleibt jedoch bestehen. Genau diese Punkte sollten früh geklärt werden, bevor ein Listing Teil produktiver Prozesse wird.
Fazit
Der Databricks Marketplace lohnt sich vor allem dann, wenn externe Daten, Modelle oder Lösungsbausteine direkt im Lakehouse-Kontext genutzt werden sollen.
Der Databricks Marketplace lohnt sich vor allem dann, wenn externe Daten, Modelle oder Lösungsbausteine direkt im Lakehouse-Kontext genutzt werden sollen. Besonders relevant wird er, wenn mehrere externe Datenquellen angebunden werden, Foundation Models in Databricks betrieben werden sollen oder eigene Datenprodukte intern, mit Partnern oder kommerziell verteilt werden müssen.
Gute Einstiegspunkte sind Wetter-, Geo- oder Branchendaten für Forecasting und Analytics, Foundation Models für produktive KI-Workloads, Lösungsbausteine für erste Use Cases sowie interne Listings für Stammdaten oder Bewegungsdaten, die von mehreren Einheiten genutzt werden.
Nicht jeder Anwendungsfall gehört in den Marketplace. Wenn eine Quelle eine enge bilaterale Beziehung verlangt, besondere Lizenz- oder Compliance-Anforderungen bestehen oder Empfänger keinen passenden Sharing-Pfad nutzen können, bleiben direkte Verträge, bilaterales Delta Sharing oder andere Integrationswege sinnvoller.
In der Praxis sollte der Marketplace als erster Prüfpunkt für externe Daten, Modelle und standardisierte Datenprodukte gesetzt werden. Die Entscheidung bleibt aber eine Architektur- und Betriebsfrage: Lizenz, Aktualität, Datenqualität, FinOps und Verantwortlichkeiten müssen bereits vor dem ersten produktiven Bezug geklärt sein.
FAQ
Der Databricks Marketplace ist ein offener Katalog von Listings für Daten, Foundation-Modelle und Lösungs-Notebooks, der auf dem Delta-Sharing-Protokoll aufsetzt. Er ist die Discovery- und Distributions-Schicht über Delta Sharing: Provider veröffentlichen Listings mit Metadaten, Lizenz-Text und Update-Frequenz, Konsumenten finden, abonnieren und beziehen die Listings direkt in ihren Unity Catalog.
