Freigeben über


Dynamisches Definieren von Artefakteinstellungen in Databricks-Ressourcenpaketen

In diesem Artikel wird beschrieben, wie Sie die Einstellungen für Artefakte in Databricks-Ressourcenpaketen außer Kraft setzen. Weitere Informationen finden Sie unter Was sind Databricks-Ressourcenpakete?

In Azure Databricks-Paketkonfigurationsdateien können Sie die Artefakteinstellungen in einer artifacts-Zuordnung auf oberster Ebene mit den Artefakteinstellungen in einer targets-Zuordnung zu verknüpfen, z. B. (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

# ...
artifacts:
  <some-unique-programmatic-identifier-for-this-artifact>:
    # Artifact settings.

targets:
  <some-unique-programmatic-identifier-for-this-target>:
    resources:
      artifacts:
        <the-matching-programmatic-identifier-for-this-artifact>:
          # Any more artifact settings to join with the settings from the
          # matching top-level artifacts mapping.

Wenn eine Artefakteinstellung sowohl in der artifacts-Zuordnung auf oberster Ebene als auch in der targets-Zuordnung für dasselbe Artefakt definiert ist, hat die Einstellung in der targets-Zuordnung Vorrang vor der Einstellung in der artifacts-Zuordnung auf oberster Ebene.

Beispiel 1: Artefakteinstellungen, die nur in der Artefaktzuordnung auf oberster Ebene definiert sind

Um zu veranschaulichen, wie dies in der Praxis funktioniert, wird im folgenden Beispiel path in der artifacts-Zuordnung auf oberster Ebene definiert. Dadurch werden alle Einstellungen für das Artefakt definiert (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

# ...
artifacts:
  my-artifact:
    type: whl
    path: ./my_package
# ...

Wenn Sie für dieses Beispiel databricks bundle validate ausführen, sieht das resultierende Diagramm wie folgt aus (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

{
  "...": "...",
  "artifacts": {
    "my-artifact": {
      "type": "whl",
      "path": "./my_package",
      "...": "..."
    }
  },
  "...": "..."
}

Beispiel 2: In Konflikt stehende Artefakteinstellungen, die in mehreren Artefaktzuordnungen definiert sind

In diesem Beispiel wird path sowohl in der artifacts-Zuordnung auf oberster Ebene als auch in der artifacts-Zuordnung in targets definiert. In diesem Beispiel hat path in der artifacts-Zuordnung in targets Vorrang vor path in der artifacts-Zuordnung auf oberster Ebene, um die Einstellungen für das Artefakt zu definieren (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

# ...
artifacts:
  my-artifact:
    type: whl
    path: ./my_package

targets:
  dev:
    artifacts:
      my-artifact:
        path: ./my_other_package
    # ...

Wenn Sie für dieses Beispiel databricks bundle validate ausführen, sieht das resultierende Diagramm wie folgt aus (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

{
  "...": "...",
  "artifacts": {
    "my-artifact": {
      "type": "whl",
      "path": "./my_other_package",
      "...": "..."
    }
  },
  "...": "..."
}