Pengantar tabel 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

Gabungan 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. Gabungan 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 merupakan 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 berbagai tabel cloud dan BigQuery dalam kueri yang sama. Semua tabel BigQuery harus berasal dari region yang sama.

Diperlukan izin penggabungan lintas-cloud

Untuk mendapatkan izin yang diperlukan untuk menjalankan gabungan lintas-cloud, minta administrator untuk memberi Anda peran IAM BigQuery Data Editor (roles/bigquery.dataEditor) di project tempat penggabungan dijalankan. Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses.

Peran yang telah ditentukan ini berisi izin yang diperlukan untuk menjalankan gabungan lintas-cloud. Untuk melihat izin yang benar-benar diperlukan, perluas bagian Izin yang diperlukan:

Izin yang diperlukan

Izin berikut diperlukan untuk menjalankan gabungan lintas-cloud:

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

Anda mung juga bisa mendapatkan izin ini dengan peran khusus atau peran bawaanlainnya.

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

Biaya penggabungan lintas-cloud

Saat Anda menjalankan operasi gabungan 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 akan membuat tabel sementara di region BigQuery Anda. BigQuery kemudian menggunakan tabel sementara ini untuk menjalankan gabungan lintas cloud dan menghapus tabel secara otomatis setelah delapan jam.

Anda dikenai biaya transfer data untuk data di tabel BigLake yang direferensikan. Namun, BigQuery membantu mengurangi biaya ini dengan hanya mentransfer kolom dan baris di tabel BigLake yang direferensikan dalam kueri, bukan keseluruhan tabel. Sebaiknya tentukan filter kolom yang sespesifik mungkin untuk lebih mengurangi biaya transfer. Tugas CTAS akan 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 mengetahui informasi lebih lanjut, lihat harga BigQuery Omni.

Pertimbangkan 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. Penyambungan dilakukan di region BigQuery setelah transfer terjadi. Jika salah satu transfer gagal dan transfer lainnya berhasil, biaya transfer data tetap diterapkan untuk transfer yang berhasil.

Batasan penggabungan lintas-cloud

  • Penggabungan lintas-cloud tidak didukung di paket gratis BigQuery dan di sandbox BigQuery.
  • Gabungan beberapa tabel BigLake dari region yang sama tidak didorong ke region BigQuery Omni.
  • 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 akan digunakan kembali meskipun jika kueri yang sama diulang beberapa kali.
  • Batas ukuran transfer untuk setiap transfer adalah 20 GB. Khususnya, jika Anda menerapkan filter pada tabel BigLake dan memuat hasilnya, ukuran tersebut harus lebih kecil dari 20 GB. Jika perlu, Anda dapat meminta batas kuota yang lebih tinggi. Tidak ada batasan byte yang dipindai.
  • Kueri gabungan lintas-cloud menggunakan kuota internal pada kecepatan kueri. Jika tingkat kueri melebihi kuota, Anda mungkin akan menerima error All our servers are busy processing data transferred between regions. Mencoba ulang kueri dalam sebagian besar kasus akan berhasil. Hubungi dukungan untuk meningkatkan kuota internal guna mendukung rasio kueri yang lebih tinggi.
  • Penggabungan lintas-cloud hanya didukung di region BigQuery yang ditempatkan bersama dengan region BigQuery Omni yang sesuai serta di multi-region US dan EU. Gabungan lintas-cloud yang dijalankan di multi-region US atau EU hanya dapat mengakses data di region Omni AS atau Uni Eropa.
  • Secara default, gabungan lintas-cloud dijalankan di region BigQuery dari set data BigQuery yang tercantum pertama kali jika semua set data diatur dalam urutan abjad. Namun, hanya 10 set data alfabet pertama yang dipindai, jadi jika semuanya berupa tabel BigLake di region BigQuery Omni, tugas akan gagal jika berisi tabel BigQuery. Untuk menghindari masalah ini, sebaiknya tentukan lokasi secara eksplisit saat menjalankan gabungan lintas-cloud yang mereferensikan lebih dari 10 set data. Perhatikan bahwa jika Anda secara eksplisit menentukan region BigQuery dan kueri Anda hanya berisi tabel BigLake, kueri Anda akan dijalankan sebagai kueri lintas cloud dan dikenai biaya transfer data.
  • Anda tidak dapat mengkueri kolom semu _FILE_NAME dengan penggabungan lintas-cloud.
  • Saat mereferensikan kolom tabel BigLake dalam klausa WHERE, Anda tidak dapat menggunakan literal NUMERIC, BIGNUMERIC, BYTES, TIME, atau INTERVAL.
  • Tugas penggabungan 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 sah dan rutinitas yang diizinkan yang merujuk tabel atau tampilan BigQuery Omni hanya didukung di region BigQuery Omni.

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 beberapa bagian lokal dan jarak jauh. Kueri berikut dikirim ke region BigQuery Omni untuk dieksekusi terlebih dahulu. Hasilnya adalah tabel sementara di region BigQuery. Anda dapat melihat pekerjaan CTAS turunan ini dan metadatanya dalam riwayat pekerjaan Anda.

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 akan 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 lainnya, pertimbangkan gabungan 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 bawah 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 dengan tanda --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 Apache Iceberg BigLake; 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 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. Cache metadata sangat membantu jika Anda bekerja dengan sejumlah besar file atau jika data dipartisi oleh hive. Jenis tabel BigLake berikut mendukung penyimpanan metadata:

  • Tabel BigLake Amazon S3
  • Tabel BigLake Cloud Storage
Metadata 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 di-cache lebih lama dari itu, operasi akan kembali 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. Me-refresh 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 pembaruan manual, jalankan prosedur sistem BQ.REFRESH_EXTERNAL_METADATA_CACHE untuk memperbarui cache metadata sesuai jadwal yang memenuhi persyaratan Anda. Jika ingin memuat ulang metadata secara selektif, Anda dapat menyediakan subdirektori direktori data tabel untuk 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.

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 tabel dan menetapkan interval penghentian ke 30 menit, beberapa operasi terhadap tabel mungkin akan dibaca dari datastore jika pembaruan cache metadata memerlukan waktu yang lebih lama dari periode biasanya 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 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 cara menyetel opsi caching metadata, lihat Membuat tabel BigLake Amazon S3 atau Membuat tabel BigLake Cloud Storage.

Tabel yang mendukung cache dengan tampilan terwujud

Anda dapat menggunakan tampilan terwujud pada tabel yang mengaktifkan 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 Berlangganan ke 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 mengkueri tabel eksternal. Sebaliknya, slot digunakan untuk kueri-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 reservasi BACKGROUND yang tersedia untuk memuat ulang cache metadata, BigQuery akan otomatis menggunakan slot di reservasi QUERY jika Anda menggunakan edisi Enterprise atau Enterprise Plus.

Langkah selanjutnya