Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developers.google.com/bigquery/docs/external-data-bigtable below:

Query Bigtable data | BigQuery

Stay organized with collections Save and categorize content based on your preferences.

This document describes how to use BigQuery to query data stored in a Bigtable external table. For information on how to query data directly from Bigtable, see GoogleSQL for Bigtable overview.

Bigtable is Google's sparsely populated NoSQL database that can scale to billions of rows, thousands of columns, and petabytes of data. For information on the Bigtable data model, see Storage model.

Before you begin, you or an administrator in your organization must create an external table for you to use. For details and required permissions, see Create a BigQuery external table.

To query Bigtable external tables, ensure you have the following roles.

• BigQuery Data Viewer (roles/bigquery.dataViewer)
• BigQuery User (roles/bigquery.user)
• Bigtable Reader (roles/bigtable.reader)

Depending on your permissions, you can grant these roles to yourself or ask your administrator to grant them to you. For more information about granting roles, see Viewing the grantable roles on resources.

To see the exact BigQuery permissions that are required to query external tables, expand the Required permissions section:

You might also be able to get these permissions with custom roles or other predefined roles.

You can run a query against a permanent external Bigtable table exactly as if it were a standard BigQuery table, subject to the limitations on external data sources. For more information, see Run interactive and batch queries.

Querying an external data source using a temporary table is useful for one-time, ad-hoc queries over external data, or for extract, transform, and load (ETL) processes.

To query an external data source without creating a permanent table, you provide a table definition for the temporary table, and then use that table definition in a command or call to query the temporary table. You can provide the table definition in any of the following ways:

• A table definition file
• An inline schema definition
• A JSON schema file

The table definition file or supplied schema is used to create the temporary external table, and the query runs against the temporary external table.

When you use a temporary external table, you do not create a table in one of your BigQuery datasets. Because the table is not permanently stored in a dataset, it cannot be shared with others.

Using a temporary external table instead of a permanent external table has some limitations, including the following:

• You must have the Bigtable Admin (roles/bigtable.admin) role.
• This approach does not let you use the Google Cloud console to infer the schema of the Bigtable table and automatically create the table definition. You must create the table definition yourself.

To query Bigtable temporary external tables, ensure you have the following roles:

• BigQuery Data Viewer (roles/bigquery.dataViewer)
• BigQuery User (roles/bigquery.user)
• Bigtable Admin (roles/bigtable.admin)

Depending on your permissions, you can grant these roles to yourself or ask your administrator to grant them to you. For more information about granting roles, see Viewing the grantable roles on resources.

To see the exact BigQuery permissions that are required to query external tables, expand the Required permissions section:

You might also be able to get these permissions with custom roles or other predefined roles.

To query Bigtable data using a temporary external table, you:

• Create a table definition file
• Submit both a query and a table definition file

Creating and querying a temporary external table is supported by the bq command-line tool and the API.

To query a temporary table using a table definition file, enter the bq query command with the --external_table_definition flag.

(Optional) Supply the --location flag and set the value to your location.

bq --location=LOCATION query \
--use_legacy_sql=false \
--external_table_definition=TABLE::DEFINITION_FILE \
'QUERY'

Replace the following:

• LOCATION: the name of your location. The --location flag is optional.
• TABLE: the name of the temporary table you're creating.
• DEFINITION_FILE: the path to the table definition file on your local machine.
• QUERY: the query you're submitting to the temporary table.

For example, the following command creates and queries a temporary table named follows using a table definition file named follows_def.

bq query \
--use_legacy_sql=false \
--external_table_definition=follows::/tmp/follows_def \
'SELECT
  COUNT(rowkey)
 FROM
   follows'

• Create a query. See Querying data for information about creating a query job.

• (Optional) Specify your location in the location property in the jobReference section of the job resource.

• Specify the external data source properties by setting the ExternalDataConfiguration for the table resource.

Before trying this sample, follow the Java setup instructions in the BigQuery quickstart using client libraries. For more information, see the BigQuery Java API reference documentation.

To authenticate to BigQuery, set up Application Default Credentials. For more information, see Set up authentication for client libraries.

The performance of queries against Bigtable external data sources depends on three factors:

• The number of rows
• The amount of data read
• The extent of parallelization

BigQuery tries to read as little data as possible by only reading the column families that are referenced in the query. The extent of parallelization depends on how many nodes you have in your Bigtable cluster and how many splits you have for your table.

Note that Bigtable auto-merges splits based on load. If your table is not being read frequently, there will be fewer splits over time and a gradual degradation in query performance. For more information, see How BigQuery optimizes your data over time.

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

When you query your Bigtable data from BigQuery, you have the following options for compute:

• Cluster nodes, which is the default.
• Data Boost (Preview), a serverless compute option that lets you isolate your analytics traffic without impacting the application serving-traffic that your clusters' nodes are handling.

To use Data Boost, you or your administrator must create a definition file that specifies a Data Boost app profile in the Bigtable URI. For more information, see Create a Bigtable external table.

If you don't use Data Boost, be aware that querying Bigtable from BigQuery consumes Bigtable CPU cycles. CPU consumption by BigQuery when using provisioned nodes for compute might affect latency and throughput for other concurrent requests such as live user traffic serving. For example, high CPU usage on Bigtable affects long-tail queries and increases latency at the 99th percentile.

As a result, you should monitor Bigtable CPU usage to verify that you're within the recommended bounds as noted on the Bigtable monitoring dashboard in the Google Cloud console. Increasing the number of nodes for your instance lets you handle both BigQuery traffic and traffic from other concurrent requests.

Queries with a row equality filter only read that specific row. For example, in GoogleSQL syntax:

SELECT
  COUNT(follows.column.name)
FROM
  `dataset.table`
WHERE
  rowkey = "alice";

Range filters such as rowkey > '1' and rowkey < '8' are also supported, but only when rowkey is read as a string with the readRowkeyAsString option.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["This document details how to use BigQuery to query data stored in Bigtable, either through permanent or temporary external tables."],["Querying permanent external Bigtable tables requires roles such as BigQuery Data Viewer, BigQuery User, and Bigtable Reader, while temporary external tables require BigQuery Data Viewer, BigQuery User, and Bigtable Admin roles."],["Temporary external tables are ideal for one-time queries or ETL processes, allowing users to query external data without permanently storing it in BigQuery datasets."],["Performance of BigQuery queries on Bigtable depends on factors such as the number of rows, the amount of data read, and the extent of parallelization, with Bigtable CPU consumption potentially impacting other traffic."],["Queries can be filtered, with row equality filters reading only specific rows, and range filters supported when row keys are read as strings using the `readRowkeyAsString` option."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4