Konfigurieren von Pipelineeinstellungen für Delta Live Tables

  • Artikel

Dieser Artikel enthält Details zum Konfigurieren von Pipelineeinstellungen für Delta Live Tables. Delta Live Tables bietet eine Benutzeroberfläche zum Konfigurieren und Bearbeiten von Pipelineeinstellungen. Die Benutzeroberfläche bietet auch eine Option zum Anzeigen und Bearbeiten von Einstellungen in JSON.

Hinweis

Sie können die meisten Einstellungen entweder mit der Benutzeroberfläche oder mit einer JSON-Spezifikation konfigurieren. Einige erweiterte Optionen sind nur mit der JSON-Konfiguration verfügbar.

Databricks empfiehlt, sich mit den Delta Live Tables-Einstellungen über die Benutzeroberfläche vertraut zu machen. Bei Bedarf können Sie die JSON-Konfiguration direkt im Arbeitsbereich bearbeiten. JSON-Konfigurationsdateien sind auch bei der Bereitstellung von Pipelines in neuen Umgebungen oder bei Verwendung der CLI oder der REST-API nützlich.

Einen vollständigen Verweis auf die JSON-Konfigurationseinstellungen von Delta Live Tables finden Sie unter Delta Live Tables-Pipelinekonfigurationen.

Hinweis

Da Computeressourcen für serverlose Pipelines vollständig verwaltet werden, stehen Computeeinstellungen wie die erweiterte automatische Skalierung, Clusterrichtlinien, Instanztypen und Clustertags nicht zur Verfügung, wenn Sie die Option Serverless (Serverlos) (Public Preview) für eine Pipeline auswählen.

Sie können Konfigurationsparameter weiterhin an eine serverlose Pipeline übergeben, aber alle Parameter, die in einem clusters -Objekt in der JSON-Konfiguration festgelegt sind, werden ignoriert.

Wenn Sie mehr über die Aktivierung von serverlosen DLT-Pipelines erfahren möchten, wenden Sie sich an Ihr Azure Databricks-Kontoteam.

Auswählen einer Produktedition

Wählen Sie die Delta Live Tables-Produktedition mit den Features, die für Ihre Pipelineanforderungen am besten geeignet sind. Die folgenden Produkt editionen sind verfügbar:

  • Core zum Ausführen von Workloads zur Streamerfassung Wählen Sie die Core-Edition aus, wenn Ihre Pipeline keine erweiterten Features benötigt, z. B. die Änderungsdatenaufnahme (CDC) oder die Erwartungen von Delta Live Tables.
  • Pro zum Ausführen von Streaming-Ingest- und CDC-Workloads. Die Pro Produkt edition unterstützt alle Core Features sowie unterstützung für Workloads, die Tabellen basierend auf Änderungen in Quelldaten aktualisieren müssen.
  • Advanced zum Ausführen von Streaming-Aufnahmelasten, CDC-Workloads und Workloads, die Erwartungen erfordern. Die Advanced Produktedition unterstützt die Features der Core Editionen und Pro unterstützt auch die Durchsetzung von Datenqualitätseinschränkungen mit Delta Live Tables-Erwartungen.

Sie können die Produktedition auswählen, wenn Sie eine Pipeline erstellen oder bearbeiten. Sie können eine andere Edition für jede Pipeline auswählen. Weitere Informationen finden Sie auf der Delta Live Tables-Produktseite.

Hinweis

Wenn Ihre Pipeline Features enthält, die von der ausgewählten Produktedition nicht unterstützt werden, z. B. Erwartungen, erhalten Sie eine Fehlermeldung mit dem Grund für den Fehler. Anschließend können Sie die Pipeline bearbeiten, um die entsprechende Edition auszuwählen.

Auswählen eines Pipelinemodus

Sie können Ihre Pipeline kontinuierlich oder mit manuellen Triggern basierend auf dem Pipelinemodus aktualisieren. Weitere Informationen finden Sie unter Fortlaufende und ausgelöste Pipelineausführung.

Wählen einer Clusterrichtlinie

Benutzer müssen über Berechtigungen zum Bereitstellen von Compute verfügen, um Delta Live Tables-Pipelines zu konfigurieren und zu aktualisieren. Arbeitsbereichsadministratoren können Clusterrichtlinien konfigurieren, um Benutzern Zugriff auf Computeressourcen für Delta Live Tables zu ermöglichen. Weitere Informationen finden Sie unter Definieren von Grenzwerten für Delta Live Tables-Pipelinecompute.

Hinweis

  • Clusterrichtlinien sind optional. Wenden Sie sich an Ihren Arbeitsbereichsadministrator, wenn Sie nicht über die für Delta Live Tables erforderlichen Compute-Berechtigungen verfügen.

  • Um sicherzustellen, dass die Standardwerte für Clusterrichtlinien korrekt angewendet werden, legen Sie den apply_policy_default_values-Wert in den Clusterkonfigurationen Ihrer Pipelinekonfiguration auf true fest:

    {
  "clusters": [
    {
      "label": "default",
      "policy_id": "<policy-id>",
      "apply_policy_default_values": true
    }
  ]
}

Konfigurieren von Quellcodebibliotheken

Sie können die Dateiauswahl auf der Delta Live Tables-Benutzeroberfläche verwenden, um den Quellcode zu konfigurieren, der Ihre Pipeline definiert. Pipelinequellcode wird in Databricks-Notebooks oder in SQL- oder Python-Skripts definiert, die in Arbeitsbereichsdateien gespeichert sind. Wenn Sie Ihre Pipeline erstellen oder bearbeiten, können Sie ein oder mehrere Notebooks oder Arbeitsbereichsdateien oder eine Kombination aus Notebooks und Arbeitsbereichsdateien hinzufügen.

Da Delta Live Tables Datasetabhängigkeiten automatisch analysiert, um den Verarbeitungsgraphen für Ihre Pipeline zu erstellen, können Sie Quellcodebibliotheken in beliebiger Reihenfolge hinzufügen.

Sie können die JSON-Datei auch so ändern, dass sie Delta Live Tables-Quellcode enthält, der in SQL- und Python-Skripts definiert ist, die in Arbeitsbereichsdateien gespeichert sind. Das folgende Beispiel enthält Notebooks und Arbeitsbereichsdateien:

{
  "name": "Example pipeline 3",
  "storage": "dbfs:/pipeline-examples/storage-location/example3",
  "libraries": [
    { "notebook": { "path": "/example-notebook_1" } },
    { "notebook": { "path": "/example-notebook_2" } },
    { "file": { "path": "/Workspace/Users/<user-name>@databricks.com/Apply_Changes_Into/apply_changes_into.sql" } },
    { "file": { "path": "/Workspace/Users/<user-name>@databricks.com/Apply_Changes_Into/apply_changes_into.py" } }
  ]
}

Angeben eines Speicherorts

Sie können einen Speicherort für eine Pipeline angeben, die im Hive-Metastore veröffentlicht wird. Die primäre Motivation für die Angabe eines Speicherorts besteht darin, den Speicherort des Objekts für von Ihrer Pipeline geschriebene Daten zu steuern.

Da alle Tabellen, Daten, Prüfpunkte und Metadaten für Delta Live Tables-Pipelines vollständig von Delta Live Tables verwaltet werden, erfolgt die meiste Interaktion mit Delta Live Tables-Datasets über Tabellen, die im Hive-Metastore oder Unity Catalog registriert sind.

Angeben eines Zielschemas für Pipelineausgabetabellen

Obwohl dies optional ist, sollten Sie ein Ziel angeben, um die von Ihrer Pipeline erstellten Tabellen zu veröffentlichen, sobald Sie über die Entwicklung und den Test einer neuen Pipeline hinausgehen. Durch die Veröffentlichung einer Pipeline in einem Ziel stehen Datasets für Abfragen an anderer Stelle in Ihrer Azure Databricks-Umgebung zur Verfügung. Weitere Informationen finden Sie unter Veröffentlichen von Daten aus Delta Live Tables-Pipelines im Hive-Metastore oder Verwenden des Unity-Katalogs mit Ihren Delta Live Tables-Pipelines.

Konfigurieren Ihrer Computeeinstellungen

Hinweis

Da Computeressourcen für serverlose Pipelines vollständig verwaltet werden, stehen Computeeinstellungen nicht zur Verfügung, wenn Sie die Option Serverless (Serverlos) (Public Preview) für eine Pipeline auswählen.

Jede Delta Live Tables-Pipeline verfügt über zwei zugeordnete Cluster:

  • Der updates-Cluster verarbeitet Pipelineupdates.
  • Der maintenance-Cluster führt tägliche Wartungsaufgaben aus.

Die von diesen Clustern verwendete Konfiguration wird durch das clusters-Attribut bestimmt, das in Ihren Pipelineeinstellungen angegeben ist.

Mithilfe von Clusterbezeichnungen können Sie Computeeinstellungen hinzufügen, die nur für einen bestimmten Clustertyp gelten. Es gibt drei Bezeichnungen, die Sie beim Konfigurieren von Pipelineclustern verwenden können:

Hinweis

Die Clusterbezeichnungseinstellung kann weggelassen werden, wenn Sie nur eine Clusterkonfiguration definieren. Die default-Bezeichnung wird auf Clusterkonfigurationen angewendet, wenn keine Einstellung für die Bezeichnung angegeben ist. Die Clusterbezeichnungseinstellung ist nur erforderlich, wenn Sie Einstellungen für verschiedene Clustertypen anpassen müssen.

  • Die default-Bezeichnung definiert Computeeinstellungen, die sowohl auf den updates- als auch auf den maintenance- Cluster angewendet werden sollen. Die Anwendung derselben Einstellungen auf beide Cluster erhöht die Zuverlässigkeit von Wartungsläufen, da sichergestellt wird, dass die erforderlichen Konfigurationen, z. B. die Anmeldeinformationen für den Datenzugriff auf einen Speicherort, auf den Wartungscluster angewendet werden.
  • Die maintenance-Bezeichnung definiert Computeeinstellungen, die nur auf den maintenance- Cluster angewendet werden sollen. Sie können die maintenance-Bezeichnung auch verwenden, um die von der default-Bezeichnung konfigurierten Einstellungen außer Kraft zu setzen.
  • Die updates-Bezeichnung definiert Einstellungen, die nur auf den updates- Cluster angewendet werden sollen. Verwenden Sie die updates-Bezeichnung, um Einstellungen zu konfigurieren, die nicht auf den maintenance-Cluster angewendet werden sollen.

Die mithilfe der Bezeichnungen default und updates definierten Einstellungen werden zusammengeführt, um die endgültige Konfiguration für den updates-Cluster zu erstellen. Wenn dieselbe Einstellung sowohl mit default- als auch mit updates-Bezeichnungen definiert wird, setzt die mit der updates-Bezeichnung definierte Einstellung die mit der default-Bezeichnung definierte Einstellung außer Kraft.

Im folgenden Beispiel wird ein Spark-Konfigurationsparameter definiert, der nur der Konfiguration für den updates-Cluster hinzugefügt wird:

{
  "clusters": [
    {
      "label": "default",
      "autoscale": {
        "min_workers": 1,
        "max_workers": 5,
        "mode": "ENHANCED"
      }
    },
    {
      "label": "updates",
      "spark_conf": {
         "key": "value"
      }
    }
  ]
}

Delta Live Tables bietet ähnliche Optionen für Clustereinstellungen wie andere Computevorgänge in Azure Databricks. Wie bei anderen Pipelineeinstellungen können Sie die JSON-Konfiguration für Cluster ändern, um Optionen anzugeben, die auf der Benutzeroberfläche nicht vorhanden sind. Siehe Compute.

Hinweis

  • Da die Delta Live Tables-Runtime den Lebenszyklus von Pipelineclustern verwaltet und eine benutzerdefinierte Version von Databricks Runtime ausführt, können Sie einige Clustereinstellungen in einer Pipelinekonfiguration nicht manuell festlegen, z. B. die Spark-Version oder Clusternamen. Weitere Informationen finden Sie unter Clusterattribute, die nicht vom Benutzer festgelegt werden können.
  • Sie können Delta Live Tables-Pipelines so konfigurieren, dass sie Photon nutzen. Weitere Informationen finden Sie unter Was ist Photon?.

Auswählen von Instanztypen zum Ausführen einer Pipeline

Standardmäßig wählt Delta Live Tables die Instanztypen für den Treiber und Workerknoten aus, auf denen die Pipeline ausgeführt wird. Sie können jedoch auch die Instanztypen manuell konfigurieren. Sie können beispielsweise Instanztypen auswählen, um die Pipelineleistung zu verbessern oder Speicherprobleme beim Ausführen der Pipeline zu beheben. Sie können Instanztypen konfigurieren, wenn Sie eine Pipeline mit der REST-API oder auf der Delta Live Tables-Benutzeroberfläche erstellen oder bearbeiten.

So konfigurieren Sie Instanztypen beim Erstellen oder Bearbeiten einer Pipeline auf der Benutzeroberfläche von Delta Live Tables:

  1. Klicken Sie auf die Schaltfläche Settings .
  2. Wählen Sie im Abschnitt Erweitert der Pipelineeinstellungen in den Dropdownmenüs Arbeitstyp und Treibertyp die Instanztypen für die Pipeline aus.

Um Instanztypen in den JSON-Einstellungen der Pipeline zu konfigurieren, klicken Sie auf die JSON-Schaltfläche, und geben Sie die Instanztypkonfigurationen in die Clusterkonfiguration ein:

Hinweis

Um zu vermeiden, dass dem maintenance-Cluster unnötige Ressourcen zugewiesen werden, wird in diesem Beispiel die updates-Bezeichnung verwendet, um die Instanztypen nur für den updates-Cluster festzulegen. Um die Instanztypen sowohl updates- als auch maintenance-Clustern zuzuweisen, verwenden Sie die default-Bezeichnung, oder lassen Sie die Einstellung für die Bezeichnung aus. Die default-Bezeichnung wird auf Pipelineclusterkonfigurationen angewendet, wenn keine Einstellung für die Bezeichnung angegeben ist. Weitere Informationen finden Sie unter Konfigurieren Ihrer Computeeinstellungen.

{
  "clusters": [
    {
      "label": "updates",
      "node_type_id": "Standard_D12_v2",
      "driver_node_type_id": "Standard_D3_v2",
      "..." : "..."
    }
  ]
}

Verwenden der automatischen Skalierung für höhere Effizienz und geringeren Ressourcenverbrauch

Verwenden Sie die erweiterte automatische Skalierung, um die Clusternutzung Ihrer Pipelines zu optimieren. Die erweiterte automatische Skalierung fügt nur dann zusätzliche Ressourcen hinzu, wenn das System ermittelt, dass diese Ressourcen die Verarbeitungsgeschwindigkeit der Pipeline erhöhen. Ressourcen werden freigegeben, wenn sie nicht mehr benötigt werden, und Cluster werden heruntergefahren, sobald alle Pipelineaktualisierungen abgeschlossen sind.

Weitere Informationen zur erweiterten Automatischen Skalierung, einschließlich Konfigurationsdetails, finden Sie unter Optimieren der Clusternutzung von Delta Live Tables-Pipelines mit erweiterter automatischer Skalierung.

Verzögern des Herunterfahrens von Computedaten

Da ein Delta Live Tables-Cluster automatisch heruntergefahren wird, wenn er nicht verwendet wird, führt das Verweisen auf eine Clusterrichtlinie, die autotermination_minutes in Ihrer Clusterkonfiguration festgelegt wird, zu einem Fehler. Um das Verhalten beim Herunterfahren von Clustern zu steuern, können Sie den Entwicklungs- oder Produktionsmodus oder die Einstellung pipelines.clusterShutdown.delay in der Pipelinekonfiguration verwenden. Im folgenden Beispiel wird der Wert pipelines.clusterShutdown.delay auf 60 Sekunden festlegt:

{
    "configuration": {
      "pipelines.clusterShutdown.delay": "60s"
    }
}

Wenn der Modus production aktiviert ist, lautet der Standardwert für pipelines.clusterShutdown.delay0 seconds. Wenn der Modus development aktiviert ist, lautet der Standardwert 2 hours.

Erstellen eines Einzelknotenclusters

Wenn Sie num_workers in Clustereinstellungen auf 0 festlegen, wird der Cluster als Einzelknotencluster erstellt. Die Konfiguration eines Clusters mit automatischer Skalierung und einer Einstellung min_workers auf 0 und max_workers auf 0 erstellt auch einen Einzelknotencluster.

Wenn Sie einen Cluster mit automatischer Skalierung konfigurieren und nur min_workers auf 0 festlegen, wird der Cluster nicht als Einzelknotencluster erstellt. Der Cluster verfügt jederzeit über mindestens einen aktiven Worker bis zum Beenden.

Eine Beispielclusterkonfiguration zum Erstellen eines Einzelknotenclusters in Delta Live Tables:

{
    "clusters": [
      {
        "num_workers": 0
      }
    ]
}

Konfigurieren von Clustertags

Sie können Clustertags verwenden, um die Nutzung Ihrer Pipelinecluster zu überwachen. Fügen Sie Clustertags auf der Benutzeroberfläche von Delta Live Tables hinzu, wenn Sie eine Pipeline erstellen oder bearbeiten, oder indem Sie die JSON-Einstellungen für Ihre Pipelinecluster bearbeiten.

Cloudspeicherkonfiguration

Für den Zugriff auf Azure Storage müssen Sie die erforderlichen Parameter, einschließlich Zugriffstoken, mithilfe von spark.conf-Einstellungen in Ihren Clusterkonfigurationen konfigurieren. Ein Beispiel für das Konfigurieren des Zugriffs auf ein Azure Data Lake Storage Gen2 -Speicherkonto (ADLS Gen2) finden Sie unter Sicheres Zugreifen auf Storage-Anmeldeinformationen mit Geheimnissen in einer Pipeline.

Parametrisieren von Pipelines

Der Python- und SQL-Code, der Ihre Datasets definiert, kann von den Pipelineeinstellungen parametrisiert werden. Die Parametrisierung ermöglicht die folgenden Anwendungsfälle:

  • Trennen von langen Pfaden und anderen Variablen von Ihrem Code
  • Reduzieren der Datenmenge, die in Entwicklungs- oder Stagingumgebungen verarbeitet wird, um Tests zu beschleunigen.
  • Wiederverwenden derselben Transformationslogik für die Verarbeitung aus mehreren Datenquellen

Im folgenden Beispiel wird der Konfigurationswert startDate verwendet, um die Entwicklungspipeline auf eine Teilmenge der Eingabedaten zu beschränken:

CREATE OR REFRESH LIVE TABLE customer_events
AS SELECT * FROM sourceTable WHERE date > '${mypipeline.startDate}';

@dlt.table
def customer_events():
  start_date = spark.conf.get("mypipeline.startDate")
  return read("sourceTable").where(col("date") > start_date)

{
  "name": "Data Ingest - DEV",
  "configuration": {
    "mypipeline.startDate": "2021-01-02"
  }
}

{
  "name": "Data Ingest - PROD",
  "configuration": {
    "mypipeline.startDate": "2010-01-02"
  }
}

Triggerintervall für Pipelines

Mit pipelines.trigger.interval können Sie das Triggerintervall für einen Flow steuern, der eine Tabelle oder eine gesamte Pipeline aktualisiert. Da eine ausgelöste Pipeline jede Tabelle nur einmal verarbeitet, wird pipelines.trigger.interval nur mit kontinuierlichen Pipelines verwendet.

Aufgrund von unterschiedlichen Standardwerten für Streaming- und Batchabfragen empfiehlt es sich, pipelines.trigger.interval für einzelne Tabellen festzulegen. Legen Sie den Wert nur dann für eine Pipeline fest, wenn Ihre Verarbeitung die Steuerung von Updates für den gesamten Pipelinegraphen erfordert.

Für eine Tabelle kann pipelines.trigger.interval mithilfe von spark_conf (Python) bzw. mithilfe von SET (SQL) festgelegt werden:

@dlt.table(
  spark_conf={"pipelines.trigger.interval" : "10 seconds"}
)
def <function-name>():
    return (<query>)

SET pipelines.trigger.interval=10 seconds;

CREATE OR REFRESH LIVE TABLE TABLE_NAME
AS SELECT ...

Wenn Sie pipelines.trigger.interval für eine Pipeline festlegen möchten, fügen Sie es dem Objekt configuration in den Pipelineeinstellungen hinzu:

{
  "configuration": {
    "pipelines.trigger.interval": "10 seconds"
  }
}

Erlauben Sie Benutzer*innen, die keine Administrator*innen sind, die Treiberprotokolle von einer Unity Catalog-fähigen Pipeline einzusehen.

Standardmäßig haben nur Pipeline-Eigentümer*innen und die Arbeitsbereichsadministrator*innen die Berechtigung, die Treiberprotokolle des Clusters einzusehen, in dem eine Unity Catalog-fähige Pipeline läuft. Sie können den Zugriff auf die Treiberprotokolle für alle Benutzer mit den Berechtigungen KANN VERWALTEN, KANN ANZEIGEN oder KANN AUSFÜHREN aktivieren, indem Sie den folgenden Spark-Konfigurationsparameter zum configuration-Objekt in den Pipeline-Einstellungen hinzufügen:

{
  "configuration": {
    "spark.databricks.acl.needAdminPermissionToViewLogs": "false"
  }
}

Hinzufügen von E-Mail-Benachrichtigungen für Pipelineereignisse

Sie können eine oder mehrere E-Mail-Adressen für den Empfang von Benachrichtigungen konfigurieren, wenn Folgendes auftritt:

  • Ein Pipelineupdate wird erfolgreich abgeschlossen.
  • Ein Pipelineupdate schlägt fehl, entweder mit einem wiederholbaren oder einem nicht wiederholbaren Fehler. Wählen Sie diese Option aus, um eine Benachrichtigung für alle Pipelinefehler zu erhalten.
  • Ein Pipelineupdate schlägt mit einem nicht wiederholbaren (schwerwiegenden) Fehler fehl. Wählen Sie diese Option aus, um nur dann eine Benachrichtigung zu erhalten, wenn ein nicht wiederholbarer Fehler auftritt.
  • Ein einzelner Datenfluss schlägt fehl.

So konfigurieren Sie E-Mail-Benachrichtigungen beim Erstellen oder Bearbeiten einer Pipeline:

  1. Klicken Sie auf Benachrichtigung hinzufügen.
  2. Geben Sie mindestens eine E-Mail-Adresse ein, um Benachrichtigungen zu empfangen.
  3. Aktivieren Sie das Kontrollkästchen für jeden Benachrichtigungstyp, der an die konfigurierten E-Mail-Adressen gesendet werden soll.
  4. Klicken Sie auf Benachrichtigung hinzufügen.

Steuern der Tombstone-Verwaltung für SCD-Typ 1-Abfragen

Die folgenden Einstellungen können verwendet werden, um das Verhalten der Tombstone-Verwaltung für DELETE-Ereignisse während der SCD-Typ 1-Verarbeitung zu steuern:

  • pipelines.applyChanges.tombstoneGCThresholdInSeconds: Legen Sie diesen Wert so fest, dass er dem höchsten erwarteten Intervall (in Sekunden) zwischen Daten in nicht ordnungsgemäßer Reihenfolge entspricht. Der Standardwert ist 172.800 Sekunden (2 Tage).
  • pipelines.applyChanges.tombstoneGCFrequencyInSeconds: Diese Einstellung steuert, wie häufig (in Sekunden) Tombstones auf Bereinigung überprüft werden. Der Standardwert beträgt 1.800 Sekunden (30 Minuten).

Weitere Informationen finden Sie unter Vereinfachte Change Data Capture mit der APPLY CHANGES API in Delta Live Tables.

Konfigurieren von Pipelineberechtigungen

Sie müssen über die CAN MANAGE oder IS OWNER-Berechtigung für die Pipeline verfügen, um Berechtigungen dafür zu verwalten.

  1. Klicken Sie in der Randleiste auf Delta Live Tables.

  2. Wählen Sie den Namen einer Pipeline aus.

  3. Wählen Sie das Kebab-Menü Vertikale Auslassungspunkte und dann Berechtigungen aus.

  4. Wählen Sie unter Berechtigungseinstellungen das Dropdownmenü Benutzer, Gruppe oder Dienstprinzipal auswählen und dann eine*n Benutzer*in, eine Gruppe oder einen Dienstprinzipal aus.

    Dialogfeld „Berechtigungseinstellungen“

  5. Wählen Sie im Dropdownmenü „Berechtigung“ eine Berechtigung aus.

  6. Klicken Sie auf Hinzufügen.

  7. Klicken Sie auf Speichern.

Aktivieren des RocksDB-Zustandsspeichers für Delta Live Tables

Sie können die RocksDB-basierte Zustandsverwaltung aktivieren, indem Sie die folgende Konfiguration festlegen, bevor Sie eine Pipeline bereitstellen:

{
  "configuration": {
     "spark.sql.streaming.stateStore.providerClass": "com.databricks.sql.streaming.state.RocksDBStateStoreProvider"
  }
}

Weitere Informationen zum RocksDB-Zustandsspeicher, einschließlich Konfigurationsempfehlungen für RocksDB, finden Sie unter Konfigurieren des RocksDB-Zustandsspeichers in Azure Databricks.