Aglomerados de configuração

Este artigo explica as opções de configuração disponíveis quando cria e edita clusters Azure Databricks. Centra-se na criação e edição de clusters utilizando a UI. Relativamente a outros métodos, veja CLI de Clusters e API de Clusters.

Criar cluster

Política de clusters

Uma política de cluster limita a capacidade de configurar clusters com base num conjunto de regras. As regras de política limitam os atributos ou valores de atributos disponíveis para a criação de clusters. As políticas de cluster têm ACLs que limitam a sua utilização a utilizadores e grupos específicos e, assim, limitam quais as políticas que pode selecionar quando cria um cluster.

Para configurar uma política de cluster, selecione a política de cluster na política de abandono.

Selecione a política de cluster

Nota

Se não tiverem sido criadas políticas no espaço de trabalho,a política de abandono não se apresenta.

Se tiver:

  • Cluster criar permissão,pode selecionar a política sem restrições e criar clusters totalmente configuráveis. A política sem restrições não limita quaisquer atributos de cluster ou valores de atributos.
  • Tanto o cluster cria permissão como acesso às políticas de cluster, pode selecionar a política sem restrições e as políticas a que tem acesso.
  • Apenas acede às políticas de cluster, pode selecionar as políticas a que tem acesso.

Modo de clusters

A Azure Databricks suporta três modos de cluster: Standard, High Concurrency e Single Node. O modo de cluster predefinido é Standard.

Nota

A configuração do cluster inclui uma definição de terminação automática cujo valor predefinido depende do modo cluster:

  • Os agrupamentos standard e single nó são configurados para terminar automaticamente após 120 minutos.
  • Os agrupamentos de alta concurrency são configurados para não terminarem automaticamente.

Importante

Não é possível alterar o modo de cluster após a criação de um cluster. Se quiser um modo de cluster diferente, tem de criar um novo cluster.

Aglomerados padrão

Os agrupamentos standard são recomendados para um único utilizador. Os clusters standard podem executar cargas de trabalho desenvolvidas em qualquer idioma: Python, R, Scala e SQL.

Aglomerados de Alta Concurrency

Um cluster de Alta Concurrency é um recurso de nuvem gerido. Os principais benefícios dos clusters de Alta Concurrency são que fornecem a partilha de grãos finos nativos da Apache Spark para a máxima utilização de recursos e latências mínimas de consulta.

Os aglomerados de Alta Concurrency funcionam apenas para SQL, Python e R. O desempenho e segurança dos clusters de Alta Concurrency é fornecido através da execução do código do utilizador em processos separados, o que não é possível em Scala.

Além disso, apenas os clusters high Concurrency suportam o controlo de acesso à mesa.

Para criar um cluster de alta concurrency, no modo de redução do modo cluster selecione High Concurrency.

Modo cluster de alta concência

Para um exemplo de como criar um cluster de Alta Concurrency utilizando a API clusters, consulte o exemplo do cluster high concurrency.

Aglomerados de nó único

Um único aglomerado de nó não tem trabalhadores e gere trabalhos de faísca no nó do motorista. Em contrapartida, os clusters de modo Standard requerem pelo menos um nó de trabalhadores da Spark, além do nó do condutor para executar trabalhos de Spark.

Para criar um único conjunto de nó, no modo de entrega do modo de cluster selecione Single Node.

Modo de cluster de nó único

Para saber mais sobre trabalhar com clusters single nó, consulte os clusters single nó.

Conjunto

Importante

Esta funcionalidade está em Pré-visualização Pública.

Para reduzir a hora de início do cluster, pode anexar um cluster a um conjunto de instâncias ociosas predefinidas. Quando ligado a uma piscina, um cluster aloca os seus nós de motorista e trabalhador da piscina. Se o pool não tiver recursos suficientes para acomodar o pedido do cluster, a piscina expande-se alojando novas instâncias do fornecedor de exemplos. Quando um cluster anexo é terminado, as instâncias que usou são devolvidas à piscina e podem ser reutilizadas por um cluster diferente.

Consulte uma piscina para saber mais sobre como trabalhar com piscinas em Azure Databricks.

Runtime do Databricks

Os tempos de execução de databricks são o conjunto de componentes centrais que funcionam nos seus clusters. Todos os tempos de execução de Databricks incluem Apache Spark e adicionam componentes e atualizações que melhoram a usabilidade, desempenho e segurança.

O Azure Databricks oferece vários tipos de tempos de execução e várias versões desses tipos de tempo de execução na versão runtime de databricks quando cria ou edita um cluster.

Para mais detalhes, consulte databricks tempos de execução.

Versão Python

Importante

Python 2 chegou ao fim da vida em 1 de janeiro de 2020. Python 2 não é suportado em Databricks Runtime 6.0 ou superior. Databricks Runtime 5.5 e abaixo continuam a apoiar Python 2.

Clusters python executando Databricks Runtime 6.0 e superior

Databricks Runtime 6.0 (Não suportado) e acima suporta apenas Python 3. Para grandes alterações relacionadas com o ambiente Python introduzidas por Databricks Runtime 6.0, consulte o ambiente Python nas notas de lançamento.

Clusters python executando Databricks Runtime 5.5 LTS

Para databricks Runtime 5.5 LTS, trabalhos de faísca, células de portátil Python e instalação da biblioteca todos suportam python 2 e 3.

A versão python padrão para clusters criados usando a UI é Python 3. Em Databricks Runtime 5.5 LTS a versão padrão para clusters criados usando a API REST é Python 2.

Especificar a versão Python

Para especificar a versão Python quando criar um cluster utilizando o UI, selecione-o a partir do drop-down da versão Python.

Versão Cluster Python

Para especificar a versão Python quando criar um cluster utilizando a API, desaprova a variável ambiental PYSPARK_PYTHON para /databricks/python/bin/python ou /databricks/python3/bin/python3 . Por exemplo, consulte o exemplo REST API Criar um cluster Python 3 (Databricks Runtime 5.5 LTS).

Para validar que a PYSPARK_PYTHON configuração entrou em vigor, num bloco de notas Python (ou %python célula):

import sys
print(sys.version)

Se /databricks/python3/bin/python3 especificou, deve imprimir algo como:

3.5.2 (default, Sep 10 2016, 08:21:44)
[GCC 5.4.0 20160609]

Importante

Para databricks Runtime 5.5 LTS, quando você corre %sh python --version em um caderno, python refere-se à versão Python do sistema Ubuntu, que é Python 2. Utilize /databricks/python/bin/python para se referir à versão de Python utilizada pelos cadernos databricks e Spark: este caminho é automaticamente configurado para apontar para o correto Python executável.

Perguntas Mais Frequentes (FAQ)

Posso usar os cadernos Python 2 e Python 3 no mesmo aglomerado?

N.º A versão Python é um cenário em todo o cluster e não é configurável numa base por caderno.

Que bibliotecas estão instaladas em aglomerados Python?

Para obter mais informações sobre as bibliotecas específicas instaladas, consulte as notas de lançamento do prazo de execução databricks.

As minhas bibliotecas PyPI existentes funcionarão com a Python 3?

Depende se a versão da biblioteca suporta a versão Python 3 de uma versão Databricks Runtime. Databricks Runtime 5.5 LTS usa Python 3.5. Databricks Runtime 6.0 ou superior e Databricks Runtime com Conda usam Python 3.7. É possível que uma versão antiga específica de uma biblioteca Python não seja compatível com Python 3.7. Para este caso, terá de utilizar uma versão mais recente da biblioteca.

As .egg minhas bibliotecas existentes funcionarão com a Python 3?

Depende se a sua biblioteca de ovos existente é compatível com python 2 e 3. Se a biblioteca não suportar o Python 3, então o acessório da biblioteca falhará ou ocorrerão erros de tempo de execução.

Para obter um guia completo sobre o código de porção para Python 3 e código de escrita compatível com python 2 e 3, consulte o Suporte Python 3.

Ainda posso instalar bibliotecas Python usando scripts init?

Um caso de uso comum para scripts de inicialização de nó cluster é instalar pacotes. Para databricks Runtime 5.5 LTS, utilize /databricks/python/bin/pip para garantir que os pacotes Python se instalam no ambiente virtual databricks Python em vez do ambiente python do sistema. Para databricks Runtime 6.0 ou superior, e Databricks Runtime com Conda, o pip comando está se referindo ao ambiente virtual pip de Python no local correto. No entanto, se estiver a usar um script init para criar o ambiente virtual Python, use sempre o caminho absoluto de acesso python e pip .

Tipo de nó de cluster

Um aglomerado é composto por um nó condutor e nós de trabalhadores. Pode escolher tipos de exemplo de fornecedor de nuvem separados para os nós do condutor e do trabalhador, embora por defeito o nó do condutor utilize o mesmo tipo de instância que o nó do trabalhador. Diferentes famílias de tipos de instâncias adaptam-se a diferentes casos de utilização, tais como cargas de trabalho intensivas em memória ou computacional.

Nota

Se os seus requisitos de segurança incluírem isolamento computacional,selecione uma Standard_F72s_V2 instância como o seu tipo de trabalhador. Estes tipos de instância representam máquinas virtuais isoladas que consomem todo o hospedeiro físico e fornecem o nível de isolamento necessário para suportar, por exemplo, cargas de trabalho do Departamento de Impacto do Departamento de Defesa dos EUA 5 (IL5).

Nó do condutor

O condutor mantém informações estatais de todos os cadernos anexados ao cluster. O nó do controlador é também responsável pela manutenção do Texto do SparkCon e pela interpretação de todos os comandos que corre a partir de um caderno ou de uma biblioteca no cluster. O nó do condutor também dirige o mestre Apache Spark que coordena com os executores de faíscas.

O valor predefinido do tipo de nó condutor é o mesmo que o tipo de nó do trabalhador. Pode escolher um tipo de nó maior com mais memória se estiver a planear collect() muitos dados dos trabalhadores da Spark e analisá-los no caderno.

Dica

Uma vez que o nó condutor mantém todas as informações do Estado dos cadernos anexos, certifique-se de retirar os cadernos não reutilizados do condutor.

Nó do trabalhador

Os trabalhadores da Azure Databricks gerem os executores spark e outros serviços necessários para o bom funcionamento dos clusters. Quando distribui a sua carga de trabalho com a Spark, todo o processamento distribuído acontece nos trabalhadores. A Azure Databricks executa um executor por nó de trabalhador; portanto, os termos executor e trabalhador são usados intercambiavelmente no contexto da arquitetura Azure Databricks.

Dica

Para executar um trabalho do Apache Spark, precisa de, pelo menos, uma função de trabalho. Se um cluster tiver zero funções de trabalho, poderá executar comandos que não sejam do Apache Spark no controlador, mas os comandos do Apache Spark falharão.

Tipos de instâncias GPU

Para tarefas computacionalmente desafiantes que exigem um alto desempenho, como as associadas à aprendizagem profunda, a Azure Databricks suporta clusters acelerados com unidades de processamento gráfico (GPUs). Este suporte está em Beta. Para obter mais informações, consulte os clusters habilitados para a GPU.

Tamanho do cluster e autoscaling

Quando criar um cluster Azure Databricks, pode fornecer um número fixo de trabalhadores para o cluster ou fornecer um número mínimo e máximo de trabalhadores para o cluster.

Quando fornece um cluster de tamanho fixo, a Azure Databricks garante que o seu cluster tem o número especificado de trabalhadores. Quando fornece um intervalo para o número de trabalhadores, a Databricks escolhe o número adequado de trabalhadores necessários para gerir o seu trabalho. Isto é referido como auto-caling.

Com a autoscalagem, a Azure Databricks reafecta dinamicamente os trabalhadores para explicar as características do seu trabalho. Algumas partes do seu oleoduto podem ser mais exigentes computacionalmente do que outras, e a Databricks adiciona automaticamente trabalhadores adicionais durante estas fases do seu trabalho (e remove-as quando já não são necessárias).

A autoscalização facilita a obtenção de uma elevada utilização do cluster, porque não é necessário providenciar o cluster para corresponder a uma carga de trabalho. Isto aplica-se especialmente às cargas de trabalho cujos requisitos mudam ao longo do tempo (como explorar um conjunto de dados durante um dia), mas também pode aplicar-se a uma carga de trabalho única mais curta cujos requisitos de provisionamento são desconhecidos. A autoscalagem oferece assim duas vantagens:

  • As cargas de trabalho podem ser mais rápidas em comparação com um cluster de tamanho constante sub-aprovisionado.
  • Os aglomerados de autoscalagem podem reduzir os custos globais em comparação com um cluster de tamanhoestotico.

Dependendo do tamanho constante do cluster e da carga de trabalho, o autoscaling dá-lhe um ou ambos estes benefícios ao mesmo tempo. O tamanho do cluster pode ir abaixo do número mínimo de trabalhadores selecionados quando o provedor de nuvem encerra casos. Neste caso, a Azure Databricks continuamente retrifica para re-provisões casos, a fim de manter o número mínimo de trabalhadores.

Nota

O autoscaling não está disponível para spark-submit empregos.

Tipos de dimensionamento automático

A Azure Databricks oferece dois tipos de autoscaling de nó de cluster: standard e otimizado. Para uma discussão sobre os benefícios da autoscalagem otimizada, consulte a publicação de blog na Optimized Autoscaling.

Os clusters automatizados (trabalho) usam sempre autoscaling otimizado. O tipo de autoscalagem realizada em clusters para todos os fins depende da configuração do espaço de trabalho.

A autoscalagem padrão é utilizada por clusters para todos os fins em espaços de trabalho no nível de preços standard. A autoscalagem otimizada é utilizada por clusters para todos os fins no Plano Premium Azure Databricks.

How autoscaling behaves (Como se comporta o dimensionamento automático)

A autoscalagem comporta-se de forma diferente consoante seja otimizada ou padrão e se é aplicada a um conjunto de todos os fins ou a um grupo de trabalho.

Dimensionamento automático otimizado

  • Escala de min a máximo em 2 passos.
  • Pode reduzir mesmo que o cluster não esteja inativo olhando para o estado do ficheiro de baralhar.
  • Reduz-se com base numa percentagem de nós atuais.
  • Nos aglomerados de trabalho, reduz-se se o cluster for subutilizado ao longo dos últimos 40 segundos.
  • Em aglomerados para todos os fins, reduz-se se o cluster for subutilizado ao longo dos últimos 150 segundos.
  • A spark.databricks.aggressiveWindowDownS propriedade de configuração Spark especifica em segundos quantas vezes um cluster toma decisões de down-scaling. Aumentar o valor faz com que um cluster diminua mais lentamente. O valor máximo é de 600.

Autoscalagem padrão

  • Começa com a adição de 8 nós. A partir daí, aumenta exponencialmente, mas pode dar muitos passos para chegar ao máximo. Pode personalizar o primeiro passo definindo a spark.databricks.autoscaling.standardFirstStepUp propriedade de configuração Spark.
  • Reduz-se apenas quando o cluster está completamente inativo e foi subutilizado nos últimos 10 minutos.
  • Reduz exponencialmente, começando com um nó.

Enable and configure autoscaling (Ativar e configurar o dimensionamento automático)

Para permitir que o Azure Databricks redimensione o seu cluster automaticamente, ativa a autoscalagem para o cluster e fornece a gama de trabalhadores min e max.

  1. Ative o dimensionamento automático.

    • All-Purpose cluster - Na página 'Criar Cluster', selecione a caixa de verificação de autoescalação ativa na caixa de opções de piloto automático:

      Ativar o dimensionamento automático

    • Cluster de trabalho - Na página Configure Cluster, selecione a caixa de verificação de autoescalação ativa na caixa de opções de piloto automático:

    Ativar o dimensionamento automático

  2. Configure os trabalhadores min e max.

    Configure os trabalhadores min e max

    Importante

    Se estiver a usar uma piscina de exemplo:

    • Certifique-se de que o tamanho do cluster solicitado é inferior ou igual ao número mínimo de casos ociosos na piscina. Se for maior, o tempo de arranque do cluster será equivalente a um cluster que não usa uma piscina.
    • Certifique-se de que o tamanho máximo do cluster é inferior ou igual à capacidade máxima da piscina. Se for maior, a criação do cluster falhará.

Exemplo auto-caling

Se reconfigurar um cluster estático para ser um cluster auto-caling, o Azure Databricks redimensiona imediatamente o cluster dentro dos limites mínimos e máximos e, em seguida, começa a autoscalar. Como exemplo, a tabela a seguir demonstra o que acontece aos agrupamentos com um determinado tamanho inicial se reconfigurar um cluster para autoescalar entre 5 e 10 nós.

Tamanho inicial Tamanho após reconfiguração
6 6
12 10
3 5

Autoscaling armazenamento local

Muitas vezes pode ser difícil estimar quanto espaço em disco um determinado trabalho irá ocupar. Para evitar que tenha de estimar quantos gigabytes de disco gerido para anexar ao seu cluster na hora da criação, o Azure Databricks ativa automaticamente o armazenamento local em todos os clusters Azure Databricks.

Com o armazenamento local autoescalando, a Azure Databricks monitoriza a quantidade de espaço de disco gratuito disponível nos trabalhadores spark do seu cluster. Se um trabalhador começar a esgotar-se demasiado no disco, o Databricks liga automaticamente um novo disco gerido ao trabalhador antes que fique sem espaço no disco. Os discos são anexados a um limite de 5 TB do espaço total do disco por máquina virtual (incluindo o armazenamento local inicial da máquina virtual).

Os discos geridos ligados a uma máquina virtual só são desligados quando a máquina virtual é devolvida ao Azure. Ou seja, os discos geridos nunca são separados de uma máquina virtual, desde que faça parte de um cluster de corrida. Para reduzir a utilização do disco gerido, a Azure Databricks recomenda a utilização desta função num cluster configurado com o tamanho do Cluster e a autoscalação ou a terminação automática.

Configuração de faíscas

Para afinar os trabalhos de Spark, pode fornecer propriedades de configuração personalizadas de Spark numa configuração de cluster.

  1. Na página de configuração do cluster, clique nas opções avançadas para alternar.

  2. Clique no separador Faísca.

    Configuração do Spark

Quando configurar um cluster utilizando a API clusters,desconfie as propriedades Spark no spark_conf campo no pedido de cluster Create ou editar o pedidode cluster .

Para definir propriedades Spark para todos os clusters, crie um script global init:

dbutils.fs.put("dbfs:/databricks/init/set_spark_params.sh","""
  |#!/bin/bash
  |
  |cat << 'EOF' > /databricks/driver/conf/00-custom-spark-driver-defaults.conf
  |[driver] {
  |  "spark.sql.sources.partitionOverwriteMode" = "DYNAMIC"
  |}
  |EOF
  """.stripMargin, true)

Ativar a encriptação de discos locais

Importante

Esta funcionalidade está em Pré-visualização Pública.

Alguns tipos de exemplos que usa para executar clusters podem ter discos ligados localmente. O Azure Databricks pode armazenar dados de baralhar ou dados efémeros nestes discos ligados localmente. Para garantir que todos os dados em repouso são encriptados para todos os tipos de armazenamento, incluindo dados de baralhar que são armazenados temporariamente nos discos locais do seu cluster, pode ativar a encriptação do disco local.

Importante

As suas cargas de trabalho podem ser executadas mais lentamente devido ao impacto de desempenho da leitura e da escrita de dados encriptados de e para os volumes locais.

Quando a encriptação do disco local é ativada, o Azure Databricks gera uma chave de encriptação localmente que é única em cada nó de cluster e é usada para encriptar todos os dados armazenados em discos locais. O âmbito da chave é local para cada nó de cluster e é destruído juntamente com o próprio nó de cluster. Durante a sua vida útil, a chave reside na memória para encriptação e desencriptação e é armazenada encriptada no disco.

Para ativar a encriptação do disco local, tem de utilizar a API dos Clusters. Durante a criação ou edição do cluster, conjunto:

{
  "enable_local_disk_encryption": true
}

Consulte Criar e Editar na referência API dos Clusters por exemplos de como invocar estas APIs.

Aqui está um exemplo de uma chamada de criação de cluster que permite encriptação de disco local:

{
  "cluster_name": "my-cluster",
  "spark_version": "7.3.x-scala2.12",
  "node_type_id": "Standard_D3_v2",
  "enable_local_disk_encryption": true,
  "spark_conf": {
    "spark.speculation": true
  },
  "num_workers": 25
}

Variáveis de ambiente

Pode definir variáveis ambientais que pode aceder a partir de scripts em execução num cluster.

  1. Na página de configuração do cluster, clique nas opções avançadas para alternar.

  2. Clique no separador Faísca.

  3. Definir as variáveis ambientais no campo Variáveis Ambientais.

    Campo de variáveis de ambiente

Também pode definir variáveis ambientais utilizando o spark_env_vars campo no pedido de cluster Create ou editar clusters API pontos finais.

Nota

As variáveis ambientais que definiu neste campo não estão disponíveis nos scripts de inicialização do nó de cluster. Os scripts init suportam apenas um conjunto limitado de variáveis de Ambientepredefinido .

Etiquetas de clusters

As tags de cluster permitem monitorizar facilmente o custo dos recursos em nuvem utilizados por vários grupos na sua organização. Pode especificar as etiquetas como pares de valor-chave quando cria um cluster, e a Azure Databricks aplica estas tags a recursos em nuvem como VMs e volumes de discos.

As tags de cluster propagam-se a estes recursos em nuvem juntamente com tags de piscina e espaço de trabalho (grupo de recursos). Para obter mais informações sobre como estes tipos de etiquetas funcionam em conjunto, consulte a utilização do Monitor utilizando etiquetas de cluster, piscina e espaço de trabalho.

Por conveniência, a Azure Databricks aplica quatro etiquetas predefinidas a cada cluster: Vendor Creator , e ClusterName ClusterId .

Além disso, em agrupamentos de emprego, a Azure Databricks aplica duas etiquetas predefinidas: RunName e JobId .

Pode adicionar tags personalizadas quando criar um cluster. Para configurar etiquetas de cluster:

  1. Na página de configuração do cluster, clique nas opções avançadas para alternar.

  2. Na parte inferior da página, clique no separador Tags.

    Separador tags

  3. Adicione um par de valor-chave para cada etiqueta personalizada. Pode adicionar até 43 etiquetas personalizadas.

As etiquetas personalizadas são apresentadas nas notas do Azure e atualizadas sempre que adiciona, edita ou apaga uma etiqueta personalizada.

Acesso SSH a clusters

O SSH permite-lhe iniciar sessão nos clusters Apache Spark remotamente para uma resolução avançada de problemas e instalar software personalizado.

Por razões de segurança, em Azure Databricks a porta SSH é fechada por defeito. Se pretender ativar o acesso da SSH aos seus clusters Spark, contacte o suporte da Azure Databricks.

Nota

O SSH só pode ser ativado se o seu espaço de trabalho for implantado na sua própria rede virual Azure.

Entrega de registos de clusters

Ao criar um cluster, pode especificar um local para entregar registos de pilotos, trabalhadores e eventos spark. Os registos são entregues a cada cinco minutos para o seu destino escolhido. Quando um cluster é terminado, a Azure Databricks garante entregar todos os registos gerados até ao fim do cluster.

O destino dos registos depende da identificação do cluster. Se o destino especificado dbfs:/cluster-log-delivery for, os registos de cluster 0630-191345-leap375 para serem entregues a dbfs:/cluster-log-delivery/0630-191345-leap375 .

Para configurar o local de entrega de registos:

  1. Na página de configuração do cluster, clique nas opções avançadas para alternar.

  2. Na parte inferior da página, clique no separador Registar.

    Entrega de registos de clusters

  3. Selecione um tipo de destino.

  4. Introduza o caminho do log de cluster.

Nota

Esta funcionalidade também está disponível na API REST. Consulte exemplos de entrega de registos de API e Cluster.

Scripts init

Um script de inicialização de nó de cluster - ou init - é um script de concha que funciona durante o arranque para cada nó de cluster antes do início do condutor ou trabalhador JVM. Pode utilizar scripts init para instalar pacotes e bibliotecas não incluídos no tempo de execução de Databricks, modificar o classpath do sistema JVM, definir propriedades do sistema e variáveis ambientais usadas pelo JVM, ou modificar parâmetros de configuração de Faíscas, entre outras tarefas de configuração.

Pode anexar scripts init a um cluster, expandindo a secção Opções Avançadas e clicando no separador Scripts Init.

Para obter instruções detalhadas, consulte os scripts de inicialização do nó de cluster.