Serviços de tratamento de dados

Os Google Cloud serviços de dados abordados nesta página incluem os que processam dados fornecidos e produzem os resultados desse processamento, quer em resposta a um pedido, quer de forma contínua. Em vez de usar a disponibilidade e a latência como os SLIs principais para estes serviços, as opções mais adequadas são as seguintes:

  • Correção, uma medida de quantos erros de processamento o pipeline incorre.
  • Atualidade, uma medida da rapidez com que os dados são tratados.

Para mais informações sobre pipelines de dados na perspetiva da SRE, consulte o artigo Pipelines de processamento de dados no Site Reliability Engineering Workbook.

Pode expressar um SLI de correção baseado em pedidos usando a estrutura TimeSeriesRatio para configurar uma proporção de itens que tiveram problemas de processamento em relação a todos os itens processados. Decide como filtrar a métrica usando as etiquetas disponíveis para chegar à sua determinação preferida dos totais "problemáticos" e "válidos".

Exprime um SLI de atualização baseado em pedidos através de uma estrutura DistributionCut.

Dataflow

O Dataflow é um serviço de estatísticas de streaming totalmente gerido que minimiza a latência, o tempo de processamento e o custo. Pode usar o Dataflow para processar dados como uma stream ou em lotes através do SDK do Apache Beam.

Para mais informações, consulte o seguinte:

INSs de correção

O Dataflow escreve dados de métricas no Cloud Monitoring através do tipo de recurso monitorizado dataflow_job e do tipo de métrica job/element_count, que contabiliza o número de elementos adicionados à pcollection até agora. A soma da etiqueta do recurso job_name dá-lhe o número de elementos a serem processados pela tarefa.

Em alternativa, pode usar o tipo de métrica logging.googleapis.com/log_entry_count com o tipo de recurso monitorizado dataflow_job para contabilizar o número de erros registados por uma tarefa específica, usando a etiqueta de métrica severity.

Pode usar estas métricas para expressar um SLI de correção baseado em pedidos como uma fração de erros e todos os elementos processados usando uma estrutura TimeSeriesRatio, conforme mostrado no exemplo seguinte:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"dataflow.googleapis.com/job/element_count\"
         resource.type=\"dataflow_job\"
         resource.label.\"job_name\"=\"my_job\"",
      "badServiceFilter":
        "metric.type=\"logging.googleapis.com/log_entry_count\"
         resource.type=\"dataflow_job\"
         resource.label.\"job_name\"=\"my_job\"
         metric.label.\"severity\"=\"error\"",
    }
  }
}

INSs de atualização

O Dataflow também escreve dados de métricas no Cloud Monitoring usando o tipo de recurso monitorizado dataflow_job e o tipo de métrica job/per_stage_system_lag, que mede a duração máxima atual durante a qual um item de dados foi processado ou está a aguardar processamento.

Pode expressar um SLI de atualização usando esta métrica com uma estrutura DistributionCut.

O exemplo de SLO seguinte espera que o elemento de dados mais antigo seja processado em menos de 100 segundos 99% das vezes durante um período contínuo de uma hora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"dataflow.googleapis.com/job/per_stage_system_lag\"
           resource.type=\"dataflow_job\"
           resource.label.\"job_name\"=\"my_job\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% data elements processed under 100 s"
}

Também pode expressar um SLI de atualização usando uma estrutura WindowsBasedSli.

O exemplo de SLO seguinte espera que 99% das janelas de cinco minutos durante um período de um dia contínuo não vejam (zero) elementos processados em mais de 100 segundos:

{
  "displayName": "Dataflow - windowed freshness",
  "serviceLevelIndicator": {
    "windowsBased": {
      "windowPeriod": "300s",
      "metricMeanInRange": {
        "timeSeries":
          "metric.type=\"dataflow.googleapis.com/job/per_stage_system_lag\"
           resource.type=\"dataflow_job\"
           resource.label.\"job_name\"=\"my_job\"",
        "range": {
          "min": "0",
          "max": "100"
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "86400s"
}

Tenha em atenção que, para uma janela ser considerada "boa", a métrica não pode exceder o limite especificado em range em nenhum momento durante a janela de avaliação.

Dataproc

O Dataproc oferece um cluster totalmente gerido e criado especificamente que pode ser dimensionado automaticamente para suportar qualquer tarefa de processamento de dados ou de análise do Hadoop ou do Spark.

Para mais informações, consulte o seguinte:

INSs de correção

O Dataproc escreve dados métricos no Cloud Monitoring através do tipo de recurso monitorizado cloud_dataproc_cluster e dos seguintes tipos de métricas:

Pode usar estas métricas para expressar um INS de correção baseado em pedidos como uma proporção, TimeSeriesRatio, de tarefas com falhas para todas as tarefas enviadas, conforme mostrado no exemplo seguinte:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"dataproc.googleapis.com/cluster/job/submitted_count\"
         resource.type=\"cloud_dataproc_cluster\"
         resource.label.\"cluster_name\"=\"my_cluster\"",
      "badServiceFilter":
        "metric.type=\"dataproc.googleapis.com/cluster/job/failed_count\"
         resource.type=\"cloud_dataproc_cluster\"
         resource.label.\"cluster_name\"=\"my_cluster\"",
    }
  }
}

INSs de atualização

O Dataproc também escreve dados métricos no Cloud Monitoring usando o tipo de recurso monitorizado cloud_dataproc_cluster e os seguintes tipos de métricas:

  • cluster/job/duration, que mede o tempo que as tarefas permanecem nos estados de processamento. Pode filtrar os dados na etiqueta da métrica state para identificar o tempo gasto em estados específicos. Por exemplo, pode criar um SLI que meça o tempo que os trabalhos estão no estado PENDING, para definir um tempo de espera máximo permitido antes de o trabalho começar a ser processado.
  • cluster/job/completion_time, que mede quanto tempo as tarefas permanecem na métrica cluster/job/completion_time. Use quando a conclusão da tarefa for uma métrica bem compreendida ou quando o volume de dados processados pelas tarefas num cluster não variar, o que afetaria o tempo de processamento.

Pode expressar um SLI de atualização usando estas métricas com uma estrutura DistributionCut, como mostrado nos exemplos seguintes.

O SLO de exemplo seguinte usa cluster/job/duration e espera que 99% dos trabalhos em "my_cluster" estejam no estado PENDING durante menos de 100 segundos num período contínuo de 24 horas:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"dataproc.googleapis.com/cluster/job/duration\"
           resource.type=\"cloud_dataproc_cluster\"
           resource.label.\"cluster_name\"=\"my_cluster\"
           metric.label.\"state\"=\"PENDING\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "86400s",
  "displayName": "Dataproc pending jobs"
}

O SLO de exemplo seguinte usa cluster/job/completion_time e espera que 99% dos trabalhos em "my_cluster" sejam concluídos em menos de 100 segundos durante um período contínuo de 24 horas:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"dataproc.googleapis.com/cluster/job/completion_time\"
           resource.type=\"cloud_dataproc_cluster\"
           resource.label.\"cluster_name\"=\"my_cluster\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "86400s",
  "displayName": "Dataproc completed jobs"
}