Google PDE: Veri Mühendisliği Mimarisi ve Tasarımı — Çalışma kılavuzu
Ş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.
Genel Bakış
Google Cloud üzerinde veri mühendisliği mimarisi ve tasarımı; güvenilir, ölçeklenebilir ve uygun maliyetli veri platformları sunmak için alan sınırları, işleme modelleri ve hizmet yetenekleri arasında bir denge kurar. Etkili tasarımlar; depolama, işlem, düzenleme (orkestrasyon) ve sunum katmanlarını bağımsız olarak ölçeklenebilir kılar; alanların birlikte çalışabilmesi için sözleşmeleri kod haline getirir ve ölçülebilir hizmet seviyesi hedefleri (SLO’lar) ile riskleri erken doğrular. Bu bölüm, kanonik mimari tarzları (data mesh, veri gölü, veri ambarı, lakehouse, operasyonel depolar), işleme modlarını (toplu, mikro-toplu, akış, olay güdümlü, lambda) ve ölçeklenebilirlik, gecikme süresi, kullanılabilirlik, tutarlılık ve maliyet arasındaki ödünleşimleri özetlemektedir. Ayrıca bölgesel ve çoklu bulut yerleşimi, şema evrimi, uçtan uca veri yaşam döngüsü, iş yükü tabanlı hizmet seçimi ve Google Cloud’a özel risk odaklı doğrulama uygulamalarını da kapsar.
Mimari Paradigmalar ve İşleme Modelleri
- Data mesh, alanlar ve veri ürünleri:
- Alan ekiplerini, net sahiplik, SLO’lar, erişim politikaları ve dokümantasyon ile “veri ürünleri” yayınlamaları için yetkilendirin. Alanları tanımlamak, meta verileri yönetmek ve BigQuery ile Cloud Storage genelinde tutarlı politikalar uygulamak için Dataplex’i kullanın. Ürünler, Pub/Sub şemaları ve BigQuery tablo şemaları aracılığıyla uygulanan sözleşmelerle BigQuery veri kümelerini, Pub/Sub konularını veya Cloud Storage yollarını kullanıma sunabilir.
- Veri gölü:
- Cloud Storage’da yaşam döngüsü ve sürüm kontrolü ile ham, açık formatlı depolama (Parquet/Avro). Heterojen iş yüklerine (Dataproc üzerinde Spark, Dataflow, Presto/Trino) ve çoklu bulut taşınabilirliğine uygundur. Dezavantajı: nesne depolarındaki nihai tutarlılık semantiği; tekrarlanabilirliğe (idempotency) ve meta veri odaklı tekilleştirmeye yönelik tasarım yapın.
- Veri ambarı:
- BigQuery’de derlenmiş, yönetilen analitik. ANSI SQL, depolama/işlem ayrımı ve ayrıntılı güvenlik için optimize edilmiştir. Dezavantajları: akış eklemeleri, sorgu zamanında kısa süreli bir eskime gösterir; katı güncellik SLA’ları için toplu yüklemeleri veya arabelleğe alınmış sorgularla eklemeyi tercih edin.
- Lakehouse:
- Açık veri gölü depolamasını ambar yetenekleriyle birleştirin. Google Cloud’da, Parquet/Avro’yu Cloud Storage’da saklayın; maliyet avantajı için BigQuery harici tablolarını, performans ve yönetişim için BigQuery yönetilen tablolarını kullanın. Dataflow veya Dataproc, bölümlenmiş/kümelenmiş stratejilerle ACID benzeri birleştirme semantiğini sürdürür.
- Operasyonel depo mimarisi:
- Uygulamaları destekleyen düşük gecikmeli işlemsel veya anahtar-değer depoları. Geleneksel OLTP için Cloud SQL’i, yatay ölçeklenebilirlikli küresel tutarlı SQL için Cloud Spanner’ı ve çok yüksek verim gerektiren geniş sütunlu erişim desenleri için Bigtable’ı seçin. Operasyonel depoları analitikten ayırın; değişiklikleri Pub/Sub, Cloud Storage veya BigQuery’ye yakalamak için CDC’yi (Datastream) kullanın.
İşleme modelleri ve ne zaman kullanılacakları:
- Toplu (Batch): Periyodik, büyük ölçekli dönüşümler (örneğin, gecelik özellik üretimi). Araçlar: Dataflow toplu iş, Dataproc. Hata modları: uzun süren iş zaman aşımları, veri çarpıklığı (skew); otomatik ölçeklendirme ve yeniden bölümleme ile azaltın.
- Mikro-toplu (Micro-batch): Güncelliği kararlılık ve maliyetle dengelemek için küçük, sık toplu işlemler (örneğin, her dakika). BigQuery’de, zamanlanmış sorguları veya sabit pencereli Dataflow’u kullanın.
- Akış (Streaming): Sınırsız veriler üzerinde milisaniyeden saniyelere varan gecikme süresi. Pub/Sub + Dataflow kullanın. Geciken/sırasız olayları olay zamanı pencereleri ve filigranlar (watermarks) ile ele alın; kopyaları önlemek için tekrarlanabilirliği (idempotency) sağlayın.
- Olay güdümlü (Event-driven): Değişikliklerle tetiklenir (GCS finalize, Pub/Sub mesajları). Durumsuz (stateless) tepkiler için Cloud Functions veya Cloud Run’ı, durum bilgisi olan (stateful) işlemler için Dataflow’u kullanın. Dezavantajı: olay başına maliyetler ile verim (throughput) arasındaki denge.
- Lambda deseni: Doğruluk ve yeniden işleme için hem akış hem de toplu işlem yollarını koruyun. Karmaşıklık iki katına çıkar; her şeyin değişmez bir günlükten (Pub/Sub’dan Cloud Storage’a arşivleme) yeniden oynatılabildiği Kappa benzeri bir basitleştirmeyi düşünün.
Geciken veriler için kısa bir Dataflow akış yapılandırma örneği:
events
.apply(Window.into(FixedWindows.of(Duration.standardMinutes(5)))
.withAllowedLateness(Duration.standardMinutes(10))
.accumulatingFiredPanes());
Alan Sahipliği, Veri Ürünleri ve Sözleşmeler
- Sahiplik ve SLO’lar:
- Her alan ekibi, kendi veri ürünlerini kullanılabilirlik, gecikme süresi ve veri kalitesi SLO’ları ile tanımlar ve işletir. SLO’ları Dataplex katalogları aracılığıyla yayınlayın ve Cloud Monitoring SLI’ları ile izleyin (örneğin, zamanında bölüm tamamlama).
- Sözleşmeler ve birlikte çalışabilirlik:
- Pub/Sub Schema Registry (Avro/Proto) ve BigQuery tablo şemaları ile şemaları zorunlu kılın. CSV alımı için Dataflow’da doğrulama yapın ve bozuk biçimli satırları ayıklama için bir “dead-letter” tablosuna yönlendirin. Birden fazla motorun aynı veriyi okuması gerektiğinde, Cloud Storage’daki açık formatlarla ve BigQuery harici tablolarıyla birlikte çalışın.
- Şema evrimi:
- Geriye dönük uyumlu değişiklikleri tercih edin: boş değer alabilen (nullable) sütunlar ekleyin, Avro/Proto’da isteğe bağlı alanlar ekleyin, kullanımdan kaldırma pencereleri olmadan yeniden adlandırma/silme işlemlerinden kaçının. Değişiklikleri sürümlenmiş sözleşmeler ve kullanımdan kaldırma takvimleri aracılığıyla bildirin.
- BigQuery örneği (geriye dönük uyumlu sütun ekleme):
ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;
- Tüketici etkisi:
- Şemaların anlamsal sürümlemesini (semantic versioning) sürdürün; geçiş sırasında hem v1 hem de v2’yi yayınlayın. Akış için, sürümlenmiş konulara yönlendirin veya bir şema sürüm alanı ekleyin. Tüketicileri fiziksel değişikliklerden yalıtmak için BigQuery’de yetkilendirilmiş görünümler (authorized views) sağlayın.
- Yönetişim ve veri kökeni (lineage):
- Meta veriler, etiketler (örneğin, PII) ve veri kökeni (lineage) için Dataplex ve Data Catalog’u kullanın. BigQuery’de satır ve sütun düzeyinde güvenlik uygulayın. Veri kaybını önleme (DLP) için, depolamadan önce hassas alanları token’laştırmak veya redakte etmek amacıyla veri alım sürecine (örneğin, Cloud Run veya Dataflow dönüşümleri) Cloud DLP’yi entegre edin.
Fonksiyonel Olmayan Ödünleşimler ve Dağıtım Topolojisi
- Ölçeklenebilirlik:
- BigQuery, analiz için elastik olarak ölçeklenir; Bigtable, düğüm sayısıyla doğrusal olarak ölçeklenir ancak hotspotting’i (tek bir noktada yoğunlaşmayı) önlemek için dikkatli bir satır anahtarı tasarımı (ör. hash’lenmiş veya döndürülmüş önekler) gerektirir. Dataflow otomatik ölçeklendirme, birikmiş işlere (backlog) yanıt verir; Pub/Sub akış kontrolünden yararlanarak geri basınç (backpressure) için tasarım yapın.
- Gecikme Süresi:
- BigQuery’ye akış (streaming), düşük gecikmeli eklemeler sunar ancak sorgularda hafif bir gecikme görülebilir; sorguları bir tazelik arabelleği (freshness buffer) veya watermark tabanlı pencerelerle tasarlayın. Büyük ölçekte 100 ms’nin altında okuma süreleri için verileri önceden hesaplayın ve Bigtable veya Memorystore üzerinden sunun.
- Erişilebilirlik ve tutarlılık:
- Cloud Spanner, güçlü tutarlılığa sahip, küresel olarak dağıtılmış SQL sağlar. Bigtable, kümeler arasında nihai tutarlılık (eventual consistency) ile yüksek erişilebilirlik sunar. BigQuery’nin erişilebilirliği bölgesel veya çok bölgelidir; dayanıklılık için kritik veri setlerini çok bölgeli (multi-region) olarak somutlaştırın (materialize).
- Maliyet:
- Taranan bayt miktarını azaltmak için BigQuery’yi bölümleme (partitioning) ve kümeleme (clustering) ile optimize edin. Ağ kısıtlı bağlantılar üzerinden gönderilen küçük dosyalar için, RPC ek yükünü azaltmak amacıyla toplu (batch) veya paket (bundle) halinde gönderin. Uygun durumlarda, önbelleğe alınmış, etkileşimli gösterge panoları için BigQuery BI Engine’i kullanın.
- Bölgesel, çok bölgeli, hibrit ve çoklu bulut:
- Bölgesel tasarım, gecikmeyi ve maliyeti azaltır; çok bölgeli depolama (ör. BigQuery US/EU çoklu bölge, Cloud Storage çift/çoklu bölge), dayanıklılığı ve yerellik seçeneklerini artırır. Felaket Kurtarma (DR) için RPO/RTO’yu tanımlayın ve kritik veri setlerini çoğaltın. Hibrit senaryolarda, CDC (Değişiklik Veri Yakalama) için Datastream’i ve toplu taşıma için Transfer Appliances veya Storage Transfer Service’i kullanın. Çoklu bulut (multi-cloud) için, Cloud Storage’da açık formatları standartlaştırın ve taşınabilir işlem gücü (Apache Beam/Dataflow, Dataproc üzerinde Spark) kullanırken, dışarı veri aktarım (egress) ve operasyonel ek yükleri göz önünde bulundurun.
Katmanlama, Yaşam Döngüsü ve Hizmet Seçimi
- Katmanların ayrılması:
- Depolama: Ham/bronze ve arşivleme için Cloud Storage; işlenmiş/sunum analitiği için BigQuery; düşük gecikmeli anahtar erişimi için Bigtable; OLTP için Spanner/Cloud SQL.
- İşlem: Sunucusuz akış/toplu iş için Dataflow; Spark/Hadoop ekosistemleri için Dataproc; depo içi ELT için BigQuery; olay tabanlı mikro servisler için Cloud Run/Functions.
- Orkestrasyon: DAG’ler ve API koreografisi için Cloud Composer (Airflow) veya Workflows; cron benzeri tetikleyiciler için Scheduler.
- Sunum: Çevrimiçi okumalar için Bigtable veya Spanner; BI için BigQuery; gösterge panelleri için Looker/BI Engine; önbelleğe alma için Memorystore.
- Veri yaşam döngüsü:
- Alım (Ingest): Akışlar için Pub/Sub; dosyalar için Storage Transfer veya gsutil; SaaS için Data Transfer Service. Doğrulama, tekilleştirme ve değişmez ham verileri nesne sürümleme (object versioning) ile Cloud Storage’a indirme.
- İşleme: Ham veriyi silver’a (temizlenmiş, uygun hale getirilmiş), ardından gold’a (işe hazır mart’lar) dönüştürmek için Dataflow veya BigQuery kullanma.
- Sunma: Analitik için BigQuery görünümlerini/tablolarını yayınlama; API’lar için özellikleri veya tahminleri önceden hesaplayıp Bigtable’a yazma.
- Saklama ve arşivleme: Coldline/Archive katmanlarına geçiş yapmak için Cloud Storage yaşam döngüsü kurallarını uygulama; saklama için bölüm sonlandırması (partition expiration) ile BigQuery zaman bölümlemesini kullanma. Gerektiğinde CMEK’i ve veri sızdırma koruması için VPC Service Controls’ü etkinleştirme.
- İş yükü özelliklerine göre hizmet seçimi:
- Geniş satırlı ve düşük gecikmeli, yüksek verimli zaman serisi: Bigtable.
- ANSI SQL ile güçlü tutarlılığa sahip küresel OLTP: Cloud Spanner.
- Mütevazı ölçekte geleneksel ilişkisel işlemler: Cloud SQL.
- ANSI SQL ve depolama/işlem ayrımı ile petabayt ölçeğinde analitik: BigQuery.
- Gerçek zamanlı alım ve işleme: Pub/Sub + Dataflow.
- Toplu Spark/Hadoop veya kütüphaneye özgü araçlar: Dataproc.
Kısa BigQuery bölümleme örneği:
CREATE TABLE ops.events
PARTITION BY DATE(event_ts)
CLUSTER BY device_id AS
SELECT * FROM staging.events_clean;
Pratik Problem Senaryosu
Contoso Mobility, küresel bir e-scooter filosu işletmektedir ve sürüş telemetrisi ile faturalandırma için gerçek zamanlı alım, işleme, depolama ve analitiğe ihtiyaç duymaktadır. Dakikada milyonlarca olayı, saniyenin altında çalışan dolandırıcılık kurallarını, güncel gösterge panellerini, gizlilik kontrollerini ve dayanıklı çok bölgeli operasyonları desteklemeleri gerekmektedir.
Yaklaşım:
- Cloud Pub/Sub ile olay alımını kurma.
- Gerekçe: Pub/Sub, tek bir küresel uç nokta, dayanıklı arabelleğe alma ve anlık yoğun cihaz trafiği için yatay ölçeklendirme sağlar. 1 saatlik pencereler için cihaz içi sıralamayı korumak amacıyla scooter başına sıralı anahtarlar kullanın.
- Cloud Dataflow (Apache Beam) ile akış işlemeyi uygulama.
- Gerekçe: Dataflow otomatik ölçeklendirmesi ani artışları yönetir ve idempotent anahtarlarla birleştirildiğinde tam olarak bir kez (exactly-once) hedefler sunar. Gecikmiş/sıra dışı telemetriyi yönetmek için olay zamanı pencereleri ve watermark’lar kullanın. İşlenmiş akışlara bir ana çıktı ve işlenemeyen kayıtlar (dead-letter) için bir yan çıktı verin.
- Yapılandırma:
.withAllowedLateness(Duration.standardMinutes(15))
.discardingFiredPanes();
- Ham ve işlenmiş verileri sırasıyla Cloud Storage ve BigQuery’de kalıcı hale getirme.
- Gerekçe: Yeniden oynatma ve denetim için ham (bronze) Avro dosyalarını çift bölgeli bir Cloud Storage bucket’ına indirin. Analitik için işlenmiş (silver) akışları, verimli nokta aramaları için scooter_id üzerinde kümelenmiş, bölümlenmiş BigQuery tablolarına yazın. Geçici akış bayatlığını önlemek için gösterge paneli sorgularında küçük bir güncellik arabelleği uygulayın.
- Operasyonel aramaları ve dolandırıcılık kontrollerini Cloud Bigtable’dan sunma.
- Gerekçe: 100 ms altı kural değerlendirmesi, düşük gecikmeli rastgele erişim gerektirir. Agregasyonları (örneğin, 5 dakikalık pencere başına cihaz başına sürüş sayısı) Dataflow’da önceden hesaplayın ve hotspotting’i önlemek ve okumaları tabletler arasında paralelleştirmek için karma ön ekli bir satır anahtarı (ör. h(prefix)+device_id+window_start) kullanarak Bigtable’a yazın.
- İşlemsel faturalandırmayı Cloud Spanner’da yönetme.
- Gerekçe: Faturalandırma, küresel olarak tutarlı SQL, güçlü tutarlılık ve yüksek erişilebilirlik gerektirir. Müşteri portalları için okuma gecikmelerini azaltmak amacıyla birincil coğrafyada bir lider ve ikincil bölgelerde salt okunur replikalar kullanın.
- Dataplex, Data Catalog ve Cloud DLP ile yönetişimi uygulama.
- Gerekçe: PII alanlarını sınıflandırın, veri setlerini etiketleyin ve BigQuery’de sütun düzeyinde güvenlik uygulayın. Depolamadan önce hassas nitelikleri token’laştırmak için Cloud DLP’yi Dataflow ardışık düzenine entegre edin. Dataplex alanları kurumsal sahipliği yansıtır; her alan, SLO’ları olan belgelenmiş veri ürünleri yayınlar.
- Cloud Composer ve Cloud Monitoring ile orkestrasyon ve operasyon sağlama.
- Gerekçe: Composer, toplu geriye dönük doldurmaları, sıkıştırmaları ve ML özellik materyalizasyonunu koordine eder. Monitoring, uçtan uca SLI’ları gözlemler: Pub/Sub birikimi (backlog), Dataflow watermark gecikmesi, BigQuery bölüm tamlığı ve Bigtable kuyruk gecikmeleri. SLO ihlallerinde uyarı verin; birikim artışına göre Dataflow’u otomatik ölçeklendirin.
- Bölümleme ve katmanlama ile maliyetleri ve yaşam döngüsünü optimize etme.
- Gerekçe: BigQuery tabloları event_ts’ye göre 90 günlük saklama süresiyle bölümlenir ve scooter_id’ye göre kümelenir. Cloud Storage, ham veriyi 30 gün sonra Coldline’a ve 180 gün sonra Archive’a taşımak için yaşam döngüsü kurallarını kullanır. Zamanlanmış BigQuery işleri, sonraki Spark işleri için dosya sayısı ek yükünü azaltmak amacıyla küçük mikro toplu iş dosyalarını daha büyük parquet nesnelerine sıkıştırır.
- Riskleri ve dayanıklılığı doğrulama.
- Gerekçe: Pub/Sub kotalarını ve Dataflow otomatik ölçeklendirmesini doğrulamak için beklenen zirvenin 2 katında yük testleri yapın. Bölgesel bir yük devretme tatbikatı gerçekleştirin: BigQuery çok bölgeli veri setleri ve çift bölgeli bucket’lar erişilebilirliği sürdürür; Spanner’ın çok bölgeli örneği, otomatik yük devretme yoluyla RPO=0 ve yapılandırılmış RTO’yu sürdürür. CMEK ve VPC Service Controls’ü zorunlu kılmak için ilke doğrulaması ile Kod Olarak Altyapı (Terraform) kullanın.
Bu mimari, sorumlulukları net bir şekilde ayırır: Pub/Sub alımı arabelleğe alır, Dataflow hesaplama yapar, Cloud Storage ve BigQuery analitik verilerini depolar ve sunar, Bigtable operasyonel okumaları hızlandırır ve Spanner tutarlı işlemleri garanti eder. Bölümleme, kümeleme, yaşam döngüsü politikaları ve otomatik ölçeklendirme yoluyla maliyetleri kontrol ederken ölçeklenebilirlik ve gecikmeyi dengeler ve belgelenmiş veri ürünleri, sözleşmeler ve sürekli doğrulama yoluyla yönetişim ve güvenilirliği yerleşik hale getirir.
Bu soruları çözün → · ExamRoll.io’da süreli pratik →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Sınavınızı geçin →