Understand the Cloud Billing data tables in BigQuery (original) (raw)

This document provides reference information for the schema of the Cloud Billing data that's exported to each table in BigQuery.

Shortly afterenabling Cloud Billing export to BigQuery, billing data tables are automatically created in the BigQuery dataset.

Frequency of data loads

FOCUS, standard, and detailed usage cost export

Pricing and CUD metadata export

Data availability

Limitations

Exporting Cloud Billing data to BigQuery is subject to the following limitations.

Table schema for the Cloud Billing data exports

The table schema for any of the Cloud Billing data exports can change.

When the table schema changes, such as when new fields are added to a BigQuery table schema for a Cloud Billing data export, any queries that directly reference the exported columns might fail. To resolve this, we recommend creatingBigQuery viewsthat query the exported tables and present the information in your preferred structure.

You can then adjust the queries that feed your reports and dashboards to pull from the views, instead of the exported tables. By using views, you can standardize the structure of the data used in your queries and dashboards.

The views you create should normalize the data so that all of the relevant tables present the same schema to your queries. This protects you from future schema changes, allowing you to modify the view's underlying query in those instances when the data schema changes.

FOCUS export and data retention

Billing data exported to the Google-provided FOCUS BigQuery export is subject to a 2-year Time To Live (TTL) policy. Data older than two years is automatically deleted from the provided FOCUS export table in the BigQuery dataset. If you need to retain your FOCUS billing data history beyond two years, copy the FOCUS data to a long-term storage table that you own.

BigQuery dataset locations and data availability

BigQuery dataset locations supported for use with Cloud Billing data:

BigQuery datasetsare configured to use alocation; either a multi-region location (EU or US), or a region location. The dataset location is set at creation time. After a dataset is created, its location can't be changed.

Cloud Billing data export supports all multi-region locations (EU or US), but only a subset of region locations. When you're configuring your Cloud Billing export settings, if you create or select a dataset that's configured to use an unsupported region location, when you attempt to save your export settings, you'll see an_Invalid dataset region_ error.

The following table lists themulti-region locationsand the region locationsthat are supported for use with BigQuery datasets that contain Cloud Billing data.

Americas Asia Pacific Europe Middle East
Multi-region: US Regions: northamerica-northeast1 (Montréal) southamerica-east1 (São Paulo) us-central1 (Iowa) us-east1 (South Carolina) us-east4 (Northern Virginia) us-west1 (Oregon) us-west2 (Los Angeles) us-west3 (Salt Lake City) us-west4 (Las Vegas) Regions: asia-east1 (Taiwan) asia-east2 (Hong Kong) asia-northeast1 (Tokyo) asia-northeast2 (Osaka) asia-northeast3 (Seoul) asia-south1 (Mumbai) asia-southeast1 (Singapore) asia-southeast2 (Jakarta) australia-southeast1 (Sydney) Multi-region: EU Regions: europe-central2 (Warsaw) europe-north1 (Finland) europe-west1 (Belgium) europe-west2 (London) europe-west3 (Frankfurt) europe-west4 (Netherlands) europe-west6 (Zurich) Regions: me-central1 (Doha) me-central2 (Dammam) me-west1 (Tel Aviv)

Locations and data availability:

Disable, re-enable, or edit export settings

If youdisable,re-enable, or edit your export settingsto update the project or dataset where your exported billing data is stored, previously exported billing data isn't backfilled to your new dataset. To include the billing information that was exported prior to switching to a different project or dataset, you must manually join the new dataset with the previous dataset. For more information, seeJoin operation.

Dataset encryption

BigQuery datasetsare configured to useencryption at restby setting an encryption key option when you create the dataset – either a Google-owned and Google-managed encryption key, or a customer-managed encryption key (CMEK). The dataset encryption option can only be set at creation time. After a dataset is created, its encryption setting can't be changed.

If you already enabled the Cloud Billing data export to BigQuery, and your dataset is configured to use a Google-managed encryption key, you can use the bq command-line tool to enable CMEK on each table in the dataset. BigQuery will automatically use thedataset default keyto protect the export tables, unless you configure it otherwise.

Learn about enabling CMEK for BigQuery tables.

Row level security

If you want to useBigQuery row-level securityon the table that contains your exported data, you must give the Cloud Billing export service accountbilling-export-bigquery@system.gserviceaccount.comfull access to the tableusing the BigQuery TRUE filter. The following command grants access to the Cloud Billing service account:

CREATE ROW ACCESS POLICY cloud_billing_export_policy
ON `__project_id__.__dataset_id__.__table_id__`
GRANT TO ('serviceAccount:billing-export-bigquery@system.gserviceaccount.com')
FILTER USING (TRUE);

FOCUS or detailed usage cost data and GKE

When exporting FOCUS usage cost data or detailed usage cost data, the export automatically includes resource-level information about Compute Engine and other services. However, for Google Kubernetes Engine (GKE) data, to view a breakdown of GKE cluster costs in a FOCUS or detailed data export, you must alsoenable cost allocation for GKE.

Resource-level tags

Resource-level Tagsmight take up to an hour to propagate to BigQuery exports. If a tag was added or removed within an hour, or if a resource has existed for less than an hour, it might not appear in the export.

Resource-level tags are available for several resources in thestandard usage cost exportand thedetailed usage cost export.