Predictive Optimization ist eine Funktion der Datenplattform Databricks, die wiederkehrende Aufräum- und Wartungsarbeiten auf Datentabellen automatisch übernimmt. Statt dass jemand diese Jobs von Hand plant und startet, entscheidet Databricks selbst, wann eine Tabelle wartungsbedürftig ist, und führt die Arbeit im Hintergrund aus. Die Kurzform ist PO (Predictive Optimization). Betroffen sind vor allem drei Aufgaben: viele kleine Dateien zu größeren zusammenfassen (OPTIMIZE), nicht mehr benötigte Alt-Dateien löschen (VACUUM) und die Datensortierung auf der Festplatte auffrischen (Re-Clustering).
Was ist Predictive Optimization?
Predictive Optimization übernimmt die Aufräumarbeiten, die auf einer Datenplattform ständig anfallen. Sie greift auf Tabellen im offenen Speicherformat Delta Lake, das Databricks für seine Tabellen nutzt. Bisher musste diese Arbeit von Hand geplant werden über regelmäßige Jobs: jede Nacht Compaction (kleine Dateien zusammenfassen), einmal pro Woche Alt-Daten wegräumen. Mit aktivierter PO planen und starten diese Jobs nicht mehr Menschen, sondern die Plattform selbst. Sie schaut auf jede Tabelle einzeln: Wie viele Dateien liegen dort? Wie oft wird geschrieben? Wie oft gelesen? Lohnt sich der Aufwand einer Wartung gerade? Tabellen, die ruhig sind und keinen Wartungsbedarf haben, lässt PO in Ruhe.
Wirkungsbereich ist ausschließlich der Unity Catalog mit verwalteten Delta-Tabellen. External Tables, Foreign Catalogs und Objekte im Hive Metastore werden nicht durch PO bedient. Die Funktion ist ein Account-Level-Feature, das ein Account-Admin einmal aktiviert; danach lässt sich PO hierarchisch auf Catalog-, Schema- oder Tabellen-Ebene über die Werte ENABLE, DISABLE und INHERIT konfigurieren. Der Default unterhalb des Catalogs ist INHERIT, sodass eine Aktivierung auf Catalog-Ebene auf alle erbenden Schemas und Tabellen wirkt.
Die Wartungsläufe laufen auf Databricks-managed Serverless-Compute, das separat von der Workspace-Compute abgerechnet wird. Das Operation-History-System-Table dokumentiert pro Lauf die ausgeführte Operation, die betroffene Tabelle und den entstandenen Compute-Verbrauch, sodass Wartungskosten in den FinOps-Reports getrennt ausgewiesen werden. Im General-Availability-Umfang deckt Predictive Optimization heute OPTIMIZE-Compaction, VACUUM und das Re-Clustering von Liquid-Clustering-Tabellen ab; die automatische Aktualisierung von Tabellen-Statistiken (ANALYZE) rollt regional aus.
Abgrenzung zu Auto Optimize, eigenen Wartungs-Jobs und Liquid Clustering
Predictive Optimization wird häufig mit verwandten Funktionen vermischt, die ebenfalls Tabellen-Performance adressieren.
| Begriff | Wann aktiv | Verhältnis zu PO |
|---|---|---|
| delta.autoOptimize / Auto Compaction | synchron beim Schreiben | beeinflusst die Schreib-Laufzeit; PO läuft asynchron auf separatem Compute |
| Manuelle OPTIMIZE-/VACUUM-Jobs (Workflows, Airflow) | nach festem Zeitplan | PO bewertet pro Tabelle und Lauf; technisch parallel möglich, sollte nicht dauerhaft doppelt laufen |
| Liquid Clustering | Schreib- und Re-Cluster-Zeit | Schema-Entscheidung (CLUSTER BY) trifft das Engineering; PO übernimmt das Re-Clustering |
| Z-Ordering | manueller OPTIMIZE ZORDER BY-Lauf | nicht Teil von PO; Liquid Clustering ist der vorgesehene Pfad für neue Tabellen |
Predictive Optimization entscheidet, wann eine Wartungs-Operation auf einer Tabelle läuft. Das Tabellen-Layout (Liquid Clustering, Partitionierung), das Schema und die Datenmodellierung bleiben Aufgabe des Engineerings. Eine aktivierte PO automatisiert die operative Ausführung der dazu passenden Wartung; die Schema-Entscheidung bleibt davon unberührt.
Beispiel: Predictive Optimization im Bronze-Layer mit Streaming-Schreibrate
Ein Bronze-Layer im Unity Catalog nimmt fortlaufend Streaming-Daten aus mehreren Quellen auf. Pro Stunde entstehen tausende kleiner Dateien, das nächtliche OPTIMIZE-Workflow läuft seit Jahren auf einem festen Schedule und kollidiert regelmäßig mit dem Streaming-Job. Nach ALTER CATALOG bronze ENABLE PREDICTIVE OPTIMIZATION beginnt Databricks, die Tabellen des Catalogs asynchron zu bewerten und Compaction-Läufe auf separatem Serverless-Compute auszuführen, sobald die Datei-Fragmentierung einer Tabelle den erwarteten Lese-Nutzen rechtfertigt. Das Operation-History-System-Table zeigt für jede Tabelle, wann eine Operation lief und wie viel Compute sie verbraucht hat.
Eine kleine append-only-Stammdatentabelle im selben Catalog bleibt unverändert. Ihr Schreibprofil erzeugt keine Fragmentierung, die einen Wartungslauf rechtfertigt, und PO löst dort keine Operation aus. Die manuelle Workflow-OPTIMIZE-Definition für diese Tabelle ist damit kostenseitig redundant und wird beim Audit der bestehenden Wartungs-Jobs zuerst abgeschaltet.
Predictive Optimization (Databricks) im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.