Google PCA: Veri Depolama, Veritabanları ve Analitik Mimarisi — Çalışma kılavuzu

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Architect — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Google Cloud üzerinde veri depolama, veritabanları ve analitik çözümleri tasarlamak; dayanıklılık, erişilebilirlik, erişim kontrolü, maliyet ve operasyonel esneklik planlaması yaparken iş yükü desenlerini doğru servislerle eşleştirmeyi gerektirir. Bu bölüm; nesne depolama ve yaşam döngüsü yönetimini; operasyonel veritabanları ve önbellekleri; analitik ambarlama ve işlemeyi; veri alım mimarilerini; ve yönetişim, koruma ve performans uygulamalarını kapsar. Tasarım seçeneklerini, operasyonel gerekçeleri ve yaygın hata modlarını veya ödünleşimleri vurgular.

Depolama ve Nesne Mimarisi

Cloud Storage bucket tasarımı

Konum: düşük gecikmeli, maliyete duyarlı iş yükleri için bölge (region); öngörülebilir yük devretme (failover) ile iş sürekliliği için çift bölge (dual-region); küresel okuma erişimi için çoklu bölge (multi-region) seçin. Çift bölge, SLA destekli, düşük bir RPO için isteğe bağlı turbo replikasyon sunar; aksi takdirde replikasyon asenkrondur.
Ad alanı ve ayrım: veri alanları, ortamlar ve hassasiyet seviyeleri için ayrı bucket’lar kullanın. Tutarlı izinler için tek tip bucket düzeyinde erişim (uniform bucket-level access) ve genel erişim engellemeyi (public access prevention) kullanın.
Depolama sınıfları: Sık erişilen (hot) veriler için Standard; seyrek erişilen (aylık) veriler için Nearline; üç ayda bir erişilen veriler için Coldline; uzun süreli saklama için Archive. Autoclass, minimum operasyonel çabayla sınıf yerleşimini otomatik olarak optimize edebilir.
Yaşam döngüsü politikaları: yaşa, depolama sınıfına veya nesne önekine göre geçişi ve silmeyi otomatikleştirin. 90 günden eski nesneleri silme örneği: { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } Şu komutla uygulayın: gsutil lifecycle set lifecycle.json gs://my-bucket
Saklama ve yasal bekletmeler (legal holds): bucket saklama politikalarını yapılandırın ve isteğe bağlı olarak azaltmayı önlemek için kilitleyin (uyumluluk). Olay tabanlı bekletmeler (event-based holds) ve nesne sürümleme (object versioning), yanlışlıkla silme veya üzerine yazma durumlarından kurtarmayı sağlar.
Replikasyon: iki bölge arasında arka planda replikasyon ile API’de senkron tutarlılık semantiği için çift bölge (dual-region) seçin; özel RPO/RTO veya görevler ayrılığı (separation of duties) gereksinimlerini karşılamak için (projeler arası veya konumlar arası kopyalar için) bucket’tan bucket’a replikasyonu kullanın.

Hata modları ve ödünleşimler

Sınıf uyuşmazlığı maliyeti ve gecikmeyi artırır. Autoclass bunu azaltır ancak nesne başına yönetim yükü ekler.
Saklama kilidi (retention lock) geri alınamaz; politikaları üretim dışı ortamlarda test edin.
Replikasyon dayanıklılığı artırır ancak yazma gecikmesini ve maliyeti yükseltebilir; okuma/yazma yollarını hedeflenen konumlara göre tasarlayın.

Desenler

Veri gölü (Data lake): Cloud Storage üzerinde ham (raw) ve işlenmiş (curated) bölgeler; Dataplex aracılığıyla yönetişim; Data Catalog’da dışsallaştırılmış şemalar.
Arşivleme: Uyumluluk için saklama kilidi (retention lock) ile Archive sınıfı, nadir analizler için BigQuery harici tabloları veya isteğe bağlı geri yükleme (on-demand restore) ile birlikte.
Lakehouse: Cloud Storage ve BigQuery genelinde erişimi tutarlı güvenlikle birleştirmek için BigLake kullanın.

Operasyonel Veri Depoları ve Önbelleğe Alma

Cloud SQL

Yüksek erişilebilirlik: beklemedeki bir kopyaya (standby) senkron replikasyon ile bölgesel HA; genellikle saniyeler ila birkaç dakika içinde otomatik yük devretme (failover). Uygulama değişikliklerini en aza indirmek için örnek (instance) uç noktası aynı kalır.
Okuma replikaları: bölge içi veya bölgeler arası, asenkron; okuma amaçlı ölçek genişletme (read scale-out) ve felaket kurtarma (DR) için iyidir. Gecikmeyi (lag) izleyin; güncel olmayan okumalar (stale reads) doğruluğu etkileyebilir.
Yedeklemeler ve PITR: zamanlanmış yedeklemeler ve işlem günlükleri (transaction logs) kullanılarak belirli bir zamana geri dönme (point-in-time recovery) (genellikle motora bağlı olarak 7 güne kadar bir pencere). Geri yüklemeyi düzenli olarak test edin.
Özel bağlantı: VPC eşlemesi (peering) üzerinden özel IP, riski ve gecikmeyi azaltır; çakışmayı önlemek için IP aralıklarını planlayın.
Taşıma (Migration): Database Migration Service, şirket içinden (on-prem) veya diğer bulutlardan düşük kesintili taşımaları destekler; yüksek hacimli bağlantılar için, paket kaybını ve gecikmeyi azaltmak amacıyla VPN yerine Dedicated veya Partner Interconnect’i tercih edin.

Artıları/Eksileri ve Hata Modları

HA yük devretmeleri bağlantıları sıfırlar; uygulamalar üstel geri çekilme (backoff) ile yeniden denemelidir. Bakım pencereleri performansı kısa süreliğine düşürebilir.
Uzun süren işlemler (transaction) replikasyon gecikmesini ve PITR kurtarma süresini artırır.
Gereğinden fazla depolama alanı sağlamak ucuz bir sigortadır; yetersiz IOPS sağlamak ise en yoğun zamanlarda gizli hatalara neden olur.

Cloud Spanner

Global ölçek ve tutarlılık: TrueTime ve iki aşamalı kesinleştirme (two-phase commit) kullanarak bölgeler arasında güçlü tutarlılığa sahip okuma/yazma işlemleri. En düşük yazma gecikmesi için bölgesel (regional); daha yüksek erişilebilirlik ve global okumalar için çok bölgeli (multi-region) seçin.
İşlemler (Transactions): satırlar ve tablolar arasında harici tutarlılık (external consistency) ve tam ACID; salt okunur işlemler replikalar arasında ölçeklenir.
Şema tasarımı: etkin nokta (hotspot) oluşumunu önleyen birincil anahtarlar (primary keys) seçin; yerellik (locality) için iç içe geçmiş tablolar (interleaved tables) kullanın; ikincil dizinlerin (secondary indexes) yazma çoğaltma (write amplification) ve geri doldurma (backfill) davranışını göz önünde bulundurun.
Bölgesellik: lider bölgenin (leader region) konumu yazma gecikmesini belirler; çok bölgeli yapı, yeter sayı (quorum) maliyetleri ve kesinleştirme (commit) gecikmesi ekler.

Artıları/Eksileri

Yazma gecikmesi, coğrafi dağılım arttıkça büyür; erişilebilirlik ve global dağıtım bunu gerektirmediği sürece çok bölgeli yapıdan kaçının.
Taban maliyeti, tek düğümlü VM veritabanlarından daha yüksektir; kapasite planlaması, SLO’lar ve büyüme ile uyumlu olmalıdır.

Firestore, Bigtable, Memorystore ve Seçim

Firestore: mobil/web arka uçları için doküman veritabanı; tek dokümanlar için güçlü tutarlılık; ayrıntılı güvenlik; otomatik indeksleme. Sık güncellenen dokümanlardaki çekişmeye (contention) dikkat edin; dağıtık sayaçlar ve toplu yazma işlemleri (batched writes) kullanın.
Bigtable: geniş sütunlu, petabayt ölçeğinde, ultra düşük gecikmeli zaman serisi ve IoT; etkin noktaları (hotspots) önlemek için satır anahtarları (row keys) tasarlayın (ör. hash veya salting); düğümler (nodes) ve kümeler (clusters) ile ölçeklendirin; erişilebilirlik için çoklu küme yönlendirmesi (multi-cluster routing). Replikasyon asenkrondur; güçlü tutarlılık küme başına (per-cluster) sağlanır.
Memorystore for Redis: bellek içi (in-memory) önbellek; Basic katmanı tek bir örnektir (HA yok); Standard katmanı replika ve otomatik yük devretme sağlar (kısa süreli bağlantı kesintileri olabilir). Doğruluk kaynağı (source of truth) olarak değil, önbellek olarak kullanın; kalıcılık (persistence) özellikleri değişkenliği azaltır ancak veritabanı yedeklerinin yerini tutmaz.

İş Yükü Odaklı Seçim

Join/ACID işlemleri gerektiren ve orta ölçekli ilişkisel iş yükleri: Cloud SQL.
Yatay ölçeklenme ve harici tutarlılık gerektiren global ilişkisel iş yükleri: Cloud Spanner.
Yüksek verimli (high-throughput) zaman serisi/telemetri veya çok büyük anahtar-değer (key-value) iş yükleri: Bigtable.
Hiyerarşik sorgular içeren, uygulama merkezli doküman modelleri: Firestore.
Geçici hızlandırma ve hız sınırlama (rate limiting): Memorystore.

Analitik, Veri Alımı ve İşleme

BigQuery

Veri kümeleri (Datasets): mantıksal güvenlik ve faturalandırma sınırları; alan (domain) ve yaşam döngüsü aşamasına göre adlandırma kuralları benimseyin.
Bölümleme (Partitioning): zamansal filtreleme için veri alım zamanına (ingestion-time) veya sütuna dayalı; ayrıca tamsayı aralığı bölümlemesi. Taramaları budamak (prune scans) için event_ts üzerinde zaman birimi bölümlemesi kullanın.
Kümeleme (Clustering): ilgili verileri depolamada bir arada konumlandırmak için en fazla dört sütun; seçici sorguların performansını ve maliyetini iyileştirir.
Rezervasyonlar (Reservations): ayrılmış slot’ları rezervasyonlar ve atamalar aracılığıyla yönetin; anlık yoğunluktaki (bursty) denemeler için esnek slot’lar (flex slots) kullanın; kaynak yetersizliğini (starvation) önlemek için kritik iş yüklerini izole edin.
Erişim kontrolü: proje ve veri kümesi düzeyinde IAM; satır düzeyinde politikalar (row-level policies) ve politika etiketleri (policy tags) ile tablo/sütun kontrolü; düzenlenmiş verileri yetkilendirilmiş görünümler (authorized views) ve rutinler aracılığıyla paylaşın.

Faydalı örnek: bq mk –dataset myproj:analytics bq mk –table –time_partitioning_field=event_ts –clustering_fields=user_id,device_type myproj:analytics.events ./schema.json

Artıları/Eksileri ve Hata Modları

Kötü bölümleme, tam tablo taramalarına (full-table scans) ve kontrolden çıkmış maliyetlere yol açar.
Kümeleme yalnızca filtreler veya join’ler kümelenmiş sütunları içerdiğinde yardımcı olur; sık sık yeniden düzenleme (reshuffle) faydayı azaltabilir.
Yetersiz slot sağlanması işleri sıraya sokar; aşırı sağlanması maliyeti artırır. Slot kullanımını ve diske taşan shuffle (spilled shuffle) işlemlerini izleyin.

Veri alımı ve işleme

Pub/Sub: global, dayanıklı, en az bir kez (at-least-once) teslimat; sıralama anahtarları (ordering keys), verim (throughput) ödünleri karşılığında anahtar başına sıralamayı zorunlu kılar. Idempotent tüketiciler (consumers) tasarlayın.
Dataflow: otomatik ölçeklendirme, tam olarak bir kez (exactly-once) durum bilgili işleme, pencerelendirme (windowing) ve tetikleyiciler (triggers) ile birleşik toplu (batch) ve akış (streaming) işleme; Streaming Engine durum yönetimini (state) dışarıya yükler. Başarısız mesaj konuları (dead-letter topics) ve yeniden oynatılabilir (replayable) kaynaklar kullanın.
Dataproc: mevcut kod ve ekosistemler için yönetilen Spark/Hadoop; geçici (ephemeral) kümeler veya otomatik ölçeklendirme; ML kütüphaneleri için veya taşımanın maliyetli olduğu durumlarda kullanın.

Toplu (Batch) ve Akış (Streaming) İşlemenin Artıları/Eksileri

Akış işleme gecikmeyi azaltır ve gerçek zamanlılığı destekler, ancak karmaşıklığı (durum yönetimi, filigranlar (watermarking), geç gelen veri) ve sürekli maliyetleri artırır.
Toplu işleme, doğruluğu ve maliyet kontrolünü basitleştirir; SLA’ların gecikmeyi tolere ettiği durumlarda kabul edilebilirdir.
Hibrit desenler: ham olayları Cloud Storage’a indirin, toplanmış KPI’ları BigQuery’ye akıtın ve doğruluk için gecelik toplu yeniden hesaplamalar çalıştırın.

Veri Ambarı Desenleri

Veri Ambarı (Warehouse): Analiz sistemi olarak BigQuery; BI (İş Zekası) sunumu için somutlaştırılmış görünümler (materialized views) ve zamanlanmış sorgular.
Göl Evi (Lakehouse): Cloud Storage’daki verileri açık formatlarla yönetin; tutarlı güvenlikle BigLake üzerinden BigQuery’ye sunun.

← Compute · Tüm alanlar · Ağ →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →