Como os endpoints de desenvolvimento do AWS Glue funcionam com cadernos do SageMaker

Uma das maneiras comuns de acessar seus endpoints de desenvolvimento é usar o Jupyter em cadernos do SageMaker. O caderno Jupyter é um aplicação Web de código aberto que é amplamente utilizada em visualização, análise, machine learning etc. Um caderno do SageMaker do AWS Glue oferece uma experiência de caderno Jupyter com endpoints de desenvolvimento do AWS Glue. No caderno do SageMaker do AWS Glue, o ambiente de caderno Jupyter é pré-configurado com SparkMagic, um plugin de código aberto do Jupyter para enviar trabalhos do Spark para um cluster remoto do Spark. Apache Livy é um serviço que permite a interação com um cluster remoto do Spark por meio de uma API REST. No caderno do SageMaker do AWS Glue, o SparkMagic está configurado para chamar a API REST em um servidor Livy em execução em um endpoint de desenvolvimento do AWS Glue.

O fluxo de texto a seguir explica como cada componente funciona:

Notebook do SageMaker do AWS Glue: (Jupyter → SparkMagic) → (rede) → endpoint de desenvolvimento do AWS Glue: (Apache Livy → Apache Spark)

Depois de executar o script do Spark escrito em cada parágrafo em um caderno Jupyter, o código do Spark é enviado ao servidor Livy via SparkMagic e, em seguida, um trabalho do Spark chamado “livy-session-N” é executado no cluster do Spark. Esse trabalho é chamado de sessão do Livy. O trabalho do Spark será executado enquanto a sessão do caderno estiver ativa. O trabalho do Spark será terminado quando você desligar o kernel do Jupyter do caderno, ou quando o tempo da sessão se esgotar. Um trabalho do Spark é iniciado por arquivo de caderno (.ipynb).

Você pode usar um único endpoint de desenvolvimento do AWS Glue com várias instâncias de cadernos do SageMaker. Você pode criar vários arquivos de caderno em cada instância de cadernos do SageMaker. Quando você abre um arquivo de cada caderno e executa os parágrafos, uma sessão do Livy é iniciada por arquivo de caderno no cluster do Spark via SparkMagic. Cada sessão do Livy corresponde a um único trabalho do Spark.

Comportamento padrão para endpoints de desenvolvimento do AWS Glue e cadernos do SageMaker

Os trabalhos do Spark são executados com base na configuração do Spark. Existem várias maneiras de definir a configuração do Spark (por exemplo, configuração do cluster do Spark, configuração do SparkMagic etc.).

Por padrão, o Spark aloca recursos de cluster para uma sessão do Livy com base na configuração do cluster do Spark. Em endpoints de desenvolvimento do AWS Glue, a configuração do cluster depende do tipo de operador. Esta tabela explica as configurações comuns por tipo de operador.

	Padrão	G.1X	G.2X
spark.driver.memory	5G	10G	20G
spark.executor.memory	5G	10G	20G
spark.executor.cores	4	8	16
spark.dynamicAllocation.enabled	VERDADEIRO	VERDADEIRO	VERDADEIRO

O número máximo de executores do Spark é calculado automaticamente pela combinação de DPU (ou NumberOfWorkers) e tipo de operador.

	Padrão	G.1X	G.2X
O número máximo de executores do Spark	(DPU - 1) * 2 - 1	(NumberOfWorkers - 1)	(NumberOfWorkers - 1)

Por exemplo, se o endpoint de desenvolvimento tiver dez operadores e o tipo de operador for G.1X, então você terá nove executores do Spark e todo o cluster terá 90G de memória de executor, uma vez que cada executor terá 10G de memória.

Independentemente do tipo de operador especificado, a alocação dinâmica de recursos do Spark será ativada. Se um conjunto de dados for grande o suficiente, o Spark pode alocar todos os executores em uma única sessão do Livy, já que spark.dynamicAllocation.maxExecutors não é definido por padrão. Isso significa que outras sessões do Livy no mesmo endpoint de desenvolvimento esperarão para iniciar novos executores. Se o conjunto de dados for pequeno, o Spark poderá alocar executores em várias sessões do Livy ao mesmo tempo.

nota

Para obter mais informações sobre como os recursos são alocados em diferentes casos de uso e como você define uma configuração para modificar o comportamento, consulte Configuração avançada: compartilhar endpoints de desenvolvimento entre vários usuários.