Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.

Nesta página

Mostrar todos

Central de ajuda/ MapReduce Service/ Visão geral de serviço/ Componentes/ Spark2x/ Princípios básicos do Spark2x

Princípios básicos do Spark2x

Atualizado em 2023-05-19 GMT+08:00

Ver PDF

O componente Spark2x aplica-se ao MRS 3.x e versões posteriores.

Descrição

Spark é uma estrutura de computação distribuída baseada em memória. Em cenários iterativos, a capacidade computacional do Spark é de 10 a 100 vezes maior que a do MapReduce porque os dados são armazenados na memória ao serem processados. O Spark pode usar o HDFS como sistema de armazenamento subjacente, permitindo que os usuários mudem rapidamente do MapReduce para o Spark. O Spark fornece recursos de análise de dados completa, como o processamento de streaming em pequenos lotes, processamento em lote off-line, consulta SQL e mineração de dados. Os usuários podem usar perfeitamente essas funções em uma mesma aplicação. Para obter detalhes sobre os novos recursos de código aberto do Spark2x, consulte Novos recursos de código aberto do Spark2x.

Os recursos do Spark são os seguintes:

Melhora a capacidade de processamento de dados por meio da computação de memória distribuída e do mecanismo de execução de grafo direcionado acíclico (DAG). O desempenho fornecido é de 10 a 100 vezes maior do que o do MapReduce.
Suporta múltiplas linguagens de desenvolvimento (Scala/Java/Python) e dezenas de operadores altamente abstratos para facilitar a construção de aplicativos de processamento de dados distribuídos.
Cria pilhas de processamento de dados usando SQL, Streaming, MLlib e GraphX para fornecer recursos de processamento de dados completo.
Adapta-se ao ecossistema Hadoop, permitindo que aplicações Spark sejam executados em Standalone, Mesos ou Yarn, permitindo o acesso a várias fontes de dados, como HDFS, HBase e Hive e suportando a migração suave da aplicação MapReduce para Spark.

Arquitetura

Figura 1 descreve a arquitetura do Spark e Tabela 1 lista os módulos do Spark.

Figura 1 Arquitetura do Spark
Clique para ampliar

**Tabela 1** Conceitos básicos
Módulo	Descrição
Gerenciador de cluster	O gerenciador de cluster gerencia os recursos no cluster. O Spark oferece suporte a vários gerenciadores de cluster, incluindo Mesos, Yarn e o gerenciador de cluster Standalone fornecido com o Spark. Por padrão, os clusters do Spark adotam o gerenciador de clusters do Yarn.
Aplicação	Aplicação Spark. Consiste em um Driver Program e vários executores.
Modo de implementação	Modo de implementação em cluster ou no cliente. No modo de cluster, o driver é executado em um nó dentro do cluster. No modo de cliente, o driver é executado no cliente (fora do cluster).
Programa do Driver	O processo principal da aplicação Spark. Ele executa a função main() de uma aplicação e cria SparkContext. Ele é usado para analisar aplicações, gerar estágios e agendar tarefas para executores. Normalmente, o SparkContext é o Programa de Drivers.
Executor	Um processo iniciado em um nó de trabalho. Ele é usado para executar tarefas e gerenciar e processar os dados usados em aplicações. Uma aplicação Spark geralmente contém vários executores. Cada executor recebe comandos do driver e executa uma ou várias tarefas.
Nó de trabalho	Um nó que inicia e gerencia executores e recursos em um cluster.
Job	Um job consiste em várias tarefas simultâneas. Um operador de ação (por exemplo, um operador de coleta) mapeia para um job.
Estágio	Cada job consiste em vários estágios. Cada estágio é um conjunto de tarefas, que é separado por Grafo Direcionado Acíclico (DAG).
Tarefa	Uma tarefa carrega a unidade de computação das lógicas de serviço. É a unidade de trabalho mínima que pode ser executada na plataforma Spark. Uma aplicação pode ser dividida em várias tarefas com base no plano de execução e na quantidade de computação.

Princípio do Spark

Figura 2 descreve a arquitetura de execução da aplicação do Spark.

Uma aplicação está sendo executada no cluster como uma coleção de processos. Driver coordena a execução da aplicação.
Para executar uma aplicação, o Driver se conecta ao gerenciador de cluster (como Standalone, Mesos e Yarn) para solicitar os recursos do executor e iniciar o ExecutorBackend. O gerenciador de cluster agenda recursos entre diferentes aplicações. Driver agenda DAGs, divide estágios e gera tarefas para a aplicação ao mesmo tempo.
Em seguida, o Spark envia os códigos da aplicação (os códigos transferidos para SparkContext, que são definidos por JAR ou Python) a um executor.
Depois que todas as tarefas forem concluídas, a execução da aplicação do usuário é interrompida.

Figura 2 Arquitetura de execução da aplicação Spark
Clique para ampliar

O Spark usa os modos Master e Worker, como mostrado na Figura 3. Um usuário envia uma aplicação no cliente do Spark e, em seguida, o agendador divide um job em várias tarefas e envia as tarefas a cada Worker para execução. Cada Worker reporta os resultados do cálculo para o Driver (Master) e, em seguida, o Driver agrega e retorna os resultados para o cliente.

Figura 3 Modo Master-Worker do Spark
Clique para ampliar

Observe o seguinte sobre a arquitetura:

As aplicações são isoladas umas das outras.
Cada aplicação tem um processo de executor independente, e cada executor inicia vários threads para executar tarefas em paralelo. Cada driver agenda suas próprias tarefas e diferentes tarefas de aplicação são executadas em diferentes JVMs, ou seja, diferentes executores.
Diferentes aplicações do Spark não compartilham dados, a menos que os dados sejam armazenados no sistema de armazenamento externo, como o HDFS.
É aconselhável implementar o programa do Driver em um local próximo ao nó de trabalho porque o programa do Driver agenda tarefas no cluster. Por exemplo, implante o programa do Driver na rede onde o nó de trabalho está localizado.

O Spark no YARN pode ser implementado em dois modos:

No modo Yarn-cluster, o driver do Spark é executado dentro de um processo ApplicationMaster que é gerenciado pelo Yarn no cluster. Depois que o ApplicationMaster é iniciado, o cliente pode sair sem interromper a execução do serviço.
No modo Yarn-client, o Driver é executado no processo de cliente e o processo ApplicationMaster é usado apenas para solicitar recursos do Yarn.

Princípio do Spark Streaming

O Spark Streaming é uma estrutura de computação em tempo real construída sobre o Spark, que expande a capacidade de processar dados de streaming em massa. O Spark suporta duas abordagens de processamento de dados: Streaming direto e Receptor.

Processo de computação de Streaming direto

Na abordagem de Streaming direto, a API direta é usada para processar dados. Tomemos como exemplo a API direta do Kafka. A API direta fornece o local de deslocamento do qual cada intervalo de lote será lido, o que é muito mais simples do que iniciar um receptor para receber continuamente dados do Kafka e dados gravados em logs de gravação antecipada (WALs). Em seguida, cada job em lote está em execução e os dados de deslocamento correspondentes estão prontos no Kafka. Essas informações de deslocamento podem ser armazenadas com segurança no arquivo de ponto de verificação e lidas por aplicações que falharam ao iniciar.

Figura 4 Transmissão de dados através da API direta do Kafka
Clique para ampliar

Após a falha, o Spark Streaming pode ler dados do Kafka novamente e processar o segmento de dados. O resultado do processamento é o mesmo, não importa se o Spark Streaming falhar ou não, porque a semântica é processada apenas uma vez.

A API direta não precisa usar o WAL e os receptores e garante que cada registro do Kafka seja recebido apenas uma vez, o que é mais eficiente. Desta forma, o Spark Streaming e o Kafka podem ser bem integrados, fazendo com que os canais de streaming sejam apresentados com alta tolerância a falhas, alta eficiência e facilidade de uso. Portanto, é aconselhável usar o Streaming direto para processar dados.

Processo de computação do Receptor

Quando uma aplicação Spark Streaming é iniciada, o StreamingContext relacionado (a base de todas as funções de streaming) usa o SparkContext para iniciar o receptor e se tornar uma tarefa de longa duração. Esses receptores recebem e salvam dados de streaming na memória do Spark para processamento. Figura 5 mostra o ciclo de vida da transferência de dados.

Figura 5 Ciclo de vida da transferência de dados
Clique para ampliar

Receber dados (seta azul).
O receptor divide um fluxo de dados em uma série de blocos e os armazena na memória do executor. Além disso, depois que a WAL é habilitada, ela grava dados na WAL do sistema de arquivos tolerante a falhas.
Notificar o driver (seta verde).
Os metadados no bloco recebido são enviados para StreamingContext no driver. Os metadados incluem:
- ID de referência de bloco usado para localizar a posição dos dados na memória do Executor.
- Bloquear informações de deslocamento de dados em logs (se a função WAL estiver ativada).
Dados do processo (seta vermelha).
Para cada lote de dados, o StreamingContext usa informações de bloco para gerar conjuntos de dados distribuídos resilientes (RDDs) e jobs. O StreamingContext executa jobs executando tarefas para processar blocos na memória do executor.
Periodicamente definir pontos de verificação (setas laranja).
Para tolerância a falhas, o StreamingContext define periodicamente pontos de verificação e os salva em sistemas de arquivos externos.

Tolerância a falhas

O Spark e seu RDD permitem o processamento contínuo de falhas de qualquer nó de trabalho no cluster. O Spark Streaming é construído em cima do Spark. Portanto, o nó de trabalho do Spark Streaming também tem a mesma capacidade de tolerância a falhas. No entanto, o Spark Streaming precisa ser executado corretamente em caso de execução de longo tempo. Portanto, o Spark deve ser capaz de se recuperar de falhas através do processo de driver (processo principal que coordena todos os Workers). Isso representa desafios para a tolerância a falhas do driver do Spark, pois o driver do Spark pode ser qualquer aplicação de usuário implementado em qualquer modo de computação. No entanto, o Spark Streaming possui uma arquitetura de computação interna. Ou seja, ele executa periodicamente a mesma computação do Spark em cada dado de lote. Tal arquitetura permite que ele armazene periodicamente pontos de verificação para espaço de armazenamento confiável e os recupere após a reinicialização do Driver.

Para dados de origem, como arquivos, o mecanismo de recuperação de Driver pode garantir zero perda de dados, pois todos os dados são armazenados em um sistema de arquivos tolerante a falhas, como o HDFS. No entanto, para outras fontes de dados, como Kafka e Flume, alguns dados recebidos são armazenados em cache apenas na memória e podem ser perdidos antes de serem processados. Isso é causado pelo modo de operação de distribuição das aplicações Spark. Quando o processo de driver falha, todos os executores em execução no Gerenciador de Cluster, juntamente com todos os dados na memória, são encerrados. Para evitar essa perda de dados, a função WAL é adicionada ao Spark Streaming.

O WAL é frequentemente usado em bancos de dados e sistemas de arquivos para garantir a persistência de qualquer operação de dados. Ou seja, primeiro registre uma operação em um log persistente e execute essa operação nos dados. Se a operação falhar, o sistema é recuperado lendo o log e reaplicando a operação predefinida. A seguir, descrevemos como usar o WAL para garantir a persistência dos dados recebidos:

Receptor é usado para receber dados de fontes de dados como Kafka. Como uma tarefa de longa duração no Executor, o Receptor recebe dados e também confirma os dados recebidos se suportados por fontes de dados. Os dados recebidos são armazenados na memória do Executor e o Driver entrega uma tarefa ao Executor para processamento.

Depois que o WAL é habilitado, todos os dados recebidos são armazenados em arquivos de log no sistema de arquivos tolerante a falhas. Portanto, os dados recebidos não são perdidos mesmo se o Spark Streaming falhar. Além disso, o receptor verifica a exatidão dos dados recebidos somente depois que os dados são pré-gravados em logs. Os dados que estão em cache, mas não armazenados, podem ser enviados novamente por fontes de dados após a reinicialização do driver. Esses dois mecanismos garantem perda zero de dados. Ou seja, todos os dados são recuperados de logs ou reenviados por fontes de dados.

Para ativar a função WAL, execute as seguintes operações:

Defina streamingContext.checkpoint (caminho para diretório) para configurar o diretório de ponto de verificação, que é um caminho de arquivo HDFS usado para armazenar pontos de verificação de streaming e WALs.
Defina spark.streaming.receiver.writeAheadLog.enable de SparkConf para true (o valor padrão é false).

Depois que o WAL é ativado, todos os receptores têm a vantagem de se recuperar de dados recebidos confiáveis. É aconselhável desabilitar o mecanismo de várias réplicas porque o sistema de arquivos tolerante a falhas do WAL também pode replicar os dados.

A taxa de transferência de recebimento de dados é reduzida depois que o WAL é habilitado. Todos os dados são gravados no sistema de arquivos tolerante a falhas. Como resultado, a taxa de transferência de gravação do sistema de arquivos e a largura de banda da rede para replicação de dados podem se tornar o gargalo potencial. Para resolver esse problema, é aconselhável criar mais receptores para aumentar o grau de paralelismo de recebimento de dados ou usar um hardware melhor para melhorar a taxa de transferência do sistema de arquivos tolerante a falhas.

Processo de recuperação

Quando um driver com falha for reiniciado, reinicie-o da seguinte maneira:

Figura 6 Processo de recuperação de computação
Clique para ampliar

Recupere a computação. (Seta laranja)
Use as informações do ponto de verificação para reiniciar o Driver, reconstruir o SparkContext e reiniciar o Receptor.
Recupere bloco de metadados. (Seta verde)
Essa operação garante que todos os blocos de metadados necessários sejam recuperados para continuar a recuperação computacional subsequente.
Relance jobs inacabados. (Seta vermelha)
Os metadados recuperados são usados para gerar RDDs e trabalhos correspondentes para processamento em lote interrompido devido a falhas.
Leia dados de bloco salvos em logs. (Seta azul)
Os dados de bloco são lidos diretamente dos WALs durante a execução dos trabalhos anteriores e, portanto, todos os dados essenciais armazenados de forma confiável nos logs são recuperados.
Reenvie dados não confirmados. (Seta roxa)
Os dados que são armazenados em cache, mas não armazenados em logs após falhas, são reenviados por fontes de dados, porque o receptor não confirma os dados.

Portanto, usando WALs e um Receptor confiável, o Spark Streaming pode evitar a perda de dados de entrada causada por falhas de Driver.

Princípio do SparkSQL e do DataSet

SparkSQL

Figura 7 SparkSQL e DataSet
Clique para ampliar

Spark SQL é um módulo para processamento de dados estruturados. Na aplicação Spark, instruções SQL ou APIs de DataSet podem ser usadas para consultar dados estruturados.

Spark SQL e DataSet também fornecem um método universal para acessar várias fontes de dados, como Hive, CSV, Parquet, ORC, JSON e JDBC. Essas fontes de dados também permitem a interação de dados. O Spark SQL reutiliza a lógica de processamento de front-end do Hive e o módulo de processamento de metadados. Com o Spark SQL, você pode consultar diretamente os dados existentes do Hive.

Além disso, o Spark SQL também fornece APIs, CLI e APIs de JDBC, permitindo diversos acessos ao cliente.

DDL/DML do Spark SQL nativo

No Spark 1.5, muitos comandos de Linguagem de Definição de Dados (DDL)/Linguagem de Manipulação de Dados (DML) são empurrados para baixo e executados no Hive, causando acoplamento com o Hive e inflexibilidade, como relatórios e resultados de erros inesperados.

O Spark2x realiza a localização de comandos e substitui o Hive por DDL/DML de Spark SQL Nativo para executar comandos DDL/DML. Além disso, o desacoplamento do Hive é realizado e os comandos podem ser personalizados.

DataSet

Um DataSet é uma coleção fortemente tipada de objetos específicos de domínio que podem ser transformados em paralelo usando operações funcionais ou relacionais. Cada Dataset também tem uma exibição não tipada chamada DataFrame que é um Dataset de linha.

O DataFrame é um conjunto de dados estruturado e distribuído que consiste em várias colunas. O DataFrame é igual a uma tabela no banco de dados de relacionamento ou o DataFrame no R/Python. O DataFrame é o conceito mais básico do Spark SQL, que pode ser criado usando vários métodos, como o conjunto de dados estruturado, a tabela de Hive, o banco de dados externo ou o RDD.

As operações disponíveis no DataSets são divididas em transformações e ações.

Uma operação de transformação pode gerar um novo DataSet,
por exemplo, map, filter, select e aggregate (groupBy).
Uma operação de ação pode acionar a computação e retornar resultados,
por exemplo, count, show ou gravar dados no sistema de arquivos.

Você pode usar um dos seguintes métodos para criar um DataSet:

A maneira mais comum é apontar o Spark para alguns arquivos em sistemas de armazenamento, usando a função read disponível em um SparkSession.

val people = spark.read.parquet("...").as[Person]  // Scala

DataSet<Person> people = spark.read().parquet("...").as(Encoders.bean(Person.class));//Java

Você também pode criar um DataSet usando a operação de transformação disponível em um existente. Por exemplo, aplique a operação de mapa em um DataSet existente para criar um DataSet:
```
val names = people.map(_.name) // In Scala: names is Dataset.
```
```
Dataset<String> names = people.map((Person p) -> p.name, Encoders.STRING)); // Java
```

CLI e JDBCServer

Além das APIs de programação, o Spark SQL também fornece as APIs de CLI/JDBC.

Os scripts spark-shell e spark-sql podem fornecer a CLI para depuração.
JDBCServer fornece APIs de JDBC. Sistemas externos podem enviar diretamente solicitações de JDBC para calcular e analisar dados estruturados.

Princípio de SparkSession

SparkSession é uma API unificada no Spark2x e pode ser considerada como uma entrada unificada para leitura de dados. SparkSession fornece um único ponto de entrada para executar muitas operações anteriormente espalhadas por várias classes e também fornece métodos de acesso a essas classes antigas para maximizar a compatibilidade.

Uma SparkSession pode ser criado usando um padrão de construtor. O construtor reutilizará automaticamente a SparkSession existente se houver uma SparkSession ou criará uma SparkSession se ela não existir. Durante as transações de I/O, as definições do item de configuração no construtor são automaticamente sincronizadas com o Spark e o Hadoop.

import org.apache.spark.sql.SparkSession
val sparkSession = SparkSession.builder
  .master("local")
  .appName("my-spark-app")
  .config("spark.some.config.option", "config-value")
  .getOrCreate()

SparkSession pode ser usada para executar consultas SQL em dados e retornar resultados como DataFrame.
```
sparkSession.sql("select * from person").show
```
A SparkSession pode ser usada para definir itens de configuração durante a execução. Esses itens de configuração podem ser substituídos por variáveis em instruções SQL.
```
sparkSession.conf.set("spark.some.config", "abcd")
sparkSession.conf.get("spark.some.config")
sparkSession.sql("select ${spark.some.config}")
```
A SparkSession também inclui um método "catalog" que contém métodos para trabalhar com o Metastore (catálogo de dados). Depois que esse método é usado, um conjunto de dados é retornado, que pode ser executado usando a mesma API de Dataset.
```
val tables = sparkSession.catalog.listTables()
val columns = sparkSession.catalog.listColumns("myTable")
```
O SparkContext subjacente pode ser acessado pela API de SparkContext da SparkSession.
```
val sparkContext = sparkSession.sparkContext
```

Princípio do Streaming Estruturado

O Streaming Estruturado é um mecanismo de processamento de fluxo construído no motor Spark SQL. Você pode usar a API de Dataset/DataFrame em Scala, Java, Python ou R para expressar agregações de streaming, janelas de tempo de evento e junções fluxo-fluxo. Se os dados de streaming forem produzidos de forma incremental e contínua, o Spark SQL continuará processando os dados e sincronizando o resultado com o conjunto de resultados. Além disso, o sistema garante de ponta a ponta garantias de tolerância a falhas exatas através de pontos de verificação e WALs.

O núcleo do Streaming Estruturado é tomar dados de streaming como uma tabela de banco de dados incremental. Semelhante ao modelo de processamento de blocos de dados, o modelo de processamento de dados de streaming aplica operações de consulta em uma tabela de banco de dados estática à computação de streaming, e o Spark usa instruções SQL padrão para consulta, para obter dados da tabela incremental e ilimitada.

Figura 8 Tabela ilimitada de Streaming Estruturado
Clique para ampliar

Cada operação de consulta gera uma tabela de resultados. Em cada intervalo de gatilho, os dados atualizados serão sincronizados com a tabela de resultados. Sempre que a tabela de resultados for atualizada, o resultado atualizado será gravado em um sistema de armazenamento externo.

Figura 9 Modelo de processamento de dados de Streaming Estruturado
Clique para ampliar

Os modos de armazenamento de Streaming Estruturado na fase de saída são os seguintes:

Modo completo: os conjuntos de resultados atualizados são gravados no sistema de armazenamento externo. A operação de gravação é realizada por um conector do sistema de armazenamento externo.
Modo de adição: se um intervalo for acionado, apenas os dados adicionados na tabela de resultados serão gravados em um sistema externo. Isso é aplicável somente nas consultas em que não se espera que as linhas existentes na tabela de resultados sejam alteradas.
Modo de atualização: se um intervalo for acionado, somente os dados atualizados na tabela de resultados serão gravados em um sistema externo, que é a diferença entre o Modo completo e o Modo de atualização.

Conceitos

RDD
Conjunto de dados distribuídos resilientes (RDD) é um conceito central do Spark. Indica um conjunto de dados distribuído somente leitura e particionado. Parciais ou todos os dados deste conjunto de dados podem ser armazenados em cache na memória e reutilizados entre cálculos.

Criação de RDD
- Um RDD pode ser criado a partir da entrada do HDFS ou de outros sistemas de armazenamento compatíveis com o Hadoop.
- Um novo RDD pode ser convertido a partir de um RDD pai.
- Um RDD pode ser convertido a partir de uma coleção de conjuntos de dados através da codificação.
Armazenamento de RDD
- Você pode selecionar diferentes níveis de armazenamento para armazenar um RDD para reutilização. (Há 11 níveis de armazenamento para armazenar um RDD.)
- Por padrão, o RDD é armazenado na memória. Quando a memória é insuficiente, o RDD transborda para o disco.
Dependência de RDD
A dependência de RDD inclui a dependência estreita e a dependência ampla.

Figura 10 Dependência de RDD
- Dependência estreita: cada partição do RDD pai é usada por no máximo uma partição do RDD filho.
- Dependência ampla: as partições do RDD filho dependem de todas as partições do RDD pai.
A dependência estreita facilita a otimização. Logicamente, cada operador do RDD é um fork/join (a join não é o operador de junção mencionado acima, mas a barreira usada para sincronizar várias tarefas simultâneas); fork o RDD para cada partição e, em seguida, execute a computação. Após a computação, junte os resultados e, em seguida, execute a operação fork/join no próximo operador do RDD. É antieconômico traduzir diretamente o RDD em implementação física. A primeira é que cada RDD (mesmo resultado intermediário) precisa ser fisicalizado em memória ou armazenamento, o que é demorado e ocupa muito espaço. A segunda é que, como uma barreira global, a operação join é muito cara e todo o processo de join será retardado pelo nó mais lento. Se as partições do RDD filho dependerem estritamente das do RDD pai, os dois processos de fork/join podem ser combinados para implementar a otimização de fusão clássica. Se a relação na sequência contínua do operador for de dependência estreita, vários processos de fork/join podem ser combinados para reduzir um grande número de barreiras globais e eliminar a fisicalização de muitos resultados intermediários do RDD, o que melhora muito o desempenho. Isso é chamado de otimização de pipeline no Spark.
Transformação e ação (operações de RDD)
As operações no RDD incluem transformação (o valor de retorno é um RDD) e ação (o valor de retorno não é um RDD). Figura 11 mostra o processo de operação do RDD. A transformação é lenta, o que indica que a transformação de um RDD para outro RDD não é executada imediatamente. O Spark registra apenas a transformação, mas não a executa imediatamente. A computação real é iniciada somente quando a ação é iniciada. A ação retorna resultados ou grava os dados do RDD no sistema de armazenamento. A ação é a força motriz para o Spark iniciar a computação.

Figura 11 Operação de RDD

Os dados e o modelo de operação do RDD são bem diferentes dos do Scala.
```
val file = sc.textFile("hdfs://...")
val errors = file.filter(_.contains("ERROR"))
errors.cache()
errors.count()
```
1. O operador de textFile lê arquivos de log do HDFS e retorna arquivos (como um RDD).
2. O operador de filtro filtra as linhas com ERROR e as atribui a erros (um novo RDD). O operador de filtro é uma transformação.
3. O operador de cache armazena em cache os erros para uso futuro.
4. O operador de contagem retorna o número de linhas de erros. O operador de contagem é uma ação.
A transformação inclui os seguintes tipos:
- Os elementos do RDD são considerados elementos simples.
  A entrada e a saída têm a relação um-para-um, e a estrutura de partição do RDD resultante permanece inalterada, por exemplo, map.
  
  A entrada e a saída têm a relação um-para-muitos, e a estrutura de partição do RDD resultante permanece inalterada, por exemplo, flatMap (um elemento torna-se uma sequência contendo vários elementos após map e, em seguida, achata para vários elementos).
  
  A entrada e a saída têm a relação um-para-um, mas a estrutura da partição do RDD resultante muda, por exemplo, union (dois RDDs integram-se a um RDD, e o número de partições torna-se a soma do número de partições de dois RDDs) e coalesce (as partições são reduzidas).
  
  Operadores de alguns elementos são selecionados a partir da entrada, como filter, distinct (elementos duplicados são excluídos), subtract (elementos que só existem neste RDD são mantidos) e sample (amostras são tomadas).
- Os elementos do RDD são considerados pares chave-valor.
  Executar o cálculo um-para-um no RDD único, como mapValues (o modo de partição do RDD de origem é mantido, o que é diferente de map).
  
  Classificar o RDD único, como sort e particionarPor (particionamento com consistência, o que é importante para a otimização local).
  
  Reestruturar e reduzir o RDD único com base na chave, como groupByKey e reduceByKey.
  
  Juntar-se e reestruturar dois RDDs com base na chave, como join e cogroup.
  
  As três operações posteriores que envolvem ordenação são chamadas de operações de shuffle.
A ação inclui os seguintes tipos:
- Gerar itens de configuração de escalar, como count (o número de elementos no RDD retornado), reduce, fold/aggregate (o número de itens de configuração de escalar que são retornados) e take (o número de elementos antes do retorno).
- Gerar a coleção Scala, como collect (importar todos os elementos do RDD para a coleção Scala) e lookup (procurar todos os valores correspondentes à chave).
- Gravar dados no armazenamento, como saveAsTextFile (que corresponde ao textFile anterior).
- Pontos de verificação, como o operador do checkpoint. Quando o Lineage é bastante longo (o que ocorre frequentemente na computação gráfica), leva um longo período de tempo para executar toda a sequência novamente quando ocorre uma falha. Nesse caso, o ponto de verificação é usado como o ponto de verificação para gravar os dados atuais no armazenamento estável.
Shuffle
Shuffle é uma fase específica na estrutura MapReduce, que está localizada entre a fase Map e a fase Reduce. Se os resultados de saída de Map forem usados pela Reduce, os resultados de saída deverão ser hash com base em uma chave e distribuídos para cada Redutor. Esse processo é chamado de Shuffle. Shuffle envolve a leitura e a escrita do disco e a transmissão da rede, de modo que o desempenho de Shuffle afete diretamente a eficiência da operação de todo o programa.

A figura abaixo mostra todo o processo do algoritmo do MapReduce.

Figura 12 Processo de algoritmo

Shuffle é uma ponte para conectar dados. A seguir, descreve-se a implementação do shuffle no Spark.

Shuffle divide um job do Spark em vários estágios. Os estágios anteriores contêm uma ou mais ShuffleMapTasks, e o último estágio contém uma ou mais ResultTasks.
Estrutura da aplicação Spark
A estrutura da aplicação Spark inclui o SparkContext inicializado e o programa principal.
- SparkContext inicializado: constrói o ambiente operacional da aplicação Spark.
  Constrói o objeto do SparkContext. O seguinte é um exemplo:
```
new SparkContext(master, appName, [SparkHome], [jars])
```
  Descrição do parâmetro:
  
  master: indica a cadeia de ligação. Os modos de link incluem local, Yarn-cluster e Yarn-client.
  
  appName: indica o nome da aplicação.
  
  SparkHome: indica o diretório em que o Spark está instalado no cluster.
  
  jars: indica o pacote de código e dependência de uma aplicação.
- Programa principal: processa dados.
Para obter detalhes sobre como enviar uma inscrição, visite https://spark.apache.org/docs/3.1.1/submitting-applications.html.
Comandos Shell do Spark
Os comandos básicos shell do Spark suportam o envio de aplicações Spark. Os comandos shell do Spark são os seguintes:
```
						./bin/spark-submit \
						--class <main-class> \
						--master <master-url> \
  ... # other options
  <application-jar> \
  [application-arguments]
```
Descrição do parâmetro:

--class: indica o nome da classe de uma aplicação Spark.

--master: indica o mestre ao qual o aplicativo Spark se vincula, como Yarn-client e Yarn-cluster.

application-jar: indica o caminho do arquivo JAR da aplicação Spark.

application-arguments: indica o parâmetro necessário para enviar a aplicação Spark. Este parâmetro pode ser deixado em branco.
Servidor JobHistory do Spark
A IU da Web do Spark é usada para monitorar os detalhes em cada fase da estrutura do Spark de um job do Spark em execução ou histórico e fornecer a exibição do log, o que ajuda os usuários a desenvolver, configurar e otimizar o job em unidades mais refinadas.