Wie baut man ein echtes Data Product in Databricks?

Haben Sie jetzt ein Data Product?

Vielleicht.

Aber nicht deshalb.

Databricks liefert heute erstaunlich viele Bausteine, die man für ein gutes Data Product benötigt: zentrale Governance über Unity Catalog, automatisches Lineage Tracking, Lakeflow für deklarative Pipelines, Quality Expectations, Metric Views für Business-Semantik, Governed Tags, Attribute-based Access Control, System Tables für Observability und Delta Sharing beziehungsweise Marketplace für die Distribution. (Databricks Docs)

Das ist viel.

Aber die Plattform beantwortet Ihnen trotzdem nicht die wichtigste Frage:

Genau dort würde ich anfangen – und genau dort setzt auch der konzeptionelle Beitrag Ein Data Product ist kein Dataset mit einem Owner an.

Denn wenn Sie ein Data Product in Databricks ausschließlich aus der technischen Perspektive betrachten, erhalten Sie möglicherweise eine hervorragend governte Tabelle.

Aber noch kein Produkt.

Beginnen Sie nicht mit Catalog und Schema

Wenn Teams über Data Products in Databricks sprechen, beginnt die Diskussion häufig ungefähr so:

Das sind wichtige Fragen.

Aber sie kommen zu früh.

Bevor Sie die Unity-Catalog-Struktur festlegen, sollten Sie etwas anderes definieren:

Nehmen wir ein Beispiel.

Ein Unternehmen möchte ein Data Product namens:

bauen.

Eine schlechte Definition wäre:

Das beschreibt die Verarbeitung.

Eine bessere Definition wäre:

Jetzt können wir Architekturentscheidungen treffen.

Denn plötzlich wissen wir:

Wer konsumiert das Produkt?

Marketing und Customer Management.

Was ist sein Zweck?

Kundensegmentierung und Kundensteuerung.

Welche zentralen Business-Begriffe brauchen wir?

Aktiver Kunde.

Umsatz.

Customer Value.

Kaufhistorie.

Welche Freshness ist notwendig?

Vielleicht vier Stunden.

Vielleicht täglich.

Welche Qualitätsfehler wären kritisch?

Fehlende Customer IDs wahrscheinlich sehr kritisch.

Eine fehlende Marketingklassifikation vielleicht weniger.

Und wer darf das Produkt verwenden?

Nicht zwangsläufig jeder, der Zugriff auf die zugrunde liegenden CRM-Daten besitzt.

Diese Fragen definieren Ihr Produkt – dasselbe Product Thinking, das hinter Data Mesh steht.

Databricks hilft Ihnen anschließend, dieses Versprechen technisch durchzusetzen.

Nicht umgekehrt.

Das Data Product ist nicht eine Tabelle

Das ist in Databricks besonders wichtig.

Ein Data Product kann technisch aus mehreren Objekten bestehen:

Die Tabelle ist dabei ein wichtiger Bestandteil.

Aber das eigentliche Data Product ist die gesamte konsumierbare Schnittstelle.

Für einen Data Scientist kann das eine kuratierte Delta Table sein.

Für einen Business User eine Metric View.

Für eine Anwendung eine View oder freigegebene Tabelle.

Für einen externen Partner ein über Delta Sharing bereitgestelltes Dataset.

Für einen AI-Agenten kann eine Metric View mit sauber definierten Feldern, Measures, Synonymen und Agent Metadata die sinnvollere Schnittstelle sein – genau der Punkt, an dem Genie Ontology und Unity Catalog Semantics ansetzen.

Deshalb würde ich eine wichtige Architekturentscheidung treffen:

Modellieren Sie Ihr Data Product logisch – und lassen Sie Databricks-Objekte einzelne Produktfähigkeiten implementieren.

Nicht:

Sondern:

Das klingt nach einem kleinen Unterschied.

In größeren Plattformen ist es ein entscheidender.

Unity Catalog ist das Rückgrat – nicht das Produkt

Unity Catalog ist heute die zentrale Governance-Schicht für Data und AI in Databricks. Zugriffssteuerung, Lineage, Auditing und Discovery werden dort über Workspaces hinweg zusammengeführt. (Databricks Docs)

Für Data Products ist das eine hervorragende Grundlage.

Aber Unity Catalog beschreibt zunächst, welche Assets existieren und wie sie kontrolliert werden.

Er sagt Ihnen nicht automatisch, welche Assets gemeinsam ein fachliches Produkt bilden.

Deshalb würde ich Unity Catalog bewusst als Produkt-Governance-Layer verwenden.

Zum Beispiel:

customer_domain
│
└── customer_value
    │
    ├── customer
    ├── customer_orders
    ├── customer_value_daily
    ├── customer_value_metrics
    └── customer_segments

Ob customer_domain dabei ein Catalog und customer_value ein Schema ist, hängt von Ihrer Governance-Struktur ab.

Databricks beschreibt Catalogs ausdrücklich als oberste Einheit der Organisation in Unity Catalog und empfiehlt, sie nach logischer Datenisolation und Zugriffsgrenzen zu strukturieren. Ein Catalog ist also nicht per Definition eine Domain und auch nicht per Definition ein Data Product. (Databricks Docs)

Das ist wichtig.

Ich würde deshalb keine Regel aufstellen wie:

Oder:

Solche Regeln sehen in Architekturdiagrammen ordentlich aus.

Sie funktionieren aber nur, solange Ihre Sicherheits-, Ownership- und Organisationsgrenzen zufällig exakt mit dieser Struktur übereinstimmen – ein Muster, das auch im Beitrag zur SAP Unity Catalog Admin Hierarchy sichtbar wird.

Eine bessere Frage lautet:

Wenn eine Domain eigene Zugriffsregeln und administrative Verantwortlichkeiten besitzt, kann ein Catalog sinnvoll sein.

Wenn mehrere Produkte dieselben Governance-Grenzen teilen, können Schemas die bessere Produktschicht darstellen.

Die Unity-Catalog-Hierarchie sollte Ihrer Governance folgen.

Nicht Ihrem Wunsch nach einem hübschen Namespace.

Ein mögliches Zielbild

Ich würde ein größeres Data Product ungefähr so zerlegen:

catalog
└── customer
    │
    ├── raw_internal
    │
    ├── curated
    │   ├── customers
    │   ├── orders
    │   └── customer_value
    │
    ├── products
    │   ├── customer_value_current
    │   └── customer_value_metrics
    │
    └── restricted

Dabei ist wichtig:

raw_internal ist kein Data Product.

curated ist ebenfalls nicht automatisch eines.

Erst unter products liegen bewusst gestaltete Konsumentenschnittstellen.

Das verhindert eine häufige Verwechslung:

Medallion Layer sind Verarbeitungsschichten. Data Products sind Konsumentschnittstellen.

Bronze, Silver und Gold können Ihnen helfen, die Daten technisch zu strukturieren.

Aber eine Gold Table wird nicht allein deshalb zum Data Product, weil sie Gold heißt.

Schritt 1: Bauen Sie die physische Wahrheit sauber

Bevor wir über Semantik sprechen können, brauchen wir eine technische Grundlage, der wir vertrauen.

Lakeflow Spark Declarative Pipelines ist dafür heute ein zentraler Databricks-Baustein. Lakeflow kann Batch- und Streaming-Pipelines deklarativ in SQL oder Python abbilden und übernimmt dabei unter anderem Orchestrierung und inkrementelle Verarbeitung. Die von Pipelines verwalteten Tabellen sind Delta Tables. (Databricks Docs)

Für unser Beispiel könnte die Pipeline Daten aus CRM, ERP und Webshop integrieren:

CRM Customer
        \
ERP Customer -----> Customer Resolution
        /                  |
Webshop                    v
                     customer_master
                           |
Orders --------------------+
                           |
                           v
                  customer_value_daily

Das Ziel dieser Ebene ist noch nicht:

Sondern:

Dazu gehören:

Erst wenn diese Grundlage stabil ist, lohnt es sich, darüber ein Produktversprechen zu bauen – und Quellen so zu verbinden, dass Entscheidungen belastbar werden, nicht nur Tabellen voll. Genau das adressiert auch die hybride Business Analytics Plattform beziehungsweise die Frage, wann eine hybride Datenplattform ohne Entscheidungslogik teuer wird.

Schritt 2: Qualität gehört in die Pipeline – aber nicht nur dorthin

Lakeflow unterstützt sogenannte Expectations.

Eine Expectation ist eine deklarative Qualitätsbedingung, die Datensätze validiert. Je nach Konfiguration können Verstöße beobachtet, entsprechende Records verworfen oder Pipeline-Updates abgebrochen werden. (Databricks Docs)

Zum Beispiel:

CONSTRAINT valid_customer
EXPECT (customer_id IS NOT NULL)
ON VIOLATION FAIL UPDATE

Oder:

CONSTRAINT positive_revenue
EXPECT (annual_revenue >= 0)
ON VIOLATION DROP ROW

Seit 2026 hat Databricks diese Funktion weiter ausgebaut. Quality Expectations können inzwischen auch bei standalone Materialized Views eingesetzt werden; Databricks hat außerdem Funktionen eingeführt, um Quality Expectations zentral mit Unity-Catalog-Tabellen zu verwalten. (Databricks Docs)

Das ist für Data Products interessant.

Denn damit wird aus:

eine technische Zusicherung.

Trotzdem würde ich einen Fehler vermeiden:

Eine Data-Quality-Regel ist nicht dasselbe wie eine Product-SLA.

Technisch können 99,99 Prozent aller Customer IDs vorhanden sein.

Wenn die Daten zwei Tage zu spät eintreffen, ist das Produkt für einen bestimmten Use Case trotzdem wertlos.

Deshalb würde ich technische Quality Expectations und fachliche Product Expectations trennen.

Beispielsweise:

Technical Quality
├── customer_id NOT NULL
├── revenue >= 0
└── valid country_code

Product Expectations
├── Freshness < 4h
├── Completeness > 99.5%
├── Customer reconciliation completed
└── Critical incidents acknowledged < 30 min

Databricks kann viel davon messen und operationalisieren.

Aber die akzeptablen Schwellenwerte müssen aus dem Produktkontext kommen.

Schritt 3: Dokumentieren Sie nicht die Tabelle. Dokumentieren Sie die Bedeutung.

Eine Tabelle kann perfekt dokumentiert und trotzdem schwer verständlich sein.

Nehmen wir:

customer_id
customer_status
net_sales
value_segment
effective_date

Technisch klingt das brauchbar.

Aber:

Databricks unterstützt Comments auf Unity-Catalog-Assets und einzelnen Spalten. Comments verbessern die Discovery und können über BROWSE sichtbar gemacht werden, ohne dass der Benutzer automatisch Zugriff auf die Daten selbst erhält. (Databricks Docs)

Databricks bietet außerdem AI-generierte Comments an.

Das ist praktisch.

Aber Databricks warnt selbst davor, AI-generierte Beschreibungen ungeprüft als Wahrheit zu übernehmen. Die Vorschläge werden aus Metadaten wie Schema und Spaltennamen erzeugt und sollen vor dem Speichern menschlich geprüft werden. (Databricks Docs)

Genau hier würde ich bei Data Products streng sein – dieselbe Grenze wie bei Evidence-first AI: Das Modell darf vorschlagen. Es darf nicht festlegen, was im Unternehmen verbindlich ist.

Ein AI-generierter Text kann:

schreiben.

Ihr Data Product muss wissen:

Das ist der Unterschied zwischen Dokumentation und Semantik – und der Grund, warum Bedeutung in den Kontextlayer gehört, nicht in den Prompt.

Schritt 4: Ziehen Sie Business-Semantik aus einzelnen Tabellen heraus

Und hier wird Databricks 2026 besonders interessant.

Metric Views sind inzwischen eine zentrale Umsetzungsschicht für Business-Semantik in Unity Catalog.

Sie ermöglichen, Business Measures zentral zu definieren und getrennt von den Dimensionen zu verwalten, über die diese Measures gruppiert oder gefiltert werden. (Databricks Docs)

Das ist für Data Products ein erheblicher Fortschritt.

Denn statt:

Table A:
annual_revenue

Dashboard B:
SUM(invoice_amount - returns)

Dashboard C:
SUM(net_amount)

Genie:
interpretiert revenue selbst

kann das Produkt eine zentrale Business-Definition bereitstellen.

Beispielsweise:

Customer Value Metric View

Dimensions
├── Customer
├── Country
├── Segment
├── Month
└── Product Group

Measures
├── Net Revenue
├── Customer Count
├── Revenue per Customer
└── 12M Customer Value

Metric Views unterstützen inzwischen nicht nur Measures und Dimensionen, sondern auch Joins, Filter, komplexere Measures und Metadaten für AI-Agenten. Databricks nennt unter anderem Synonyme, Display Names und Formatierungsregeln, die die Interpretation durch Agents verbessern sollen. (Databricks Docs)

Damit entsteht etwas sehr Interessantes:

Die fachliche Schnittstelle eines Data Products muss nicht mehr identisch mit seiner physischen Tabelle sein.

Das ist genau das, was ich möchte – und was wir bei Genie Ontology und Unity Catalog Semantics als Plattform-Umsetzung des Kontextlayers einordnen.

Die Delta Tables repräsentieren die physische Datenbasis.

Die Metric View repräsentiert einen Teil der fachlichen Bedeutung.

Der Consumer bekommt nicht einfach:

Sondern:

Für Analytics und AI ist das erheblich wertvoller.

Schritt 5: Verwenden Sie Tags nicht als Dekoration

Tags in Unity Catalog können Assets organisieren und die Discovery unterstützen.

Mit Governed Tags können Organisationen darüber hinaus kontrollierte, accountweite Tag-Vokabulare definieren. Databricks unterstützt inzwischen außerdem System Tags; bestimmte System Tags können beispielsweise Assets als zertifiziert oder deprecated kennzeichnen. (Databricks Docs)

Damit können Sie eine echte Product-Governance aufbauen.

Zum Beispiel:

domain = customer
product = customer_value
lifecycle = production
criticality = tier_1
classification = internal

Und zusätzlich:

Certified

für die offizielle Konsumentschnittstelle.

Oder später:

Deprecated

wenn ein Produkt ersetzt wird.

Das klingt banal.

Ist es aber nicht.

Denn in vielen Plattformen existieren gleichzeitig:

customer_value
customer_value_v2
customer_value_new
customer_value_final
customer_value_final2
customer_value_2025
customer_value_use_this

Das eigentliche Problem ist dann nicht Data Discovery.

Das Problem ist:

Niemand weiß, welches Asset autoritativ ist.

Ein Data Product sollte diese Frage explizit beantworten.

Nicht durch Konvention.

Durch Metadata und Governance.

Schritt 6: Ownership technisch und organisatorisch trennen

Unity Catalog besitzt ein klares Ownership-Modell.

Jedes securable object hat einen Owner. Der Owner besitzt weitreichende Rechte auf dieses Objekt und kann Privilegien verwalten beziehungsweise Ownership übertragen. Databricks empfiehlt für produktive Assets ausdrücklich, Ownership eher Gruppen als einzelnen Personen zuzuweisen. (Databricks Docs)

Das ist sinnvoll.

Aber:

Unity-Catalog-Ownership ist nicht automatisch Product Ownership.

Eine Gruppe wie

grp_customer_data_admin

kann technisch Owner eines Schemas sein.

Der fachliche Data Product Owner könnte trotzdem eine konkrete Rolle im Customer-Bereich sein.

Diese beiden Verantwortlichkeiten sollten bewusst verbunden werden.

Zum Beispiel:

Business Product Owner
Roman / Customer Analytics
        |
        | Product decisions
        v
Customer Value Data Product
        ^
        | Technical administration
        |
Unity Catalog Owner
grp_customer_data_product_admin

Warum trennen?

Weil der Business Product Owner vielleicht entscheiden muss:

Der Unity Catalog Owner dagegen:

Beides ist Ownership.

Aber nicht dieselbe Art.

Wenn Sie das nicht trennen, landen fachliche Entscheidungen häufig bei Plattformadmins.

Und technische Berechtigungsentscheidungen bei Fachbereichen.

Beides ist keine besonders gute Idee.

In der Entscheidungsarchitektur ist das derselbe Unterschied: Ownership ohne Entscheidungsrecht bleibt Eskalation. Genau das adressiert der Ownership Blueprint – und organisatorisch die Frage, warum genehmigte Entscheidungen nicht umgesetzt werden.

Schritt 7: Bauen Sie Zugriff als Produktfähigkeit

Ein Data Product ist nicht self-service-fähig, wenn jeder Zugriff über ein Ticket läuft.

Unity Catalog bietet ein hierarchisches Privilegienmodell auf Catalog-, Schema- und Objektebene. Databricks empfiehlt, dieses Hierarchiemodell bewusst zu nutzen und Berechtigungen über Gruppen zu organisieren. (Databricks Docs)

Für Data Products würde ich Zugriffsmodelle deshalb möglichst vorhersehbar gestalten.

Zum Beispiel:

customer_value_consumers
        |
        +-- SELECT customer_value_metrics
        +-- SELECT customer_value_current

customer_value_engineers
        |
        +-- MODIFY curated tables
        +-- manage pipelines

customer_value_admins
        |
        +-- MANAGE product schema

Noch interessanter wird es mit Attribute-based Access Control.

Unity Catalog ABAC verwendet Governed Tags als Attribute, auf deren Grundlage Policies dynamisch angewendet werden können. Databricks unterstützt damit unter anderem Row Filters und Column Masks; entsprechende Regeln können auf einer höheren Ebene definiert und automatisch auf passende Assets angewendet werden. (Databricks Docs)

Das ist für Data Products wesentlich skalierbarer als:

Genau dazu: Skalierende Sicherheit mit ABAC, Tags und automatischen Policies.

Ein Produkt sollte Sicherheitsregeln nicht jedes Mal neu erfinden.

Es sollte sich innerhalb einer Governance-Struktur bewegen, in der Regeln aus seinen Eigenschaften ableitbar sind.

Schritt 8: Lineage ist Teil des Product Contracts

Wenn ein Data Product von anderen Produkten oder Anwendungen konsumiert wird, müssen Änderungen kontrolliert erfolgen.

Dafür ist Lineage entscheidend.

Unity Catalog erfasst Lineage für Databricks-Queries automatisch und kann sie bis auf Spaltenebene darstellen. Die Lineage umfasst dabei nicht nur Tabellen, sondern beispielsweise auch Jobs, Notebooks und Dashboards; mit External Lineage können inzwischen auch Assets außerhalb Databricks in den Graph aufgenommen werden. (Databricks Docs)

Damit wird eine wichtige Frage beantwortbar:

Stellen Sie sich vor, Sie möchten:

customer_segment

ersetzen durch:

customer_value_segment.

Bevor Sie die Änderung durchführen, sollte der Data Product Owner wissen:

Das ist kein nettes Architekturfeature.

Das ist Change Management.

Und genau deshalb gehört Lineage für mich zum Data Product.

Nicht als hübsche Visualisierung.

Sondern als Voraussetzung für kontrollierte Evolution.

Schritt 9: Machen Sie Nutzung messbar

Product Thinking endet nicht mit:

Die relevante Frage lautet:

Databricks System Tables geben inzwischen Zugriff auf eine Vielzahl operativer Informationen im system Catalog, darunter Audit Events, Lineage, Billing, Compute- und weitere Nutzungsdaten. (Databricks Docs)

Mit:

system.access.table_lineage

können Sie beispielsweise programmatisch untersuchen, welche Assets gelesen und geschrieben werden und welche Databricks-Entities beteiligt waren. Die Lineage-Systemtabellen halten dabei ein rollierendes Zeitfenster für entsprechende Events vor. (Databricks Docs)

Zusätzlich existiert mit:

system.query.history

eine Query-History-Systemtabelle für SQL Warehouses und unterstützte serverless Workloads. (Databricks Docs)

Damit kann ein Product Team Fragen stellen wie:

Das ist eine völlig andere Betriebslogik als:

Ein Produkt, das niemand konsumiert, ist kein Erfolg.

Auch wenn sein Pipeline Graph grün ist.

Schritt 10: Messen Sie auch die Kosten des Produkts

Data Products besitzen nicht nur Value.

Sie verursachen Kosten.

Das wird besonders relevant, wenn Domains eigene Produkte betreiben sollen.

Databricks stellt Billing-Informationen über system.billing.usage bereit. Usage Records lassen sich unter anderem Ressourcen, Identitäten und Produkten zuordnen; Tags können ebenfalls zur Kostenanalyse beitragen. (Databricks Docs)

Damit können wir erstmals eine unangenehme, aber sinnvolle Frage stellen:

Nicht nur Entwicklung.

Sondern:

Das macht Product Thinking vollständiger.

Denn ein Data Product sollte nicht ausschließlich messen:

Sondern:

Schritt 11: Versionieren Sie das Produkt wie Software

Ein häufiges Anti-Pattern sieht so aus:

Für produktive Data Products ist das zu wenig.

Databricks hat seine früheren Asset Bundles inzwischen in Declarative Automation Bundles umbenannt. Sie dienen dazu, Databricks-Projekte einschließlich Jobs und Pipelines als deklarative Projektdefinitionen zu verwalten und Software-Engineering-Praktiken wie Source Control, Testing und CI/CD zu unterstützen. (Databricks Docs)

Für ein Data Product würde ich deshalb möglichst viel versionierbar machen:

customer-value/
│
├── databricks.yml
├── resources/
│   ├── pipeline.yml
│   └── jobs.yml
│
├── src/
│   ├── ingestion/
│   ├── transformation/
│   └── quality/
│
├── semantics/
│   └── customer_value_metric_view.yml
│
├── tests/
│
└── README.md

Nicht jedes Element muss exakt in dieser Struktur liegen.

Die Idee ist wichtiger:

Das Produkt besitzt einen reproduzierbaren Build- und Deployment-Prozess.

Wenn Sie customer_value morgen in einer neuen Umgebung bereitstellen müssen, sollte die Antwort nicht lauten:

Schritt 12: Definieren Sie den Consumer Contract

Jetzt kommen wir zum eigentlichen Produktversprechen.

Angenommen, das Data Product veröffentlicht:

customer_id
customer_segment
net_revenue_12m
orders_12m
last_order_date

Dann sollte der Consumer nicht nur das Schema kennen.

Er sollte wissen:

Manche Teile können direkt in Databricks operationalisiert werden:

Andere Teile benötigen weiterhin organisatorische Vereinbarungen.

Genau deshalb würde ich einen Data Contract nicht mit einem einzelnen Databricks-Feature gleichsetzen.

Der Contract ist die Vereinbarung.

Databricks implementiert Teile davon.

Schritt 13: Veröffentlichen Sie das Produkt über die richtige Schnittstelle

Nicht jeder Consumer sollte direkt Ihre internen Delta Tables sehen.

Ich würde deshalb bewusst zwischen internen Implementierungsobjekten und veröffentlichten Product Interfaces unterscheiden.

Zum Beispiel:

Für interne Analytics kann eine Metric View die richtige Schnittstelle sein.

Für technische Downstream-Systeme eine Table oder View.

Für externe oder organisationsübergreifende Nutzung Delta Sharing – siehe auch Delta Sharing und Daten teilen statt kopieren.

Databricks Marketplace verwendet OpenSharing für den kontrollierten Zugriff auf Data Products. In Unity-Catalog-fähigen Workspaces können Marketplace-Angebote neben tabellarischen Daten unter anderem auch Volumes, AI Models, Notebooks und Apps umfassen. (Databricks Docs)

Das unterstreicht einen wichtigen Punkt:

Ein Data Product ist in Databricks nicht zwangsläufig nur tabellarische Daten.

Das Produkt ist das konsumierbare Angebot.

Die technische Form hängt vom Consumer ab.

Schritt 14: Planen Sie Deprecation von Anfang an

Data Products werden häufig veröffentlicht.

Aber selten beendet.

Dabei gehört genau das zum Lifecycle.

Angenommen, Sie ersetzen:

customer_value_v1

durch:

customer_value_v2.

Dann brauchen Sie einen kontrollierten Übergang.

Zum Beispiel:

v1
│
├── mark as Deprecated
├── identify consumers via lineage
├── publish replacement
├── communicate deadline
├── monitor remaining usage
└── remove after migration

v2
│
└── mark as Certified

Die aktuellen Discovery-Funktionen in Unity Catalog unterstützen systemseitige Trust Signals wie Certified und Deprecated, die in Discovery und Search sichtbar werden können. (Databricks Docs)

Das ist sehr nützlich.

Denn plötzlich ist Lifecycle kein Wiki-Eintrag mehr.

Er wird Teil der Plattform.

Noch wichtiger:

Mit Lineage und Usage-Daten können Sie überprüfen, ob wirklich niemand mehr die alte Version verwendet.

Erst dann löschen Sie.

Nicht:

So würde ich ein Data Product in Databricks zusammensetzen

Wenn wir alles zusammenführen, entsteht ungefähr dieses Modell:

Keine dieser Boxen alleine ist das Data Product.

Das Zusammenspiel ist das Produkt.

Meine minimale Definition für ein echtes Databricks Data Product

Ich würde ein Asset erst dann ernsthaft als Data Product bezeichnen, wenn ich mindestens diese Fragen beantworten kann.

Wenn Sie diese Fragen nicht beantworten können, haben Sie wahrscheinlich ein gutes Dataset.

Vielleicht sogar ein hervorragend governedes Dataset.

Aber noch kein vollständiges Data Product.

Was Databricks Ihnen abnimmt

Databricks ist inzwischen erstaunlich gut darin, viele technische Eigenschaften eines Data Products zentral abzubilden.

Unity Catalog kann Governance und Discovery bereitstellen. (Databricks Docs)

Lakeflow kann Verarbeitung und Quality Enforcement operationalisieren. (Databricks Docs)

Metric Views können Business-Metriken und Semantik zentralisieren. (Databricks Docs)

Governed Tags und ABAC können Metadaten und Policies skalierbar machen. (Databricks Docs)

Lineage kann Abhängigkeiten sichtbar machen. (Databricks Docs)

System Tables können Betrieb, Nutzung und Kosten beobachtbar machen. (Databricks Docs)

Delta Sharing und Marketplace können Produkte kontrolliert distribuieren. (Databricks Docs)

Declarative Automation Bundles können ihre technische Implementierung reproduzierbar machen. (Databricks Docs)

Das ist eine ziemlich vollständige technische Werkzeugkiste.

Was Databricks Ihnen nicht abnimmt

Die Plattform kann Ihnen trotzdem nicht sagen:

Das bleiben Organisationsentscheidungen.

Und genau hier scheitern viele Data-Product-Initiativen.

Nicht weil ihnen Features fehlen.

Sondern weil sie hoffen, dass die Plattform Product Thinking ersetzt.

Das tut sie nicht.

Vielleicht ist das die eigentliche Architektur

Wenn ich heute ein Data Product in Databricks bauen müsste, würde ich deshalb nicht mit dieser Frage beginnen:

Ich würde mit dieser beginnen:

Danach kann die Plattform ihre Stärke ausspielen.

Lakeflow macht das Produkt reproduzierbar.

Delta macht seine physische Datenbasis zuverlässig.

Unity Catalog macht es governbar.

Quality Expectations machen Regeln ausführbar.

Metric Views machen Business-Bedeutung expliziter.

Lineage macht Abhängigkeiten sichtbar.

System Tables machen Nutzung und Kosten messbar.

Delta Sharing macht Distribution kontrollierbar.

Aber erst der Konsument macht daraus ein Produkt.

Denn eine Delta Table beantwortet:

Unity Catalog beantwortet:

Eine Metric View beantwortet:

Und ein echtes Data Product beantwortet letztlich eine andere Frage: