Google PDE: Veri Depolama, Veri Gölleri ve Dosya Formatları — Çalışma kılavuzu

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Data Engineer — Ç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.

Dosya formatları, sıkıştırma ve sorgu davranışı

Doğru formatı seçmenin maliyet ve performans üzerinde birinci dereceden etkileri vardır.

• Sütun bazlı formatlar (Parquet, ORC)

  • Güçlü yönleri: sütun ayıklama (column pruning), koşul itme (predicate pushdown), her sütun için kodlama ve sıkıştırma, istatistikler ve bölünebilir dosyalar.
  • Dezavantajları: yazma zamanında daha yüksek CPU kullanımı; şema evrimi dikkatli bir şekilde yönetilmelidir (örneğin, sütun EKLEMEK güvenli; tür değişiklikleri risklidir).
  • Sıkıştırma: Hız için Snappy, desteklendiği yerlerde daha iyi sıkıştırma oranları için ZSTD. Birlikte çalışabilirlik kısıtlamaları gerektirmedikçe sütun bazlı formatlar için GZIP’ten kaçının.

• Satır odaklı Avro

  • Güçlü yönleri: güçlü tipleme ile şema evrimi, blok düzeyinde sıkıştırma, bölünebilir; akış (streaming) landing zone’ları ve veri değişimi için mükemmeldir.
  • Dezavantajları: analitik için tarama verimliliği sütun bazlı formatlara göre daha düşüktür; iyileştirilmiş (curated) zone’larda Parquet/ORC’ye dönüştürün.

• CSV ve JSON (yarı yapılandırılmış)

  • CSV: insan tarafından okunabilir, değerler basit olduğunda en düşük ek yüke sahiptir; şema, tür ve kaçış (escape) karakteri tutarlılığından yoksundur; büyük ölçekte ayrıştırması (parse) maliyetlidir.
  • JSON: kendi kendini tanımlayan ve esnektir; ölçeklenebilir dağıtık okumalar için satır sonu ile ayrılmış JSON (newline-delimited JSON) gereklidir; ayrıntılıdır ve ayrıştırması CPU’yu yoğun kullanır.
  • Mümkün olan yerlerde, ham CSV/JSON’ı kaydedin, ardından doğrulayın ve analitik için Avro/Parquet’e dönüştürün.

• BigQuery harici ve BigLake tabloları

  • Parquet/ORC harici tabloları, koşul itme (pushdown) ve sütun ayıklamadan yararlanır; CSV/JSON ise genellikle yararlanmaz, bu da daha yüksek taranan bayt miktarına yol açar.
  • Sıkıştırılmış CSV (GZIP) harici tabloları worker’lar arasında bölünemez; daha yavaş okumalar bekleyin.
  • Örnek: Hive stili bölümlere sahip bir Parquet BigLake tablosu oluşturma:

undefined

Düzen, bölümleme, performans mühendisliği, yerleşim ve geçiş

• Nesne düzeni ve bölümleme

  • Bölümler ve kümeleme anahtarları için Hive tarzı yolları benimseyin: gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
  • Dengeli paralellik ve görev ek yükü için tekil dosya boyutlarını 128–1024 MB aralığında tutun. Bölüm başına milyonlarca dosyadan kaçının.
  • Küçük dosya sorunlarını şu yöntemlerle azaltın:
    • Yüklemeleri istemci tarafında toplu olarak işleyin.
    • Yoğun olmayan saatlerde küçük dosyaları birleştirmek için Dataflow/Spark sıkıştırma (compaction) işlerini kullanın.
    • Orijinal küçük dosyaları arşivleyin ve analitik için yalnızca sıkıştırılmış verileri kullanıma sunun.

• BigQuery bölümleme ve kümeleme

  • Veri alım zamanına veya yüksek kardinaliteye sahip bir filtre sütununa (ör. event_date) göre bölümleyin. Meta veriyi şişiren aşırı bölümlemeden (ör. dakika başına) kaçının.
  • Sık filtrelenen/sıralanan boyutlara göre (en fazla dört) kümeleyin. Kümeleme, veri yerelliğini artırır ve taranan bayt miktarını azaltır.
  • Yoğun interaktif analitik için yerel BigQuery tablolarını tercih edin; yönetilen göl erişimi, motorlar arası paylaşım ve maliyet izolasyonu için BigLake/harici tabloları kullanın.

• Sorgu performansı üzerindeki etkiler

  • Sütun tabanlı formatlar, harici tarama maliyetlerini önemli ölçüde azaltır; CSV/JSON harici tabloları genellikle tam dosya taraması gerektirir.
  • Tutarlılık garantileri, Cloud Storage okumalarında yapay gecikmelere olan ihtiyacı ortadan kaldırır, ancak alt sistemler (ör. BigQuery akış eklemeleri) kısa süreli veri görünürlüğü gecikmesi yaşayabilir—gereken yerlerde watermark’lar veya okuma gecikmeleri ile tasarım yapın.

• Yerleşim, dayanıklılık ve kurtarma

  • Yerleşim kısıtlamalarını karşılamak için bucket/dataset konumlarını seçin; çıkış trafiğini (egress) ve gecikmeyi azaltmak için işlem gücünü (compute) aynı yerde konumlandırın.
  • Düşük RPO için turbo replikasyonlu çift bölge (dual-region) kullanın; insan hatası ve fidye yazılımlarından kurtulabilirlik için sürüm oluşturma (versioning) ve saklama politikalarını (retention policies) birleştirin.
  • Olağanüstü Durum Kurtarma (DR) için, bucket replikasyonu kullanarak bucket’ları ayrı bir projeye/bölgeye çoğaltın ve ayrı IAM sınırları ile koruyun.

• Güvenli geçiş ve doğrulama

  • Çok aşamalı planlayın: tohumlama (toplu aktarım), artımlı senkronizasyon (mtime/pencereli kopyalama), geçiş (kaynağı salt okunur yapma) ve geçiş sonrası doğrulama.
  • Sağlama toplamları (checksums), sayımlar, bayt toplamları ve örnek kod çözme ile doğrulayın. Tablo verileri için satır sayılarını ve hash özetlerini karşılaştırın:

undefined

• Paralel kopyalama sırasında üzerine yazmaları önlemek için ön koşulları (ifGenerationMatch) kullanın. Sürüm oluşturma veya korunmuş kaynak ile bir geri alma penceresi bırakın.
• Geçişten sonra, yeni erişim profiline göre yaşam döngüsü (lifecycle) ve Autoclass’ı etkinleştirin; doğrulamalar geçene kadar saklama kilidini (retention lock) etkinleştirmekten kaçının.

Pratik Problem Senaryosu

Acme Retail, bir lojistik ortağından bölgesel bir Cloud Storage bucket’ına günlük olarak CSV dosyaları almaktadır. Dosyalar ara sıra bozuk satırlar içermektedir. Acme’nin bu verileri alması, doğrulaması, analize hazır bir formata dönüştürmesi ve neredeyse gerçek zamanlı panolar için BigQuery’ye yüklemesi, aynı zamanda hatalı satırları inceleme için saklaması ve yönetişimi uygulaması gerekmektedir.

Yaklaşım:

1. Ham veriyi Dataplex’te konumlandırın ve yönetin

   • gs://acme-raw/logistics/ yoluna eşlenmiş bir ham bölge (raw zone) varlığı ile bir Dataplex gölü oluşturun.
   • Gerekçe: Merkezi yönetişim, meta veri ve veri kökeni (lineage). IAM’i bölge düzeyinde uygulayın ve alt sistemlerde uygulanması için hassas alanları ilke etiketleriyle (policy tags) etiketleyin.

2. Yaşam döngüsü ve saklama politikalarını uygulayın

   • acme-raw üzerinde 30 günlük bir bucket saklama politikası uygulayın ve nesne sürüm oluşturmayı (object versioning) etkinleştirin.
   • Gerekçe: Ortağın kazara üzerine yazma/silme işlemlerine karşı korur; kısa saklama süresi maliyet ve kurtarılabilirliği dengeler. Sürüm oluşturma, hatalı teslimatların geri alınmasını kolaylaştırır.

3. Bir Dataflow toplu iş hattı (batch pipeline) ile doğrulayın ve veri alın

   • Nesne sonlandırma bildirimleri üzerine günlük bir Dataflow işi tetikleyin. CSV’yi şema ve kayıt bazında doğrulama ile okuyun; geçerli kayıtları BigQuery hazırlık (staging) tablosuna (event_date’e göre bölümlenmiş) yazın ve ayrıştırma/doğrulama hatalarını bir dead-letter BigQuery tablosuna yönlendirin.
   • Gerekçe: Dataflow, ölçeklenebilir paralel ayrıştırma ve sağlam dead-letter yönetimi sunar, böylece analistler bozuk satırları inceleyebilir. Bu, heterojen CSV kalitesi için en iyi uygulamayı yansıtır.

4. Düzenlenmiş bölgede (curated zone) Parquet formatına dönüştürün ve sıkıştırın

   • Aynı iş hattı, doğrulanmış verileri gs://acme-curated/logistics/date=YYYY-MM-DD/ yoluna ~256–512 MB boyutunda Parquet dosyaları olarak yazar.
   • Gerekçe: Parquet, BigQuery ve Spark’ta sütun ayıklama (column pruning) ve koşul itme (predicate pushdown) özelliklerini etkinleştirerek taranan bayt miktarını düşürür ve gecikmeyi iyileştirir; sıkıştırma (compaction), ortağın teslimat modelinden kaynaklanan küçük dosya ek yükünü azaltır.

5. Yönetilen analitiği BigLake aracılığıyla kullanıma sunun

   • Düzenlenmiş Parquet yolu üzerinde Hive otomatik bölümleme ile bir BigLake harici tablosu oluşturun; ortağa özgü filtreler için sütun düzeyinde ilke etiketleri (policy tags) ve satır erişim politikaları (row access policies) uygulayın.
   • Gerekçe: Merkezi denetim ile BigQuery ve Spark genelinde tek tip, ayrıntılı erişim. Bölüm ayıklama (partition pruning), tarih filtrelerindeki tarama maliyetlerini azaltır.

6. Kritik özet verileri yerel BigQuery’ye yükleyin

   • Sık kullanılan (hot) panolar için, düzenlenmiş Parquet harici tablosundan son N günlük veriyi yerel, kümelenmiş ve bölümlenmiş bir tabloya alan zamanlanmış bir BigQuery işi çalıştırın.
   • Gerekçe: Yerel depolama, yüksek eşzamanlı BI’ı hızlandırırken, harici BigLake tablosu daha geniş erişim için yönetilen kayıt sistemi (system-of-record) olarak kalır.

7. Cloud Logging ve Pub/Sub ile izleyin ve uyarı oluşturun

   • Dataflow ve BigQuery yükleme işi sonuçlarını Pub/Sub’a filtreleyen bir log havuzu (log sink) oluşturun; hatalar veya artan bozuk satır oranları için anlık uyarılar almak üzere izleme aracıyla entegre edin.
   • Gerekçe: Sürekli sorgulama (polling) olmadan hedeflenmiş, tabloya özgü operasyonel görünürlük; SRE uygulamalarını destekler.

8. Depolama sınıfını ve yerleşimi optimize edin

   • Düzenlenmiş Parquet’i 14 gün boyunca Standard sınıfında tutun, 30 gün sonra yaşam döngüsü kuralı ile Coldline’a geçirin; çıkış trafiğini (egress) önlemek için hem ham hem de düzenlenmiş bucket’ları BigQuery veri setleriyle aynı bölgede saklayın.
   • Gerekçe: Sık okuma (hot read) performansını maliyetle dengeler. Aynı yerde konumlandırma, uyumluluğu sürdürür ve gecikme ile çıkış (egress) ücretlerini en aza indirir.

9. Uçtan uca kaliteyi doğrulayın

   • Her çalıştırmadan sonra, hazırlık (staging), düzenlenmiş harici ve yerel BigQuery tabloları arasındaki sayımları ve hash özetlerini karşılaştırın; anormallikleri karantinaya alın.
   • Gerekçe: Şema kaymasının veya veri alım regresyonlarının erken tespiti; kriptografik veya parmak izi (fingerprint) hash’leri, tam yeniden tarama olmadan hafif bir güvence sağlar.

Bu tasarım, dead-letter analizi ile dayanıklı veri alımı, verimli sorgular için analize hazır Parquet, Dataplex ve BigLake aracılığıyla merkezi yönetişim ve maliyet optimizasyonlu yaşam döngüsü politikaları sunar; tüm bunları yaparken en az ayrıcalıkla erişim (least-privilege access) ve denetlenebilir operasyonlara bağlı kalır.

← Veri Mühendisliği Mimarisi ve Tasarımı · Tüm alanlar · BigQuery Analitiği ve Veri Ambarı Mühendisliği →

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

Google'a göz atın →