este documento dá uma breve visão de como a faísca funciona em clusters, para facilitar a compreensão dos componentes envolvidos. Leia o Guia de apresentação de candidaturas para aprender sobre o lançamento de aplicações em um cluster.
as aplicações de faísca funcionam como conjuntos independentes de processos em um aglomerado, coordenado pelo objeto SparkContextem seu programa principal (chamado de programa driver).
especificamente, para funcionar em um cluster, o SparkContext pode se conectar a vários tipos de gerentes de clusters(ou o próprio Gerenciador de clusters autônomo da Spark, Mesos ou fios), que alocam recursos em aplicações. Uma vez conectado, Spark adquire executores em nós no cluster, que são processos que executam computações e armazenam dados para sua aplicação.Em seguida, ele envia seu código de aplicação (definido por arquivos JAR ou Python passados para SparkContext) para os executores. Finalmente, SparkContext envia tarefas para os executores para executar.
há várias coisas úteis para notar sobre esta arquitetura:
- cada aplicação recebe seus próprios processos executores, que permanecem até a duração de toda a aplicação e executar tarefas em múltiplos threads. Isto tem o benefício de isolar as aplicações umas das outras, tanto do lado do escalonamento (cada condutor programa as suas próprias tarefas) como do lado do executor (tarefas de diferentes aplicações executadas em diferentes JVMs). No entanto, também significa que os dados não podem ser partilhados através de diferentes aplicações de faísca (exemplos de SparkContext), sem o reescrever para um sistema de armazenamento externo.
- Spark is agnostic to the underlying cluster manager. Desde que possa adquirir processos executores, e estes comuniquem entre si, é relativamente fácil executá-lo mesmo em um gerenciador de acluster que também suporta outras aplicações (por exemplo, Mesos/fio).
- o programa driver deve ouvir e aceitar conexões de entrada de seus executores através de sua vida útil (por exemplo, ver faísca.controlador.porto na configuração da rede). Como tal, o programa driver deve ser orientado em rede a partir dos nós dos trabalhadores.
- porque o driver programa tarefas no cluster, ele deve ser executado perto dos códigos de trabalho, de preferência na mesma rede local. Se você gostaria de enviar pedidos para o resumo remotamente, é melhor abrir um RPC para o driver e fazer com que ele envie operações de perto do que executar um driver longe dos nós do trabalhador.
tipos de Gestores de clusters
o sistema suporta actualmente vários gestores de clusters:
- Standalone-um simples gestor de clusters incluído com faísca que torna fácil a criação de um cluster.
- Apache Mesos – um gerente geral de clusters que também pode executar Hadoop MapReduceand service applications.
- Hadoop YARN-o Gestor de recursos em Hadoop 2.
- Kubernetes-um sistema de código aberto para automatizar a implantação, escala e gestão de aplicações contentorizadas.
um projecto de terceiros (não suportado pelo projecto Spark) existe para adicionar apoio à forNomad como gestor de clusters.
a apresentação de candidaturas
as candidaturas podem ser submetidas a um conjunto de qualquer tipo utilizando o script spark-submit.O Guia de apresentação de candidaturas descreve como fazê-lo.
Monitoring
cada programa driver tem uma interface web, tipicamente na porta 4040, que mostra informações sobre runningtasks, executores e uso de armazenamento. Basta ir para em um navegador web para acessar esta UI. O Guia de monitorização descreve igualmente outras opções de monitorização.
Job Scheduling
Spark gives control over resource allocation both across applications (at the level of the clustermanager) and within applications (if multiple computations are happening on the same SparkContext).A visão geral de programação de Tarefas descreve isso em mais detalhes.
Glossário
a tabela A seguir resume os termos que você verá usado para se referir a conceitos de cluster:
| Termo | Significado |
|---|---|
| o Aplicativo | programa do Usuário construída sobre o Spark. Consiste em um programa de driver e executores no cluster. |
| frasco de Aplicação | um frasco contendo a aplicação de faísca do utilizador. Em alguns casos, os usuários vão querer criar um” jar uber ” contendo sua aplicação junto com suas dependências. O jar do usuário nunca deve incluir bibliotecas Hadoop ou Spark, no entanto, estes serão adicionados em tempo de execução. |
| programa de Driver | processo execução da função main() do aplicativo e criar o SparkContext |
| gerenciador de Cluster | Um serviço externo para a aquisição de recursos no cluster (por exemplo, independente do gestor, Mesos, de FIOS) |
| Implantar o modo | Distingue onde o controlador de processo é executado. No modo “cluster”, o framework lança o driver dentro do cluster. No modo” cliente”, o Submissor lança o driver fora do cluster. |
| nó de trabalhador | qualquer nó que possa executar o código de aplicação no agregado |
| Executor | um processo lançado para uma aplicação em um nó de trabalhador, que executa tarefas e mantém os dados em memória ou armazenamento de disco através deles. Cada aplicação tem seus próprios executores. |
| a Tarefa | Uma unidade de trabalho que irá ser enviado para um executor |
| Trabalho | Uma computação paralela composta de várias tarefas que receber gerado em resposta a uma Faísca de ação (e.g. save, collect); você verá este termo usado nos registros do motorista. |
| Fase | cada trabalho é dividido em conjuntos menores de tarefas chamadas estágios que dependem um do outro (semelhante ao mapa e reduzir os estágios em MapReduce); você verá este termo usado nos registros do motorista. |