Servidor de histórico permanente do Dataproc

Visão geral

O Dataproc O Persistent History Server (PHS) oferece interfaces da Web para ver o histórico de jobs para jobs executados em clusters ativos ou excluídos do Dataproc. Ela está disponível em Versão de imagem do Dataproc e posterior, executada em um cluster de nó único do Dataproc. Ele oferece interfaces da Web nos seguintes arquivos e dados:

• Arquivos de histórico de jobs do MapReduce e do Spark

• Flinke os arquivos de histórico de tarefas (consulte Componente Flink opcional do Dataproc para criar um cluster do Dataproc e executar jobs do Flink)

• Arquivos de dados da linha do tempo do aplicativo criados por Serviço de cronograma do Yarn v2 e armazenado em uma instância do Bigtable.

• Registros de agregação YARN

O Persistent History Server acessa e exibe o histórico de jobs do Spark e do MapReduce arquivos de histórico de jobs Flink e arquivos de registros YARN gravados no Cloud Storage durante o ciclo de vida dos clusters de jobs do Dataproc.

Limitações

• Um cluster PHS do Dataproc permite visualizar arquivos de histórico de jobs apenas dos jobs do Dataproc executados no projeto em que o cluster do PHS está localizado. Além disso, a versão de imagem do cluster do PHS e o da imagem dos clusters de job precisa corresponder. Por exemplo, é possível usar um Cluster PHS da versão de imagem 2.0 para visualizar os arquivos do histórico de jobs executados nos clusters de job da versão de imagem do Dataproc 2.0 que estavam no projeto em que o cluster PHS está localizado.

• Um cluster PHS não oferece suporte Kerberos e Autenticação pessoal.

.

Também é possível visualizar o histórico e os dados da tarefa via Gateway de componentes do Dataproc interfaces da Web em execução em um cluster do Dataproc. Esses arquivos de histórico de jobs no cluster e as interfaces da Web não persistem após a exclusão do cluster.

Criar um cluster PHS do Dataproc

É possível executar o seguinte gcloud dataproc clusters create em um terminal local ou em Cloud Shell com as seguintes flags e propriedades do cluster para criar um cluster de nó único no servidor de histórico permanente do Dataproc.

Para informações sobre diferentes maneiras de criar um cluster do Dataproc, incluindo usando o console do Google Cloud, as bibliotecas de cliente do Cloud e a API Dataproc, consulte Como criar um cluster do Dataproc.

gcloud dataproc clusters create CLUSTER_NAME \
    --project=PROJECT \
    --region=REGION \
    --single-node \
    --enable-component-gateway \
    --optional-components=COMPONENT \
    --properties=PROPERTIES

• CLUSTER_NAME: especifique o nome do cluster de PHS.
• PROJECT: especifique o projeto a ser associado ao cluster do PHS. Isso O projeto precisa ser igual ao projeto associado ao cluster que executa os jobs. Consulte Criar um cluster de job do Dataproc.
• REGION: especifique uma região do Compute Engine em que o cluster do PHS será localizado.
• --single-node: um cluster de PHS é um Dataproc cluster de nó único.
• --enable-component-gateway: essa sinalização ativa Gateway de componentes interfaces da Web no cluster do PHS.
• COMPONENT: use esta sinalização para instalar um ou mais componentes opcionais no cluster. É necessário especificar o componente opcional FLINK para executar o Flink HistoryServer no cluster PHS para visualizar Flinke os arquivos de histórico de jobs.
• PROPERTIES: Especifique um ou mais propriedades do cluster.

• Opcionalmente, adicione o parâmetro --image-version para especificar a versão da imagem do cluster do PHS. A versão de imagem do PHS deve corresponder à versão da imagem dos clusters de jobs do Dataproc. Consulte Limitações.

  Observações:

  • Os exemplos de valor de propriedade nesta seção usam um "*" caractere curinga para permitir que o PHS correspondem a vários diretórios no bucket especificado gravados por clusters de job diferentes (mas consulte Considerações sobre a eficiência de caracteres curinga.
  • Nos exemplos a seguir, há sinalizações --properties separadas para ajudam na legibilidade. A prática recomendada ao usar gcloud dataproc clusters create para criar um Dataproc no Compute Engine cluster é usar uma sinalização --properties para especificar uma lista de propriedades separadas por vírgula (consulte formatação de propriedades do cluster).

  Propriedades:

  • yarn:yarn.nodemanager.remote-app-log-dir=gs://bucket-name/*/yarn-logs: Adicione esta propriedade para especificar o local do Cloud Storage em que o PHS acessará os registros YARN gravados por clusters de job.

  • spark:spark.history.fs.logDirectory=gs://bucket-name/*/spark-job-history: Adicione essa propriedade para ativar o histórico persistente de jobs do Spark. Essa propriedade especifica o local em que o PHS acessará os registros do histórico de jobs do Spark gravados por clusters de jobs.

    Nos clusters do Dataproc 2.0+, as duas propriedades a seguir também precisam ser definidas para ativar os registros de histórico do PHS Spark. Consulte Opções de configuração do servidor de histórico do Spark. spark.history.custom.executor.log.url é um valor literal que contém {{PLACEHOLDERS}} para variáveis que serão definidas pelo servidor de histórico permanente. Essas variáveis não são definidas pelos usuários. Transmita o valor da propriedade conforme mostrado.

    --properties=spark:spark.history.custom.executor.log.url.applyIncompleteApplication=false
    

    --properties=spark:spark.history.custom.executor.log.url={{YARN_LOG_SERVER_URL}}/{{NM_HOST}}:{{NM_PORT}}/{{CONTAINER_ID}}/{{CONTAINER_ID}}/{{USER}}/{{FILE_NAME}}
    

  • mapred:mapreduce.jobhistory.read-only.dir-pattern=gs://bucket-name/*/mapreduce-job-history/done: Adicione esta propriedade para ativar o histórico persistente de jobs do MapReduce. Esta propriedade especifica o local do Cloud Storage em que o PHS acessará os registros do histórico de jobs do MapReduce gravados por clusters de jobs.

  • dataproc:yarn.atsv2.bigtable.instance=projects/project-id/instance_id/bigtable-instance-id: depois de você Configurar o serviço de linha do tempo do Yarn v2, adicione esta propriedade para usar o cluster PHS e visualizar dados da linha do tempo no Serviço de cronograma de aplicativos YARN V2 e Tez (consulte Interfaces da Web do Gateway de componentes).

  • flink:historyserver.archive.fs.dir=gs://bucket-name/*/flink-job-history/completed-jobs: Use esta propriedade para configurar o HistoryServer do Flink para monitorar um uma lista de diretórios separada por vírgulas.

  Exemplos de propriedades:

  --properties=spark:spark.history.fs.logDirectory=gs://bucket-name/*/spark-job-history
  

  --properties=mapred:mapreduce.jobhistory.read-only.dir-pattern=gs://bucket-name/*/mapreduce-job-history/done
  

  --properties=flink:flink.historyserver.archive.fs.dir=gs://bucket-name/*/flink-job-history/completed-jobs
  

Criar um cluster de job do Dataproc

É possível executar o seguinte comando em um terminal local ou no Cloud Shell para criar Cluster de jobs do Dataproc que executa jobs e grava arquivos de histórico de jobs um servidor de histórico permanente (PHS).

Para informações sobre diferentes formas de instalação, configurar e executar o Flink em um cluster do Dataproc, consulte Componente Flink opcional do Dataproc.

gcloud dataproc clusters create CLUSTER_NAME \
    --project=PROJECT \
    --region=REGION \
    --optional-components=COMPONENT \
    --enable-component-gateway \
    --properties=PROPERTIES \
    other args ...

• CLUSTER_NAME: especifica o nome do cluster de job.
• PROJECT: especifica o projeto associado ao cluster de job.
• REGION: especifique a região do Compute Engine onde o cluster de job vai estar localizado.
• --enable-component-gateway: essa sinalização ativa Gateway de componentes interfaces da Web no cluster de job.
• COMPONENT: use esta sinalização para instalar um ou mais componentes opcionais no cluster. Especificar o componente opcional FLINK para executar jobs do Flink. no cluster.

• PROPERTIES: adicionar um ou mais dos itens a seguir propriedades do cluster para definir locais não padrão do Cloud Storage relacionados ao PHS e outras propriedades do cluster de job.

  Observações:

  • Os exemplos de valor de propriedade nesta seção usam um "*" caractere curinga para permitir que o PHS correspondem a vários diretórios no bucket especificado gravados por clusters de job diferentes (mas consulte Considerações sobre a eficiência de caracteres curinga.
  • Nos exemplos a seguir, há sinalizações --properties separadas para ajudam na legibilidade. A prática recomendada ao usar gcloud dataproc clusters create para criar um Dataproc no Compute Engine cluster é usar uma sinalização --properties para especificar uma lista de propriedades separadas por vírgula (consulte formatação de propriedades do cluster).

  Propriedades:

  • yarn:yarn.nodemanager.remote-app-log-dir: Por padrão, os registros YARN agregados são ativados no job do Dataproc clusters e são gravados neles bucket temporário. Adicione esta propriedade para especificar um local diferente do Cloud Storage em que o cluster vai gravar registros de agregação para acesso pelo Persistent History Server.

    --properties=yarn:yarn.nodemanager.remote-app-log-dir=gs://bucket-name/directory-name/yarn-logs
    

  • spark:spark.history.fs.logDirectory e spark:spark.eventLog.dir: Por padrão, os arquivos do histórico de jobs do Spark são salvos no cluster temp bucket diretório /spark-job-history. É possível adicionar essas propriedades para especificar diferentes locais do Cloud Storage para esses arquivos. Se os dois forem usadas, elas precisam apontar para diretórios no mesmo bucket.

    --properties=spark:spark.history.fs.logDirectory=gs://bucket-name/directory-name/spark-job-history
    

    --properties=spark:spark.eventLog.dir=gs://bucket-name/directory-name/spark-job-history
    

  • mapred:mapreduce.jobhistory.done-dir e mapred:mapreduce.jobhistory.intermediate-done-dir: Por padrão, os arquivos de histórico de jobs do MapReduce são salvos no cluster temp bucket em /mapreduce-job-history/done e /mapreduce-job-history/intermediate-done diretórios. O mapreduce.jobhistory.intermediate-done-dir intermediário é um armazenamento temporário. os arquivos intermediários são movidos para a Local mapreduce.jobhistory.done-dir quando o job MapReduce for concluído. É possível adicionar essas propriedades para especificar locais para esses arquivos. Se ambas as propriedades forem usadas, elas deverão apontar para no mesmo bucket.

    --properties=mapred:mapreduce.jobhistory.done-dir=gs://bucket-name/directory-name/mapreduce-job-history/done
    

    --properties=mapred:mapreduce.jobhistory.intermediate-done-dir=gs://bucket-name/directory-name/mapreduce-job-history/intermediate-done
    

  • spark:spark.history.fs.gs.outputstream.type e spark:spark.history.fs.gs.outputstream.sync.min.interval.ms: Adicionar estes Conector do Cloud Storage para alterar as propriedades do modo como o cluster de job envia dados para o Cloud Storage. O spark:spark.history.fs.gs.outputstream.type padrão é BASIC, que envia dados para o Cloud Storage após a conclusão do job. Você pode mudar essa configuração para FLUSHABLE_COMPOSITE para alterar o comportamento de limpeza a fim de copiar dados para o Cloud Storage em em intervalos regulares enquanto o job está em execução.

    --properties=spark:spark.history.fs.gs.outputstream.type=FLUSHABLE_COMPOSITE
    

    O padrão spark:spark.history.fs.gs.outputstream.sync.min.interval.ms, que controla a frequência com que os dados são transferidos para o Cloud Storage, é 5000ms e pode ser alterado para um intervalo de tempo diferente de ms:

    --properties=spark:spark.history.fs.gs.outputstream.sync.min.interval.ms=intervalms
    

    Observação:para definir essas propriedades, o cluster de job do Dataproc versão de imagem precisa usar o conector do Cloud Storage versão 2.2.0 ou posterior. Você pode verificar a versão do conector instalada nas versões de imagem no Página Lista de versões de imagens do Dataproc.
  • dataproc:yarn.atsv2.bigtable.instance: depois de você Configurar o serviço de linha do tempo do Yarn v2, adicione esta propriedade para gravar dados da linha do tempo YARN no Instância do Bigtable para visualização no cluster PHS Interfaces da Web do YARN Application Linha do tempo V2 e do Tez. Observação: a criação do cluster falhará se a instância do Bigtable não existe.

    --properties=dataproc:yarn.atsv2.bigtable.instance=projects/project-id/instance_id/bigtable-instance-id
    

  • flink:jobhistory.archive.fs.dir: os arquivos do Flink JobManager Jobs Flink concluídos por meio do upload de informações de jobs arquivados em um diretório do sistema de arquivos. Use esta propriedade para definir o diretório do arquivo em flink-conf.yaml:

    --properties=flink:jobmanager.archive.fs.dir=gs://bucket-name/job-cluster-1/flink-job-history/completed-jobs
    

Usar PHS com cargas de trabalho em lote do Spark

Para usar o Persistent History Server com o Dataproc sem servidor para Cargas de trabalho em lote do Spark:

1. Crie um cluster do PHS.

2. Selecione ou especifique o cluster do PHS ao enviar uma carga de trabalho em lote do Spark;

Usar o PHS com o Dataproc no Google Kubernetes Engine

Para usar o Persistent History Server com Dataproc no GKE:

1. Crie um cluster do PHS.

2. Selecione ou especifique o cluster do PHS ao Crie um cluster virtual do Dataproc no GKE.

Interfaces da Web do Gateway de Componentes

No console do Google Cloud, pelo Dataproc Página Clusters, clique no nome do cluster do PHS para abrir a página Detalhes do cluster. Na guia Interfaces da Web, selecione os links Gateway do componente para abrir interfaces da Web em execução no cluster do PHS.

Observação: esses links de gateway de componente também são fornecidos. no console do Google Cloud para o cluster de job durante o ciclo de vida do cluster de jobs (consulte Como ver e acessar URLs do Gateway de Componentes).

Observação: o cluster PHS YARN ResourceManager e a Web do HDFS NameNode do Kubernetes não acessam e exibem dados.

Interface da Web do servidor de histórico do Spark

A captura de tela abaixo mostra a interface da Web do Spark History Server mostrando links para jobs do Spark executados no job-cluster-1 e job-cluster-2 após a configuração configure spark.history.fs.logDirectory e spark:spark.eventLog.dir dos clusters de job e os locais spark.history.fs.logDirectory do cluster do PHS da seguinte maneira:

job-cluster-1	gs://example-cloud-storage-bucket/job-cluster-1/spark-job-history
job-cluster-2	gs://example-cloud-storage-bucket/job-cluster-2/spark-job-history
phs-cluster	gs://example-cloud-storage-bucket/*/spark-job-history

Pesquisa de nomes de apps

Para listar jobs por nome de aplicativo na interface da Web do Spark History Server, digite o nome de um app na caixa de pesquisa. O nome do app pode ser definido de uma das seguintes maneiras: (listado por prioridade):

1. Dentro do código do aplicativo ao criar o contexto do Spark.
2. Definido pelo spark.app.name quando o job é enviado
3. Definido pelo Dataproc para o nome completo do recurso REST do job (projects/project-id/regions/region/jobs/job-id)

Os usuários podem inserir um termo de nome de app ou recurso na caixa Pesquisa para encontrar e listar vagas.

Logs de eventos

A interface da Web do Spark History Server oferece um botão Event Log que você pode clique para fazer o download dos logs de eventos do Spark. Esses registros são úteis para examinar o ciclo de vida do aplicativo Spark.

Jobs do Spark

Os aplicativos do Spark são divididos em vários jobs, que são divididos em vários estágios. Cada estágio pode ter várias tarefas, que são executadas em nós de executor (workers).

• Clique em um ID do app Spark na interface da Web para abrir a página "Jobs do Spark", que fornece um cronograma de eventos e um resumo dos jobs no aplicativo.

  

• Clique em um job para abrir a página "Detalhes do job" com um gráfico acíclico dirigido (DAG, na sigla em inglês) e um resumo dos estágios do job.

  

• Clique em um cenário ou use a guia Stages (Estágios) para selecionar um estágio para abri-lo Página de detalhes.

  

  A etapa inclui uma visualização do DAG, um cronograma do evento e métricas das tarefas na etapa. Use esta página para solucionar problemas relacionados a tarefas substituídas, atrasos no programador e erros de falta de memória. O visualizador do DAG mostra a linha de código derivada da etapa, ajudando a rastrear os problemas no código.

• Clique na guia Executores para obter informações sobre o nós do driver e do executor.

  

  Informações importantes nesta página incluem o número de núcleos e o número de tarefas executadas em cada executor.

  Se um aplicativo for executado lentamente, observe o tamanho das leituras e gravações aleatórias. Uma grande quantidade de dados pode prejudicar o desempenho.

Interface da Web do Tez

O Tez é o mecanismo de execução padrão para Hive e Pig no Dataproc. Enviar um job do Hive em um cluster de job do Dataproc inicia um Aplicativo Tez (consulte Como usar o Apache Hive no Dataproc .

Se você configurou o serviço de linha do tempo do Yarn v2 e definir a propriedade dataproc:yarn.atsv2.bigtable.instance quando você criou os clusters de jobs do Dataproc e do PHS, o YARN grava gerou dados do cronograma de jobs do Hive e Pig para o Bigtable especificado instância para recuperação e exibição na interface da Web do Tez em execução na Servidor PHS.

Observação: a guia Consultas do Hive não é compatível com a interface da Web do Tez em execução. no cluster do PHS.

Interface da Web YARN do cronograma V2 do aplicativo

Se você configurou o serviço de linha do tempo do Yarn v2 e definir a propriedade dataproc:yarn.atsv2.bigtable.instance quando você criou os clusters de jobs do Dataproc e do PHS, o YARN grava gerou dados do cronograma de jobs para a instância especificada do Bigtable para recuperação e aparecem na interface da Web do serviço YARN do Linha do Tempo do aplicativo YARN Servidor PHS. Os jobs do Dataproc estão listados em Atividade de fluxo na interface da Web.

Configurar o serviço de linha do tempo do Yarn v2

Para configurar o serviço de linha do tempo do Yarn v2, configure uma instância do Bigtable e, se necessário, verifique os papéis da conta de serviço da seguinte maneira:

1. Crie uma instância do Bigtable.

2. Verifique os papéis da conta de serviço, se necessário. O padrão Conta de serviço de VM usado por VMs de clusters do Dataproc tem as permissões necessárias para criar e configurar a instância do Bigtable do serviço de linha do tempo YARN. Se você criar o job ou o cluster PHS com uma conta de serviço de VM personalizada, a conta precisa ter Papel Administrator ou Bigtable User do Bigtable.

Esquema de tabela obrigatório

O suporte a PHS do Dataproc para Serviço de cronograma do YARN v2 requer a criação de um esquema específico instância do Bigtable. O Dataproc cria o conjunto de dados esquema quando um cluster de job ou de PHS é criado com o propriedade dataproc:yarn.atsv2.bigtable.instance definida para apontar para o instância do Bigtable.

Observação: se o esquema obrigatório da instância do Bigtable existir quando o dataproc:yarn.atsv2.bigtable.instance é enviada ao Dataproc, O Dataproc não vai criar o esquema.

Confira a seguir o esquema obrigatório da instância do Bigtable:

Tabelas	Grupos de colunas
prod.timelineservice.application	c,i,m
prod.timelineservice.app_flow	m
prod.timelineservice.entity	c,i,m
prod.timelineservice.flowactivity	i
prod.timelineservice.flowrun	i
prod.timelineservice.subapplication	c,i,m

Coleta de lixo do Bigtable

É possível configurar a Coleta de lixo do Bigtable baseada em idade para Tabelas ATSv2:

• Instalar cbt e (incluindo a criação do .cbrtc file).

• Crie a política de coleta de lixo com base na idade do ATSv2:

export NUMBER_OF_DAYS = number \
cbt setgcpolicy prod.timelineservice.application c maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.application i maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.application m maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.app_flow m maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.entity c maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.entity i maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.entity m maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.flowactivity i maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.flowrun i maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.subapplication c maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.subapplication i maxage=${NUMBER_OF_DAYS} \
cbt setgcpolicy prod.timelineservice.subapplication m maxage=${NUMBER_OF_DAYS}

Observações:

NUMBER_OF_DAYS: o número máximo de dias é 30d.