Servidor de histórico permanente do Dataproc

Informações gerais

O servidor de histórico permanente (PHS, na sigla em inglês) do Dataproc fornece interfaces da Web para exibir o histórico de jobs executados em clusters ativos ou excluídos do Dataproc. Ele está disponível na versão da imagem 1.5 e posteriores do Dataproc e é executado em um cluster de nó único do Dataproc. Ele fornece interfaces da Web para os seguintes arquivos e dados:

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

• Arquivos do histórico de jobs Flink. 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 pelo YARN Timeline Service v2 e armazenados em uma instância do Bigtable.

• Registros de agregação do SOY

O servidor de histórico permanente acessa e exibe os arquivos de histórico de jobs do Spark e do MapReduce, os arquivos de histórico de jobs Flink e os arquivos de registro do Crashlytics 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 PHS está localizado. Além disso, a versão da imagem do cluster do PHS e a versão da imagem dos clusters de job do Dataproc precisam ser correspondentes. Por exemplo, é possível usar um cluster PHS de versão de imagem do Dataproc 2.0 para visualizar arquivos do histórico de jobs executados em clusters desse tipo que estavam localizados no projeto em que o cluster PHS está.

• Um cluster PHS não é compatível com o Kerberos e a autenticação pessoal.

Também é possível ver o histórico e os dados do job por meio das interfaces da Web do Gateway de componentes do Dataproc em execução em um cluster do Dataproc. Esses arquivos de histórico de jobs e interfaces da Web no cluster não são mantidos após a exclusão do cluster.

Criar um cluster PHS do Dataproc

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

Para informações sobre diferentes maneiras de criar um cluster do Dataproc, incluindo o uso do console do Google Cloud, das bibliotecas de cliente do Cloud e da 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: especifica o nome do cluster PHS.
• PROJECT: especifica o projeto a ser associado ao cluster PHS. Esse projeto precisa ser o mesmo que o projeto associado ao cluster que executa os jobs. Consulte Criar um cluster de jobs do Dataproc.
• REGION: especifique uma região do Compute Engine em que o cluster PHS estará localizado.
• --single-node: um cluster PHS é um cluster de nó único do Dataproc.
• --enable-component-gateway: essa sinalização ativa as interfaces da Web do Gateway de componentes no cluster do PHS.
• COMPONENT: use essa sinalização para instalar um ou mais componentes opcionais no cluster. Especifique o componente opcional FLINK para executar o serviço da Web Flink HistoryServer no cluster PHS para ver os arquivos do histórico de jobs do Flink.
• PROPERTIES. Especifique uma ou mais propriedades do cluster.

• Se quiser, adicione a sinalização --image-version para especificar a versão da imagem do cluster do PHS. A versão da imagem PHS precisa corresponder à versão de 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 corresponda a vários diretórios no bucket especificado gravado por diferentes clusters de jobs. Consulte Considerações de eficiência de caracteres curinga.
  • Sinalizações --properties separadas são mostradas nos exemplos abaixo para ajudar na legibilidade. A prática recomendada ao usar gcloud dataproc clusters create para criar um cluster do Dataproc no Compute Engine é usar uma sinalização --properties para especificar uma lista de propriedades separadas por vírgulas. Consulte Como formatar as propriedades do cluster.

  Propriedades:

  • yarn:yarn.nodemanager.remote-app-log-dir=gs://bucket-name/*/yarn-logs: adicione essa propriedade para especificar o local do Cloud Storage em que o PHS acessará os registros do Crashlytics gravados pelos clusters do job.

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

    Nos clusters do Dataproc 2.0+, as duas propriedades a seguir também precisam ser definidas para ativar os registros de histórico do Spark PHS. Consulte Opções de configuração do servidor de histórico do Spark. O valor 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 essa propriedade para ativar o histórico de jobs do MapReduce persistente. Essa propriedade especifica o local do Cloud Storage em que o PHS vai 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 Configurar o Yarn Timeline Service v2, adicione essa propriedade para usar o cluster PHS para visualizar os dados da linha do tempo nas interfaces da Web do YARN Application Timeline Service 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 essa propriedade para configurar o Flink HistoryServer para monitorar 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 jobs do Dataproc

Execute o comando a seguir em um terminal local ou no Cloud Shell para criar um cluster de jobs do Dataproc que execute jobs e grave arquivos de histórico de jobs em um servidor de histórico permanente (PHS).

Para informações sobre diferentes maneiras de instalar, 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 em que o cluster de job estará localizado.
• --enable-component-gateway: essa sinalização ativa as interfaces da Web do Gateway de componentes no cluster do job.
• COMPONENT: use essa sinalização para instalar um ou mais componentes opcionais no cluster. Especifique o componente opcional FLINK para executar jobs do Flink no cluster.

• PROPERTIES: adicione uma ou mais das propriedades de cluster a seguir para definir locais do Cloud Storage não padrão relacionados a PHS e outras propriedades de cluster de jobs.

  Observações:

  • Os exemplos de valor de propriedade nesta seção usam um caractere curinga "*" para permitir que o PHS corresponda a vários diretórios no bucket especificado gravado por diferentes clusters de jobs. Consulte Considerações de eficiência de caracteres curinga.
  • Sinalizações --properties separadas são mostradas nos exemplos abaixo para ajudar na legibilidade. A prática recomendada ao usar gcloud dataproc clusters create para criar um cluster do Dataproc no Compute Engine é usar uma sinalização --properties para especificar uma lista de propriedades separadas por vírgulas. Consulte Como formatar as propriedades do cluster.

  Propriedades:

  • yarn:yarn.nodemanager.remote-app-log-dir: por padrão, os registros agregados do Crashlytics são ativados nos clusters de jobs do Dataproc e gravados no bucket temporário do cluster. Adicione essa 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 de histórico de jobs do Spark são salvos no cluster temp bucket no diretório /spark-job-history. É possível adicionar essas propriedades para especificar diferentes locais do Cloud Storage para esses arquivos. Se as duas propriedades forem usadas, elas precisarão 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 nos diretórios /mapreduce-job-history/done e /mapreduce-job-history/intermediate-done. O local mapreduce.jobhistory.intermediate-done-dir intermediário é um armazenamento temporário. Os arquivos intermediários são movidos para o local mapreduce.jobhistory.done-dir quando o job do MapReduce é concluído. É possível adicionar essas propriedades para especificar diferentes locais do Cloud Storage para esses arquivos. Se as duas propriedades forem usadas, elas precisarão apontar para diretórios 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: adicione essas propriedades do conector do Cloud Storage para alterar o comportamento padrão de como o cluster de jobs envia dados ao Cloud Storage. O spark:spark.history.fs.gs.outputstream.type padrão é BASIC, que envia dados ao Cloud Storage após a conclusão do job. É possível alterar essa configuração para FLUSHABLE_COMPOSITE a fim de alterar o comportamento de limpeza para copiar dados para o Cloud Storage em intervalos regulares enquanto o job está em execução.

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

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

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

    Observação: para definir essas propriedades, a versão da imagem do cluster de jobs do Dataproc precisa usar a versão 2.2.0 ou posterior do conector do Cloud Storage. Verifique a versão do conector instalada nas versões da imagem na página Lista de versões de imagem do Dataproc.
  • dataproc:yarn.atsv2.bigtable.instance: depois de configurar o Yarn Timeline Service v2, adicione essa propriedade para gravar os dados da linha do tempo do Crashlytics na instância do Bigtable especificada para visualização nas interfaces da Web YARN Application Timeline Service V2 e Tez do cluster PHS. Observação: a criação do cluster falhará se a instância do Bigtable não existir.

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

  • flink:jobhistory.archive.fs.dir: os arquivos do Flink JobManager concluíram jobs do Flink fazendo upload das informações deles para um diretório do sistema de arquivos. Use essa propriedade para definir o diretório de 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 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 servidor de histórico permanente com o Dataproc no GKE:

1. Crie um cluster PHS.

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

Interfaces da Web do Gateway de componentes

No console do Google Cloud, na página Clusters do Dataproc, clique no nome do cluster PHS para abrir a página Detalhes do cluster. Na guia Interfaces da Web, selecione os links do Gateway do componente para abrir as 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 job. Consulte Como visualizar e acessar URLs do Gateway de componentes.

Observação :as interfaces da Web YARN ResourceManager e HDFS NameNode do cluster PHS não acessam e exibem dados.

Interface da Web do Spark History Server

A captura de tela a seguir mostra a interface da Web do servidor de histórico do Spark mostrando links para jobs do Spark executados em job-cluster-1 e job-cluster-2 depois de configurar os locais spark.history.fs.logDirectory, spark:spark.eventLog.dir e 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 do app na interface da Web do Spark History Server, insira o nome de um app na caixa de pesquisa. O nome do app pode ser definido de uma das seguintes maneiras (listadas por prioridade):

1. Dentro do código do aplicativo ao criar o contexto do Spark.
2. Definido pela propriedade 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 Pesquisar para encontrar e listar jobs.

Logs de eventos

A interface da Web do Spark History Server fornece um botão Event Log em que você pode clicar 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 uma linha do tempo de eventos e um resumo das tarefas 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 uma etapa ou use a guia "Stages" para selecionar uma etapa e abrir a página "Detalhes da fase".

  

  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 "Executors" (Executores) para ver informações sobre os nós do driver e do executor do aplicativo Spark.

  

  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. O envio de um job Hive em um cluster de jobs do Dataproc inicia um aplicativo Tez. Consulte Como usar o Apache Hive no Dataproc .

Se você configurou o Yarn Timeline Service v2 e definiu a propriedade dataproc:yarn.atsv2.bigtable.instance ao criar os clusters de jobs PHS e Dataproc, o Crashlytics gravará os dados do cronograma de jobs do Hive e Pig gerados na instância do Bigtable especificada para recuperação e exibição na interface da Web do Tez em execução no 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 do Application Timeline V2

Se você configurou o Yarn Timeline Service v2 e definiu a propriedade dataproc:yarn.atsv2.bigtable.instance ao criar os clusters de jobs do PHS e do Dataproc, o Crashlytics gravará os dados do cronograma do job gerados na instância do Bigtable especificada para recuperação e exibição na interface da Web do Application Timeline Service do AAPT em execução no servidor PHS. Os jobs do Dataproc são listados na guia Atividade de fluxo na interface da Web.

Configurar o Yarn Timeline Service v2

Para configurar o Yarn Timeline Service v2, configure uma instância do Bigtable e, quando 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. A conta de serviço de VM padrão usada pelas VMs de cluster do Dataproc tem as permissões necessárias para criar e configurar a instância do Bigtable para o serviço Lighthouse Timeline. Se você criar o job ou o cluster PHS com uma conta de serviço de VM personalizada, será necessário que ela tenha o papel do Bigtable Administrator ou Bigtable User.

Esquema de tabela obrigatório

O suporte a PHS do Dataproc para o serviço de linha do tempo do Yarn v2 requer um esquema específico criado na instância do Bigtable. O Dataproc cria o esquema necessário quando um cluster de job ou cluster PHS é criado com a propriedade dataproc:yarn.atsv2.bigtable.instance definida para apontar para a instância do Bigtable.

Observação :se o esquema de instância necessário do Bigtable existir quando a propriedade dataproc:yarn.atsv2.bigtable.instance for enviada ao Dataproc, o Dataproc não criará o esquema.

Veja 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 com base na idade para tabelas ATSv2:

• Instale o cbt, incluindo a criação do .cbrtc file.

• Crie a política de coleta de lixo baseada em 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.