Pengantar tabel eksternal BigLake

Dokumen ini berisi ringkasan tentang BigLake dan mengasumsikan Anda telah memahami tabel database dan Identity and Access Management (IAM). Untuk membuat kueri data yang disimpan di penyimpanan data yang didukung, Anda harus terlebih dahulu membuat tabel BigLake, lalu membuat kuerinya menggunakan sintaksis GoogleSQL:

Anda juga dapat mengupgrade tabel eksternal ke BigLake. Untuk mengetahui informasi selengkapnya, baca Mengupgrade tabel eksternal ke BigLake.

Tabel BigLake memungkinkan Anda membuat kueri data terstruktur di penyimpanan data eksternal dengan delegasi akses. Delegasi akses akan memisahkan akses ke tabel BigLake dari akses ke penyimpanan data yang mendasarinya. Koneksi eksternal yang terkait dengan akun layanan digunakan untuk terhubung ke penyimpanan data. Akun layanan menangani pengambilan data dari penyimpanan data, maka Anda hanya perlu memberi pengguna akses ke tabel BigLake. Hal ini memungkinkan Anda menerapkan keamanan yang mendetail di level tabel, termasuk keamanan tingkat baris dan tingkat kolom. Untuk tabel BigLake berdasarkan Cloud Storage, Anda juga dapat menggunakan penyamaran data dinamis. Untuk mempelajari lebih lanjut solusi analisis multi-cloud yang menggunakan tabel BigLake dengan data Amazon S3 atau Blob Storage, lihat BigQuery Omni.

Penyimpanan data yang didukung

Anda dapat menggunakan tabel BigLake dengan penyimpanan data berikut:

Dukungan tabel sementara

Tabel BigLake berdasarkan Cloud Storage dapat bersifat sementara atau permanen. Tabel BigLake yang didasarkan pada Amazon S3 atau Blob Storage harus bersifat permanen.

Beberapa file sumber

Anda dapat membuat tabel BigLake berdasarkan beberapa sumber data eksternal, asalkan sumber data tersebut memiliki skema yang sama.

Gabungan lintas cloud

Join lintas cloud memungkinkan Anda menjalankan kueri yang mencakup region Google Cloud dan BigQuery Omni. Anda dapat menggunakan operasi JOIN GoogleSQL untuk menganalisis data di berbagai solusi penyimpanan, seperti AWS, Azure, set data publik, dan layanan Google Cloud lainnya. Penggabungan lintas cloud menghilangkan kebutuhan untuk menyalin data di seluruh sumber sebelum menjalankan kueri.

Anda dapat mereferensikan tabel BigLake di mana saja dalam pernyataan SELECT seolah-olah tabel tersebut adalah tabel BigQuery standar, termasuk dalam pernyataan bahasa manipulasi data (DML) dan bahasa definisi data (DDL) yang menggunakan subkueri untuk mengambil data. Anda dapat menggunakan beberapa tabel BigLake dari cloud dan tabel BigQuery yang berbeda dalam kueri yang sama. Semua tabel BigQuery harus berasal dari region yang sama.

Izin yang diperlukan untuk bergabung lintas cloud

Untuk mendapatkan izin yang diperlukan guna menjalankan join lintas cloud, minta administrator untuk memberi Anda peran IAM BigQuery Data Editor (roles/bigquery.dataEditor) pada project tempat join dijalankan. Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

Peran bawaan ini berisi izin yang diperlukan untuk menjalankan join lintas cloud. Untuk melihat izin yang benar-benar diperlukan, luaskan bagian Izin yang diperlukan:

Izin yang diperlukan

Izin berikut diperlukan untuk menjalankan penggabungan lintas cloud:

  • bigquery.datasets.create
  • bigquery.tables.create

Anda mungkin juga bisa mendapatkan izin ini dengan peran khusus atau peran bawaan lainnya.

Join lintas cloud membuat set data dengan awalan __bigquery_xregion_sink_ dan tabel sementara dalam set data ini, sehingga untuk hanya memberikan akses ke resource yang dibuat oleh join lintas cloud, gunakan kondisi resource.name.startsWith untuk jenis resource Table dan Dataset.

Untuk mengetahui informasi lebih lanjut tentang peran dan izin IAM di BigQuery, baca Pengantar IAM.

Biaya join lintas cloud

Saat Anda menjalankan operasi join lintas cloud, BigQuery akan mengurai kueri menjadi bagian lokal dan jarak jauh. Bagian lokal diperlakukan sebagai kueri standar di region BigQuery. Bagian jarak jauh dikonversi menjadi operasi CREATE TABLE AS SELECT (CTAS) pada tabel BigLake yang direferensikan di region BigQuery Omni, yang membuat tabel sementara di region BigQuery Anda. BigQuery kemudian menggunakan tabel sementara ini untuk menjalankan join lintas cloud dan menghapus tabel secara otomatis setelah delapan jam.

Anda akan dikenai biaya transfer data untuk data dalam tabel BigLake yang dirujuk. Namun, BigQuery membantu mengurangi biaya ini dengan hanya mentransfer kolom dan baris dalam tabel BigLake yang direferensikan dalam kueri, bukan seluruh tabel. Sebaiknya tentukan filter kolom yang sempit untuk lebih mengurangi biaya transfer. Tugas CTAS muncul di histori tugas Anda dan menampilkan informasi seperti jumlah byte yang ditransfer. Transfer yang berhasil akan menimbulkan biaya meskipun tugas kueri utama gagal. Untuk informasi selengkapnya, lihat harga BigQuery Omni.

Perhatikan kueri berikut sebagai contoh:

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

Contoh ini memiliki dua transfer: satu dari tabel karyawan (dengan filter level) dan satu dari tabel karyawan aktif. Penggabungan dilakukan di region BigQuery setelah transfer terjadi. Jika satu transfer gagal dan transfer lainnya berhasil, tagihan transfer data masih berlaku untuk transfer yang berhasil.

Batasan join lintas cloud

  • Join lintas cloud tidak didukung di tingkat gratis BigQuery dan di sandbox BigQuery.
  • Agregasi mungkin tidak didorong ke region BigQuery Omni jika kueri berisi pernyataan JOIN.
  • Setiap tabel sementara hanya digunakan untuk satu kueri lintas cloud dan tidak digunakan kembali meskipun kueri yang sama diulang beberapa kali.
  • Batas ukuran transfer untuk setiap transfer adalah 60 GB. Secara khusus, jika Anda menerapkan filter pada tabel BigLake dan memuat hasilnya, ukurannya harus lebih kecil dari 60 GB. Jika perlu, Anda dapat meminta batas kuota yang lebih tinggi. Tidak ada batasan byte yang dipindai.
  • Kueri join lintas cloud menggunakan kuota internal pada frekuensi kueri. Jika rasio kueri melebihi kuota, Anda mungkin menerima error All our servers are busy processing data transferred between regions. Mencoba ulang kueri akan berfungsi dalam sebagian besar kasus. Hubungi dukungan untuk meningkatkan kuota internal guna mendukung rasio kueri yang lebih tinggi.
  • Join lintas cloud hanya didukung di region BigQuery yang berlokasi bersama dengan region BigQuery Omni yang sesuai dan di multi-region US dan EU. Join lintas cloud yang dijalankan di multi-region US atau EU hanya dapat mengakses data di masing-masing region BigQuery Omni Amerika Serikat atau Uni Eropa.
  • Jika kueri join lintas cloud mereferensikan 10 set data atau lebih dari region BigQuery Omni, kueri tersebut mungkin gagal dengan error Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>. Untuk menghindari masalah ini, sebaiknya tentukan lokasi secara eksplisit saat Anda menjalankan join lintas cloud yang mereferensikan lebih dari 10 set data. Perhatikan bahwa jika Anda menentukan region BigQuery secara eksplisit dan kueri Anda hanya berisi tabel BigLake, kueri Anda akan dijalankan sebagai kueri lintas cloud dan menimbulkan biaya transfer data.
  • Anda tidak dapat mengkueri kolom semu _FILE_NAME dengan join lintas cloud.
  • Saat mereferensikan kolom tabel BigLake dalam klausa WHERE, Anda tidak dapat menggunakan literal INTERVAL atau RANGE.
  • Tugas join lintas cloud tidak melaporkan jumlah byte yang diproses dan ditransfer dari cloud lain. Informasi ini tersedia di tugas CTAS turunan yang dibuat sebagai bagian dari eksekusi kueri lintas cloud.
  • Tampilan yang diotorisasi dan rutinitas yang diotorisasi yang mereferensikan tabel atau tampilan BigQuery Omni hanya didukung di region BigQuery Omni.
  • Jika kueri lintas cloud Anda mereferensikan kolom STRUCT atau JSON, tidak ada pushdown yang diterapkan ke subkueri jarak jauh. Untuk mengoptimalkan performa, sebaiknya buat tampilan di region BigQuery Omni yang memfilter kolom STRUCT dan JSON serta hanya menampilkan kolom yang diperlukan sebagai kolom individual.
  • Kueri perjalanan waktu tidak didukung oleh join lintas cloud.

Contoh penggabungan lintas cloud

Kueri berikut menggabungkan tabel orders di region BigQuery dengan tabel lineitem di region BigQuery Omni:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Kueri ini dibagi menjadi bagian lokal dan jarak jauh. Kueri berikut dikirim ke region BigQuery Omni untuk dijalankan terlebih dahulu. Hasilnya adalah tabel sementara di region BigQuery. Anda dapat melihat tugas CTAS turunan ini dan metadatanya di histori tugas.

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

Setelah tabel sementara dibuat, operasi JOIN selesai, dan kueri berikut dijalankan:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Sebagai contoh lain, pertimbangkan join lintas cloud berikut:

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
SELECT c_mktsegment, c_name
FROM aws_dataset.customer
WHERE c_mktsegment = 'FURNITURE'
LIMIT 10;

Dalam kueri ini, klausa LIMIT tidak didorong ke region BigQuery Omni. Semua pelanggan di segmen pasar FURNITURE ditransfer ke region BigQuery terlebih dahulu, lalu batas 10 diterapkan.

Konektor

Anda dapat mengakses data di tabel BigLake berdasarkan Cloud Storage dari alat pemrosesan data lain menggunakan konektor BigQuery. Misalnya, Anda dapat mengakses data di tabel BigLake dari Apache Spark, Apache Hive, TensorFlow, Trino, atau Presto. BigQuery Storage API menerapkan kebijakan tata kelola tingkat baris dan kolom pada semua akses data ke tabel BigLake, termasuk melalui konektor.

Misalnya, diagram berikut menunjukkan cara BigQuery Storage API memungkinkan pengguna mengakses data yang diotorisasi menggunakan mesin kueri open source seperti Apache Spark:

Arsitektur BigLake.

Untuk mengetahui informasi selengkapnya tentang konektor yang didukung oleh BigQuery, lihat Konektor BigQuery.

Tabel BigLake di penyimpanan objek

Untuk administrator data lake, BigLake memungkinkan Anda menetapkan kontrol akses pada tabel, bukan file, yang memberi Anda opsi lebih mendetail saat menetapkan akses pengguna ke data di data lake.

Tabel BigLake menyederhanakan kontrol akses dengan cara ini, maka sebaiknya gunakan tabel BigLake untuk membangun dan memelihara koneksi ke penyimpanan objek eksternal.

Anda dapat menggunakan tabel eksternal jika tata kelola tidak diperlukan, atau untuk penemuan dan manipulasi data ad hoc.

Batasan

  • Semua batasan untuk tabel eksternal berlaku untuk tabel BigLake.
  • Tabel BigLake pada penyimpanan objek diberi batasan yang sama seperti tabel BigQuery. Untuk mengetahui informasi selengkapnya, lihat Kuota.

  • BigLake tidak mendukung kredensial yang diturunkan cakupannya dari Autentikasi Cluster Pribadi Dataproc. Sebagai solusinya, untuk menggunakan cluster dengan Autentikasi Cluster Pribadi, Anda harus memasukkan kredensial menggunakan Batas Akses Kredensial kosong dengan flag --access-boundary=<(echo -n "{}"). Misalnya, perintah berikut mengaktifkan sesi propagasi kredensial dalam project bernama myproject untuk cluster bernama mycluster: 

    gcloud dataproc clusters enable-personal-auth-session \
    --region=us \
    --project=myproject \
    --access-boundary=<(echo -n "{}") \
    mycluster

  • Tabel BigLake bersifat hanya baca. Anda tidak dapat memodifikasi tabel BigLake menggunakan pernyataan DML atau metode lainnya.

  • Tabel BigLake mendukung format berikut:

  • Anda tidak dapat menggunakan metadata yang disimpan dalam cache dengan tabel eksternal BigLake untuk Apache Iceberg; BigQuery sudah menggunakan metadata yang ditangkap Iceberg dalam file manifes.

  • BigQuery Storage API tidak tersedia di lingkungan cloud lainnya, seperti AWS dan Azure.

  • Jika Anda menggunakan metadata yang disimpan dalam cache, batasan berikut akan berlaku:

    • Anda hanya dapat menggunakan metadata yang disimpan dalam cache dengan tabel BigLake yang menggunakan format Avro, ORC, Parquet, JSON, dan CSV.
    • Jika Anda membuat, mengupdate, atau menghapus file di Amazon S3, kueri file tersebut tidak akan menampilkan data yang telah diupdate hingga cache metadata berikutnya dimuat ulang. Hal ini dapat menyebabkan hasil yang tidak diharapkan. Misalnya, jika Anda menghapus file dan menulis file baru, hasil kueri Anda dapat mengecualikan file lama dan baru, bergantung pada kapan metadata yang disimpan dalam cache terakhir diupdate.
    • Penggunaan kunci enkripsi yang dikelola pelanggan (CMEK) dengan metadata yang di-cache tidak didukung untuk tabel BigLake yang merujuk data Amazon S3 atau Blob Storage.

Model keamanan

Peran organisasi berikut biasanya terlibat dalam mengelola dan menggunakan tabel BigLake:

  • Administrator data lake. Administrator ini biasanya mengelola kebijakan Identity and Access Management (IAM) pada bucket dan objek Cloud Storage.
  • Administrator data warehouse. Administrator ini biasanya membuat, menghapus, dan mengupdate tabel.
  • Analis data. Analis biasanya membaca data dan menjalankan kueri.

Administrator data lake bertanggung jawab untuk membuat koneksi dan membagikannya dengan administrator data warehouse. Selanjutnya, administrator data warehouse akan membuat tabel, menetapkan kontrol akses yang sesuai, dan membagikan tabel tersebut kepada analis data.

Penyimpanan cache metadata untuk peningkatan performa

Anda dapat menggunakan metadata yang di-cache untuk meningkatkan performa kueri pada beberapa jenis tabel BigLake. Caching metadata sangat membantu jika Anda mengerjakan sejumlah besar file atau jika data dipartisi oleh hive. Jenis tabel BigLake berikut mendukung caching metadata:

  • Tabel BigLake Amazon S3
  • Tabel BigLake Cloud Storage
Metadata tersebut mencakup nama file, informasi partisi, dan metadata fisik dari file seperti jumlah baris. Anda dapat memilih apakah akan mengaktifkan caching metadata di tabel atau tidak. Kueri dengan jumlah file yang besar dan filter partisi Hive akan mendapatkan manfaat terbesar dari caching metadata.

Jika Anda tidak mengaktifkan caching metadata, kueri pada tabel harus membaca sumber data eksternal untuk mendapatkan metadata objek. Membaca data ini akan meningkatkan latensi kueri; membuat daftar jutaan file dari sumber data eksternal dapat memakan waktu beberapa menit. Jika Anda mengaktifkan caching metadata, kueri dapat menghindari pencantuman file dari sumber data eksternal serta dapat mempartisi dan memangkas file dengan lebih cepat.

Ada dua properti yang mengontrol fitur ini:

  • Keusangan maksimum menentukan kapan kueri menggunakan metadata yang disimpan dalam cache.
  • Mode cache metadata menentukan cara metadata dikumpulkan.

Saat mengaktifkan caching metadata, Anda dapat menentukan interval maksimum keusangan metadata yang dapat diterima untuk operasi terhadap tabel. Misalnya, jika Anda menentukan interval 1 jam, operasi terhadap tabel akan menggunakan metadata yang disimpan dalam cache jika telah diperbarui dalam satu jam terakhir. Jika metadata yang disimpan dalam cache lebih lama dari itu, operasi akan kembali untuk mengambil metadata dari datastore (Amazon S3 atau Cloud Storage). Anda dapat menentukan interval keusangan antara 30 menit dan 7 hari.

Anda dapat memilih untuk memuat ulang cache secara otomatis atau manual:

  • Untuk pemuatan ulang otomatis, cache dimuat ulang pada interval yang ditentukan sistem, biasanya antara 30 dan 60 menit. Memuat ulang cache secara otomatis merupakan pendekatan yang baik jika file di datastore ditambahkan, dihapus, atau diubah secara acak. Jika Anda perlu mengontrol waktu pemuatan ulang, misalnya untuk memicu pemuatan ulang di akhir tugas pemuatan transformasi ekstrak, gunakan pemuatan ulang manual.

  • Untuk pemuatan ulang manual, Anda akan menjalankan prosedur sistem BQ.REFRESH_EXTERNAL_METADATA_CACHE untuk memuat ulang cache metadata sesuai jadwal yang memenuhi persyaratan Anda. Untuk tabel BigLake, Anda dapat memuat ulang metadata secara selektif dengan menyediakan subdirektori direktori data tabel. Hal ini memungkinkan Anda menghindari pemrosesan metadata yang tidak perlu. Memuat ulang cache secara manual merupakan pendekatan yang baik jika file di datastore ditambahkan, dihapus, atau diubah pada interval yang diketahui, misalnya sebagai output pipeline.

    Jika Anda melakukan beberapa pemuatan ulang manual secara serentak, hanya satu yang akan berhasil.

Cache metadata akan habis masa berlakunya setelah 7 hari jika tidak diperbarui.

Pembaruan cache manual dan otomatis dijalankan dengan prioritas kueri INTERACTIVE.

Jika Anda memilih untuk menggunakan pembaruan otomatis, sebaiknya buat pemesanan, lalu buat tugas dengan jenis tugas BACKGROUND untuk project yang menjalankan tugas pembaruan cache metadata. Hal ini mencegah tugas pembaruan bersaing dengan kueri pengguna untuk resource, dan berpotensi gagal jika tidak tersedia resource yang memadai.

Anda harus mempertimbangkan bagaimana nilai interval keusangan dan mode caching metadata akan berinteraksi sebelum menetapkannya. Perhatikan contoh berikut:

  • Jika Anda memuat ulang cache metadata secara manual untuk sebuah tabel, dan menetapkan interval usang menjadi 2 hari, Anda harus menjalankan prosedur sistem BQ.REFRESH_EXTERNAL_METADATA_CACHE setiap 2 hari atau kurang jika menginginkan operasi terhadap tabel agar menggunakan metadata yang disimpan dalam cache.
  • Jika Anda memuat ulang cache metadata secara otomatis untuk sebuah tabel, dan menetapkan interval keusangan ke 30 menit, beberapa operasi terhadap tabel mungkin akan membaca dari datastore jika pembaruan cache metadata dilakukan sisi yang lebih panjang dari jendela 30 hingga 60 menit seperti biasanya.

Untuk menemukan informasi tentang tugas pemuatan ulang metadata, buat kueri tampilan INFORMATION_SCHEMA.JOBS, seperti yang ditunjukkan dalam contoh berikut:

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

Untuk tabel BigLake Cloud Storage yang didasarkan pada file Parquet, statistik tabel dikumpulkan selama pemuatan ulang cache metadata dan digunakan untuk meningkatkan rencana kueri.

Untuk mempelajari lebih lanjut, lihat Cache metadata.

Untuk mengetahui informasi selengkapnya tentang menyetel opsi caching metadata, lihat Membuat tabel BigLake Amazon S3 atau Membuat tabel BigLake Cloud Storage.

Tabel yang mengaktifkan cache dengan tampilan terwujud

Anda dapat menggunakan tampilan terwujud melalui tabel yang mendukung cache metadata BigLake untuk meningkatkan performa dan efisiensi saat membuat kueri data terstruktur yang disimpan di Cloud Storage atau Amazon Simple Storage Service (Amazon S3). Tampilan terwujud ini berfungsi seperti tampilan terwujud atas tabel penyimpanan yang dikelola BigQuery, termasuk manfaat pemuatan ulang otomatis dan smart tuning.

Integrasi

Tabel BigLake dapat diakses dari sejumlah fitur BigQuery dan layanan gcloud CLI lainnya, termasuk layanan berikut yang ditandai.

Analytics Hub

Tabel BigLake kompatibel dengan Analytics Hub. Set data yang berisi tabel BigLake dapat dipublikasikan sebagai listingan Analytics Hub. Pelanggan Analytics Hub dapat berlangganan listingan ini, yang menyediakan set data hanya baca, yang disebut set data tertaut, di project mereka. Pelanggan dapat membuat kueri semua tabel dalam set data tertaut, termasuk semua tabel BigLake. Untuk mengetahui informasi selengkapnya, lihat Melihat dan berlangganan listingan.

BigQuery ML

Anda dapat menggunakan BigQuery ML untuk melatih dan menjalankan model di BigLake pada Cloud Storage.

Perlindungan Data Sensitif

Sensitive Data Protection akan memindai tabel BigLake Anda untuk mengidentifikasi dan mengklasifikasikan data sensitif. Jika data sensitif terdeteksi, transformasi de-identifikasi Sensitive Data Protection dapat menyamarkan, menghapus, atau mengaburkan data tersebut.

Biaya

Biaya dikaitkan dengan aspek tabel BigLake berikut:

Jika memiliki reservasi slot, Anda tidak akan dikenai biaya untuk membuat kueri tabel eksternal. Sebagai gantinya, slot digunakan untuk kueri ini.

Tabel berikut menunjukkan pengaruh model penetapan harga Anda terhadap penerapan biaya ini:


Harga sesuai permintaan
Edisi Standard, Enterprise, dan Enterprise Plus

Kueri
Anda ditagih untuk byte yang diproses oleh kueri pengguna.
Slot dalam penetapan pemesanan dengan jenis tugas QUERY digunakan selama waktu kueri.

Memuat ulang cache metadata secara manual.
Anda ditagih untuk byte yang diproses untuk memuat ulang cache.
Slot dalam penetapan pemesanan dengan jenis tugas QUERY digunakan selama pemuatan ulang cache.

Memuat ulang cache metadata secara otomatis.
Anda ditagih untuk byte yang diproses untuk memuat ulang cache.
Slot dalam penetapan pemesanan dengan jenis tugas BACKGROUND digunakan selama pemuatan ulang cache.

Jika tidak ada pemesanan BACKGROUND yang tersedia untuk memuat ulang cache metadata, BigQuery akan otomatis menggunakan slot di pemesanan QUERY jika Anda menggunakan edisi Enterprise atau Enterprise Plus.

Anda juga dikenai biaya untuk penyimpanan dan akses data oleh Cloud Storage, Amazon S3, dan Azure Blob Storage, sesuai dengan panduan harga setiap produk.

Langkah selanjutnya