Skip to content

Watching and coordinating a pipeline's moving parts

Data pipeline orchestration on Google Cloud is primarily handled by Cloud Composer (managed Apache Airflow), which schedules and coordinates dependencies across GCP services like Dataflow, BigQuery, and Dataproc. Monitoring relies on Cloud Monitoring and Cloud Logging for metrics, dashboards, alerting, and log-based troubleshooting across pipeline components.

1 · Learn the must-know

  • Cloud Composer uses DAGs (Directed Acyclic Graphs) written in Python to define task dependencies and scheduling, running on a managed Google Kubernetes Engine cluster.
  • Dataflow jobs automatically emit metrics to Cloud Monitoring (e.g., system lag, data freshness, throughput) without additional instrumentation, and these can be viewed in the Dataflow job monitoring UI or custom dashboards.
  • Cloud Monitoring alerting policies can trigger notifications (via channels like email, Pub/Sub, or PagerDuty) when pipeline metrics breach thresholds, such as high system lag or failed job counts.
  • Cloud Logging aggregates logs from Dataflow, Dataproc, BigQuery, and Composer, and supports log-based metrics and sinks for exporting logs to BigQuery or Cloud Storage for further analysis.
  • A common gotcha is that Composer environments have their own Airflow web UI and scheduler health metrics separate from the DAG task-level logs, so both environment health and task execution must be monitored independently.
  • For event-driven or serverless orchestration without needing full Airflow capabilities, Cloud Functions or Workflows can trigger and chain pipeline steps based on events like new files in Cloud Storage or Pub/Sub messages.

2 · Check your understanding

Check this objectiveFree · always available

A streaming Dataflow pipeline reads from Pub/Sub, applies windowed aggregations, and writes results to BigQuery. Occasionally the pipeline falls behind the incoming data rate, and downstream dashboards start showing stale results. The team wants a Cloud Monitoring alerting policy that fires specifically when the pipeline is falling behind on processing, not merely when workers are busy. Which metric should the alert be based on?

Your objective map0 tried · 0 answered correctly · 67 untouched

What you have tried across GCP PDE's objectives, not a readiness score.

Designing data processing systems~22% of the exam0 of 17 tried
Ingesting and processing the data~25% of the exam0 of 11 tried
Storing the data~20% of the exam0 of 13 tried
Preparing and using data for analysis~15% of the exam0 of 11 tried
Maintaining and automating data workloads~18% of the exam0 of 15 tried

3 · Keep going