yoklateknik mülakat

Data Engineer Wh Materialized Views Caching Mülakat Soruları

75 doğrulanmış Data Engineer Wh Materialized Views Caching mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Wh Materialized Views CachingZorluk 1
Snowflake'te normal (materialize edilmemiş) bir view ile materialized view arasındaki temel fark nedir?
  • aMaterialized view sonucunu fiziksel olarak saklar
  • bMaterialized view yalnızca warehouse belleğinde var olur
  • cİkisi de her zaman aynı execution plan'a derlenir
  • dAradaki fark sadece bir adlandırma kuralıdır
Açıklama:Snowflake materialized view'ı sonuç kümesini diskte saklar ve kendi depolamasına, ayrıca bir yenileme mekanizmasına ihtiyaç duyar; normal view'ın saklanan verisi yoktur, her referansta sorguyu yeniden çalıştırır.
Wh Materialized Views CachingZorluk 1
Snowflake'te materialized view kullanımı hangi edition şartına bağlıdır?
  • aStandard dahil her edition'da kullanılabilir
  • bEdition'dan bağımsız, ayrı satılan bir eklenti
  • cEnterprise Edition veya üzerini gerektirir
  • dYalnızca hesabın bölgesine bağlıdır
Açıklama:Snowflake'te materialized view'lar Enterprise Edition (veya üzeri) özelliğidir; Standard Edition hesaplar materialized view oluşturamaz.
Wh Materialized Views CachingZorluk 2
Bir Snowflake mühendisi, iki temel tabloyu birbirine JOIN eden bir sorguyla materialized view tanımlamaya çalışıyor. Ne olur?
  • aNormal şekilde oluşturulur; JOIN'ler desteklenir
  • bOluşturma başarısız olur; JOIN'ler materialized view sorgusunda desteklenmez
  • cJOIN yok sayılır; yalnızca ilk tablo materialize edilir
  • dOluşturulur ama otomatik olarak normal view'a dönüşür
Açıklama:Snowflake materialized view'lar, self-join dahil JOIN içeren bir sorgu üzerinde tanımlanamaz; tanımlayıcı sorgu tek bir tabloya dayanmalıdır.
Wh Materialized Views CachingZorluk 2
Snowflake'te bir materialized view, temel tablo değiştikçe kullanıcı açısından nasıl güncel kalır?
  • aKullanıcı her değişiklikten sonra REFRESH çalıştırmalıdır
  • bHiç güncellenmez; drop edilip yeniden oluşturulmalıdır
  • cKullanıcı verisini elle yeniden yazan bir task zamanlamalıdır
  • dOtomatik bir arka plan servisi onun bakımını yapar
Açıklama:Snowflake materialized view bakımı tamamen otomatiktir: arka plan servisi, temel tablo değiştikçe view'ı günceller; bazı diğer ambarların aksine kullanıcının çalıştıracağı bir REFRESH komutu yoktur.
Wh Materialized Views CachingZorluk 2
CREATE MATERIALIZED VIEW mv_scored AS
SELECT id, my_custom_udf(amount) AS scored_amount
FROM orders;

Snowflake'te my_custom_udf bir user-defined function iken bu ifade çalıştırıldığında ne olur?
  • aBaşarılı olur; her türlü UDF tam desteklenir
  • bBaşarısız olur; hiçbir türde UDF'e izin verilmez
  • cYalnızca SQL dilinde yazılmış UDF'lerde başarılı olur
  • dBaşarılı olur ama UDF yalnızca oluşturmada bir kez çalışır
Açıklama:Snowflake, external function dahil UDF'lerin materialized view'ın tanımlayıcı sorgusunda kullanılmasına açıkça izin vermez, bu yüzden bu CREATE ifadesi UDF'in yazıldığı dilden bağımsız başarısız olur.
Wh Materialized Views CachingZorluk 3
Bir ekip, büyük bir Snowflake materialized view'ında belirli bir kolona filtre uygulayan sorguların hâlâ view'ın saklanan verisinin büyük bir kısmını taradığını fark ediyor. Bu filtre için pruning'i iyileştirmek üzere materialized view'ın kendisinde ne yapılandırabilirler?
  • aMaterialized view üzerinde bir clustering key
  • bMaterialized view üzerinde bir foreign key kısıtı
  • cHiçbir şey; bu ayar yalnızca temel tablolarda olur
  • dCREATE INDEX ile ikincil bir index
Açıklama:Snowflake, materialized view üzerinde doğrudan bir clustering key tanımlanmasına izin verir; bu, saklanan micro-partition'ları o key'e göre yeniden organize ederek filtre pruning'ini iyileştirir — ancak kendi bakım maliyetini de ekler.

1950 soruluk Data Engineer bankasında kendini sına.

Mülakata başla