1. GİRİŞ

Google BigQuery, petabayt ölçeğinde veriyi SQL ile sorgulamayı sağlayan, sunucusuz (serverless) bir veri ambarı hizmetidir. Kuruluşların büyük veri iş yüklerini yönetirken donanım/altyapı detaylarıyla uğraşmasını ortadan kaldırır; depolama ve hesaplama katmanlarını ayrıştırarak ölçeklenebilir, esnek ve maliyet etkin analizler sunar. Bu rehber BigQuery'nin iç mimarisini, temel bileşenlerini, nasıl çalıştığını ve üretimde karşılaşılan pratik konuları mühendis perspektifiyle ele alacaktır.

Bu teknoloji neden konuşuluyor?

Veri hacimlerinin hızla büyümesi, gerçek zamanlı analitik beklentileri ve maliyet yönetimi gereksinimleri, bulut tabanlı sunucusuz veri ambarlarına talebi artırdı. BigQuery, hem yüksek performanslı analizler hem de kullanım‑başına‑öde (pay‑per‑query) veya rezervasyon tabanlı modellerle esneklik sunması nedeniyle birçok kurum tarafından tercih ediliyor.

Kimler için önemli?

Veri mühendisleri, analistler, veri bilimciler, platform mühendisleri ve CTO/VP seviyesindeki teknik karar vericiler için önemlidir. Özellikle büyük veri işleyen, hızlı prototipleme ve analiz gerektiren ekipler BigQuery'den fayda sağlar.

Hangi problemleri çözüyor?

• Petabayt ölçeğinde veri üzerinde düşük-latency analitik sorgular
• Altyapı yönetimi olmadan ölçeklenebilir hesaplama
• Depolama ve hesaplamanın bağımsız ölçeklenmesi sayesinde maliyet ve performans dengelemesi

2. KAVRAMSAL TEMELLER

2.1 Temel terimler ve kavramlar

• Colossus: Google'ın dağıtık dosya sistemi; BigQuery'nin veri depolama katmanına temel sağlar.
• Dremel: Google'ın sütun‑odaklı dağıtık sorgu yürütme motoru; BigQuery'nin sorgu motorunun atası ve mimari ilham kaynağıdır.
• Slot: BigQuery'de sorgu hesaplama kaynağını temsil eden sanal CPU birimi; rezervasyon ve on‑demand modellerde yönetilir.
• Storage vs Compute ayrımı: BigQuery'de veriler Colossus üzerine depolanır; sorgular izole edilmiş hesaplama kaynaklarında çalışır.
• Partitioning ve Clustering: Tablo düzeyinde performans optimizasyonu için kullanılan fiziksel veri düzenleri.
• Materialized view: Sık kullanılan sorgu sonuçlarını önceden hesaplayıp saklayarak performansı iyileştiren yapı.

2.2 BigQuery'nin mimari felsefesi

BigQuery; sunucusuzluk, depolama‑hesaplama ayrımı, sütun‑odaklı depolama ve yüksek paralel sorgu yürütme üzerine kuruludur. Bu kombinasyon, büyük veri analizlerini hem esnek hem de yönetimi kolay hale getirir. Ayrıca Google'ın global altyapısının sağladığı dayanıklılık ve performans avantajları BigQuery'nin temel değeridir.

3. NASIL ÇALIŞIR?

3.1 Yüksek seviyeli sistem mimarisi

BigQuery mimarisi kabaca üç ana katmana ayrılabilir: ingest/deposit (yükleme), storage (Colossus, sütun‑odaklı formatlar) ve compute (Dremel benzeri dağıtık sorgu motoru). Sorgu gönderildiğinde, öncelikle sorgu planlayıcı logical plan oluşturur, ardından physical plan ile işi parçalara ayırır. Bu parçalar paralel olarak yürütülür ve sonuçlar toplanarak kullanıcıya döndürülür.

3.2 Depolama katmanı — Colossus ve sütun‑odaklı format

BigQuery verileri sütun‑odaklı ve sıkıştırılmış biçimlerde saklar. Colossus üzerinde saklanan bu veriler, okuma sırasında yalnızca sorguda ihtiyaç duyulan sütunları açarak I/O maliyetini düşürür. Ayrıca parça (shard) ve dağıtım stratejileri veri locality ve parallel read performansını etkiler.

3.3 Sorgu yürütme motoru — Dremel paradigması

Dremel, sorguları çok seviyeli bir dağıtık ağaç yapısında paralelleştirir: leaf node'lar veriyi okur ve kısmi sonuç üretir, ara katmanlar bu kısmi sonuçları birleştirir ve root node final sonucu döndürür. Bu model, milyarlarca satırı tarayan sorguların düşük latency ile tamamlanmasını sağlar.

3.4 Slot'lar ve kaynak yönetimi

BigQuery'de hesaplama kapasitesi slot'lar ile ifade edilir. On‑demand sorgularda Google otomatik slot tahsisi yaparken, rezervasyon modelinde kuruluşlar slot alır ve bunları workload'lara atayabilir. Slot yönetimi sorgu concurrency ve throughput üzerinde doğrudan etkilidir; iyi planlanmamış concurrency, beklemelere ve maliyet artışına neden olabilir.

3.5 Query optimizer ve execution planner

BigQuery optimizer, sorguları cost‑based yaklaşımla yeniden yazar; filtre itme (predicate pushdown), column pruning, join reordering ve broadcast/hash join gibi stratejiler kullanır. Ayrıca sorgu sırasında dinamik kararlar alınarak verimli join stratejileri seçilir (ör. shuffle vs broadcast).

3.6 Veri yükleme ve ingestion stratejileri

BigQuery'ye veri yüklemenin çeşitli yolları vardır: batch (load job), streaming insert (low‑latency insert API), ve federated query (ör. Cloud Storage, Google Drive, Cloud SQL, Bigtable). Streaming insert hızlıdır ancak küçük parçalar halinde veri eklenir; bu durumda partitioning ve clustering ile performansı korumak gerekir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Reklam teknolojileri ve telemetri

Büyük reklam platformları (örn. Google Ads vb. iç platformlar) günlük terabaytlarca telemetriyi işleyip analitik çıkarımlar yapar; BigQuery sütun‑odaklı depolama ve paralel sorgu yürütme ile bu analizleri düşük maliyetle destekler.

4.2 Finansal analiz ve risk hesaplamaları

Finansal kuruluşlar risk modelleri, backtesting ve gün sonu raporlamaları için büyük veri ambarlarına ihtiyaç duyar. BigQuery, büyük veri setleri üzerinde kompleks SQL sorguları ve pencere fonksiyonları ile bu kullanımları etkin şekilde destekler.

4.3 IoT ve zaman serisi analitiği

IoT cihazlarından gelen yüksek hacimli zaman serisi verisi BigQuery'ye toplu veya streaming olarak yüklenebilir; partitioned tables ve clustering ile sorgu performansı optimize edilir.

4.4 ML model eğitim‑hazırlık ve online scoring

BigQuery ML (BQML), veri bilimcilere SQL üzerinden modeller eğitme olanağı sağlar; feature engineering ve büyük veri hazırlığı için BigQuery sıkça tercih edilir. Eğitilmiş modeller export edilerek online scoring altyapılarına entegre edilebilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Sunucusuzluk: Altyapı yönetimi gerektirmez; ölçek otomatik.
• Depolama ve hesaplama ayrımı: Kaynakları bağımsız ölçekleyerek maliyet verimliliği sağlar.
• Yüksek paralellik: Dremel benzeri yürütme modeli sayesinde büyük sorgular hızlı tamamlanır.
• Entegrasyon: Google Cloud ekosistemindeki araçlarla sıkı entegrasyon (Dataflow, Pub/Sub, Dataproc, AI Platform).

Sınırlamalar

• Maliyet öngörülebilirliği: On‑demand sorgu maliyetleri öngörülemeyebilir; rezervasyon ve cost control gerektirir.
• İşlem esnekliği: Bazı operasyonel görevler (ör. çok düşük seviyeli optimizasyon) kullanıcı kontrolünde değildir.
• Streaming maliyeti ve gecikme: Sürekli yüksek hızda streaming insert'ler maliyet ve latency sorunları yaratabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıda BigQuery ve alternatif veri ambarı çözümlerinin karşılaştırması yer alıyor:

7. EN İYİ PRATİKLER

Production kullanımı

• Partitioning (ingestion time, event time) ve clustering stratejilerini iş yüküne göre belirleyin.
• Small file probleminden kaçının; streaming batch'leri coalesce ederek yazın.
• Reservation ve slot yönetimi ile cost vs performance hedeflerinizi hizalayın.

Performans optimizasyonu

• Column pruning ve predicate pushdown için sorguları sadeleştirin.
• Materialized view ve denormalize edilmiş özet tablolar kullanarak maliyeti ve sorgu süresini düşürün.
• JOIN stratejilerinde broadcast join vs shuffle join maliyetlerini göz önünde bulundurun; küçük tablolarda broadcast tercih edin.

Güvenlik

• Dikkatli IAM rolleri: least privilege ilkesiyle dataset ve table erişimlerini yönetin.
• Data encryption at rest ve in transit; müşteri tarafından yönetilen şifreleme (CMEK) gereksinimlerinde gerekli konfigürasyonu uygulayın.
• Row‑level ve column‑level access kontrol (Authorized Views, Policy Tags) ile veri koruması sağlayın.

Ölçeklenebilirlik

• Reservation ve slot assignment planları ile concurrency hedeflerinizi sağlayın.
• Data lifecycle: eski verileri düşük maliyetli storage'a taşıma veya partitioning ile yaşam döngüsü kurma.

8. SIK YAPILAN HATALAR

• Partition key yanlış seçimi: hotspot ve yavaş sorgulara neden olur.
• Clustering gereksinimi olmadan büyük taramalar yapmak; maliyet artışı görülür.
• Streaming insert'leri küçük parçalarda yazmak; small files ve yüksek API maliyetleri.
• Reservation yönetimini ihmal etmek: ani concurrency artışlarında beklemeler oluşur.
• Veri dönüşümlerini gereksiz yere BigQuery'de yapmak; ETL yerine ELT ile ön işleme düşünün.

9. GELECEK TRENDLER

9.1 Hibrit ve çoklu bulut veri ambarları

Kurumlar veri yerel��ği, regülasyon ve maliyet nedenleriyle multi‑cloud stratejilerine yönelecek; veri ambarı sağlayıcıları cross‑cloud veri paylaşımı ve taşınabilirlik üzerine yenilikler geliştirecek.

9.2 AI destekli sorgu optimizasyonu

Veri ambarı optimizer'ları geçmiş sorgu telemetrisinden öğrenip gelecekteki sorgular için plan önerileri sunacak; adaptif caching ve otomatik materialization daha yaygın hale gelecek.

9.3 Serverless OLAP evrimi

Serverless veri ambarları daha sofistike resource management yaklaşımları ile maliyet‑performans dengesini iyileştirecek; granüler sorgu sınırlamaları ve AI tabanlı priority scheduling bekleniyor.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. BigQuery neden sütun‑odaklı depolama kullanır?

   Sütun‑odaklı depolama, yalnızca sorguda ihtiyaç duyulan sütunların okunmasını sağlayarak I/O'yu azaltır ve büyük tablolarda maliyeti düşürür.

2. Slot nedir ve neden önemlidir?

   Slot, BigQuery'de sorgu hesaplaması için kullanılan sanal CPU birimidir; concurrency ve throughput için kritik kaynak yönetim birimidir.

3. Partitioning ve clustering arasındaki fark nedir?

   Partitioning veriyi zaman veya mantıksal aralıklarla fiziksel olarak ayırır; clustering belirli sütunlara göre veri sıralaması ve benzer satırların aynı blokta tutulmasını sağlar. İkisi birlikte performansı önemli ölçüde artırabilir.

4. Streaming insert ile batch load arasında nasıl seçim yapılır?

   Gerçek zamanlı ihtiyaç varsa streaming kullanın; aksi halde batch load daha düşük maliyetli ve daha verimlidir. Streaming, küçük parçalardaki yazma nedeniyle maliyet/performans dezavantajı getirebilir.

5. BigQuery ML hangi senaryolarda uygundur?

   SQL bilen veri bilimciler için feature engineering ve hızlı prototip modelleme idealdir; büyük veri üzerinde doğrudan model eğitimi mümkündür ancak özel training/serving altyapısı gereken büyük modeller için ek çözümler gerekebilir.

6. On‑demand vs reservation modelleri arasındaki karar nasıl verilir?

   Düzensiz, spiky sorgu yükleri için on‑demand uygundur; öngörülebilir, yüksek hacimli sürekli yüklerde reservation ile maliyet avantajı elde edilir.

7. Veri güvenliğini nasıl sağlarım?

   IAM rollerini sıkı yönetin, policy tags ve authorized views ile hassas veriyi kısıtlayın, CMEK ve audit log kullanarak uyumluluğu sağlayın.

8. BigQuery'de maliyeti nasıl optimize ederim?

   Partitioning, clustering, materialized views, reservation planları ve sorgu optimizasyonları ile taranan veri hacmini azaltarak maliyeti düşürün; ayrıca cost monitoring araçları ile anormallikleri tespit edin.

Anahtar Kavramlar

Colossus

Google'ın dağıtık dosya sistemi; veri depolama için altyapı sağlar.

Dremel

Dağıtık, sütun‑odaklı sorgu yürütme paradigmaları sunan sorgu motoru tasarımı.

Slot

Sorgu yürütme için tahsis edilen hesaplama birimi; rezervasyonlarla yönetilebilir.

Partitioning

Tablo verisinin mantıksal olarak bölümlere ayrılması; sorgu performansını iyileştirir.

Öğrenme Yol Haritası

1. 0–1 ay: BigQuery temel kavramları, SQL sorguları ve basit partition/clustering deneyleri yapın.
2. 1–3 ay: Data ingestion yöntemleri (batch vs streaming), cost kontrol ve reservation temel parametrelerini öğrenin.
3. 3–6 ay: Query optimization, materialized views, ve BigQuery ML ile basit modeller geliştirin.
4. 6–12 ay: Production scale ingestion, slot yönetimi, güvenlik politikaları ve veri yaşam döngüsü stratejilerini uygulamaya alın.
5. 12+ ay: Hibrit/multi‑cloud veri ambarı stratejileri, AI‑optimizasyonlu query planner ve otomatik materialization çözümlerini takip edin ve uygulayın.