Google Cloud now lets you call the standard logging module from within a BigQuery Python UDF, and those logs appear automatically in Cloud Logging. The change removes the need for custom exporters or side‑car services, enabling row‑level observability directly at query time—a practical benefit for anyone building or operating data pipelines.
Python UDF Logging Overview
The new feature expands the execution environment of BigQuery Python UDFs to include the standard library’s logging facilities. When a UDF emits logging.error() or logging.warning(), the runtime formats the message as structured JSON and writes it to the built‑in _AllLogs view. No additional configuration, plugins, or connectors are required.
Implementation Steps
Below is a minimal, production‑ready UDF that validates incoming JSON payloads, logs diagnostic information on failure, and returns NULL for bad rows.
CREATE OR REPLACE FUNCTION `YOUR_PROJECT.YOUR_DATASET.safe_parse_json`(
raw_payload STRING,
required_key STRING
)
RETURNS STRING
LANGUAGE python
OPTIONS (
entry_point='safe_parse_json',
runtime_version='python-3.11'
)
AS '''
import json
import logging
def safe_parse_json(raw_payload, required_key):
if not raw_payload or raw_payload.strip() == "":
logging.warning(json.dumps({"error_type": "EMPTY_PAYLOAD"}))
return None
try:
data = json.loads(raw_payload)
if required_key and (required_key not in data or data[required_key] is None):
logging.error(json.dumps({
"error_type": "MISSING_REQUIRED_KEY",
"missing_key": required_key,
"raw_payload": raw_payload[:200]
}))
return None
return json.dumps(data)
except Exception as e:
logging.error(json.dumps({
"error_type": "JSON_SYNTAX_ERROR",
"error_message": str(e),
"raw_payload": raw_payload[:200]
}))
return None
''' ;
Typical usage in an ingestion query looks like:
SELECT safe_parse_json(payload, 'event_id') AS clean_json FROM `raw_events`;
Rows that fail validation generate structured log entries, which can be queried later via:
SELECT * FROM `region-us`.INFORMATION_SCHEMA._AllLogs WHERE jsonPayload.error_type IS NOT NULL;
Operational and Security Considerations
- Alerting. Cloud Monitoring can create a log‑based metric on
error_typeand fire alerts when error rates exceed a threshold. - Isolation of bad data. Because the UDF returns
NULLon error, downstream SQL can filter out problematic rows without aborting the whole query. - Replay workflow. Quarantined payloads remain in the source table; engineers can re‑run the validation after fixing data issues, using the same UDF.
- Log retention and access. Logs are stored in Cloud Logging with the same retention policies as other logs. Access control follows IAM on the logging service, so ensure appropriate roles for the teams that will query
_AllLogs. - Performance impact. Emitting logs adds minimal overhead compared to a pure SQL UDF, but the cost of additional log ingestion should be accounted for in budgeting.
Related CloudNinjas coverage: Google Cloud.
What This Means For Practitioners
Adopt the native Python UDF logging pattern when you need fine‑grained visibility into data validation or transformation steps inside BigQuery. Define a single reusable UDF that logs structured error objects, set up a log‑based metric for real‑time alerting, and use the _AllLogs view for post‑mortem analysis or data recovery. Evaluate the added log volume against your monitoring budget, and verify that IAM policies on Cloud Logging restrict log access to authorized personnel. This approach streamlines observability without introducing external dependencies, making it a pragmatic addition to resilient data pipelines.


