Tentang akses data lintas cloud

Fitur akses data lintas cloud memungkinkan Anda membuat kueri data yang disimpan di penyedia cloud lain langsung dari Google Cloud tanpa memigrasikan file atau membuat pipeline ETL yang kompleks dengan Cross-Cloud Interconnect.

Sebagai bagian dari Lakehouse tanpa batas, kemampuan ini memungkinkan Anda melakukan analisis terpadu dan menerapkan AI di seluruh set data terdistribusi menggunakan BigQuery, lingkungan Apache Spark mandiri, atau Managed Service untuk Apache Spark.

Selain kueri analitis, Anda dapat menggunakan data gabungan untuk insight dan tata kelola yang didukung AI:

  • Analisis Percakapan: Buat agen khusus yang didasarkan pada sumber data persis Anda, termasuk tabel lintas cloud, untuk menganalisis data di seluruh cloud dari satu percakapan.
  • Knowledge Catalog: Gunakan fitur Knowledge Catalog untuk pembuatan profil dan insight data dengan sumber data gabungan.

Kasus penggunaan

Lakehouse mendukung beberapa kasus penggunaan utama untuk mengakses data di beberapa penyedia cloud:

  • Pengurangan pemindahan data memungkinkan Anda mengkueri data yang disimpan di lingkungan cloud lain secara langsung, sehingga menyederhanakan akses dan pemrosesan data.
  • Analisis terpadu memungkinkan Anda melakukan analisis lanjutan dengan fitur yang konsisten dan pengoptimalan hardware di semua data Anda, di mana pun data tersebut berada.
  • AI dan ML tanpa Batas memungkinkan Anda menerapkan model AI, agen otonom, dan machine learning langsung ke data jarak jauh Anda tanpa memigrasikannya.

Cara kerja akses data lintas-cloud

Lakehouse membuat kueri data jarak jauh menggunakan proses berikut:

  1. Penemuan metadata: Google Cloud's Lakehouse terhubung ke katalog REST Apache Iceberg jarak jauh, seperti Databricks Unity atau AWS Glue. Lakehouse menemukan data tanpa menyalin file apa pun. Bergantung pada penyedia katalog jarak jauh, Lakehouse mengautentikasi secara aman melalui Secret Manager atau federasi token OpenID Connect dengan Google sebagai penyedia identitas (federasi token OIDC).
  2. Transportasi yang aman: Memilih untuk merutekan traffic melalui interkoneksi pribadi (misalnya, CCI Khusus atau Partner Interconnect) secara signifikan mengurangi biaya transfer data dibandingkan dengan internet publik dan membuat latensi sangat dapat diprediksi.
  3. Eksekusi yang dioptimalkan: Saat kueri membaca data dari cloud jarak jauh, Lakehouse akan menyimpan sementara segmen data tersebut secara lokal dalam Google Cloud penyimpanan khusus. Kueri berikutnya menggunakan cache lokal, yang menghindari sebagian besar biaya keluar lintas cloud.

Katalog yang didukung

Lakehouse mendukung kueri data dari penyedia katalog jarak jauh berikut:

  • Databricks Unity Catalog: Didukung di Amazon Web Services (AWS) dan Google Cloud.
  • AWS Glue: Didukung di Amazon Web Services (AWS).
  • Katalog Snowflake Horizon: Didukung di Amazon Web Services (AWS) dan Google Cloud.
  • SAP Business Data Cloud (BDC): Didukung menggunakan konektor SAP BDC.

Konsep inti

Bagian ini menjelaskan komponen utama yang penting untuk menggunakan fitur akses data lintas cloud.

Lapisan metadata

Lapisan metadata terhubung ke endpoint katalog REST Apache Iceberg jarak jauh untuk menyinkronkan metadata resource Iceberg (namespace, tabel) berdasarkan interval refresh. Lakehouse mengautentikasi secara aman dengan kredensial OAuth yang disimpan di Secret Manager atau federasi token OIDC.

Lapisan transpor

Lapisan transportasi memungkinkan BigQuery dan mesin open source untuk mengueri data menggunakan metadata yang disinkronkan dari lapisan metadata. Untuk jenis katalog jarak jauh tertentu, 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 membuat kueri data yang disimpan di bucket Amazon S3 Amazon Web Services (AWS) melalui Cross-Cloud Interconnect pribadi menggunakan Dedicated Cross-Cloud Interconnect atau Partner Cross-Cloud Interconnect.

Menggunakan interkoneksi pribadi memberikan manfaat berikut:

  • Peningkatan keamanan: Data berpindah melalui koneksi jaringan pribadi antara Google Cloud dan AWS, sehingga tidak menggunakan internet publik.
  • Biaya yang lebih rendah: Berpotensi menurunkan biaya traffic keluar dari AWS dibandingkan dengan traffic keluar internet, terutama jika digabungkan dengan kapasitas interkoneksi pribadi Anda.
  • Performa yang konsisten: Latensi dan bandwidth jaringan yang lebih mudah diprediksi dibandingkan dengan internet publik.

Ringkasan arsitektur

Untuk mengaktifkan kueri pribadi, Anda mengonfigurasi jalur dari BigQuery ke bucket AWS Amazon S3 melalui interkoneksi pribadi Anda. Komponen utama dalam Google Cloud Virtual Private Cloud (VPC) (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.

Menggunakan ILB dengan beberapa Elastic Network Interface (ENI) sebagai backend sangat penting untuk load balancing, skalabilitas, dan ketersediaan tinggi. Hal ini berlaku baik Anda menggunakan CCI Khusus atau Partner Interconnect.

Alur kerja kueri pribadi mengikuti proses ini:

  1. BigQuery menggunakan koneksi yang dikonfigurasi dengan layanan Service Directory.
  2. Service Directory 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 Anda.
  5. Traffic mengalir dari ILB, melalui NEG, di seluruh interkoneksi pribadi, ke ENI AWS.
  6. ENI AWS, yang merupakan bagian dari Endpoint Antarmuka VPC Amazon S3 (AWS PrivateLink), memberikan akses pribadi ke layanan Amazon S3.

Internet publik (tanpa CCI)

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

Saat membuat kueri 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 traffic keluar: Transfer data dikenai biaya traffic keluar internet standar dari penyedia cloud jarak jauh Anda (misalnya, AWS), yang biasanya lebih tinggi daripada tarif traffic keluar interkoneksi pribadi.
  • Latensi variabel: Performa jaringan, bandwidth, dan latensi bergantung pada perutean dan kemacetan internet publik, sehingga waktu eksekusi kueri kurang dapat diprediksi dibandingkan dengan interkoneksi pribadi khusus.
  • Penyiapan yang disederhanakan: Tidak memerlukan infrastruktur jaringan tambahan, peering VPC, atau konfigurasi Service Directory di Google Cloud atau penyedia cloud jarak jauh Anda.

Ringkasan arsitektur

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

Alur kerja kueri internet publik mengikuti proses berikut:

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

Caching cerdas

Saat Anda membuat kueri data cloud jarak jauh, Lakehouse akan otomatis menyimpan dalam cache blok data yang diambil secara lokal dalam Google Cloud. Caching diaktifkan secara otomatis untuk semua kueri lintas cloud guna membantu meminimalkan biaya keluar dari penyedia cloud jarak jauh. Kueri berikutnya yang menargetkan data yang di-cache dibaca langsung dari penyimpanan Google Cloud lokal, bukan mengambil ulang data di seluruh cloud.

Penghematan biaya traffic keluar

Saat eksekusi kueri awal, Lakehouse mengambil blok data yang diperlukan dari penyedia cloud jarak jauh dan mengisi cache lokal. Kueri berikutnya yang menargetkan blok data yang sama dibaca langsung dari cache Google Cloud lokal, bukan mengambil ulang data di seluruh cloud.

Untuk beban kerja dengan pola kueri berulang pada set data yang sama, caching mengurangi biaya keluar lintas cloud dengan menayangkan permintaan data dari penyimpanan lokal. Penghematan biaya keluar yang sebenarnya bergantung pada faktor-faktor seperti pola akses kueri, rasio modifikasi data, dan retensi cache di region target. Google Cloud

Memverifikasi penggunaan cache dan penghematan biaya egress dalam statistik tugas

Untuk memverifikasi rasio hit cache dan penghematan biaya keluar untuk kueri, periksa statistik kueri di konsol atau API BigQuery (JobStatistics2). Karena kueri dapat mereferensikan data di beberapa penyedia, statistik tugas menyediakan kolom object_storage_stats (objectStorageStats) berulang dengan entri untuk setiap penyedia cloud yang diakses selama eksekusi.

Setiap entri object_storage_stats melaporkan metrik berikut:

  • cloud_provider (cloudProvider): Penyedia cloud yang menghosting object storage (misalnya, AWS atau AZURE).
  • cache_bytes_read (cacheBytesRead): Total byte yang dibaca dari cache Google Cloud lokal, sehingga tidak perlu membaca penyimpanan objek jarak jauh.
  • object_storage_bytes_read (objectStorageBytesRead): Total byte yang dibaca langsung dari penyimpanan objek penyedia cloud jarak jauh.

Pertimbangan residensi dan yurisdiksi data

Membuat katalog atau koneksi gabungan di region Google Cloud menyimpan data dalam penyimpanan yang di-cache secara lokal dalam region target tersebut.

Jika data cloud jarak jauh Anda berada di wilayah geografis atau wilayah hukum yang berbeda (misalnya, AWS Amazon S3 di Uni Eropa yang dipasangkan dengan komputasi BigQuery di us-east4), pembuatan kueri lintas cloud menyimpan salinan data saat istirahat yang di-cache dari data jarak jauh di regionGoogle Cloud target. Pengguna atau administrator yang membuat koneksi atau katalog harus memastikan bahwa penyimpanan cache lintas yurisdiksi mematuhi persyaratan residensi data, kedaulatan, dan kepatuhan organisasi mereka.

Dukungan enkripsi dan CMEK

Kunci enkripsi yang dikelola pelanggan (CMEK) tidak didukung untuk penyiapan cache Lakehouse. Semua blok data yang di-cache dienkripsi saat dalam penyimpanan menggunakan Google-owned and Google-managed encryption keysdefault.

Jika organisasi Anda menerapkan batasan kebijakan organisasi Batasi Layanan Non-CMEK (constraints/gcp.restrictNonCmekServices), Lakehouse akan otomatis menonaktifkan caching untuk kueri yang mengakses tabel yang dibatasi. Kueri tetap berhasil dieksekusi, tetapi tidak menyimpan blok data dalam cache atau mendapatkan manfaat dari penghematan egress terkait cache.

Langkah berikutnya