Partilhar via

Substituir com configurações de destino

Esta página descreve como substituir ou unir configurações de nível superior com configurações de destino em Databricks Asset Bundles. Para obter informações sobre configurações de pacote, consulte Configuração do Databricks Asset Bundle.

Substituição de configurações de artefato

Você pode substituir as configurações de artefato em um mapeamento de nível artifacts superior pelas configurações de artefato em um targets mapeamento, por exemplo:

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

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

Se qualquer configuração de artefato for definida no mapeamento de nível artifacts superior e no targets mapeamento para o mesmo artefato, a configuração no targets mapeamento terá precedência sobre a configuração no mapeamento de nível artifacts superior.

Exemplo 1: Configurações de artefato definidas somente no mapeamento de artefatos de nível superior

Para demonstrar como isso funciona na prática, no exemplo a seguir, path é definido no mapeamento de nível artifacts superior, que define todas as configurações para o artefato:

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

Ao executar databricks bundle validate para este exemplo, o gráfico resultante é:

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

Exemplo 2: Configurações de artefato conflitantes definidas em vários mapeamentos de artefatos

Neste exemplo, path é definido tanto no mapeamento de nível superior artifacts como no mapeamento artifacts em targets. Neste exemplo, path no mapeamento em artifacts tem precedência sobre o targets de nível superior em path para definir as configurações do artefato artifacts.

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

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

Ao executar databricks bundle validate para este exemplo, o gráfico resultante é:

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

Sobreposições de configurações de cluster

Você pode substituir ou combinar as configurações de cluster de trabalho ou pipeline para um alvo.

Para tarefas, use job_cluster_key dentro de uma definição de tarefa para identificar configurações de cluster de tarefa no mapeamento de nível superior resources para unir com configurações de cluster de tarefa em um mapeamento targets.

# ...
resources:
  jobs:
    <some-unique-programmatic-identifier-for-this-job>:
      # ...
      job_clusters:
        - job_cluster_key: <some-unique-programmatic-identifier-for-this-key>
          new_cluster:
            # Cluster settings.

targets:
  <some-unique-programmatic-identifier-for-this-target>:
    resources:
      jobs:
        <the-matching-programmatic-identifier-for-this-job>:
          # ...
          job_clusters:
            - job_cluster_key: <the-matching-programmatic-identifier-for-this-key>
              # Any more cluster settings to join with the settings from the
              # resources mapping for the matching top-level job_cluster_key.
          # ...

Se alguma configuração de cluster for definida tanto no mapeamento de nível superior resources quanto no mapeamento targets para o mesmo job_cluster_key, então a configuração no mapeamento targets terá precedência sobre a configuração no mapeamento de nível superior resources.

Para os pipelines declarativos do Lakeflow Spark, use label dentro das definições de configurações de cluster de um pipeline para identificar configurações de cluster em um mapeamento de nível superior resources a fim de unir com as configurações de cluster em um mapeamento targets, por exemplo:

# ...
resources:
  pipelines:
    <some-unique-programmatic-identifier-for-this-pipeline>:
      # ...
      clusters:
        - label: default | maintenance
          # Cluster settings.

targets:
  <some-unique-programmatic-identifier-for-this-target>:
    resources:
      pipelines:
        <the-matching-programmatic-identifier-for-this-pipeline>:
          # ...
          clusters:
            - label: default | maintenance
              # Any more cluster settings to join with the settings from the
              # resources mapping for the matching top-level label.
          # ...

Se alguma configuração de cluster for definida tanto no mapeamento de nível superior resources quanto no mapeamento targets para o mesmo label, então a configuração no mapeamento targets terá precedência sobre a configuração no mapeamento de nível superior resources.

Exemplo 1: Novas configurações de cluster de trabalho definidas em vários mapeamentos de recursos e sem conflitos de configurações

Neste exemplo, spark_version no mapeamento de nível superior resources é combinado com node_type_id e num_workers no mapeamento resources em targets para definir as configurações para o job_cluster_key chamado my-cluster:

# ...
resources:
  jobs:
    my-job:
      name: my-job
      job_clusters:
        - job_cluster_key: my-cluster
          new_cluster:
            spark_version: 13.3.x-scala2.12

targets:
  development:
    resources:
      jobs:
        my-job:
          name: my-job
          job_clusters:
            - job_cluster_key: my-cluster
              new_cluster:
                node_type_id: Standard_DS3_v2
                num_workers: 1
          # ...

Quando você executa databricks bundle validate para este exemplo, o gráfico resultante é o seguinte:

{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "job_clusters": [
          {
            "job_cluster_key": "my-cluster",
            "new_cluster": {
              "node_type_id": "Standard_DS3_v2",
              "num_workers": 1,
              "spark_version": "13.3.x-scala2.12"
            }
          }
        ],
        "...": "..."
      }
    }
  }
}

Exemplo 2: Novas configurações de cluster de trabalho conflitantes definidas em vários mapeamentos de recursos

Neste exemplo, spark_version e num_workers são definidos tanto no mapeamento de nível superior resources como no mapeamento resources em targets. Neste exemplo, spark_version e num_workers no mapeamento resources em targets têm precedência sobre spark_version e num_workers no mapeamento de nível superior resources, para definir as configurações para o job_cluster_key chamado my-cluster:

# ...
resources:
  jobs:
    my-job:
      name: my-job
      job_clusters:
        - job_cluster_key: my-cluster
          new_cluster:
            spark_version: 13.3.x-scala2.12
            node_type_id: Standard_DS3_v2
            num_workers: 1

targets:
  development:
    resources:
      jobs:
        my-job:
          name: my-job
          job_clusters:
            - job_cluster_key: my-cluster
              new_cluster:
                spark_version: 12.2.x-scala2.12
                num_workers: 2
          # ...

Quando você executa databricks bundle validate para este exemplo, o gráfico resultante é o seguinte:

{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "job_clusters": [
          {
            "job_cluster_key": "my-cluster",
            "new_cluster": {
              "node_type_id": "Standard_DS3_v2",
              "num_workers": 2,
              "spark_version": "12.2.x-scala2.12"
            }
          }
        ],
        "...": "..."
      }
    }
  }
}

Exemplo 3: Configurações de cluster de pipeline definidas em vários mapeamentos de recursos e sem conflitos de configurações

Neste exemplo, node_type_id no mapeamento de nível superior resources é combinado com num_workers no resources mapeamento em targets para definir as configurações para o label denominado default:

# ...
resources:
  pipelines:
    my-pipeline:
      clusters:
        - label: default
          node_type_id: Standard_DS3_v2

targets:
  development:
    resources:
      pipelines:
        my-pipeline:
          clusters:
            - label: default
              num_workers: 1
          # ...

Quando você executa databricks bundle validate para este exemplo, o gráfico resultante é o seguinte:

{
  "...": "...",
  "resources": {
    "pipelines": {
      "my-pipeline": {
        "clusters": [
          {
            "label": "default",
            "node_type_id": "Standard_DS3_v2",
            "num_workers": 1
          }
        ],
        "...": "..."
      }
    }
  }
}

Exemplo 4: Configurações conflitantes de cluster de pipeline definidas em vários mapeamentos de recursos

Neste exemplo, num_workers é definido tanto no mapeamento de nível superior resources como no mapeamento resources em targets. num_workers no mapeamento em resources tem precedência sobre targets no mapeamento de nível superior num_workers, para definir as configurações para o resources chamado label:

# ...
resources:
  pipelines:
    my-pipeline:
      clusters:
        - label: default
          node_type_id: Standard_DS3_v2
          num_workers: 1

targets:
  development:
    resources:
      pipelines:
        my-pipeline:
          clusters:
            - label: default
              num_workers: 2
          # ...

Quando você executa databricks bundle validate para este exemplo, o gráfico resultante é o seguinte:

{
  "...": "...",
  "resources": {
    "pipelines": {
      "my-pipeline": {
        "clusters": [
          {
            "label": "default",
            "node_type_id": "Standard_DS3_v2",
            "num_workers": 2
          }
        ],
        "...": "..."
      }
    }
  }
}

Sobreposição de configurações de tarefas

Você pode usar o tasks mapeamento dentro de uma definição do trabalho para integrar as configurações de tarefas em um mapeamento de nível superior resources com as configurações de tarefa em um mapeamento targets, por exemplo:

# ...
resources:
  jobs:
    <some-unique-programmatic-identifier-for-this-job>:
      # ...
      tasks:
        - task_key: <some-unique-programmatic-identifier-for-this-task>
          # Task settings.

targets:
  <some-unique-programmatic-identifier-for-this-target>:
    resources:
      jobs:
        <the-matching-programmatic-identifier-for-this-job>:
          # ...
          tasks:
            - task_key: <the-matching-programmatic-identifier-for-this-key>
              # Any more task settings to join with the settings from the
              # resources mapping for the matching top-level task_key.
          # ...

Para unir o mapeamento de nível superior resources e o mapeamento targets para a mesma tarefa, os mapas de tarefa task_key devem ser definidos com o mesmo valor.

Se qualquer configuração de tarefa for definida no resources mapeamento de nível superior e no targets mapeamento para o mesmo task, a configuração no targets mapeamento terá precedência sobre a configuração no resources mapeamento de nível superior.

Exemplo 1: Configurações de tarefas de trabalho definidas em vários mapeamentos de recursos e sem conflitos de configurações

Neste exemplo, spark_version no mapeamento de nível superior resources é combinado com node_type_id e num_workers no mapeamento resources em targets para definir as configurações para o task_key chamado my-task:

# ...
resources:
  jobs:
    my-job:
      name: my-job
      tasks:
        - task_key: my-key
          new_cluster:
            spark_version: 13.3.x-scala2.12

targets:
  development:
    resources:
      jobs:
        my-job:
          name: my-job
          tasks:
            - task_key: my-task
              new_cluster:
                node_type_id: Standard_DS3_v2
                num_workers: 1
          # ...

Quando executa o databricks bundle validate para este exemplo, o gráfico resultante é o seguinte (reticências indicam conteúdo omitido para brevidade):

{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "tasks": [
          {
            "new_cluster": {
              "node_type_id": "Standard_DS3_v2",
              "num_workers": 1,
              "spark_version": "13.3.x-scala2.12"
            },
            "task-key": "my-task"
          }
        ],
        "...": "..."
      }
    }
  }
}

Exemplo 2: Configurações conflitantes de tarefas de trabalho definidas em vários mapeamentos de recursos

Neste exemplo, spark_version e num_workers são definidos tanto no mapeamento de nível superior resources como no mapeamento resources em targets. spark_version e num_workers no mapeamento em resources têm precedência sobre targets e spark_version no mapeamento de nível superior num_workers. Isto define as definições para o task_key nomeado my-task (reticências indicam conteúdo omitido, para brevidade):

# ...
resources:
  jobs:
    my-job:
      name: my-job
      tasks:
        - task_key: my-task
          new_cluster:
            spark_version: 13.3.x-scala2.12
            node_type_id: Standard_DS3_v2
            num_workers: 1

targets:
  development:
    resources:
      jobs:
        my-job:
          name: my-job
          tasks:
            - task_key: my-task
              new_cluster:
                spark_version: 12.2.x-scala2.12
                num_workers: 2
          # ...

Quando você executa databricks bundle validate para este exemplo, o gráfico resultante é o seguinte:

{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "tasks": [
          {
            "new_cluster": {
              "node_type_id": "Standard_DS3_v2",
              "num_workers": 2,
              "spark_version": "12.2.x-scala2.12"
            },
            "task_key": "my-task"
          }
        ],
        "...": "..."
      }
    }
  }
}
  • Last updated on