Panduan Google Cloud: Bagaimana Menerapkan BigQuery Physical Storage Billing: Achieving 8x Compression di Production?
Ringkasan: Mengubah model billing BigQuery dari logical ke physical storage untuk data telemetri yang bersifat append-only dapat menghasilkan penghematan biaya hingga 70%. Dengan memanfaatkan kompresi format Capacitor yang mencapai rasio 8x dan melakukan tuning pada time-travel window melalui INFORMATION_SCHEMA.TABLE_STORAGE, enterprise dapat secara drastis menekan TCO tanpa mengorbankan performa query atau retensi data jangka panjang.
Halo, saya Doddi Priyambodo, Google Cloud SEA Solutions Consultant dan Principal Enterprise Architect. Di tahun 2026 ini, volume data yang dihasilkan oleh aplikasi enterprise—mulai dari log mikrolayanan Kubernetes, clickstream pengguna, hingga telemetri perangkat IoT—telah mencapai skala eksabita. Dalam banyak interaksi saya dengan CTO dan VP of Engineering di Asia Tenggara, keluhan nomor satu yang selalu muncul di meja diskusi adalah tagihan penyimpanan data analitik yang membengkak.
Secara historis, banyak organisasi membuang data telemetri mereka setelah 30 hari karena biaya penyimpanannya dianggap tidak masuk akal. Namun, di era di mana model AI generatif seperti Gemini 2.5 Pro membutuhkan konteks historis yang masif untuk melakukan root cause analysis atau deteksi anomali, membuang data bukanlah sebuah opsi. Kita harus menyimpannya, dan kita harus menyimpannya dengan murah. Di sinilah pemahaman mendalam tentang arsitektur penyimpanan fisik BigQuery menjadi senjata rahasia seorang arsitek cloud. Artikel ini adalah blueprint teknis dan panduan FinOps definitif tentang bagaimana saya merancang migrasi dari logical ke physical storage billing di BigQuery untuk beban kerja telemetri berskala Petabyte.
Apa yang Baru Dirilis Google Cloud & Masalah Enterprise yang Diselesaikan
Selama bertahun-tahun, BigQuery secara default menagih pelanggan berdasarkan logical bytes—yakni ukuran data mentah yang tidak terkompresi. Model ini sangat sederhana dan mudah diprediksi. Jika Anda memasukkan 1 TB file JSON atau CSV ke dalam BigQuery, Anda akan ditagih untuk 1 TB penyimpanan aktif (sekitar $20 per bulan). Namun, model ini menyembunyikan sebuah keajaiban engineering yang terjadi di balik layar: BigQuery tidak pernah benar-benar menyimpan data Anda dalam format mentah.
Di bawah kap mesinnya, BigQuery menggunakan format penyimpanan berorientasi kolom (columnar storage) yang sangat canggih bernama Capacitor. Format Capacitor menggunakan berbagai teknik kompresi agresif seperti Run-Length Encoding (RLE), dictionary encoding, dan delta encoding. Untuk data telemetri—yang biasanya berisi ribuan baris dengan nilai timestamp yang berurutan, status HTTP yang berulang (seperti "200 OK"), dan struktur JSON bersarang yang identik—Capacitor dapat dengan mudah mencapai rasio kompresi 5x hingga 12x. Masalahnya bagi enterprise adalah: dalam model logical billing, Google Cloud yang menikmati keuntungan dari kompresi ini, bukan Anda.
Google Cloud kemudian merilis kemampuan untuk beralih ke Physical Storage Billing di tingkat dataset. Ini adalah perubahan paradigma yang masif. Dengan model ini, Anda ditagih berdasarkan ukuran data setelah dikompresi oleh Capacitor. Harga per gigabyte untuk physical storage memang lebih mahal ($0.04/GiB-bulan dibandingkan $0.02/GiB-bulan untuk logical), tetapi karena rasio kompresi telemetri rata-rata mencapai 8x, matematika FinOps-nya sangat menguntungkan pelanggan.
Namun, pengalaman saya di lapangan menunjukkan bahwa ini bukanlah tombol ajaib yang bisa Anda tekan begitu saja tanpa risiko. Ada sebuah "jebakan" arsitektural yang sering menjatuhkan tim Data Engineering yang kurang waspada: Time Travel dan Fail-safe.
Ketika Anda beralih ke physical billing, Anda tidak hanya membayar untuk data aktif yang terkompresi, tetapi Anda juga harus membayar untuk byte fisik yang digunakan oleh fitur Time Travel dan Fail-safe. Time Travel memungkinkan Anda melakukan query pada snapshot data dari masa lalu (hingga 7 hari secara default), sementara Fail-safe adalah jendela retensi tambahan 7 hari yang dikelola oleh Google untuk pemulihan bencana. Jika tabel Anda memiliki tingkat mutasi yang tinggi (banyak operasi UPDATE, DELETE, atau MERGE), BigQuery harus menyimpan versi lama dari blok data tersebut. Dalam skenario churn tinggi ini, ukuran time-travel physical bytes bisa membengkak melebihi ukuran data aktif itu sendiri, membuat tagihan physical billing Anda justru lebih mahal daripada logical billing.
Inilah mengapa blueprint ini secara spesifik menargetkan Tabel Telemetri. Data telemetri bersifat append-only (hanya disisipkan, tidak pernah dihapus atau diubah secara individual). Karena tidak ada mutasi, overhead Time Travel mendekati nol. Untuk memvalidasi hipotesis ini sebelum melakukan perubahan, Google Cloud menyediakan view sistem yang sangat krusial: INFORMATION_SCHEMA.TABLE_STORAGE. Anda dapat membaca dokumentasi resminya di https://cloud.google.com/bigquery/docs/information-schema-table-storage. View ini mengekspos metrik presisi tinggi seperti active_logical_bytes, active_physical_bytes, dan time_travel_physical_bytes, yang memungkinkan kita menghitung rasio kompresi aktual secara deterministik sebelum mengambil keputusan FinOps.
Arsitektur Referensi di Google Cloud
Sebagai seorang Principal Architect, aturan emas saya adalah: Isolasi domain penagihan Anda. Jangan pernah mencampur tabel transaksional (yang sering di-update) dengan tabel telemetri (yang append-only) di dalam dataset yang sama. Karena pengaturan billing model diterapkan pada level dataset, kita harus mendesain topologi penyimpanan yang memisahkan beban kerja berdasarkan pola mutasinya.
Berikut adalah arsitektur referensi produksi yang saya terapkan untuk pipeline telemetri berskala besar:
flowchart LR
subgraph Ingestion Layer
A[GKE Microservices] -->|Fluent Bit / OTel| B(Pub/Sub Telemetry Topic)
B --> C{Dataflow / Cloud Run}
end
subgraph BigQuery Storage Layer
C -->|Streaming Insert / Storage Write API| D[(Dataset: bq_telemetry_prod)]
D -.->|Billing Model: PHYSICAL| E[Capacitor Compressed Storage]
D -.->|Time Travel: 2 Days| F[Time Travel Storage]
end
subgraph FinOps & AI Analysis Layer
G[INFORMATION_SCHEMA.TABLE_STORAGE]
D --> G
G -->|Scheduled Query| H[(Dataset: bq_finops_metrics)]
H --> I[Looker TCO Dashboard]
H -->|Vertex AI SDK| J((Gemini 2.5 Pro FinOps Agent))
end
classDef gcp fill:#fbbc04,stroke:#ea4335,stroke-width:2px,color:black;
classDef storage fill:#34a853,stroke:#188038,stroke-width:2px,color:white;
classDef ai fill:#4285f4,stroke:#1a73e8,stroke-width:2px,color:white;
class A,B,C gcp;
class D,E,F storage;
class J ai;
Dalam arsitektur di atas, data telemetri mengalir dari klaster Google Kubernetes Engine (GKE) melalui agen OpenTelemetry atau Fluent Bit menuju Pub/Sub. Dari sana, pipeline Dataflow atau layanan Cloud Run menggunakan BigQuery Storage Write API (dengan semantik exactly-once) untuk menyisipkan data secara streaming ke dalam dataset khusus bernama bq_telemetry_prod.
Dataset ini dikonfigurasi secara eksplisit dengan storage_billing_model = PHYSICAL. Selain itu, karena ini adalah data telemetri di mana pemulihan dari kesalahan manusia (seperti tidak sengaja menjalankan DELETE tanpa klausa WHERE) dapat dimitigasi dengan memutar ulang pesan dari Pub/Sub, kita menurunkan jendela Time Travel dari default 7 hari menjadi hanya 2 hari. Ini secara drastis memangkas potensi overhead penyimpanan fisik.
Di lapisan observabilitas, kita tidak melakukan tebak-tebakan. Kita menggunakan Scheduled Query yang membaca dari INFORMATION_SCHEMA.TABLE_STORAGE setiap malam untuk merekam rasio kompresi historis ke dalam dataset FinOps terpisah. Data ini kemudian divisualisasikan di Looker dan dianalisis secara otomatis oleh agen AI yang ditenagai oleh model Gemini 2.5 Pro untuk mendeteksi anomali kompresi (misalnya, jika seorang developer tiba-tiba mulai mengirimkan payload biner terenkripsi yang merusak rasio kompresi Capacitor).
Implementasi Langkah demi Langkah
Mari kita terjemahkan arsitektur di atas menjadi eksekusi teknis yang nyata. Implementasi ini terdiri dari fase penemuan (discovery), eksekusi infrastruktur, dan otomatisasi analisis.
Langkah 1: Analisis Rasio Kompresi dengan SQL
Sebelum mengubah apa pun di production, Anda wajib menjalankan query diagnostik ini. Query ini memanfaatkan TABLE_STORAGE view untuk menghitung persis berapa banyak uang yang akan Anda hemat (atau hilangkan) jika Anda beralih ke physical billing.
-- Jalankan di BigQuery Studio
WITH storage_metrics AS (
SELECT
table_schema AS dataset_name,
table_name,
-- Logical Bytes
(active_logical_bytes + long_term_logical_bytes) / POW(1024, 3) AS total_logical_gib,
-- Physical Bytes (termasuk overhead)
(active_physical_bytes + long_term_physical_bytes + time_travel_physical_bytes + fail_safe_physical_bytes) / POW(1024, 3) AS total_physical_gib,
-- Rasio Kompresi
SAFE_DIVIDE(
(active_logical_bytes + long_term_logical_bytes),
(active_physical_bytes + long_term_physical_bytes)
) AS base_compression_ratio
FROM
`region-us`.INFORMATION_SCHEMA.TABLE_STORAGE
WHERE
table_schema = 'bq_telemetry_prod'
)
SELECT
dataset_name,
table_name,
ROUND(total_logical_gib, 2) AS logical_gib,
ROUND(total_physical_gib, 2) AS physical_gib,
ROUND(base_compression_ratio, 2) AS compression_ratio,
-- Kalkulasi Biaya (Asumsi harga us-central1)
ROUND(total_logical_gib * 0.02, 2) AS estimated_logical_cost_usd,
ROUND(total_physical_gib * 0.04, 2) AS estimated_physical_cost_usd,
ROUND((total_logical_gib * 0.02) - (total_physical_gib * 0.04), 2) AS potential_savings_usd
FROM
storage_metrics
ORDER BY
potential_savings_usd DESC;
Jika kolom potential_savings_usd menunjukkan angka positif yang besar (yang biasanya terjadi jika compression_ratio di atas 2.5x), Anda memiliki lampu hijau untuk melanjutkan.
Langkah 2: Tuning Time Travel dan Konfigurasi Dataset via Terraform
Sebagai best practice rekayasa keandalan situs (SRE), kita tidak melakukan perubahan melalui konsol UI. Kita mendefinisikan infrastruktur sebagai kode (IaC) menggunakan Terraform. Berikut adalah blok konfigurasi yang tepat untuk membuat dataset telemetri yang dioptimalkan secara fisik.
resource "google_bigquery_dataset" "telemetry_prod" {
dataset_id = "bq_telemetry_prod"
friendly_name = "Production Telemetry Data"
description = "Dataset for append-only telemetry with physical billing"
location = "US"
# KUNCI FINOPS: Ubah model penagihan ke fisik
storage_billing_model = "PHYSICAL"
# KUNCI OPTIMASI: Kurangi jendela time travel ke 48 jam (2 hari)
# Ini meminimalkan overhead time_travel_physical_bytes
max_time_travel_hours = "48"
labels = {
environment = "production"
cost_center = "platform-engineering"
data_type = "append-only-logs"
}
}
Jika Anda perlu mengubah dataset yang sudah ada tanpa Terraform, Anda dapat menggunakan perintah bq CLI yang sangat spesifik ini:
# Mengubah dataset yang sudah ada ke physical billing dan 2 hari time travel
bq update \
--storage_billing_model=PHYSICAL \
--max_time_travel_hours=48 \
project_id:bq_telemetry_prod
Langkah 3: Analisis FinOps Otomatis dengan Vertex AI Gemini 2.5 Pro
Di tahun 2026, kita tidak lagi menganalisis anomali kompresi secara manual. Saya selalu mengimplementasikan skrip Python ringan yang berjalan di Cloud Run, mengambil data dari TABLE_STORAGE, dan menggunakan model gemini-2.5-pro untuk memberikan rekomendasi FinOps dalam bahasa manusia kepada tim Data Engineering.
import os
from google.cloud import bigquery
from google import genai
from google.genai import types
def analyze_storage_efficiency(project_id: str, dataset_id: str):
# Inisialisasi BigQuery Client
bq_client = bigquery.Client(project=project_id)
# Ambil metrik dari INFORMATION_SCHEMA
query = f"""
SELECT table_name, active_logical_bytes, active_physical_bytes, time_travel_physical_bytes
FROM `{project_id}.region-us.INFORMATION_SCHEMA.TABLE_STORAGE`
WHERE table_schema = '{dataset_id}'
LIMIT 10
"""
df = bq_client.query(query).to_dataframe()
# Konversi data ke string untuk konteks LLM
context_data = df.to_csv(index=False)
# Inisialisasi Vertex AI GenAI SDK (Gemini 2.5 Pro)
# Menggunakan model aktif tahun 2026
ai_client = genai.Client(vertexai=True, project=project_id, location="us-central1")
prompt = f"""
Anda adalah Principal FinOps Architect. Analisis data BigQuery TABLE_STORAGE berikut.
Data ini menunjukkan byte logis, byte fisik, dan byte time-travel.
Berikan rekomendasi apakah tabel-tabel ini cocok untuk PHYSICAL storage billing.
Fokus pada rasio kompresi (logical/physical) dan peringatkan jika time_travel_physical_bytes terlalu tinggi.
Data:
{context_data}
"""
response = ai_client.models.generate_content(
model='gemini-2.5-pro',
contents=prompt,
config=types.GenerateContentConfig(
temperature=0.2,
)
)
print("Rekomendasi FinOps AI:")
print(response.text)
# Eksekusi fungsi
# analyze_storage_efficiency("my-gcp-project", "bq_telemetry_prod")
Skrip ini bertindak sebagai "penjaga gerbang" cerdas yang dapat diintegrasikan ke dalam alur kerja CI/CD atau dijalankan sebagai cron job mingguan untuk memastikan tidak ada regresi dalam efisiensi penyimpanan.
Kesiapan Production: FinOps, Kuota & Guardrails Keamanan
Mengubah model penagihan adalah keputusan finansial tingkat tinggi. Sebelum Anda meluncurkan perubahan ini ke seluruh organisasi, Anda harus memahami dampak TCO (Total Cost of Ownership), batasan kuota, dan kontrol keamanan yang diperlukan.
📊 Simulasi FinOps & TCO Produksi
Untuk memberikan gambaran konkret, saya telah menjalankan simulasi deterministik menggunakan alat kalkulasi FinOps resmi Google Cloud. Skenario ini mengasumsikan sebuah enterprise yang menghasilkan 1 Petabyte (1.000.000 GiB) data telemetri mentah setiap bulannya.
📊 Simulasi FinOps & TCO Produksi: Simulasi TCO: Logical vs Physical Storage untuk 1 PB Telemetry Data (Perhitungan SKU Terverifikasi)
Asumsi Beban Kerja Produksi (us-central1 / asia-southeast1):
- 1 PB (1,000,000 GiB) raw telemetry/log data per bulan.
- Rasio kompresi 8x (125,000 GiB physical base) berkat format Capacitor BigQuery.
- Data bersifat append-only (time-travel churn rendah). Time-travel window di-tune ke 2 hari.
- Overhead Time-travel & Fail-safe diasumsikan menambah 30% dari base physical storage (total 162,500 GiB physical).
| Opsi Arsitektur |
Rincian Rumus & Harga Satuan SKU (Resmi) |
Total Biaya Bulanan Terverifikasi |
| Opsi A: Logical Storage Billing (Default) |
BigQuery Logical Storage (1 PB Uncompressed): $0.02/GiB-month × 1,000,000 = $20,000.00 |
$20,000.00 / mo |
| Opsi B: Physical Storage Billing (Optimized) |
BigQuery Physical Storage (Compressed + Time Travel + Fail-safe): $0.04/GiB-month × 162,500 = $6,500.00 |
$6,500.00 / mo |
| Dampak Net FinOps (Penghematan Bulanan) |
Terverifikasi dengan Python SKU Engine |
Penghematan 67.5% ($13,500.00 / bulan) |
Sumber Harga Resmi Google Cloud (2026.09): cloud.google.com
Seperti yang Anda lihat dari tabel di atas, meskipun harga satuan physical storage dua kali lipat lebih mahal, kompresi 8x yang dihasilkan oleh Capacitor menghancurkan kalkulasi tersebut. Penghematan sebesar $13.500 per bulan (atau lebih dari $160.000 per tahun) hanya dari satu dataset adalah kemenangan FinOps yang masif yang akan membuat CFO Anda tersenyum lebar.
Kuota dan Batasan Sistem
Pengalaman saya mengajarkan bahwa selalu ada batasan tersembunyi saat beroperasi di skala Petabyte. Saat Anda beralih ke physical billing, perhatikan hal-hal berikut:
- Batas Perubahan Model Penagihan: Anda hanya dapat mengubah model penagihan penyimpanan (storage billing model) pada sebuah dataset sekali setiap 14 hari. Ini adalah mekanisme perlindungan dari Google untuk mencegah eksploitasi arbitrase harga. Oleh karena itu, pastikan analisis
TABLE_STORAGE Anda solid sebelum mengeksekusi perintah bq update.
- Kapasitas Storage Write API: Jika Anda menyerap data telemetri dalam jumlah besar secara real-time, pastikan kuota throughput Storage Write API Anda di wilayah tersebut mencukupi. Kompresi Capacitor terjadi di latar belakang secara asinkron; data yang baru masuk mungkin awalnya memakan ruang fisik yang lebih besar sebelum proses pemadatan (compaction) internal BigQuery berjalan.
Guardrails Keamanan dan Tata Kelola (Governance)
Di lingkungan enterprise yang diatur ketat (seperti perbankan atau telekomunikasi di Asia Tenggara), kita tidak bisa membiarkan sembarang engineer mengubah model penagihan.
1. Identity and Access Management (IAM)
Untuk mengubah storage_billing_model, seorang pengguna atau service account memerlukan izin bigquery.datasets.update. Izin ini secara default tergabung dalam role roles/bigquery.dataOwner atau roles/bigquery.admin. Praktik terbaik saya adalah mencabut role ini dari pengguna manusia di lingkungan produksi dan hanya memberikannya kepada Service Account Terraform yang dijalankan melalui pipeline CI/CD yang diaudit.
2. VPC Service Controls (VPC-SC)
Data telemetri sering kali mengandung informasi sensitif (PII) yang bocor melalui log aplikasi. Memastikan dataset BigQuery Anda berada di dalam perimeter VPC Service Controls adalah kewajiban mutlak. Ini mencegah eksfiltrasi data, bahkan jika seseorang memiliki kredensial IAM yang valid, mereka tidak dapat melakukan query atau mengekstrak data dari luar jaringan korporat yang diizinkan.
3. Organization Policies
Sayangnya, per tahun 2026, belum ada Organization Policy Constraint bawaan yang memaksa semua dataset baru untuk menggunakan physical billing. Oleh karena itu, tata kelola harus ditegakkan melalui modul Terraform standar perusahaan. Tim Platform Engineering harus menyediakan modul terraform-google-bigquery-dataset yang sudah di- hardcode dengan logika kondisional: jika variabel dataset_type diisi dengan "telemetry", maka modul secara otomatis menerapkan PHYSICAL billing dan membatasi max_time_travel_hours ke 48 jam.
Sebagai penutup, menguasai mekanisme penyimpanan fisik BigQuery bukan sekadar latihan teknis; ini adalah kompetensi inti bagi arsitek data modern. Dengan memahami bagaimana Capacitor memampatkan data, bagaimana Time Travel memengaruhi tagihan fisik, dan bagaimana memantau semuanya melalui INFORMATION_SCHEMA.TABLE_STORAGE, Anda mengubah pusat biaya (cost center) menjadi keunggulan kompetitif bagi enterprise Anda. Jangan biarkan data telemetri Anda membusuk atau menguras anggaran—kompres, optimalkan, dan manfaatkan untuk inovasi AI masa depan.
