Panduan Use Case Google Cloud: Bagaimana Menerapkan BigQuery Physical Storage Billing: Achieving 8x Compression on Telemetry Tables di Production?

Halo rekan-rekan tech leaders, Doddi Priyambodo di sini. Sebagai Enterprise Architect yang sering menangani massive data platform di region SEA, salah satu low-hanging fruit untuk optimasi cloud spend di tahun 2026 ini adalah manajemen storage billing di BigQuery.

Banyak enterprise masih membayar logical bytes untuk data telemetri, log, dan time-series mereka. Padahal, data jenis ini memiliki kardinalitas yang memungkinkan kompresi ekstrem. Mari kita bedah bagaimana kita bisa memanfaatkan INFORMATION_SCHEMA.TABLE_STORAGE untuk melakukan transisi ke Physical Storage Billing dan memangkas TCO hingga 80%.

Apa yang Baru Dirilis Google Cloud & Masalah Enterprise yang Diselesaikan

Secara default, BigQuery men-charge berdasarkan Logical Storage (ukuran data mentah/uncompressed). Masalahnya, untuk workload seperti telemetri IoT, clickstream, atau application logs, format data sangat repetitif (JSON keys, timestamps, status codes). Di backend, BigQuery menggunakan format columnar Capacitor yang secara otomatis mengompresi data ini dengan rasio yang bisa mencapai 8x hingga 12x.

Jika Anda menggunakan Logical Billing, Anda mensubsidi efisiensi kompresi ini. Google Cloud merilis kapabilitas untuk mengubah model billing di level dataset menjadi Physical Storage Billing. Dengan model ini, Anda hanya membayar bytes yang benar-benar tersimpan di disk setelah kompresi.

Tantangan Enterprise (The Catch): Saat Anda pindah ke Physical Billing, Anda juga mulai di-charge untuk Time Travel storage dan Fail-safe storage. Jika tabel Anda memiliki tingkat churn yang tinggi (banyak operasi UPDATE/DELETE), physical bytes dari historical snapshots bisa membengkak. Oleh karena itu, visibilitas menggunakan view TABLE_STORAGE menjadi sangat kritikal sebelum melakukan switch.

Arsitektur Referensi di Google Cloud

Berikut adalah arsitektur referensi FinOps-driven untuk mengotomatisasi analisis dan transisi storage billing menggunakan BigQuery dan Vertex AI di tahun 2026.

flowchart LR
    subgraph Data Ingestion
        A[Cloud Storage / PubSub] -->|Storage Write API| B(BigQuery Dataset: Telemetry)
    end

    subgraph BigQuery Storage Layer
        B -->|Capacitor Compression 8x| C[(Physical Storage)]
        B -->|Time Travel Window: 2-7 Days| C
    end

    subgraph FinOps & AI Automation
        C -.->|Query Metrics| D[INFORMATION_SCHEMA.TABLE_STORAGE]
        D -->|Extract Storage Stats| E[Cloud Run: FinOps Job]
        E -->|Analyze Compression Ratio| F{Vertex AI: gemini-3.1-pro-preview}
        F -->|Actionable Insights| G[Looker FinOps Dashboard]
        F -->|Auto-remediate| H[Terraform / bq CLI]
    end

Implementasi Langkah demi Langkah

Untuk mengeksekusi migrasi ini di production, kita tidak bisa menebak-nebak. Kita harus mengukur rasio kompresi dan overhead Time Travel.

1. Analisis Rasio Kompresi dengan SQL

Jalankan query ini untuk melihat dataset mana yang paling profitable untuk dipindah ke Physical Billing.

SELECT 
  table_schema AS dataset_name,
  SUM(active_logical_bytes) / POW(1024, 4) AS logical_tb,
  SUM(active_physical_bytes) / POW(1024, 4) AS physical_tb,
  SUM(time_travel_physical_bytes) / POW(1024, 4) AS time_travel_tb,
  -- Hitung rasio kompresi (semakin tinggi semakin baik)
  SUM(active_logical_bytes) / NULLIF(SUM(active_physical_bytes), 0) AS compression_ratio,
  -- Estimasi cost (Asumsi US Multi-region: Logical $20/TB, Physical $40/TB)
  (SUM(active_logical_bytes) / POW(1024, 4)) * 20 AS est_logical_cost,
  ((SUM(active_physical_bytes) + SUM(time_travel_physical_bytes)) / POW(1024, 4)) * 40 AS est_physical_cost
FROM 
  `region-us`.INFORMATION_SCHEMA.TABLE_STORAGE
WHERE 
  total_logical_bytes > 0
GROUP BY 
  1
HAVING 
  compression_ratio > 4.0 -- Filter dataset dengan kompresi di atas 4x
ORDER BY 
  est_logical_cost DESC;

2. Otomatisasi Analisis dengan Python & Vertex AI (Gemini 3.1 Pro Preview)

Di 2026, kita menggunakan LLM untuk memberikan rekomendasi FinOps secara dinamis berdasarkan hasil query di atas.

from google.cloud import bigquery
import vertexai
from vertexai.generative_models import GenerativeModel

# Inisialisasi client
project_id = "enterprise-data-hub-2026"
vertexai.init(project=project_id, location="asia-southeast1")
bq_client = bigquery.Client(project=project_id)

# Ambil data dari TABLE_STORAGE (menggunakan query di atas)
query = """
    SELECT table_schema, 
           SUM(active_logical_bytes)/POW(1024,4) as logical_tb, 
           SUM(active_physical_bytes)/POW(1024,4) as physical_tb,
           SUM(time_travel_physical_bytes)/POW(1024,4) as time_travel_tb
    FROM `region-asia-southeast1`.INFORMATION_SCHEMA.TABLE_STORAGE
    GROUP BY 1
"""
df = bq_client.query(query).to_dataframe()

# Gunakan model active 2026 untuk analisis FinOps
model = GenerativeModel("gemini-3.1-pro-preview")
prompt = f"""
Sebagai Principal Cloud FinOps Architect, analisis data storage BigQuery berikut:
{df.to_string()}
Berikan rekomendasi dataset mana yang harus diubah ke 'PHYSICAL' storage billing. 
Pertimbangkan bahwa Physical storage cost adalah $40/TB dan Logical adalah $20/TB.
Abaikan dataset dengan time_travel_tb yang sangat tinggi.
"""

response = model.generate_content(prompt)
print(response.text)

3. Eksekusi Perubahan Billing Model & Tuning Time Travel

Setelah mengidentifikasi dataset telemetri (misal: iot_telemetry_prod), ubah billing model dan turunkan Time Travel window (karena data telemetri biasanya append-only dan jarang butuh restore 7 hari ke belakang).

Menggunakan Terraform (Best Practice):

resource "google_bigquery_dataset" "telemetry_dataset" {