Serviços de processamento de dados

Os serviços de dados do Google Cloud discutidos nesta página incluem os que processam dados fornecidos e geram os resultados desse processamento, seja em resposta a uma solicitação ou continuamente. Em vez de usar disponibilidade e latência como SLIs principais para esses serviços, as opções mais apropriadas são as seguintes:

  • Correção, uma medida de quantos erros de processamento o pipeline gera.
  • Atualização, uma medida da velocidade de processamento dos dados.

Para mais informações sobre pipelines de dados na perspectiva do SRE, consulte Pipelines de processamento de dados no manual de engenharia de confiabilidade do site.

Para expressar um SLI com base em solicitações, use a estrutura TimeSeriesRatio para configurar uma classificação de itens que tiveram problemas de processamento para todos os itens processados. Você decide como filtrar a métrica usando os rótulos disponíveis para chegar à determinação preferida dos totais "com problema" e "válidos".

Para expressar um SLI de atualização baseado em solicitações, use uma estrutura DistributionCut.

Dataflow

O Dataflow é um serviço de análise de streaming totalmente gerenciado que minimiza a latência, o tempo de processamento e o custo. É possível usar o Dataflow para processar dados como stream ou em lotes usando o SDK do Apache Beam.

Para mais informações, consulte os seguintes tópicos:

SLIs de correção

O Dataflow grava dados de métricas no Cloud Monitoring usando o tipo de recurso monitorado dataflow_job e o tipo de métrica job/element_count, que conta o número de elementos adicionados à PCollection. A soma no rótulo de recurso job_name fornece o número de elementos a serem processados pelo job.

Separadamente, é possível usar o tipo de métrica logging.googleapis.com/log_entry_count com o tipo de recurso monitorado dataflow_job para contar o número de erros registrados por um job específico, usando o rótulo de métrica severity.

É possível usar essas métricas para expressar um SLI de correção com base em solicitações como uma fração de erros e todos os elementos processados por meio de uma estrutura TimeSeriesRatio, conforme mostrado no exemplo a seguir:

"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\"",
    }
  }
}

SLIs de atualização

O Dataflow também grava dados de métricas no Cloud Monitoring usando o tipo de recurso monitorado dataflow_job e o tipo de métrica job/per_stage_system_lag, que mede a duração máxima atual que um item de dados tem processado ou aguardado para processar.

Expresse um SLI de atualização com essa métrica usando uma estrutura DistributionCut.

O SLO de exemplo a seguir espera que o elemento de dados mais antigo seja processado em menos de 100 segundos em 99% do tempo 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 é possível expressar um SLI de atualização usando uma estrutura WindowsBasedSli.

O SLO de exemplo a seguir espera que 99% das janelas de cinco minutos em um período de um dia inteiro não exibam elementos (zero) 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"
}

Para que uma janela seja 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 fornece um cluster personalizado, totalmente gerenciado, que pode ser escalonado automaticamente para dar suporte a qualquer job de processamento de dados ou análise do Hadoop ou Spark.

Para mais informações, consulte os seguintes tópicos:

SLIs de correção

O Dataproc grava dados de métricas no Cloud Monitoring usando o tipo de recurso monitorado cloud_dataproc_cluster e os seguintes tipos de métricas:

É possível usar essas métricas para expressar um SLI de correção com base em solicitações como uma proporção, TimeSeriesRatio, de jobs com falha para todos os jobs enviados, conforme mostrado no exemplo a seguir:

"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\"",
    }
  }
}

SLIs de atualização

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

  • cluster/job/duration, que mede quanto tempo os jobs permanecem em estado de processamento. É possível filtrar os dados no rótulo de métrica state para identificar o tempo gasto em estados específicos. Por exemplo, é possível criar um SLI que mede quanto tempo os jobs estão no estado PENDING para definir um tempo de espera máximo permitido antes que o job comece a ser processado.
  • cluster/job/completion_time, que mede quanto tempo os jobs permanecem na métrica cluster/job/completion_time. Use quando a conclusão do job for uma métrica bem compreendida ou quando o volume de dados processados pelos jobs em um cluster não variar, o que afetaria o tempo de processamento.

É possível expressar um SLI de atualização com essas métricas usando uma estrutura DistributionCut, como mostrado nos exemplos a seguir.

No exemplo a seguir, o SLO usa cluster/job/duration e espera que 99% dos jobs em "my_cluster" estejam no estado PENDING por menos de 100 segundos em um 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"
}

No exemplo a seguir, o SLO usa cluster/job/completion_time e espera que 99% dos jobs em "my_cluster" sejam concluídos em menos de 100 segundos em 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"
}