Pular para o conteúdo principal

Substituir com configurações de destino

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

Substituição de configurações de artefato​

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

YAML
# ...
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 superior artifacts e no mapeamento targets para o mesmo artefato, a configuração no mapeamento targets terá precedência sobre a configuração no mapeamento de nível superior artifacts .

Exemplo 1: Configurações de artefatos 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 superior artifacts , que define todas as configurações do artefato:

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

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

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

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

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

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

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

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

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

Substituições de configurações de cluster​

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

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

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

Para o pipeline declarativo LakeFlow , use label nas configurações cluster de uma definição pipeline para identificar as configurações cluster em um mapeamento resources de nível superior para join com as configurações cluster em um mapeamento targets , por exemplo:

YAML
# ...
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 superior resources e no mapeamento targets para o mesmo label, 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 cluster de tarefas definidas em vários mapeamentos de recurso 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 denominado my-cluster:

YAML
# ...
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: i3.xlarge
                num_workers: 1
          # ...

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

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

Exemplo 2: Novas configurações cluster de tarefas conflitantes definidas em vários mapeamentos de recurso​

Neste exemplo, spark_version e num_workers são definidos no mapeamento de nível superior resources e 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 denominado my-cluster:

YAML
# ...
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: i3.xlarge
            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:

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

Exemplo 3: configurações cluster de pipeline definidas em vários mapeamentos de recurso e sem conflitos de configuração​

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

YAML
# ...
resources:
  pipelines:
    my-pipeline:
      clusters:
        - label: default
          node_type_id: i3.xlarge

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:

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

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

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

YAML
# ...
resources:
  pipelines:
    my-pipeline:
      clusters:
        - label: default
          node_type_id: i3.xlarge
          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:

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

Substituição de configurações de tarefasJob​

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

YAML
# ...
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 join o mapeamento de nível superior resources e o mapeamento targets para a mesma tarefa, o task_key dos mapeamentos de tarefas deve ser definido 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 Job definidas em vários mapeamentos de recurso e sem conflitos de configuração​

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 denominado my-task:

YAML
# ...
resources:
  jobs:
    my-job:
      name: my-job
      tasks:
        - task_key: my-task
          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: i3.xlarge
                num_workers: 1
          # ...

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

JSON
{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "tasks": [
          {
            "new_cluster": {
              "node_type_id": "i3.xlarge",
              "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 recurso​

Neste exemplo, spark_version e num_workers são definidos no mapeamento de nível superior resources e no mapeamento resources em targets. 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 . Isso define as configurações para o task_key chamado my-task (reticências indicam conteúdo omitido, por brevidade):

YAML
# ...
resources:
  jobs:
    my-job:
      name: my-job
      tasks:
        - task_key: my-task
          new_cluster:
            spark_version: 13.3.x-scala2.12
            node_type_id: i3.xlarge
            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:

JSON
{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "tasks": [
          {
            "new_cluster": {
              "node_type_id": "i3.xlarge",
              "num_workers": 2,
              "spark_version": "12.2.x-scala2.12"
            },
            "task_key": "my-task"
          }
        ],
        "...": "..."
      }
    }
  }
}
Última atualização em