Google PDE: BigQuery Analitiği ve Veri Ambarı Mühendisliği — Ç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.

Genel Bakış

BigQuery; depolamayı işlem gücünden ayıran, neredeyse sonsuz ölçek, ANSI SQL ve entegre yönetişim sağlayan sunucusuz, sütunlu bir MPP analitik ambarıdır. BigQuery üzerinde ambar mühendisliği; şema tasarımı (bölümleme, kümeleme, denormalizasyon ve normalizasyon karşılaştırması, iç içe geçmiş kayıtlar), veri alım (ingestion) desenleri (toplu yüklemeler, akış, Storage Write API) ve iş yükü yönetimi (isteğe bağlı (on-demand) ve kapasite tabanlı sürümler ve rezervasyonlar) arasında bir denge kurar. Taranan bayt miktarını en aza indirmek ve gecikme süresini azaltmak için güçlü güvenlik (yetkilendirilmiş görünümler, satır/sütun politikaları, politika etiketleri), maliyet kontrolleri ve performans araçları bir arada bulunur. Bu bölüm, üretim ortamında öngörmeniz gereken temel tasarım, operasyonlar ve hata modlarını kapsar.

Depolama ve Anlambilim: Veri Kümeleri, Tablolar, Görünümler ve Göl Erişimi

Veri kümeleri, tablolar, görünümler:
- Veri kümeleri, IAM ve yönetişimi kapsar. İzolasyon ve faturalandırma netliği için kiracı başına ayrı veri kümeleri tutun.
- Standart tablolar verileri yerel olarak saklar; bölümleme ve kümeleme, yerleşimi ve ayıklamayı (pruning) yönetir.
- Görünümler, veri depolamadan SQL mantığını kapsüller. Yetkilendirilmiş görünümler, bir görünüm sahibinin altta yatan tabloları gizlerken diğer projelere veya kiracılara kısıtlı alt kümeleri sunmasına olanak tanır.
- Materyalleştirilmiş görünümler (MV’ler) önceden hesaplanmış sonuçları kalıcı hale getirir ve otomatik olarak yenilenir. Sorgu yeniden yazma mekanizması, uyumlu olduğunda MV’leri şeffaf bir şekilde kullanır; uyumsuz koşullar veya fonksiyonlar ise bunları atlar.
- Harici tablolar Cloud Storage, Google Drive veya Google Sheets’teki verilere referans verir. Veri alımından (ingestion) kaçınırlar ancak kolaylık karşılığında iş hacmi (throughput) ve fonksiyon desteğinden ödün verirler. Tekrarlanan analizler için verileri yerel tablolara alın (ingest edin).
Bölümleme, kümeleme ve iç içe geçmiş kayıtlar:
- Taramaları ayıklamak (prune) için veri alım zamanına, DATE/TIMESTAMP/DATETIME’a veya bir tamsayı aralığına göre bölümleme yapın. Ayıklamayı (pruning) etkinleştirmek için bölümleme sütununda WHERE filtreleri veya _PARTITIONDATE gibi dekoratörler kullanın.
- Yüksek kardinaliteye sahip, sık filtrelenen veya birleştirilen (join) sütunlar (en fazla 8) üzerinde kümeleme yapın. BigQuery otomatik olarak yeniden kümelenir; tekrarlanan küçük DML işlemleri kümeleme kalitesini geçici olarak düşürebilir.
- İç içe ve tekrarlanan kayıtlar (STRUCT, ARRAY), birleştirme (join) ek yükü olmadan bire çok ilişkileri modeller. UNNEST’i dikkatli kullanın; büyük diziler üzerinde tekrarlanan UNNEST işlemleri veriyi dramatik bir şekilde genişletebilir (fan out).
Denormalizasyon ve normalizasyon karşılaştırması:
- Birleştirmeleri (join) en aza indirmek ve sütunlu taramalardan yararlanmak için boyut (dimension) niteliklerini olgu (fact) tablolarına denormalize edin; bu, okuma ağırlıklı analizler için idealdir.
- Yazma çoğaltması (write amplification), güncelleme sıcak noktaları (hotspot) veya kendi kendine birleştirmeler (self-join) çekişmeye veya karmaşıklığa neden olduğunda normalizasyon yapın (örneğin, kendi kendine birleştirme (self-join) patlamalarını önlemek için ana hasta ve ziyaret tablolarını ayırmak). Hibrit bir yaklaşım düşünün: normalize edilmiş çekirdek varlıklar ile geniş, denormalize edilmiş olgular veya iç içe geçmiş alt öğeler.
Materyalleştirilmiş görünümler: tasarım konuları
- Bölümlenmiş temel tablolar üzerinde kararlı, artımlı agregasyonlar için en iyisidir. MV yenilemesi asenkrondur; alt sistem kullanıcıları eskime pencerelerini tolere etmeli veya bir geri dönüş (fallback) olarak temel tabloları sorgulamalıdır.
- Artımlı yenileme için bölümleme sütununa göre filtreleme ve gruplama yapın. Belirleyici olmayan (non-deterministic) fonksiyonlar, desteklenmeyen birleştirmeler (join) veya UDF’ler, MV’leri yeniden yazma işleminden diskalifiye edebilir.
Federe sorgular, BigLake ve itme (pushdown):
- Federe sorgular, harici sistemleri (örneğin, Cloud SQL) doğrudan SQL ile okur. Hafif birleştirmeler (join) veya tek seferlik keşifler için kullanışlıdırlar ancak daha yüksek gecikme süresine ve daha sıkı kotalara sahiptirler; ağır analizler için verileri BigQuery’ye çıkarın (extract).
- BigLake tabloları, Cloud Storage’daki veya açık tablo formatlarındaki (Parquet gibi) veriler üzerinde sütun ve satır seviyesinde kontrollerle göl (lake) ve ambar yönetişimini birleştirir. Yüklem (predicate) ve projeksiyon itme (pushdown) özellikleri indirilen bayt miktarını azaltır; ancak büyük taramalar, maksimum performans için yine de verilerin yerel tablolara alınmasını (ingestion) gerektirir.
Joker karakterli tablolar ve eski parçalar (shard’lar):
- Joker karakterli sorgular, tarihe göre parçalanmış (sharded) tablolar için eski bir desendir. Yerel bölümlemeyi tercih edin, ancak gerektiğinde şu şekilde kullanın: SELECT ... FROM bigquery-public-data.noaa_gsod.gsod* WHERE _TABLE_SUFFIX >= '2010'.

Sorgu Optimizasyonu ve İş Yükü Yönetimi

Bölüm (partition) ayıklama ve kümeleme:
- Soğuk bölümleri taramaktan kaçınmak için her zaman bölüm sütununa göre filtreleyin. Dar aralıklarla BETWEEN kullanın.
- Kümeleme anahtarlarını seçiciliğe göre sıralayın; ilk anahtarlar sık kullanılan filtreler ve join’lerle eşleşmelidir. Çok düşük kardinaliteye sahip sütunlarda kümeleme yapmaktan kaçının.
Sorgu planı optimizasyonu:
- Eğik (skewed) join’leri, büyük shuffle işlemlerini veya ayıklanmamış taramaları bulmak için EXPLAIN ve yürütme ayrıntılarını kullanın.
- SELECT listeleri ve alt sorgularla sütun sayısını erkenden azaltın; BigQuery sütun tabanlıdır ve kullanılmayan sütunları verimli bir şekilde atar.
- Büyük verilerde hız/maliyet dengesi için yaklaşık (approximate) agregasyonları (örneğin, APPROX_QUANTILES) tercih edin.
- Veri alım kaynakları olayları tekrarlayabildiğinde, pencere fonksiyonları (window functions) ile tekilleştirme uygulayın:

undefined

Join’ler ve denormalizasyon:
- Shuffle’ı azaltmak için join anahtarlarını kümeleme anahtarları olarak birlikte konumlandırın. Bloom filtreleri veya ön agregasyon, aşırı eğiklik (skew) durumunda yardımcı olabilir.
- Sıcak (hot) join’lerden kaçınmak için küçük, yavaş değişen boyutları (dimension) fact tablolarına denormalize edin. Sık güncellenen çok geniş boyutlar için normalleştirin ve kümeleme anahtarlarına ve materialize edilmiş join’lere güvenin.
İş yükü yönetimi, slot’lar, sürümler (editions) ve otomatik ölçeklendirme:
- İsteğe bağlı (On-demand): BigQuery, işlem gücünü sorgu başına elastik olarak ölçeklendirir; taranan TB başına ödeme yaparsınız. Maliyeti, faturalandırılan maksimum bayt ve bölüm ayıklama ile kontrol edin.
- BigQuery sürümleri (Standard, Enterprise, Enterprise Plus) ile kapasite tabanlı model, slot rezervasyonlarını kullanır. Temel taahhütler satın alın, rezervasyonlar oluşturun ve projeleri veya klasörleri atayın. Otomatik ölçeklendirme, yoğun zamanlarda slot ekleyebilir ve talep düştüğünde bunları serbest bırakabilir; çakışmayı önlemek için ETL ve BI için ayrı rezervasyonlar kullanın.
- İş önceliği: düşük gecikme için etkileşimli (interactive) (varsayılan); geçmişe dönük veri doldurma (backfill) ve zamanlanmış sorgular için toplu (batch). Toplu işler, rezervasyonda veya hizmette boş kapasite bulunana kadar kuyruğa alınır, ardından normal maliyetle çalışır.
Eşzamanlılık ve kotalar:
- Kritik iş yüklerini izole etmek için rezervasyonları ve atamaları kullanın. Karma kiracılar (mixed tenants) için, bunları özel eşzamanlılık limitleriyle ayrı rezervasyonlara veya projelere yerleştirin.
- Atıf (attribution) için işleri etiketleyin; slot kullanımı ve kuyruk gecikmeleri için INFORMATION_SCHEMA.JOBS ve Cloud Monitoring metriklerini izleyin.
BI önbelleğe alma ve verinin güncelliği:
- Sorgu sonuçları önbelleği, aynı sorgular için gecikmeyi/maliyeti iyileştirir; bir saatten daha güncel veriye ihtiyaç duyan istemcilerde devre dışı bırakın. Bazı BI araçları verileri bağımsız olarak önbelleğe alır—en son sonuçları görüntülemek için rapor önbelleğini devre dışı bırakın.

Veri Alımı, Federasyon ve Kurtarma

Yükleme (Load) işleri:
- Cloud Storage’dan toplu yüklemeler (Avro/Parquet tercih edilir) güvenilir ve uygun maliyetlidir. Şemayı ve kodlamayı (encoding) açıkça belirtin; eşleşmeyen CSV kodlamaları, bayt-bayt tutarsızlıkların yaygın bir nedenidir.
- Birleştirme (merge) işlemlerinden kaçınmak için bölüm dekoratörleri (partition decorators) kullanın veya bölümlenmiş tablolara yükleyin. Büyük yüklemeler için bölüme göre paralelleştirin.
Akış (Streaming) ile veri alımı ve Storage Write API:
- Eski (legacy) akış eklemeleri basittir ancak daha katı kotalara sahiptir ve birkaç saniyeliğine nihai tutarlılık (eventual consistency) gösterebilir; çok yeni veriler üzerinde zaman yolculuğu (time travel) gecikebilir.
- Storage Write API, daha iyi tekilleştirme kontrolleri ile yüksek verim ve düşük gecikmeli yazmalar için önerilen yoldur. Tekrarları önlemek için idemopotans (stream offset’leri) kullanın.
- Uygulama tasarımı, aktarım halindeki (in-flight) olayları tolere etmelidir: etkileşimli sorguları beklenen kullanılabilirliğe göre (örneğin, gözlemlenen gecikmenin 2 katı) geciktirin veya veri alım zamanı bölümlerinde watermark’lar kullanın.
Dataflow ve dead-letter tasarımı:
- İş ortaklarından gelen bozuk satırlı CSV’ler için, ayrıştırmak ve doğrulamak üzere Dataflow kullanın, geçerli kayıtları Storage Write API aracılığıyla BigQuery’ye yazın ve hataları incelemek üzere bir dead-letter tablosuna yönlendirin.
- BigQuery’den büyük ölçekte okuma yaparken, yalnızca gerekli alanları seçmek ve shuffle’ı azaltmak için sorgu tabanlı okumaları (fromQuery) tercih edin.
Zamanlanmış sorgular ve dönüşümler:
- ELT dönüşümleri, artımlı toplamalar (incremental rollups) ve tablo bakımı için zamanlanmış sorguları kullanın. Bölümlenmiş, kümelenmiş hedeflere yazmayı tercih edin. Zamanlanmış sorgular varsayılan olarak toplu (batch) önceliğe sahiptir ve rezervasyonlarla entegre olur.
Bildirimler ve gözlemlenebilirlik:
- Belirli tablo ekleme işlerinde uyarıları tetiklemek için BigQuery denetim günlüklerini bir log sink ile Pub/Sub’a aktarın:
  - Filtre örneği:

undefined

Kullanım modellerini keşfetmek ve yönetişimi (governance) uygulamak için Cloud Logging denetim günlüklerini ve INFORMATION_SCHEMA görünümlerini kullanın.
Zaman yolculuğu (Time travel), anlık görüntüler (snapshots) ve klonlar:
- Zaman yolculuğu, bir tabloyu önceki bir zaman damgasında (varsayılan 7 gün) sorgulamanıza olanak tanır. Geçmiş durumları okumak için FOR SYSTEM_TIME AS OF kullanın.
- Tablo anlık görüntüleri, yazma anında kopyalama (copy-on-write) ile belirli bir anın görünümünü yakalar; tutarlı geçmişe dönük veri doldurma veya kurtarma için kullanın. Tablo klonları, ayrışana kadar minimum depolama ile geliştirme veya ’eğer-olursa’ analizi için neredeyse anında meta veri kopyaları sağlar.
- Kurtarma seçenekleri:
  - Küçük hatalar: zaman yolculuğunu kullanarak sorgulayın ve geri yüklemek için INSERT…SELECT kullanın.
  - Büyük geri yükleme: anlık görüntüden veya klondan oluşturun, ardından değiştirin (swap).
- Saklama (retention) politikasını uygulamak için tablo ve bölüm son kullanma süresini ayarlayın; saklama süresinin zaman yolculuğu ihtiyaçlarıyla uyumlu olduğunu doğrulayın.
Federasyon kaynakları:
- Hafif join’ler için Cloud SQL federasyonunu kullanın; sürekli analizler veya büyük taramalar için, yerel (native) tablolara veri çıkarma-yükleme (extract-load) işlemini zamanlayın.
- Cloud Storage’daki Parquet/ORC üzerindeki BigLake tabloları, ilke etiketlerini (policy tags) uygulayabilir ve filtreleri ve sütun projeksiyonlarını aşağı itebilir (push down); yine de yerel depolamadan daha yüksek gecikme bekleyin.

Güvenlik, Yönetişim ve Maliyet Kontrolü

IAM ve en az ayrıcalık ilkesi:
- Veri kümesi düzeyindeki rolleri (BigQuery Data Viewer, Data Editor) yalnızca onaylanmış kullanıcılara minimum düzeyde verin; API erişimini hizmet hesapları ve özel olarak seçilmiş gruplarla kısıtlayın.
- İzolasyon için istemcileri ve ortamları veri kümesi ve projeye göre ayırın. Gürültülü komşu (noisy neighbors) sorununu önlemek için rezervasyonları proje veya klasör bazında atayın.
Yetkilendirilmiş görünümler ve satır düzeyinde güvenlik:
- Yetkilendirilmiş görünümler, yalnızca seçili sütunları/satırları harici projelere sunarken, görünümün projesi tablo erişimini korur. Görünümü ve kaynağı aynı veri kümesinde tutun veya hedef projeye veri kümesi düzeyinde yetkilendirme kullanın.
- Satır erişim politikaları ile satır düzeyinde güvenlik, sorgu zamanında satırları kullanıcıya veya gruba göre filtreler; katmanlı kontrol için yetkilendirilmiş görünümlerle birleştirin.
Sütun düzeyinde güvenlik ve politika etiketleri:
- Hassas sütunları korumak ve veri maskelemeyi etkinleştirmek için Data Catalog politika etiketlerini kullanın. Veri sınıflandırmasıyla uyumlu hale getirmek için erişimi (tablolara değil) etiketlere atayın. İş ortağı erişimi için, etiketler aracılığıyla PII (Kişisel Tanımlanabilir Bilgi) sütunlarını maskeleyin veya erişimi engelleyin.
BigQuery ML ve veri ambarı içi analitik:
- CREATE MODEL ve ML.PREDICT ile doğrudan BigQuery’de modelleri (örneğin, doğrusal/lojistik regresyon, XGBoost, K-means, zaman serisi) eğitin ve sunun. Özellikleri (features) bölümlenmiş tablolarda saklayın ve zamanlanmış yeniden eğitim kullanın.
- Uzak modeller (remote models), birleşik yönetişim dahilinde puanlama yapmak için SQL’den Vertex AI veya harici uç noktaları çağırmanıza olanak tanır. Tekrarlanan sorgular için gecikmeyi amorti etmek amacıyla çıktıları tablolarda önbelleğe alın.
Maliyet kontrolleri ve performans sorunlarını giderme:
- Taranan bayt miktarını azaltın:
  - Bölümleme ve kümeleme yapın; her zaman bu anahtarlara göre filtreleyin.
  - Yalnızca gerekli sütunları seçin (SELECT); SELECT * kullanımından kaçının.
  - Uygulanabilir olan yerlerde materyalize görünümler ve sonuç önbelleğe almayı kullanın.
  - Maliyeti sınırlamak için maximum_bytes_billed parametresini ayarlayın.
- Performans sorunlarını giderin:
  - Veri çarpıklığı (skew), ayıklanmamış bölümler (non-pruned partitions) veya shuffle etkin noktaları (hotspots) için iş yürütme ayrıntılarını inceleyin. Shuffle’ı azaltmak için join anahtarlarını yeniden düzenleyin veya ön toplama (pre-aggregate) yapın.
  - MV yeniden yazımlarını doğrulayın; uyumlu koşul ifadeleri (predicates) ve deterministik fonksiyonlar olduğundan emin olun.
  - Yeni akış verilerini göstermeyen panolar için, tutarlılık gecikmesini hesaba katın veya istemci tarafı önbelleğe almayı devre dışı bırakın.
- Yönetişim görünürlüğü: Geri ödeme yapmak ve aykırı değerleri belirlemek için Cloud Logging, INFORMATION_SCHEMA ve ayrıntılı iş etiketleri ile denetim yapın.

Pratik Problem Senaryosu

NovaCare Health, bölgesel bir teletıp platformu işletmektedir. Tek tablolu bir patient_and_visit tasarımı pilot projeyi desteklemişti, ancak 100 kat ölçekte raporlar zaman aşımına uğruyor, akış yoluyla yapılan upsert (güncelleme/ekleme) işlemlerinden dolayı yinelenen kayıtlar ortaya çıkıyor ve iş ortakları katı veri izolasyonu talep ediyor.

Yaklaşım:

Şemayı ve yerleşimi yeniden tasarlayın
- Normalleştirilmiş temel tablolar oluşturun: patients(patient_id, demographics, updated_at) ve visits(visit_id, patient_id, visit_ts, metrics, updated_at).
- visits tablosunu DATE(visit_ts) üzerinde bölümlenmiş, patient_id ve visit_id’ye göre kümelenmiş bir tablo yapın. Pano hızını artırmak için küçük referans boyutlarını (dimensions) visits tablosu içinde denormalize edilmiş olarak tutun.
- Gerekçe: Normalleştirme, tek bir yoğun kullanılan (hot) tablo üzerindeki pahalı self-join’leri ve yoğun satır güncellemelerini önler. Bölümleme, geçmişe yönelik taramaları ayıklar (pruning); kümeleme, patient_id üzerindeki join’leri ve filtreleri bir arada konumlandırarak shuffle’ı azaltır.
Storage Write API ile veri alın ve tekrarlanabilirliği (idempotency) sağlayın
- Gelen olayları ayrıştırmak, doğrulamak ve tekrarlanabilir ofsetlerle (idempotent offsets) Storage Write API’deki adlandırılmış akışlara yazmak için bir Dataflow pipeline’ı kullanın.
- Hatalı biçimlendirilmiş olayları, incelenmek üzere bir dead-letter BigQuery tablosuna yönlendirin.
- Gerekçe: Storage Write API, eski (legacy) akış yöntemlerine göre daha yüksek verim, daha düşük gecikme ve daha iyi tekilleştirme garantileri sunar. Dead-lettering, iş ortağı veri kalitesi sorunlarına ilişkin görünürlüğü korur.
Sorgularda güncellik ve tekilleştirme için tasarım yapın
- Etkileşimli analitik için, en son bölümü sorgulamadan önce kısa bir filigran (watermark) ekleyin (örneğin, gözlemlenen kullanılabilirliğin 2 katı); veya devam eden (in-flight) satırları hariç tutmak için _PARTITIONDATE’e göre partition_date <= CURRENT_DATE() koşuluyla filtreleyin.
- Kaynak sistemdeki yeniden denemeleri tolere etmesi gereken görünümlerde ROW_NUMBER() OVER (PARTITION BY visit_id ORDER BY event_ts DESC) = 1 kullanın.
- Gerekçe: Akış, kısa bir aralık için nihai tutarlıdır (eventually consistent). Filigranlama ve pencere tabanlı tekilleştirme, panoları geçici boşluklardan ve yinelenen kayıtlardan korur.
Materyalize görünümlerle yaygın toplu işlemleri (aggregates) hızlandırın
- DATE(visit_ts) ve hasta kohortlarına göre gruplandırılmış günlük KPI’lar için visits tablosu üzerinde bölümle hizalanmış MV’ler oluşturun. Koşul ifadelerinin (predicates) yeniden yazımla uyumlu olduğundan emin olun.
- Gerekçe: MV’ler, tekrarlanan raporlar için gecikmeyi ve taranan bayt miktarını azaltır; BigQuery, MV’yi şeffaf bir şekilde kullanmak için sorguları yeniden yazar.
Kiracı (tenant) izolasyonunu ve ayrıntılı güvenliği uygulayın
- Her iş ortağını özel bir veri kümesine yerleştirin. İş ortağı gruplarına en az ayrıcalık ilkesine uygun veri kümesi rolleri verin.
- Ham tabloları açığa çıkarmadan, paylaşılan, iş ortakları arası karşılaştırmalar (benchmarks) için yetkilendirilmiş görünümler yayınlayın.
- PII sütunlarına politika etiketleri uygulayın ve dahili çok kiracılı (multi-tenant) analitik için erişimi partner_id’ye göre kısıtlamak amacıyla visits tablosuna satır erişim politikaları ekleyin.
- Gerekçe: Kiracı başına veri kümesi segmentasyonu, yetkilendirilmiş görünümler ve politika etiketleri ile birleştiğinde, özel olarak seçilmiş paylaşıma olanak tanırken en az ayrıcalık ilkesini uygular.
İş yüklerini sürümler (editions), rezervasyonlar ve otomatik ölçeklendirme (autoscaling) ile yönetin
- BigQuery sürümlerinde kapasite satın alın ve iki rezervasyon oluşturun: etl (Dataflow hedefleri, zamanlanmış dönüşümler) ve bi (geçici/raporlama). Projeleri buna göre atayın ve ani yükselişleri karşılamak için otomatik ölçeklendirmeyi etkinleştirin.
- ELT sorgularını net SLA’larla toplu (batch) olarak zamanlayın; etkileşimli projeler için maximum_bytes_billed parametresini ayarlayın.
- Gerekçe: Ayrı rezervasyonlar, ETL’in BI kaynaklarını tüketmesini (starving) önler. Otomatik ölçeklendirme, aşırı kaynak ayırmadan anlık yoğun yüklere uyum sağlar.
Maliyeti yönetin ve kullanımı gözlemleyin
- visit_ts üzerinde filtrelemeyi zorunlu kılın; paylaşılan görünümlerde SELECT * kullanımını reddedin. Ayıklanmamış taramaları ve çarpık join’leri tespit etmek için INFORMATION_SCHEMA.JOBS kullanın.
- Beklenmedik artışlar için izleme uyarılarını tetiklemek amacıyla, visits üzerindeki insert işlerine göre filtrelenmiş bir log sink ile BigQuery denetim günlüklerini Pub/Sub’a aktarın.
- Gerekçe: Bayt ayıklama (byte-pruning) ve sütun projeksiyonu maliyeti kontrol eder; denetim günlükleri, erişim modellerini ve anormallikleri neredeyse gerçek zamanlı olarak ortaya çıkarır.
Kurtarma ve geriye dönük veri doldurma (backfill) işlemlerini planlayın
- Uyumluluk ve zaman yolculuğu (time-travel) ihtiyaçlarıyla uyumlu varsayılan tablo sona erme politikalarını etkinleştirin. Büyük düzenlemeler için bir anlık görüntü (snapshot) oluşturun, değişiklikleri çalıştırın ve gerekirse hızlıca geri alın. Depolama alanını kopyalamadan dev/test amaçlı ’eğer-olursa’ (what-if) analizleri için tablo klonlarını kullanın.
- Gerekçe: Anlık görüntüler ve klonlar hızlı, alan açısından verimli güvenlik ağları sağlar; zaman yolculuğu ise küçük düzeltici geri yüklemeleri kapsar.
Veri ambarı içi ML’i entegre edin
- İşlenmiş özellikleri (engineered features) bölümlenmiş tablolarda saklayın ve yeniden kabul riskini tahmin etmek için BigQuery ML sınıflandırma modellerini eğitin. Vertex AI üzerinde barındırılan harici modeller için, uzak modeller (remote models) oluşturun ve düşük gecikmeli join’ler için tahminleri kümelenmiş bir tabloda önbelleğe alın.
- Gerekçe: ML’i veriye yakın tutmak, veri hareketini ve yönetişim karmaşıklığını azaltır; uzak çıkarım (remote inference) sonuçlarını önbelleğe almak, gecikmeyi ve maliyeti amorti eder.

Bu tasarımla NovaCare, 100 kat yük altında öngörülebilir performans, güçlü kiracı izolasyonu ve yönetilen maliyetler elde ederken, düşük gecikmeli analitik ve tekrarlanabilir kurtarma yeteneklerini korur.

← Veri Depolama · Tüm alanlar · Dataflow ve Apache Beam ile Akış İşleme →

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