The data practitioner role on Google Cloud

Birchline Outfitters is halfway through moving its data warehouse from an aging SQL Server box in the head-office server room to BigQuery. The cloud migration team has already built the projects, networks and billing structure, and Owen Mitchell's Workspace rollout is under way. The data itself, though, still needs people who understand it: where each file comes from, what each column means, which numbers can be trusted and how fresh they must be. That work belongs to Ravi Menon's analytics team, and this course follows its newest member as he learns to do it on Google Cloud.

Mateo Alvarez joined Birchline two years ago as a store sales analyst. He knows the business well. He can tell you which stores sell the most kayaks in May, why the warehouse in Groveport ships more on Mondays, and how a returned tent shows up in the weekly report. Until now he has worked mostly in spreadsheets and in SQL queries against the old warehouse. Ravi has asked him to become the team's first certified data practitioner, so that someone on the team can prepare and load data on Google Cloud without waiting for the platform engineers. Mateo plans to sit the Associate Data Practitioner exam in the spring of 2027.

Ravi set up twice-weekly sessions on Tuesday and Thursday afternoons, starting on October 6, 2026. This course follows the first twelve, which cover the first section of the exam: preparing and ingesting data. Later courses cover analysis and presentation (GCP-221), pipelines and data management (GCP-222), and exam readiness (GCP-194).

What a data practitioner does

A data practitioner sits between the people who build data platforms and the people who use data to make decisions. Platform or data engineers design the large pipelines, the streaming systems and the shared infrastructure. Analysts and business users ask questions and read dashboards. The practitioner does the everyday work that connects the two: finding the right data, checking whether it is complete and correct, cleaning it, loading it into the right place, and making it ready for analysis. On a small team, as at Birchline, the same person may also build simple scheduled pipelines and manage access to the datasets they look after.

Ravi describes the job in terms of questions the practitioner must be able to answer for any dataset on the team:

• Where does it come from, and how does it get here? (source system, file or stream, transfer tool)
• What does it look like? (format, schema, data types, size, how often it changes)
• Can it be trusted? (completeness, accuracy, duplicates, freshness)
• What has to happen to it before anyone uses it? (cleaning, standardizing, joining, aggregating)
• Where should it live, and for how long? (storage service, location, storage class, retention)
• Who may see it, and how will we know if something goes wrong? (access, monitoring, quality checks)

Each of those questions maps onto a part of the exam. This course concentrates on the first five, and leaves most of the last one to GCP-222.

The Associate Data Practitioner exam

Google's exam guide groups the exam into four sections. The weights below are approximate, as the guide gives them, and they tell Mateo where to spend his study time. Preparation and ingestion is the largest single section, which is why the team starts here.

Within the first section, the guide lists two groups of skills. The first is preparing and processing data: telling ETL, ELT and ETLT apart, choosing a data transfer tool, assessing data quality and cleaning data. The second is extracting and loading data into storage systems: recognizing data formats, choosing an extraction tool, selecting a storage solution (including the type of location, such as regional, dual-region, multi-region or zonal), classifying data as structured, semi-structured or unstructured, and loading data with the right tool. Every lesson in this course maps to one or more of those skills, and lesson 12 brings them together in a lab.

The certification page lists the practical details. The exam lasts two hours and has 50 to 60 multiple choice and multiple select questions. It is offered in English and Japanese, online with a remote proctor or at a testing center, and the certification is valid for three years. The registration fee is 125 US dollars plus tax. Google recommends about six months of hands-on experience with data on Google Cloud, which is one reason Ravi wants Mateo doing real work on Birchline's data rather than only reading.

Three ways to arrange the work: ETL, ELT and ETLT

Every data job involves three activities: extracting data from a source, transforming it into a useful shape, and loading it into a destination. The order of those activities is a design choice, and the exam expects you to know the three common patterns.

In ETL (extract, transform, load), data is transformed before it reaches the destination. A processing tool such as Dataflow or Cloud Data Fusion reads the source, cleans and reshapes the data, and writes only the finished result. ETL suits cases where raw data must not land in the destination at all, for example because it contains fields that must be removed first, or where the transformations are heavy and better done by a processing engine.

In ELT (extract, load, transform), raw data is loaded first, usually into BigQuery, and then transformed inside the destination with SQL. This has become the most common pattern on Google Cloud because BigQuery can transform large tables quickly, the raw data stays available for re-processing if a rule turns out to be wrong, and analysts can write and review the transformations themselves. Tools such as Dataform and BigQuery data preparation are built for this pattern.

In ETLT (extract, transform, load, transform), a light transformation happens on the way in and the heavier work happens after loading. The first transformation usually handles things that must happen early: masking or removing sensitive fields, fixing file encodings, or converting a format so that it can be loaded at all. The second stage does the business logic in the warehouse.

Ravi's rule of thumb for the team is "ELT unless there is a reason not to". Loading raw data first and keeping it means that when a cleaning rule is wrong, the team can fix the rule and re-run it instead of asking a store to resend last month's files. The reasons not to are real, though: personal data that should never sit in a raw table, streams that need to be acted on in seconds, and files that cannot be loaded until they are converted.

A map of the services

Google Cloud has many data services, and much of the exam is about choosing between them. Mateo finds it helps to sort them by the job they do rather than by name. Lessons later in the course look at each in detail.

Two services appear in almost every lesson. Cloud Storage is object storage: it holds files of any kind in buckets, and it is usually the first place data lands when it arrives from outside. BigQuery is Google's serverless data warehouse: it stores tables and runs SQL over them without anyone managing servers, and it is where most of Birchline's prepared data will live.

Birchline's data estate

In the first session, Ravi and Mateo list the data sources the team is responsible for. The inventory is rough, but it gives every later lesson a real example to work with.

The table already shows why one tool will not do everything. Nightly store files suit a batch load. The shop database changes all day and is wanted within the hour, which points toward change data capture. Web events arrive continuously and some uses need them within a minute, which points toward streaming. The old warehouse is a one-time bulk move. Choosing the approach for each is the subject of lesson 5.

Mateo also notices that the estate mixes three kinds of data. Store sales and orders are structured: fixed columns with fixed types. Returns exports and web events are semi-structured: JSON records whose fields can vary from one record to the next. Product photos and scanned supplier invoices are unstructured: files whose content has no columns at all. The kind of data affects where it is stored and how it is loaded, and lesson 2 returns to it.

Sizing the work

Before choosing tools, Ravi asks Mateo to estimate how much data the nightly store files add each month, because the answer affects storage cost and how long loads take. Mateo uses an average row size measured from a sample file.

# Rough monthly volume of the nightly store sales files.
stores = 40
rows_per_store_per_night = 750      # average from last month's files
bytes_per_row = 180                 # measured from a sample CSV file
nights = 30

rows = stores * rows_per_store_per_night * nights
megabytes = rows * bytes_per_row / 1_000_000
print(f"Rows per month: {rows:,}")
print(f"Size per month: about {megabytes:,.0f} MB")
print(f"Size per year:  about {megabytes * 12 / 1000:,.1f} GB")

Rows per month: 900,000
Size per month: about 162 MB
Size per year:  about 1.9 GB

A gigabyte or two a year is tiny for BigQuery. The lesson for Mateo is that store sales are not a big data problem; they are a reliability problem. Forty files must arrive every night, in the expected format, without duplicates, and the team must know by eight in the morning if one is missing. Web events are the opposite: small individually but numerous, at about 2 million a day, and their challenge is volume and speed.

Working practices for the team

Ravi sets out a few practices that the rest of the course builds on. They are not Google rules, but they reflect how experienced teams use the services.

• Land raw data unchanged in a landing bucket or raw dataset, and keep it for an agreed time, so loads can be re-run.
• Separate raw, staging and curated data. At Birchline these become the BigQuery datasets raw, staging and curated in the project bl-data-prod.
• Keep data in the same location throughout a pipeline: us-east5 (Columbus, Ohio), so that loads and queries do not cross regions.
• Write every transformation down, preferably as SQL kept in version control, so that anyone can see how a number was produced.
• Check data quality at every stage, and treat a failed check as an incident, not an inconvenience.

The location rule matters for more than speed. Birchline keeps customer data in US regions, and cardholder data falls under PCI DSS wherever it is stored, so every bucket and dataset that holds customer information is created in a US region. Columbus is the primary region and Council Bluffs, Iowa, the second region for backups. Several states have their own consumer privacy laws, which Teresa Okonjo's security team tracks.