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 cloud menggunakan transfer lintas-cloud atau membuat 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 Penggabungan lintas-cloud.

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 dapat menghemat biaya transfer data keluar karena data tidak dipindahkan. Tidak ada biaya tambahan untuk akun AWS atau Azure Anda terkait analisis BigQuery Omni, karena kueri dijalankan pada cluster yang 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.

Tabel objek dan BigLake mendukung metadata tentang file dalam cache dari sumber data eksternal, seperti Cloud Storage dan Amazon Simple Storage Service (Amazon S3). Metadata tersebut mencakup nama file, informasi partisi, dan metadata fisik dari file seperti jumlah baris. Anda dapat memilih apakah akan mengaktifkan cache metadata pada tabel atau tidak. Kueri yang memiliki jumlah file besar dan dengan filter partisi Hive akan mendapatkan manfaat terbesar dari penyimpanan metadata.

Jika Anda tidak mengaktifkan penyimpanan metadata ke cache, kueri pada tabel harus membaca sumber data eksternal untuk mendapatkan metadata objek yang dapat meningkatkan latensi kueri; daftar jutaan file dari sumber data eksternal dapat memerlukan waktu beberapa menit. Jika Anda mengaktifkan caching metadata, kueri dapat menghindari pencantuman file dari sumber data eksternal serta mencapai partisi dan pruning file yang lebih cepat.

Ada dua properti yang mengontrol fitur ini:

  • Keusangan maksimum, yang mengontrol kapan kueri menggunakan metadata yang disimpan dalam cache.
  • Mode cache metadata, yang mengontrol 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 Cloud Storage. Anda dapat menentukan interval keusangan antara 30 menit dan 7 hari.

Anda dapat memilih untuk memperbarui 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 sumber data eksternal 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 pembaruan manual, jalankan prosedur sistem BQ.REFRESH_EXTERNAL_METADATA_CACHE untuk memperbarui cache metadata sesuai jadwal yang memenuhi persyaratan Anda. Memuat ulang cache secara manual merupakan pendekatan yang baik jika file di Cloud Storage 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.

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 otomatis memuat ulang cache metadata untuk sebuah tabel, dan menetapkan interval usang menjadi 30 menit, beberapa operasi terhadap tabel kemungkinan akan dibaca dari Cloud Storage jika pemuatan ulang cache metadata memerlukan waktu yang lebih lama daripada periode 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 mengetahui informasi selengkapnya, lihat Pembuatan cache metadata.

Tabel yang mendukung cache dengan tampilan terwujud

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

Agar data Amazon S3 dalam tampilan terwujud tersedia di region BigQuery yang didukung untuk penggabungan, buat replika tampilan terwujud. Anda hanya dapat membuat replika tampilan terwujud dari tampilan material yang diizinkan.

Batasan

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

  • Menangani data di salah satu region BigQuery Omni tidak didukung oleh edisi Standard dan Enterprise Plus. Untuk mengetahui informasi selengkapnya tentang edisi, lihat Pengantar edisi BigQuery.
  • Tampilan INFORMATION_SCHEMA, OBJECT_PRIVILEGES, STREAMING_TIMELINE_BY_*, TABLE_SNAPSHOTS, TABLE_STORAGE, dan PARTITIONS 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 Alokasi region BigQuery
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 - Eropa (Irlandia) aws-eu-west-1 europe-west1
Azure
Azure - East US 2 azure-eastus2 us-east4

Langkah selanjutnya