Compartilhar via

Substituir com as configurações de destino

Esta página descreve como substituir ou unir configurações de nível superior com as configurações de destino nos Pacotes de Ativos do Databricks. Para obter informações sobre as configurações do pacote, consulte a configuração do Pacote de Ativos do Databricks.

Substituição das configurações de artefato

Você pode substituir as configurações de artefato em um mapeamento de nível superior artifacts com as configurações de artefato em um mapeamento targets, 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 do 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 apenas 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 do artefato:

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

Ao executar databricks bundle validate neste exemplo, o resultado é o seguinte grafo:

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

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

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

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

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

Ao executar databricks bundle validate neste exemplo, o resultado é o seguinte grafo:

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

Substituições de configurações de cluster

Você pode substituir ou modificar as configurações de cluster para tarefas ou pipelines de acordo com um destino.

Para trabalhos, use job_cluster_key dentro de uma definição de trabalho para identificar as configurações do cluster de trabalho no mapeamento de nível resources superior para ingressar com as configurações do cluster de trabalho em um targets mapeamento:

# ...
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 qualquer configuração de cluster for definida no mapeamento de nível resources superior e no targets mapeamento para o mesmo job_cluster_key, a configuração no targets mapeamento terá precedência sobre a configuração no mapeamento de nível resources superior.

Para os Lakeflow Spark Declarative Pipelines, use label dentro das configurações de cluster de uma especificação de pipeline para identificar as configurações de cluster em um mapeamento de nível superior resources para associar 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 qualquer configuração de cluster for definida no mapeamento de nível resources superior e no targets mapeamento para o mesmo label, a configuração no targets mapeamento terá precedência sobre a configuração no mapeamento de nível resources superior.

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 resources superior é combinado com node_type_id e num_workers no resources mapeamento targets para definir as configurações para o job_cluster_key nomeado 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 grafo 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: Configurações conflitantes do novo cluster 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 quanto no mapeamento resources em targets. Neste exemplo, 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, para definir as configurações para o resources nomeado job_cluster_key:

# ...
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 grafo 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 superior de nível resources é combinado com num_workers no mapeamento resources em targets para definir as configurações para o label nomeado 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 grafo 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 resources nível superior quanto no mapeamento resources em targets. num_workers resources no mapeamento de targets terão precedência sobre num_workers no mapeamento de nível resources superior, para definir as configurações para o label nomeado default:

# ...
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 grafo 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 tarefa

Você pode usar o mapeamento tasks dentro de uma definição de tarefa para juntar as configurações de tarefas no mapeamento de nível superior resources com as configurações de tarefas no 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 mapeamentos de task_key tarefa devem ser definidos com o mesmo valor.

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

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

Neste exemplo, spark_version no mapeamento de nível resources superior é combinado com node_type_id e num_workers no resources mapeamento targets para definir as configurações para o task_key nomeado 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 você executa este exemplo databricks bundle validate, o gráfico resultante é o seguinte (reticências indicam conteúdo omitido, para fins de 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 de tarefa 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 quanto 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. Isso define as configurações para o task_key nomeado my-task (reticências indicam conteúdo omitido, para fins de 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 grafo 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