Tentang akses data lintas cloud

Fitur akses data lintas cloud memungkinkan Anda mengkueri data yang disimpan di penyedia cloud lain langsung dari Google Cloud tanpa memigrasikan file atau membangun pipeline ETL yang kompleks. Kueri dapat dirutekan melalui internet publik atau menggunakan Cross-Cloud Interconnect untuk transportasi jaringan pribadi.

Akses data lintas cloud di Lakehouse menyatukan workload analisis dan AI di seluruh set data terdistribusi Anda melalui BigQuery, lingkungan Apache Spark mandiri, atau Managed Service untuk Apache Spark.

Selain menjalankan kueri analisis, Anda dapat membangun agen analisis percakapan yang didasarkan pada tabel terdistribusi Anda—termasuk sumber lintas cloud—untuk menganalisis data di seluruh cloud dari satu percakapan. Anda juga dapat menggunakan Knowledge Catalog untuk pembuatan profil data dan insight di berbagai platform jarak jauh.

Kapan harus menggunakan akses data lintas-cloud

Berikut adalah beberapa kasus penggunaan umum:

  • Membuat kueri tabel multi-cloud di tempat: jalankan analisis BigQuery SQL dan Managed Service untuk Apache Spark langsung di tabel Apache Iceberg eksternal di Amazon Web Services (AWS) dan Microsoft Azure tanpa memigrasikan file atau memelihara pipeline ETL.
  • Menerapkan isolasi jaringan lintas cloud pribadi: merutekan pembacaan data kueri dan pemuatan ulang metadata latar belakang melalui Cross-Cloud Interconnect untuk membantu memenuhi kebijakan keamanan dan kepatuhan yang membatasi traffic internet publik.
  • Mengurangi biaya transfer data lintas cloud yang berulang: gabungkan tarif egress interkoneksi pribadi yang dapat diprediksi dengan caching blok lokal otomatis diGoogle Cloud untuk dasbor BI dan workload analisis yang berulang.
  • Menyatukan tata kelola lintas cloud dan agen AI: tempatkan agen analisis percakapan di tabel terdistribusi dan terapkan penemuan, pembuatan profil, dan silsilah Knowledge Catalog di seluruh cloud.

Arsitektur

Diagram berikut mengilustrasikan arsitektur akses data lintas cloud Lakehouse:

Arsitektur akses data lintas cloud Lakehouse di seluruh Google Cloud, Amazon Web Services (AWS), dan partner SaaS.
Arsitektur Lakehouse menghubungkan mesin Google Cloud AI dan analisis ke katalog cloud eksternal, penyimpanan objek, dan partner SaaS.

Diagram sebelumnya mengilustrasikan arsitektur di seluruh Google Cloud dan lingkungan cloud dan SaaS eksternal:

  • Google Cloud: menyediakan AI, tata kelola, analisis, dan akses data lintas cloud di seluruh set data jarak jauh:
    • Agen dan pengalaman AI: membangun agen otonom di Conversational Analytics dan Gemini Enterprise yang menelusuri data dan makna semantik di Knowledge Catalog serta menjalankan kueri melalui mesin analisis dan pemrosesan.
    • Knowledge Catalog: memberikan tata kelola terpadu dan silsilah data, bersama dengan insight data, pembuatan profil, dan produk data, dengan menyinkronkan metadata dan silsilah dari Lakehouse.
    • Mesin analisis dan pemrosesan: menjalankan workload BigQuery SQL, BigQuery AI, dan Looker, atau memproses data jarak jauh dengan Managed Service untuk Apache Spark dan mesin terbuka (Apache Spark, Apache Flink, dan Trino) dengan me-resolve metadata dan membaca tabel melalui Lakehouse.
    • Akses data lintas cloud Lakehouse: mengkueri data jarak jauh secara langsung tanpa migrasi file atau pipeline ETL:
      • Sinkronisasi metadata: menemukan dan menyinkronkan metadata tabel melalui Apache Iceberg REST dan Delta Sharing menggunakan katalog runtime Lakehouse, melakukan autentikasi melalui OpenID Connect (OIDC) atau Secret Manager, dan menyediakan kredensial sementara yang tercakup.
      • Kemampuan lintas cloud (AWS): meng-cache blok data baca di Google Cloud menggunakan cache read-through tingkat blok (Caching cerdas (cache lokal)), dan merutekan traffic melalui Dedicated Cross-Cloud Interconnect (CCI), Partner Interconnect, atau internet (dengan TLS) menggunakan Transportasi jaringan lintas cloud.
  • Sumber data SaaS dan cloud eksternal: menghosting katalog jarak jauh, cloud data SaaS, dan penyimpanan objek:
    • Katalog cloud dan SaaS eksternal: menyinkronkan metadata dari Katalog data cloud (AWS Glue Data Catalog di AWS, serta Databricks Unity Catalog dan Snowflake Horizon Catalog di AWS atau Google Cloud) dan cloud data SaaS (Salesforce Data Cloud, Workday Data Lake di AWS atauGoogle Cloud, dan SAP Business Data Cloud (BDC)) melalui Iceberg REST API dan Delta Sharing (untuk SAP BDC).
    • Penyimpanan objek cloud eksternal (AWS): menyimpan tabel Apache Iceberg (file data Parquet) dan Tabel Amazon S3 di Amazon S3 untuk pembacaan blok langsung melalui CCI atau internet (dengan TLS).

Cara kerja akses data lintas cloud

Lakehouse membuat kueri data jarak jauh menggunakan proses berikut:

  1. Penemuan metadata: Katalog runtime Lakehouse terhubung ke endpoint katalog REST Apache Iceberg jarak jauh, seperti Databricks Unity Catalog, AWS Glue Data Catalog, atau Snowflake Horizon Catalog, untuk menemukan metadata tabel tanpa menyalin file. Bergantung pada penyedia katalog jarak jauh, Lakehouse melakukan autentikasi melalui Secret Manager atau federasi token OIDC dengan Google sebagai penyedia identitas.
  2. Transportasi yang aman: Memilih untuk merutekan traffic melalui interkoneksi pribadi (misalnya, Dedicated CCI atau Partner Interconnect) akan mengurangi biaya transfer data secara signifikan dibandingkan dengan internet publik dan membuat latensi sangat dapat diprediksi.
  3. Eksekusi yang dioptimalkan: Saat Anda mengaktifkan caching lintas cloud di katalog atau koneksi gabungan, Lakehouse akan meng-cache blok file yang diambil secara lokal dalam region eksekusi kueri Google Cloud . Kueri berikutnya yang menargetkan blok file yang sama akan dibaca langsung dari cache lokal, bukan mengambil ulang file dari cloud jarak jauh, sehingga membantu mengurangi biaya egress lintas cloud dan meningkatkan performa kueri.

Katalog yang didukung

Lakehouse mendukung kueri data dari penyedia katalog jarak jauh berikut:

Konsep inti

Akses data lintas cloud memisahkan pembaruan metadata latar belakang dari transportasi data kueri, sehingga Anda dapat merutekan salah satu atau kedua lapisan traffic secara pribadi berdasarkan persyaratan keamanan dan biaya Anda.

Lapisan metadata

Lapisan metadata di katalog runtime Lakehouse terhubung ke endpoint katalog REST Apache Iceberg jarak jauh untuk menyinkronkan namespace dan metadata tabel Apache Iceberg berdasarkan interval refresh. Lakehouse melakukan autentikasi menggunakan kredensial yang disimpan di Secret Manager atau penggabungan token OIDC.

Secara default, permintaan autentikasi dan refresh metadata latar belakang dikirim melalui internet publik menggunakan TLS. Jika katalog jarak jauh Anda membatasi akses jaringan publik atau kebijakan keamanan Anda memerlukan traffic bidang kontrol pribadi, Anda dapat mengonfigurasi layanan Direktori Layanan metadata (--metadata-service-directory-name) untuk AWS Glue Data Catalog (di AWS), Databricks Unity Catalog (di AWS dan Azure), dan Snowflake Horizon Catalog (di AWS dan Azure). Konfigurasi ini merutekan traffic metadata dan autentikasi secara pribadi melalui Dedicated Cross-Cloud Interconnect atau Partner Cross-Cloud Interconnect (untuk AWS), secara independen atau bersama dengan transport kueri pribadi (--service-directory-name).

Lapisan transpor

Lapisan transport memungkinkan BigQuery dan mesin open source mengkueri file tabel jarak jauh menggunakan metadata yang disinkronkan dari lapisan metadata. Untuk katalog jarak jauh yang didukung, Lakehouse mendukung kueri data melalui internet publik atau interkoneksi pribadi khusus.

Pilih metode transportasi yang sesuai dengan persyaratan arsitektur dan keamanan Anda:

Milik pelanggan (CCI)

Anda dapat mengonfigurasi BigQuery untuk mengkueri data yang disimpan di bucket Amazon S3 atau container Azure Data Lake Storage Gen2 (ADLS Gen2) melalui Cross-Cloud Interconnect pribadi menggunakan Dedicated Cross-Cloud Interconnect atau Partner Cross-Cloud Interconnect.

Menggunakan interkoneksi pribadi memberikan manfaat berikut:

  • Keamanan yang ditingkatkan: Data dikirim melalui koneksi jaringan pribadi antara Google Cloud dan AWS atau Azure, sehingga menghindari internet publik.
  • Biaya yang lebih rendah: Biaya egress yang berpotensi lebih rendah dari AWS atau Azure dibandingkan dengan egress internet, terutama jika digabungkan dengan kapasitas interkoneksi pribadi Anda.
  • Performa yang konsisten: Latensi dan bandwidth jaringan yang lebih dapat diprediksi dibandingkan dengan internet publik.

Ringkasan arsitektur

Untuk mengaktifkan kueri pribadi, konfigurasikan jalur dari BigQuery ke bucket Amazon S3 atau container ADLS Gen2 melalui interkoneksi pribadi Anda. Komponen utama dalam Google Cloud Virtual Private Cloud (VPC) adalah load balancer internal (ILB). ILB mendistribusikan permintaan dari BigQuery ke endpoint pribadi untuk Amazon S3 dalam VPC AWS Anda (yang disediakan menggunakan AWS PrivateLink) atau untuk ADLS Gen2 dalam Jaringan Virtual (VNet) Azure Anda, yang disediakan menggunakan Azure Private Link.

Menggunakan ILB dengan beberapa antarmuka jaringan elastis (ENI) atau kartu antarmuka jaringan (NIC) sebagai backend sangat penting untuk load balancing, skalabilitas, dan ketersediaan tinggi. Hal ini berlaku baik jika Anda menggunakan Dedicated CCI maupun Partner Interconnect.

Alur kerja kueri pribadi mengikuti proses berikut:

  1. BigQuery menggunakan koneksi yang dikonfigurasi dengan layanan Direktori Layanan.
  2. Direktori Layanan me-resolve nama layanan ke alamat IP internal Google Cloud ILB.
  3. ILB menerima permintaan dari BigQuery dan mendistribusikannya ke backend yang dikonfigurasi.
  4. Backend ILB adalah Grup Endpoint Jaringan (NEG) Konektivitas Hybrid, yang masing-masing mengarah ke alamat IP pribadi ENI di VPC AWS atau NIC di VNet Azure Anda.
  5. Traffic mengalir dari ILB, melalui NEG, melintasi interconnect pribadi, ke ENI AWS atau NIC Azure.
  6. AWS ENI, bagian dari endpoint antarmuka VPC Amazon S3 (AWS PrivateLink), atau NIC Azure, bagian dari endpoint pribadi ADLS Gen2 (Azure Private Link), menyediakan akses pribadi ke layanan Amazon S3 atau ADLS Gen2.

Internet publik (tanpa CCI)

Jika Anda tidak mengonfigurasi interkoneksi pribadi, kueri ke katalog jarak jauh Anda akan dikirim melalui internet publik secara default.

Saat mengkueri data melalui internet publik, pertimbangkan implikasi berikut:

  • Enkripsi standar: Permintaan akses data dan transfer data dienkripsi dalam pengiriman menggunakan protokol TLS standar di seluruh internet publik.
  • Biaya egress: Transfer data dikenai biaya egress internet standar dari penyedia cloud jarak jauh Anda (misalnya, AWS atau Azure), yang biasanya lebih tinggi daripada tarif egress interkoneksi pribadi.
  • Latensi variabel: Performa, bandwidth, dan latensi jaringan bergantung pada perutean dan kemacetan internet publik, sehingga waktu eksekusi kueri menjadi kurang dapat diprediksi dibandingkan dengan interkoneksi pribadi khusus.
  • Penyiapan yang disederhanakan: Tidak memerlukan infrastruktur jaringan tambahan, peering VPC, atau konfigurasi Direktori Layanan di Google Cloud atau penyedia cloud jarak jauh Anda.

Ringkasan arsitektur

Saat mengkueri data melalui internet publik, Lakehouse terhubung langsung ke endpoint penyimpanan objek dan katalog jarak jauh Anda tanpa memerlukan infrastruktur jaringan cloud jarak jauh atau pribadi Google Cloud .

Alur kerja kueri internet publik mengikuti proses berikut:

  1. BigQuery memulai kueri terhadap tabel jarak jauh yang ditentukan dalam katalog Lakehouse Anda.
  2. Lakehouse melakukan autentikasi secara aman dengan katalog Apache Iceberg jarak jauh Anda menggunakan kredensial yang disimpan di Secret Manager atau penggabungan token OIDC.
  3. Lakehouse mengambil metadata tabel dan file manifes melalui internet publik untuk mengidentifikasi file data pokok yang relevan (misalnya, di Amazon S3 atau ADLS Gen2).
  4. Permintaan akses data untuk objek yang mendasarinya dikirim langsung dari Google Cloud melalui internet publik menggunakan enkripsi TLS standar.
  5. Layanan penyimpanan jarak jauh memverifikasi permintaan menggunakan kredensial sementara yang tercakup dan disediakan oleh Lakehouse, serta menampilkan blok file yang diminta melalui internet publik ke Google Cloud.

Caching cerdas

Untuk membantu mengurangi biaya traffic keluar lintas cloud dan mempercepat kueri yang membaca blok file yang sama, Anda dapat mengaktifkan caching lintas cloud di katalog gabungan Lakehouse dan koneksi lintas cloud BigQuery tanpa biaya tambahan.

Saat Anda mengaktifkan caching lintas cloud, Lakehouse akan meng-cache blok file yang diambil dari Amazon S3 atau Azure Blob Storage secara lokal dalam region eksekusi kueri Google Cloud . Kueri berikutnya, termasuk kueri berbeda yang menargetkan blok file yang sama, akan dibaca langsung dari cache lokal, bukan mengambil ulang file dari cloud jarak jauh.

Google otomatis mengelola kapasitas, retensi, dan penghapusan cache. Penghematan biaya egress Anda yang sebenarnya bergantung pada pola kueri, seberapa sering file sumber berubah, dan retensi cache di region Google Cloudtarget. Sebelum menyajikan data yang di-cache, setiap kueri memverifikasi metadata dan izin akses dengan sumber penyimpanan jarak jauh sehingga Anda tidak membaca data yang sudah tidak berlaku atau mengabaikan izin yang dicabut.

Caching lintas cloud dinonaktifkan secara default. Anda dapat mengaktifkan atau menonaktifkan caching saat membuat atau memperbarui katalog gabungan Lakehouse atau koneksi lintas cloud BigQuery. Untuk petunjuk konfigurasi, lihat panduan penyiapan untuk penyedia katalog yang didukung atau Membuat koneksi lintas cloud.

Memverifikasi penggunaan cache dan penghematan biaya egress

Untuk memverifikasi rasio cache ditemukan dan mengukur penghematan biaya egress, periksa detail tugas di konsol BigQuery atau periksa kolom objectStorageStats (object_storage_stats) di statistik tugas kueri JobStatistics2 BigQuery:

  • cloudProvider (cloud_provider): penyedia cloud yang menghosting penyimpanan objek (misalnya, AWS atau AZURE).
  • cacheBytesRead (cache_bytes_read): total byte yang dibaca dari cache Google Cloud lokal, sehingga menghindari pembacaan penyimpanan objek jarak jauh.
  • objectStorageBytesRead (object_storage_bytes_read): total byte yang dibaca langsung dari penyimpanan objek penyedia cloud.

Untuk mengetahui petunjuk tentang cara mengambil metrik ini menggunakan alat command line bq, lihat Memantau penggunaan cache dan penghematan biaya egress.

Pertimbangan residensi data dan yurisdiksi

Saat Anda mengaktifkan caching lintas cloud, Lakehouse akan menyimpan sementara salinan file jarak jauh yang di-cache dalam penyimpanan di region Google Cloud tempat kueri dijalankan. Sebelum mengaktifkan caching untuk file yang berada di region atau yurisdiksi geografis lain (misalnya, Amazon S3 atau Azure Blob Storage di Uni Eropa yang dikueri dari us-east4), pastikan bahwa menyimpan salinan sementara yang di-cache di regionGoogle Cloud target memenuhi persyaratan residensi data dan kepatuhan organisasi Anda.

Dukungan enkripsi dan CMEK

Data yang di-cache dienkripsi dalam penyimpanan menggunakanGoogle-owned and Google-managed encryption keysdefault. Kunci enkripsi yang dikelola pelanggan (CMEK) tidak didukung untuk caching lintas cloud.

Jika organisasi Anda menerapkan batasan kebijakan organisasi Restrict Non-CMEK Services (constraints/gcp.restrictNonCmekServices), Lakehouse akan otomatis menonaktifkan caching untuk kueri yang mengakses tabel yang dibatasi. Kueri Anda tetap berjalan, tetapi dibaca langsung dari penyimpanan jarak jauh tanpa meng-cache blok file.

Mode identitas

Lakehouse mendukung dua mode identitas untuk akses data lintas cloud:

  • Identitas layanan (default): Pembaruan metadata latar belakang dan kueri dijalankan menggunakan akun layanan katalog, yang dapat dikonfigurasi dengan autentikasi OIDC (direkomendasikan) atau berbasis Secret.

  • Federasi identitas pengguna: Pemuatan ulang metadata latar belakang dijalankan menggunakan akun layanan katalog, tetapi kueri dijalankan menggunakan identitas pengguna akhir dan disebarkan ke katalog jarak jauh. Hal ini memungkinkan katalog jarak jauh mengatribusikan kueri dari Google Cloud ke pengguna akhir, sehingga memungkinkan penegakan izin dan pembuatan log audit. Federasi identitas harus dikonfigurasi di katalog jarak jauh.

Langkah berikutnya