BigQuery maliyet kontrolü: tahmin, üst sınır ve izleme

İsteğe bağlı sorgu maliyeti neye bağlıdır?

BigQuery'de isteğe bağlı (on-demand) fiyatlandırmada ödediğiniz tutar, sorgularınızın işlediği veri miktarıyla orantılıdır. Sonucun kaç satır döndürdüğü değil, sorgunun kaç bayt okuduğu belirleyicidir. Bu yüzden maliyet kontrolü, esasen okunan baytı öngörme, sınırlama ve izleme işidir.

Alternatif model kapasite fiyatlandırmasıdır: burada slot adı verilen işlem gücünü rezervasyon ve taahhütlerle ayırırsınız. Kapasite modelinde sorgu başına bayt değil, ayırdığınız slot miktarı fatura belirler. Hangi modelin uygun olduğu iş yükünüzün öngörülebilirliğine bağlıdır; güncel birim fiyatlar Google Cloud'un fiyat sayfasında yayımlanır.

Bu sayfadaki yöntemlerin çoğu isteğe bağlı model içindir. Kapasite modelinde ise rezervasyonla slot tavanı koymak ve slot tahmincisiyle boyutlandırma yapmak asıl kontrol yöntemidir.

Sorguyu çalıştırmadan önce nasıl tahmin edersiniz?

En basit tahmin, Google Cloud konsolundaki sorgu düzenleyicisinde yapılır. Düzenleyici sorgunun sözdizimini denetler ve çalıştırmadan önce işlenecek tahmini bayt miktarını gösterir. Alışkanlık haline getirmeniz gereken ilk adım budur.

Otomasyonda ya da komut satırında kuru çalıştırma (dry run) kullanırsınız:

bq query --use_legacy_sql=false --dry_run 'SELECT customer_id, amount FROM sales.orders WHERE order_time >= @start_date'

API üzerinden aynı sonucu iş yapılandırmasında dryRun alanını true yaparak alırsınız. Kuru çalıştırma sorguyu yürütmez ve ücret doğurmaz, yalnızca tahmini bayt değerini döndürür.

Tahminin sınırlarını bilin. Kümeli tablolarda BigQuery hangi blokları okuyacağını önceden bilemediği için kuru çalıştırma bir üst sınır verir; gerçek faturalanan bayt daha düşük çıkabilir. Satır düzeyi güvenlik uygulanan tablolarda kuru çalıştırma sıfır bayt gösterebilir, bu yüzden tahmin bu tablolarda yanıltıcıdır.

Sorguyu ucuzlatan alışkanlıklar

BigQuery sütun bazlı depolama kullandığından yalnızca ihtiyaç duyduğunuz sütunları seçmek okunan veriyi doğrudan azaltır. Tüm sütunları çeken bir sorgu yerine ihtiyaç duyulan alanları adıyla yazın.

Tabloya göz atmak istiyorsanız sorgu çalıştırmayın. Tablo ekranındaki önizleme sekmesi, bq head komutu ya da tabledata.list yöntemi veriyi ücretsiz gösterir.

LIMIT eklemek kümelenmemiş tablolarda okunan veriyi değiştirmez. Resmî belgenin açıkça belirttiği bu nokta, en sık yapılan yanlış varsayımlardan biridir. Gerçek tasarruf, bölümlenmiş tablolarda bölüm filtresiyle ve kümeli tablolarda küme sütunu filtresiyle gelir; bu yöntemin ayrıntısı ayrı bir sayfada anlatılır.

Çok adımlı ve pahalı dönüşümlerde ara sonucu bir hedef tabloya yazın. Aynı ağır sorguyu her raporda yeniden çalıştırmak yerine hazır sonucu okumak hem hız hem maliyet kazandırır. Büyük sonuç tabloları için varsayılan tablo sona erme süresi tanımlamak da depolamada birikmeyi önler.

Faturalanacak bayta üst sınır koymak

İsteğe bağlı modelde en güçlü korumalardan biri en fazla faturalanacak bayt ayarıdır. Komut satırında --maximum_bytes_billed bayrağı, API'de maximumBytesBilled özelliği kullanılır. Sorgunun tahmini bu üst sınırı aşıyorsa sorgu çalışmaz ve ücret alınmaz.

Kullanımı basittir: bq query komutuna --maximum_bytes_billed bayrağını bayt cinsinden bir değerle eklersiniz; zamanlanmış sorgularda ve servis hesaplarında bu değeri varsayılan kılmak iyi bir uygulamadır. Kümeli tablolarda tahmin üst sınır olduğundan, gerçek faturalanan bayt sınırın altında kalacak olsa bile sorgu reddedilebilir; bu durumda sınırı gerçekçi bir değere yükseltmeniz gerekir.

Sınır, tek bir sorgu içindir. Gün boyunca toplam harcamayı sınırlamak için özel günlük sorgu kotaları tanımlayın: proje ya da kullanıcı başına günlük işlenecek veri miktarına sınır koyabilirsiniz. Kota dolduğunda sorgular durur. Bu iki katman birlikte hem tek sorgudaki kazayı hem de günlük taşmayı keser.

Bölümlü tablolarda ek bir güvence olarak bölüm filtresi zorunluluğunu açabilirsiniz; filtresiz bir sorgu hiç başlamaz.

Harcamayı kimin ne kadar yaptığını izleme

Kontrol, ölçmeden olmaz. INFORMATION_SCHEMA altındaki JOBS görünümü, projedeki sorgu işlerinin kaydını tutar; hangi kullanıcının ya da servis hesabının maliyeti yarattığını bulmak için en pratik kaynaktır. Örnek bir sorgu:

SELECT user_email, SUM(total_bytes_billed) AS billed_bytes FROM region_qualifier.INFORMATION_SCHEMA.JOBS WHERE creation_time >= @start_date GROUP BY user_email ORDER BY billed_bytes DESC;

region_qualifier yerine, veri kümelerinizin bulunduğu bölgenin niteleyicisini (örneğin region-eu biçiminde) ters tırnak içinde yazın. Aynı mantıkla sorgu metnine ya da etikete göre gruplayıp en pahalı tekrarlayan sorguları çıkarabilirsiniz. Listenin başında çıkan sorgular, bölümleme, kümeleme ya da ara tablo ile ucuzlatılacak ilk adaylardır.

Google Cloud faturalama tarafında bütçe ve uyarı tanımlamak son güvenlik ağıdır. Bütçe eşiği aşıldığında sorumlu ekip e-postayla haberdar edilir, böylece ay sonu faturasını beklemeden müdahale edebilirsiniz.

Pratik bir maliyet kontrol listesi

Yeni bir veri ambarı ekibi için sıra şöyle olabilir:

• Konsolda her sorgu öncesi tahmini bayta bakın.
• Servis hesaplarının ve zamanlanmış sorguların üstüne maximum bytes billed koyun.
• Proje ve kullanıcı için günlük özel kota belirleyin.
• Büyük olay tablolarını tarihe göre bölümleyin ve bölüm filtresini zorunlu yapın.
• Haftalık olarak JOBS görünümünden en pahalı kullanıcı ve sorguları listeleyin.
• Aynı ağır dönüşümü tekrarlayan raporlar için ara tablo kurun.
• Faturalama bütçesi ve uyarısı tanımlayın.
• Sürekli yüksek ve öngörülebilir iş yükünüz varsa kapasite fiyatlandırmasını değerlendirin.

Her maddenin bir sahibi olsun: kota ve bütçe platform ekibinde, sorgu düzeni analistlerde. Maliyet kontrolü tek seferlik bir ayar değil, düzenli bir gözden geçirme işidir.

Bu konuyu Mindset programlarında nerede çalışırsınız?

Maliyet kontrolü bir analistin kendi sorgusunu optimize etmesiyle başlar, platform ekibinin kota ve bütçe tanımlamasıyla tamamlanır. Mindset kataloğundaki BigQuery ile Bulut Sorgulama eğitimi müfredatında SQL ve maliyet yönetimi, bölümleme ve kümeleme ile performans, güvenlik ve maliyet yönetimi başlıklarını içerir; bu yüzden hem analist hem platform tarafı için uygundur.

Tablo tasarımıyla taranan veriyi azaltmak isteyen veri mühendisleri için BigQuery İleri Seviye: Bölümleme ve Kümeleme eğitimi, bölümleme stratejileri ile sorgu optimizasyonu ve yürütme analizini ayrıntılı işler. Kurumsal ekipler kendi sorgu geçmişlerini çalışma malzemesi yaparak sonuçları doğrudan kendi harcamalarına bağlayabilir.