Professional Cloud Data Engineer
professional-cloud-data-engineer
Gauge your current knowledge
Gauge your current knowledge
professional-cloud-data-engineer
Gauge your current knowledge
Gauge your current knowledge
ETL (Extract, Transform, Load) and ELT (Extract, Load, Transform) are two main ways to process data, and the choice between them affects cost, speed, and how much work is involved. The key difference is when the data gets cleaned up or changed. In ETL, you transform the data using a separate processing engine before you put it into the final storage like a data warehouse. In ELT, you load the raw data directly into the warehouse first and then use the warehouse's own powerful engine to do the transformations after it's loaded.
On Google Cloud, this means choosing between programmatic tools and declarative services. Programmatic ETL uses code written in frameworks like Apache Spark or Apache Beam, which run on services such as Cloud Dataproc or Cloud Dataflow. This gives you maximum control for very complex or custom logic, especially with data that isn't neatly structured in tables. The trade-off is higher complexity because you must manage the underlying compute clusters, their scaling, and the code itself.
Declarative ELT uses BigQuery SQL and User-Defined Functions (UDFs) to transform data right inside BigQuery. This approach is very efficient for most business logic that can be expressed in SQL and leverages BigQuery's serverless, scalable engine. It greatly reduces operational work since there are no clusters to manage. However, it is less suited for extremely complex, non-relational logic or for data that is too messy to load into the warehouse's structure in the first place.
You choose based on your data and needs. Use ELT for structured data and SQL-friendly transformations where you want lower operational overhead. Use ETL for unstructured data, complex custom logic, or when you need to clean data before it can fit into the warehouse schema. Often, a hybrid approach works best: an initial ETL stage using Dataflow or Dataproc cleans and structures raw data from Cloud Storage, then loads it into BigQuery where further, powerful ELT transformations are done with SQL.
Orchestration automates the coordination of multiple tasks or systems into a complete workflow. In data engineering, these workflows are often described as DAGs (Directed Acyclic Graphs), which show the order of tasks and their dependencies. Dependencies can create patterns: fan-in (multiple pipelines feeding into one) and fan-out (one pipeline triggering many). Poorly managed dependencies can cause cascading failures, where one pipeline's problem stops all the pipelines that depend on it.
Cloud Composer is a managed service for Apache Airflow, designed for orchestrating complex, long-running data pipelines. You define workflows by writing Airflow DAGs in Python, using specialized components like operators (which define a single task), sensors (which wait for a condition to be met), and mechanisms to share data between tasks. Cloud Composer handles the scheduling, execution, and monitoring, removing the need to manage the Airflow infrastructure yourself. DAGs are stored in a Cloud Storage bucket and are automatically picked up by the service.
Google Cloud Workflows is a serverless orchestration service better suited for lightweight, event-driven tasks, especially those involving microservices. It uses a simple YAML-based definition to describe a series of steps. Workflows are triggered by events or schedules (using Cloud Scheduler) and execute with low latency. Choose Workflows when you need to quickly chain together API calls or services without the overhead of a full Airflow environment. It is not meant for the complex dependencies and long runtimes typical of large-scale data pipelines.
When building orchestration, start by moving existing workflows to the cloud without major changes. Then, analyze the dependencies to see which tasks can run in parallel to speed up overall execution. Finally, refactor by pulling common tasks out into shared, reusable DAGs. The decision between Cloud Composer and Workflows hinges on complexity: use Cloud Composer for intricate data pipelines with many interdependent tasks, and use Workflows for simpler, faster orchestrations of services.
Cloud Dataflow is the serverless runner for pipelines written using the Apache Beam SDK. A key feature of Beam is its unified model, meaning you can write your data transformation logic once and run it on both streaming (real-time) and batch (historical) data. Dataflow handles the underlying infrastructure, using techniques like Vertical Autoscaling to adjust worker memory on the fly and prevent failures.
To build effective pipelines, you must handle advanced data distribution challenges. A hot key occurs when too much data is grouped under a single key, causing one worker to become a bottleneck. You can fix this by re-distributing the data using transforms like ParDo to create new, more balanced keys. For aggregation steps, you can use the withFanout parameter to spread the computational load. Tools like Job Visualizer and Cloud Profiler help you monitor pipeline execution to find and fix these performance issues.
Robust pipeline design also involves using structured data and managed connectors. Apache Beam's Managed I/O connectors simplify reading from and writing to services like BigQuery and data lake formats like Apache Iceberg. For example, a streaming pipeline can use these connectors to perform Change Data Capture (CDC), reading new changes from an Iceberg table and automatically writing the processed results to a target table with a defined schema. This managed approach reduces the custom code needed for integration.
Finally, these data transformation pipelines are often steps in a larger workflow. They need to be orchestrated alongside other tasks. Services like Cloud Composer (for general data workflows) or Vertex AI Pipelines (for machine learning workflows) can execute these multi-step DAGs. They manage the order, handle failures, and ensure that your batch and streaming processing jobs are triggered reliably and their results are passed correctly to the next stage.