Pengantar BigQuery Omni

Dengan BigQuery Omni, Anda dapat menjalankan analisis BigQuery pada data yang disimpan di Amazon Simple Storage Service (Amazon S3) atau Azure Blob Storage menggunakan tabel BigLake.

Banyak organisasi yang menyimpan data di beberapa cloud publik. Data ini sering kali disimpan secara terpisah, karena sulit untuk mendapatkan insight keseluruhan dari semua data. Disarankan agar dapat menganalisis data dengan alat data multi-cloud yang murah, cepat, dan tidak menciptakan overhead tambahan untuk tata kelola data yang terdesentralisasi. Dengan menggunakan BigQuery Omni, kami mengurangi hambatan ini dengan antarmuka terpadu.

Untuk menjalankan analisis BigQuery pada data eksternal, Anda harus terhubung ke Amazon S3 atau Blob Storage terlebih dahulu. Jika ingin membuat kueri data eksternal, Anda harus membuat tabel BigLake yang mereferensikan data Amazon S3 atau Blob Storage.

Anda juga dapat memindahkan data antar-cloud untuk menggabungkan data di seluruh awan menggunakan transfer lintas-cloud atau buat kueri data di seluruh cloud menggunakan gabungan lintas-cloud. BigQuery Omni menawarkan solusi analisis lintas cloud dengan kemampuan untuk menganalisis data di mana pun berada dan fleksibilitas untuk mereplikasi data jika diperlukan. Untuk mengetahui informasi selengkapnya, baca artikel Memuat data dengan transfer lintas-cloud dan Cross-cloud join.

Arsitektur

Arsitektur BigQuery memisahkan komputasi dari penyimpanan, sehingga memungkinkan BigQuery melakukan penskalaan sesuai kebutuhan untuk menangani beban kerja yang sangat besar. BigQuery Omni memperluas arsitektur ini dengan menjalankan mesin kueri BigQuery di cloud lainnya. Hasilnya, Anda tidak perlu memindahkan data secara fisik ke penyimpanan BigQuery. Pemrosesan terjadi di tempat data tersebut berada.

Arsitektur BigQuery Omni

Hasil kueri dapat ditampilkan ke Google Cloud melalui koneksi yang aman, — misalnya untuk ditampilkan di Konsol Google Cloud. Atau, Anda dapat menulis hasilnya langsung ke bucket Amazon S3 atau Blob Storage. Dalam kasus ini, tidak ada perpindahan lintas cloud dari hasil kueri.

BigQuery Omni menggunakan peran IAM AWS standar atau akun utama Azure Active Directory untuk mengakses data di langganan Anda. Anda mendelegasikan akses baca atau tulis ke BigQuery Omni, dan dapat mencabut akses kapan saja.

Aliran data saat membuat kueri data

Gambar berikut menjelaskan cara data berpindah antara Google Cloud dan AWS atau Azure untuk kueri berikut:

  • Pernyataan SELECT
  • Pernyataan CREATE EXTERNAL TABLE
Perpindahan data antara Google Cloud dan AWS atau Azure untuk kueri.
Gambar 1: Perpindahan data antara Google Cloud dan AWS atau Azure untuk kueri.
  1. Bidang kontrol BigQuery menerima tugas kueri dari Anda melalui Konsol Google Cloud, alat command line bq, metode API, atau library klien.
  2. Bidang kontrol BigQuery mengirimkan tugas kueri untuk diproses ke bidang data BigQuery di AWS atau Azure.
  3. Bidang data BigQuery menerima kueri dari bidang kontrol melalui koneksi VPN.
  4. Bidang data BigQuery membaca data tabel dari bucket Amazon S3 atau Blob Storage.
  5. Bidang data BigQuery menjalankan tugas kueri pada data tabel. Pemrosesan data tabel terjadi di region AWS atau Azure yang ditentukan.
  6. Hasil kueri ditransmisikan dari bidang data ke bidang kontrol melalui koneksi VPN.
  7. Bidang kontrol BigQuery menerima hasil tugas kueri untuk ditampilkan kepada Anda sebagai respons terhadap tugas kueri. Data ini disimpan hingga 24 jam.
  8. Hasil kueri dikembalikan kepada Anda.

Untuk mengetahui informasi selengkapnya, baca Membuat kueri data Amazon S3 dan Data Azure Blob Storage.

Aliran data saat mengekspor data

Gambar berikut menjelaskan cara perpindahan data antara Google Cloud dan AWS atau Azure selama pernyataan EXPORT DATA.

Perpindahan data antara Google Cloud dan AWS atau Azure untuk kueri ekspor.
Gambar 2: Pergerakan data antara Google Cloud dan AWS atau Azure untuk kueri ekspor.
  1. Bidang kontrol BigQuery menerima tugas kueri ekspor dari Anda melalui Konsol Google Cloud, alat command line bq, metode API, atau library klien. Kueri berisi jalur tujuan untuk hasil kueri di bucket Amazon S3 atau Blob Storage.
  2. Bidang kontrol BigQuery mengirimkan tugas kueri ekspor untuk diproses ke bidang data BigQuery (di AWS atau Azure).
  3. Bidang data BigQuery menerima kueri ekspor dari bidang kontrol melalui koneksi VPN.
  4. Bidang data BigQuery membaca data tabel dari bucket Amazon S3 atau Blob Storage.
  5. Bidang data BigQuery menjalankan tugas kueri pada data tabel. Pemrosesan data tabel terjadi di region AWS atau Azure yang ditentukan.
  6. BigQuery menulis hasil kueri ke jalur tujuan yang ditentukan dalam bucket Amazon S3 atau Blob Storage.

Untuk mengetahui informasi selengkapnya, baca Mengekspor hasil kueri ke Amazon S3 dan Blob Storage.

Manfaat

Performa. Anda bisa mendapatkan insight lebih cepat karena data tidak disalin di cloud, dan kueri berjalan di region yang sama dengan tempat data Anda berada.

Biaya. Anda menghemat biaya transfer data keluar karena data tidak bergerak. Tidak ada biaya tambahan pada akun AWS atau Azure Anda yang terkait dengan Analisis BigQuery Omni, karena kuerinya berjalan di cluster dikelola oleh Google. Anda hanya akan ditagih untuk menjalankan kueri, menggunakan model harga BigQuery.

Keamanan dan tata kelola data. Anda dapat mengelola data di langganan AWS atau Azure Anda sendiri. Anda tidak perlu memindahkan atau menyalin data mentah dari cloud publik. Semua komputasi terjadi di layanan multi-tenant BigQuery yang berjalan dalam region yang sama dengan data Anda.

Arsitektur serverless. Seperti BigQuery lainnya, BigQuery Omni adalah penawaran serverless. Google men-deploy dan mengelola cluster yang menjalankan BigQuery Omni. Anda tidak perlu menyediakan resource atau mengelola cluster apa pun.

Kemudahan pengelolaan. BigQuery Omni menyediakan antarmuka pengelolaan terpadu melalui Google Cloud. BigQuery Omni dapat menggunakan akun Google Cloud dan project BigQuery yang sudah ada. Anda dapat menulis kueri GoogleSQL di Konsol Google Cloud untuk melakukan kueri data di AWS atau Azure, dan melihat hasil yang ditampilkan di Konsol Google Cloud.

Transfer lintas cloud. Anda dapat memuat data ke tabel BigQuery standar dari bucket S3 dan Blob Storage. Untuk mengetahui informasi selengkapnya, baca artikel Mentransfer data Amazon S3 dan Memindahkan data Blob Storage ke BigQuery.

Penyimpanan cache metadata untuk peningkatan performa

Anda dapat menggunakan metadata yang di-cache untuk meningkatkan performa kueri pada tabel BigLake yang mereferensikan data Amazon S3. Hal ini sangat membantu terutama jika Anda mengerjakan sejumlah besar file atau jika data dipartisi oleh hive.

{i>Metadata<i} meliputi nama file, informasi partisi, dan metadata dari file seperti jumlah baris. Anda dapat memilih untuk mengaktifkannya penyimpanan {i>metadata <i} ke dalam tabel. Kueri dengan sejumlah besar file dan dengan Hive filter partisi mendapat manfaat paling banyak dari {i>caching<i} metadata.

Jika Anda tidak mengaktifkan penyimpanan metadata ke cache, kueri pada tabel harus membaca sumber data eksternal untuk mendapatkan metadata objek. Membaca data ini meningkatkan latensi kueri; sehingga Anda perlu membuat daftar jutaan file dari sumber data eksternal. beberapa menit. Jika Anda mengaktifkan penyimpanan metadata metadata, kueri dapat menghindari file listingan dari sumber data eksternal dan dapat membuat partisi serta memangkas file 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 di-cache jika metadata lebih lama dari itu, operasi akan kembali mengambil metadata dari Sebagai gantinya, Amazon S3. 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. Memperbarui cache secara otomatis adalah pendekatan yang baik jika file dalam Amazon S3 ditambahkan, dihapus, atau diubah secara acak dengan interval tertentu. Jika Anda perlu mengontrol waktu pemuatan ulang, misalnya untuk memicu pemuatan ulang di akhir tugas pemuatan transformasi ekstrak, gunakan pemuatan ulang manual.

  • Untuk pembaruan manual, Anda menjalankan Sistem BQ.REFRESH_EXTERNAL_METADATA_CACHE prosedur untuk memperbarui cache metadata sesuai jadwal yang memenuhi kebutuhan Anda. Memperbarui {i>cache<i} secara manual adalah pendekatan yang baik jika file dalam Amazon S3 ditambahkan, dihapus, atau dimodifikasi pada interval yang diketahui, misalnya sebagai output dari 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 secara otomatis memperbarui {i> cache metadata<i} untuk tabel, dan Anda mengatur interval penghentian menjadi 30 menit, ada kemungkinan bahwa beberapa operasi terhadap tabel mungkin dibaca dari Amazon S3 jika pembaruan cache metadata mengambil waktu yang lebih lama dari biasanya Periode 30 hingga 60 menit.

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 mengetahui informasi selengkapnya, lihat Pembuatan cache metadata.

Tabel yang mendukung cache dengan tampilan terwujud

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

Untuk menyediakan data Amazon S3 dalam tampilan terwujud di region BigQuery yang didukung untuk penggabungan, membuat replika tampilan terwujud. Anda hanya dapat membuat replika tampilan terwujud melalui tampilan material yang diotorisasi.

Batasan

Selain batasan untuk tabel BigLake, batasan berikut berlaku untuk BigQuery Omni, yang mencakup tabel BigLake berdasarkan data Amazon S3 dan Blob Storage:

  • Bekerja dengan data di salah satu BigQuery Omni region tidak didukung oleh Standard dan Edisi Enterprise Plus. Untuk mengetahui informasi selengkapnya tentang edisi, lihat Pengantar edisi BigQuery.
  • OBJECT_PRIVILEGES, STREAMING_TIMELINE_BY_*, TABLE_SNAPSHOTS, TABLE_STORAGE, TABLE_CONSTRAINTS, KEY_COLUMN_USAGE, CONSTRAINT_COLUMN_USAGE, dan PARTITIONS INFORMATION_SCHEMA penayangan tidak tersedia untuk tabel BigLake berdasarkan Data Amazon S3 dan Blob Storage.
  • Tampilan terwujud tidak didukung untuk Blob Storage.
  • UDF JavaScript tidak didukung.

  • Pernyataan SQL berikut tidak didukung:

  • Batasan berikut berlaku pada proses kueri dan pembacaan tabel sementara tujuan (pratinjau):

    • Membuat kueri tabel sementara tujuan dengan pernyataan SELECT tidak didukung.
    • Penggunaan BigQuery Storage Read API untuk membaca data dari tabel sementara tujuan tidak didukung.
    • Saat menggunakan driver ODBC, pembacaan throughput tinggi (opsi EnableHTAPI) tidak didukung.

  • Kueri terjadwal hanya didukung melalui metode API atau CLI. Opsi tabel tujuan dinonaktifkan untuk kueri. Hanya kueri EXPORT DATA yang diizinkan.

  • BigQuery Storage API tidak tersedia di region BigQuery Omni.

  • Jika kueri Anda menggunakan klausa ORDER BY dan memiliki ukuran hasil lebih besar dari 256 MB, kueri Anda akan gagal. Untuk mengatasi hal ini, perkecil ukuran hasil atau hapus klausa ORDER BY dari kueri. Untuk mengetahui informasi selengkapnya tentang kuota BigQuery Omni, lihat Kuota dan batas.

  • Penggunaan kunci enkripsi yang dikelola pelanggan (CMEK) dengan set data dan tabel eksternal tidak didukung.

Harga

Untuk mengetahui informasi tentang harga dan penawaran berbatas waktu di BigQuery Omni, lihat harga BigQuery Omni.

Kuota dan batas

Untuk mengetahui informasi tentang kuota BigQuery Omni, lihat Kuota dan batas.

Jika hasil kueri Anda lebih dari 20 GiB, sebaiknya ekspor hasilnya ke Amazon S3 atau Blob Storage. Untuk mempelajari kuota untuk BigQuery Connection API, lihat BigQuery Connection API.

Lokasi

BigQuery Omni memproses kueri di lokasi yang sama dengan set data yang berisi tabel yang Anda kuerikan. Setelah Anda membuat set data, lokasi tidak dapat diubah. Data Anda berada dalam akun AWS atau Azure Anda. Region BigQuery Omni mendukung pemesanan edisi Enterprise dan harga compute (analisis) on demand. Untuk informasi selengkapnya tentang edisi, lihat Pengantar edisi BigQuery.
Deskripsi region Nama region Region BigQuery yang ditempatkan
AWS
AWS - AS Timur (N. Utara) aws-us-east-1 us-east4
AWS - AS Barat (Oregon) aws-us-west-2 us-west1
AWS - Asia Pasifik (Seoul) aws-ap-northeast-2 asia-northeast3
AWS - Asia Pasifik (Sydney) aws-ap-southeast-2 australia-southeast1
AWS - Eropa (Irlandia) aws-eu-west-1 europe-west1
AWS - Eropa (Frankfurt) aws-eu-central-1 europe-west3
Azure
Azure - East US 2 azure-eastus2 us-east4

Langkah berikutnya