DEV Community: Ben Watson

Deeper into Dataform 3: Auditing Dataform

Ben Watson — Sat, 06 Jun 2026 12:20:44 +0000

It's important to monitor Dataform - jobs executed by Dataform can be the primary source of BigQuery costs in a modern data platform. Forgetting to incrementalise a table, using a table instead of a view in the wrong place or performing complex window functions on a large table can all incur large costs and long run times.

Using the WorkflowInvocationAction for each job we can extract its BigQuery Job ID, then extract key metadata for each BigQuery job by querying INFORMATION_SCHEMA.JOBS_BY_PROJECT, before writing the output back to BigQuery so that it can be analysed (maybe even by transforming it in Dataform).

from google.cloud import dataform_v1
from google.cloud import bigquery
from datetime import datetime

# ------------------------------------------------------------
# CONFIG
# ------------------------------------------------------------
PROJECT_ID = "my-project"
REGION = "europe-west2"
REPOSITORY_ID = "analytics"
WORKFLOW_INVOCATION_ID = "123456789"
BQ_REGION = "region-europe-west2"
OUTPUT_TABLE = "my-project.raw_dataform_monitoring.raw_dataform_bigquery_metrics"

# ------------------------------------------------------------
# CLIENTS
# ------------------------------------------------------------
dataform = dataform_v1.DataformClient()
bq = bigquery.Client(project=PROJECT_ID)

repository = dataform.repository_path(
    PROJECT_ID,
    REGION,
    REPOSITORY_ID
)

invocation_name = f"{repository}/workflowInvocations/{WORKFLOW_INVOCATION_ID}"


# ------------------------------------------------------------
# 1. GET WORKFLOW INVOCATION ACTIONS → EXTRACT JOB IDS
# ------------------------------------------------------------
job_ids = set()

actions = dataform.list_workflow_invocation_actions(
    parent=invocation_name
)

for action in actions:
    # only BigQuery actions contain job metadata
    if hasattr(action, "bigquery_action") and action.bigquery_action:
        if action.bigquery_action.job_id:
            job_ids.add(action.bigquery_action.job_id)

job_ids = list(job_ids)

print(f"Found {len(job_ids)} BigQuery jobs")


# ------------------------------------------------------------
# 2. SINGLE BIGQUERY QUERY FOR ALL JOBS
# ------------------------------------------------------------
if not job_ids:
    print("No jobs found.")
    exit()

job_filter = ",".join([f'"{jid}"' for jid in job_ids])

query = f"""
SELECT
  job_id,
  creation_time,
  start_time,
  end_time,
  state,
  total_bytes_processed,
  total_bytes_billed,
  total_slot_ms,
  reservation_id
FROM `{BQ_REGION}.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id IN ({job_filter})
  AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR)
"""

results = bq.query(query).result()


# ------------------------------------------------------------
# 3. WRITE TO MONITORING TABLE
# ------------------------------------------------------------
rows = []

for job in results:
    runtime = None
    if job.start_time and job.end_time:
        runtime = (job.end_time - job.start_time).total_seconds()

    rows.append({
        "job_id": job.job_id,
        "workflow_invocation_id": WORKFLOW_INVOCATION_ID,
        "creation_time": job.creation_time,
        "start_time": job.start_time,
        "end_time": job.end_time,
        "runtime_seconds": runtime,
        "state": job.state,
        "bytes_processed": job.total_bytes_processed,
        "bytes_billed": job.total_bytes_billed,
        "slot_ms": job.total_slot_ms,
        "reservation_id": job.reservation_id,
        "ingested_at": datetime.utcnow().isoformat()
    })

errors = bq.insert_rows_json(OUTPUT_TABLE, rows)

if errors:
    print("Insert errors:", errors)
else:
    print(f"Wrote {len(rows)} rows to {OUTPUT_TABLE}")

Note that INFORMATION_SCHEMA.JOBS_BY_PROJECT is only queried once, rather than being called per job. JOBS_BY_PROJECT can be a huge table, especially if the same project is being queried by high-usage BI tools. Make sure to use the creation_time partition column to reduce query costs.

This auditing can be automatically triggered by creating a log sync that pushes to a PubSub and triggers a Cloud Function running the above code whenever a Workflow Execution completes.

What I Learned From Building a Data Mesh

Ben Watson — Mon, 01 Jun 2026 18:03:55 +0000

Early on in my time as the tech lead of a central data team I realised that central data ownership wasn't a sustainable model. Central ownership had been hugely effective in helping my team to quickly build a trusted single source of truth and create a company-wide data culture and governance around it, but as we matured we quickly reached data overload.

The small team of analysts and engineers were expected to be subject matter experts on every possible domain, making it difficult to prioritise demands and not always putting expertise in the hands of those who best understand the data.

When I'm talking about data ownership I mean responsibilities such as:

Ingesting and storing raw data
Transforming and modelling data
Defining, documenting and exposing gold layer data
Owning BI content
Being the point of contact for queries on data

I looked to a data mesh model - transferring data ownership to domain teams. This process took about 18 months. What I learned is that scaling data ownership isn't about removing the central data team, it's about changing its role from owning data to enabling others to own it safely.

1. Start with teams who want data ownership

There will always be some teams that are reluctant to own their own data, maybe due to seeing it as an additional workload, requiring new skillsets that they don't possess, or simply that they're happy with a system that currently works well enough.

Instead, approach a team who have a problem that could be solved by joining the data mesh. In my case this was a team who wanted to be able to refresh their data on demand as one middle step in a larger workflow. At the time it wasn't possible to easily do this in the single data platform, but it would be possible if they owned their own data. The mesh had its first "client" and they were excited about it!

From here it was easy to demonstrate value, and the early success created momentum. Suddenly more teams wanted in, and eventually this approach became the natural way for teams to manage their data.

2. Turn the central data team into a product team

Data ownership alone isn't enough. If every domain team has to build ingestion, testing, monitoring and deployment capabilities from scratch, the organisation simply replaces one bottleneck with many smaller ones.

Build a Data Platform as a Product by bundling together all of the central data team's useful tools into an easily-deployable package. Think:

Tools for ingesting data
CI/CD pipelines - useful as they allow for all changes to pass through a standardised set of checks and validations
Automated testing
Data quality checks
Cost and performance monitoring
Scheduling
Alerting
Dictionary and contract service integrations (more on these in section 4)

Deploy this product to mesh teams and keep them involved. Make the roadmap visible, ask for feature requests, create a community of teams for asking questions and giving feedback, and make versioned releases.

The analysts in the central data team can then also become more product-focused and take on an ownership role of the BI tool, defining dashboard standards and owning key, centralised dashboards (such as "home page" dashboards that aggregate critical business-wide metrics).

3. Be opinionated about what gets shared

It's not possible or desirable to dictate how others work. Allow other teams to retain flexibility in how they handle their internal processes. You'll quickly encounter friction if you force everyone to ingest data using the same method, or to deduplicate using the same lines of SQL, or to name all raw data tables the same way.

Instead, only be strict on shared outputs. Gold layer data should meet company-wide standards, including:

Documentation (including refresh times, ownership and support channels)
Data quality standards
Naming conventions

This inevitably creates some variation between teams, but that's often a worthwhile trade-off for allowing domains to optimise for their own needs while still producing consistent shared outputs.

Enforce this automatically where possible, such as with CI/CD hooks that require all columns in a table to be documented, or that ensure that primary keys are actually primary.

4. Discovery and contracts aren't optional

A data dictionary and data contract service are both vital as data becomes more distributed. A data dictionary is required because if nobody can find a dataset, they'll rebuild it. A data contract service is required as if nobody knows who's consuming a dataset, they'll break it. Discoverability is key.

A central, visible repository of what data is available and who is consuming it help keep data safe, and provide that consolidating, standardising layer where it matters the most.

Consider automating these where possible. For the dictionary this could be a daily job that runs across all gold layer tables in the data mesh, extracting metadata and informing mesh teams where their data doesn't meet the expected standards. For the data contract service this could be a job that scans access logs and automatically identifies consumers (people, teams and services), alongside a CI/CD hook that informs engineers if they're making a change that will break the schema of a contracted table.

These services are also useful for the central data team, enabling a single-pane-of-glass through which the entire mesh can be viewed.

5. Maintain a single access point for data queries

Once technology teams own their own data, business users may be unsure who to contact about different dashboards and datasets, lowering trust in data and reducing data visibility. Instead, maintain a single access point for data queries, and implement processes to ensure that requests are distributed to the correct teams. This could be as simple as a Slack channel that uses emoji reaction workflows to ping the relevant team.

Conclusion

As is demonstrated by the above points, a successful data mesh is created by distributing ownership while centralising standards, tooling and discoverability.

The role of the central data team changes from building pipelines to enabling others to do so safely and consistently. Domain expertise moves closer to the data, bottlenecks are reduced, and the platform becomes more scalable without sacrificing trust.

Deeper into Dataform 2: Other API features

Ben Watson — Sun, 24 May 2026 15:03:00 +0000

In part 1 we looked at the Dataform CompilationResult and WorkflowInvocation objects. Let's follow up with a quick look at some other API endpoints that I find useful.

Workspace management - `delete_workspace` and `create_workspace`

delete_workspace is essential for Dataform instances used by large teams as it allows workspaces to be automatically deleted post-merge, saving the bi-annual "can everyone please let me know which workspaces they're finished with?" message. This can be integrated into CI/CD tools such as GitHub Actions.

from google.cloud import dataform_v1

client = dataform_v1.DataformClient()

workspace_path = client.workspace_path(
    PROJECT_ID,
    REGION,
    REPOSITORY_ID,
    WORKSPACE_ID,
)

try:
    operation = client.delete_workspace(name=workspace_path)

There's also create_workspace - very useful for automatically creating a workspace if a code change is made on a new branch outside of the Dataform UI.

Git operations - `push_git_changes` and `pull_git_changes`

Another set of useful endpoints that allow code changes to be automatically applied outside of the Dataform UI:

from google.cloud import dataform_v1

client = dataform_v1.DataformClient()

workspace_path = client.workspace_path(
    project_id,
    region,
    repository_id,
    workspace_id,
)

# ------------------------------------------------------------
# 1. Pull latest changes from Git into the workspace
# ------------------------------------------------------------
print("Pulling latest Git changes into workspace...")

pull_request = dataform_v1.PullGitChangesRequest(
    name=workspace_path
)

pull_operation = client.pull_git_changes(request=pull_request)
print("Pull initiated:", pull_operation.operation.name)

# Optional: wait for completion (simplified polling)
pull_result = pull_operation.result()
print("Pull completed successfully")

# ------------------------------------------------------------
# (Optional) 2. Make programmatic changes here
# ------------------------------------------------------------
# e.g. update config blocks, inject variables, generate models, format SQL, etc.

print("Applying automated workspace changes...")

# ------------------------------------------------------------
# 3. Push workspace changes back to Git
# ------------------------------------------------------------
print("Pushing workspace changes to Git...")

push_request = dataform_v1.PushGitChangesRequest(
    name=workspace_path
)

push_operation = client.push_git_changes(request=push_request)
push_result = push_operation.result()
print("Push completed successfully")
print("Workspace successfully synced with Git")

Deeper into Dataform 1: Exploring the API

Ben Watson — Sun, 24 May 2026 15:02:20 +0000

Series overview

This series of blog posts is aimed at Dataform users who are looking to explore beyond its core functionality. Among other things we'll dig into Dataform's powerful API, create automated CI/CD processes in GitHub Actions, build pipelines to monitor costs, and modify the config {} block through code.

Dataform's API is the natural starting point for diving into Dataform's more powerful and less-documented capabilities. Understanding of the API allows users to utilise Dataform as the all-powerful hub of an automated modern data platform.

Dataform API key concepts

The API has two objects that serve as essential components of any workflow:

CompilationResult - the compiled state of a Dataform workspace at a specific point in time (the result of building the DAG).
WorkflowInvocation - a single execution of a CompilationResult (the result of running the DAG).

`CompilationResult`

from google.cloud import dataform_v1

client = dataform_v1.DataformClient()

project_id = "my-project"
region = "europe-west2"
repository_id = "analytics"
workspace_id = "dev"

workspace = client.workspace_path(
    project_id,
    region,
    repository_id,
    workspace_id,
)

repository = client.repository_path(
    project_id,
    region,
    repository_id,
)

compilation_result = dataform_v1.CompilationResult(
    workspace=workspace
)

response = client.create_compilation_result(
    parent=repository,
    compilation_result=compilation_result,
)

print(response.name)

The response takes the form projects/<project_id>/locations/<region>/repositories/<repository_id>/compilationResults/<compilation_result_id> (where <compilation_result_id> is a UUID v4).

A CompilationResult object is generated in the Dataform UI each time a code change is detected, although the UI conceals its ID. The ID can be seen in the Executions page in the UI following a run.

The CompilationResult includes information about each job inside the Dataform workspace, allowing users to traverse the DAG through code and extract information such as the config {} block of each file. Each job can then be iterated over via:

request = dataform_v1.QueryCompilationResultActionsRequest(
    name=COMPILATION_RESULT
)
response = client.query_compilation_result_actions(
    request=request
)
for action in response.compilation_result_actions:
    ...

`WorkflowInvocation`

from google.cloud import dataform_v1

client = dataform_v1.DataformClient()

project_id = "my-project"
region = "europe-west2"
repository_id = "analytics"

repository = client.repository_path(
    project_id , region, repository_id 
)

# compilation_result comes from the previous snippet
invocation = dataform_v1.WorkflowInvocation(
    compilation_result=compilation_result.name
)

response = client.create_workflow_invocation(
    parent=repository,
    workflow_invocation=invocation,
)

print(f'{response.name}: {response.state}')

A WorkflowInvocation is generated in the Dataform UI each time an Execution is run:

The WorkflowInvocation includes information about each job that has been executed, allowing users to tie jobs to their BigQuery job IDs, and see the objects created (such as tables or views). Each executed job can be iterated over via:

request = dataform_v1.QueryWorkflowInvocationActionsRequest
    name=WORKFLOW_INVOCATION
)
response = client.query_workflow_invocation_actions(
    request=request
)
for action in response.workflow_invocation_actions:
    ...

Tying them together

The real power of Dataform’s API emerges when these two objects are combined. A typical workflow looks like this:

A workspace is updated (manually or via Git),
A CompilationResult is generated from the workspace,
A WorkflowInvocation is created from that compilation,
BigQuery executes the resulting DAG.

With just these two objects it's possible to automate building and running Dataform DAGs outside of the Dataform UI. This enables easy CI/CD pipelines, which we'll cover in a later post.