Örnek sorular
Data Pipeline ReliabilityZorluk 1
Bir veri pipeline'ında fail-fast ile dead-letter-queue (DLQ) hata yönetimi stratejileri arasındaki temel fark nedir?
- aFail-fast, başarısız kaydı sonsuza kadar yeniden dener; dead-letter-queue ise hiçbir kayıt tutmadan onu hemen siler.
- bFail-fast ilk hatada tüm çalışmayı durdurur; DLQ ise başarısız kayıtları ayırıp devam eder.✓
- cFail-fast ve dead-letter-queue, ekiplerin aynı teknik için kullandığı yalnızca iki farklı isimdir.
- dFail-fast yalnızca streaming pipeline'lara, dead-letter-queue ise yalnızca batch pipeline'lara uygulanır.
Açıklama:Fail-fast, kötü bir durumun daha ileri yayılmaması için ilk hatada tüm çalışmayı durdurur; bu, availability'yi güvenlik lehine feda eder. Dead-letter-queue ise yalnızca sorunlu kayıtları sonradan incelenmek üzere ayırır, geri kalan batch işlenmeye devam eder. (a) her iki stratejiyi de yanlış tarif eder. (c) yanlıştır — farklı trade-off'ları temsil ederler. (d) yanlış bir kısıtlamadır; her iki desen de her iki işleme biçiminde uygulanabilir.
Data Pipeline ReliabilityZorluk 2
Bir retry politikası toplamda en fazla 3 deneme (1 orijinal + 2 retry) yapılmasına izin veriyor; denemeler arasında sabit 5 saniyelik bir bekleme var. Orijinal deneme t=0'da başarısız oluyor. Her retry de anında başarısız olursa, pipeline hangi zamanda pes edip işlemi kalıcı başarısız olarak işaretler?
- at=10 saniyede; üçüncü toplam deneme başarısız olup limite ulaşıldığında.✓
- bt=15 saniyede; yapılandırılmış limitin ötesinde dördüncü bir deneme daha yapıldıktan sonra.
- ct=5 saniyede; yapılandırılmış maksimum göz ardı edilip yalnızca ilk retry'den sonra.
- dHemen t=0'da; çünkü orijinal deneme zaten kalıcı bir başarısızlık sayılır.
Açıklama:1. deneme t=0'da başarısız olur; 5 saniyelik beklemeden sonra 2. deneme (1. retry) t=5'te başarısız olur; bir 5 saniye daha beklemeden sonra 3. deneme (2. retry) t=10'da başarısız olur. Bu toplam 3 denemedir, yani politikanın limitine ulaşılmıştır ve işlem t=10 saniyede kalıcı başarısız olarak işaretlenir. (b) yapılandırılmış deneme limitini aşar. (c) limite ulaşılmadan durur. (d) retry'lerin hiç yapılandırılmadığını varsayar.
Data Pipeline ReliabilityZorluk 2
Exponential backoff retry stratejisinde, ardışık retry denemeleri arasındaki bekleme süresi tipik olarak nasıl davranır?
- aKaç deneme başarısız olmuş olursa olsun tamamen sabit kalır.
- bHer denemeyle azalır, böylece başarısız olan işlemler zamanla giderek daha hızlı yeniden denenir.
- cHer başarısızlıkla kabaca üstel olarak büyür; genellikle rastgele jitter ile birlikte kullanılır.✓
- dHer denemeden sonra sıfıra sıfırlanır ve yalnızca ilk retry için anlamlıdır.
Açıklama:Exponential backoff, art arda gelen her başarısızlıktan sonra bekleme süresini katlar (ör. 1sn, 2sn, 4sn, 8sn...); birçok istemcinin tam olarak aynı anda yeniden denememesi için genellikle jitter da eklenir. (a) sabit-gecikme stratejisini tarif eder, exponential backoff'u değil. (b) amaçlanan davranışın tam tersidir. (d) deseni tamamen yanlış anlar.
Data Pipeline ReliabilityZorluk 1
Bir veri pipeline'ı bağlamında pipeline SLA (service level agreement) tipik olarak neyi tanımlar?
- aVerinin hedefe yüklenmeden önce dönüştürülmesinde kullanılan tam iç algoritmayı.
- bVerinin ne zaman hazır olacağına dair beklentiyi ve kabul edilebilir kalite/eksiksizliği.✓
- cPipeline'ın kod tabanı üzerinde çalışmasına izin verilen maksimum mühendis sayısını.
- dPipeline'ın kodunda asla bug olmayacağına dair bir garantiyi.
Açıklama:Pipeline SLA'sı, tüketicilerin güvenebileceği sonuçlara dair bir taahhüttür — tipik olarak zamanlılık (veri ne zaman hazır olacak) ve bazen kalite eşikleri — bir implementasyon detayı değil. (a), (c) ve (d) bir SLA'nın gerçekte taahhüt ettiği şeyle ilgisiz konulardır.
Data Pipeline ReliabilityZorluk 2
Bir dataset'in her saat güncellenmesi bekleniyor. En son 14:00'te başarıyla güncellendi. Şu an saat 16:45. Şu andaki veri tazeliği (freshness) gecikmesi nedir?
- a1 saat 45 dakika
- b2 saat 45 dakika✓
- c45 dakika
- d3 saat 45 dakika
Açıklama:Freshness lag, son başarılı güncellemeden bu yana geçen süredir: 16:45 - 14:00 = 2 saat 45 dakika. Beklenen sıklık saatlik olduğu için bu, verinin ciddi şekilde gecikmiş olduğu anlamına da gelir. (a), (c) ve (d) basit aritmetik hatalardır.
Data Pipeline ReliabilityZorluk 2
Downstream bir rapor, bir metrik için anormal derecede düşük sayılar gösteriyor, ama pipeline hatasız tamamlandı ve hiçbir job başarısız olmadı. Bu durumu en iyi ne tanımlar?
- aBu olamaz; hatasız tamamlanan bir pipeline her zaman doğru çıktı üretir.
- bBu normal bir SLA ihlalidir, çünkü SLA ihlalleri her zaman job başarısızlığı olarak görünür.
- cBu yalnızca bir retry politikası yanlış yapılandırmasını gösterir; daha fazla retry sorunu yakalardı.
- dBu, başarı görünmesine rağmen verinin bozuk olduğu sessiz veri bozulması (silent data corruption) olabilir.✓
Açıklama:Bir job, örneğin bir upstream schema değişikliği ya da exception fırlatmayan ince bir mantık hatası nedeniyle, başarıyla sonlanırken yine de yanlış veya eksik çıktı üretebilir. Bu, sessiz veri bozulmasının tanımlayıcı özelliğidir: hata sinyali yok ama veri bozuk. (a) yanlıştır — başarı durumu doğruluğu garanti etmez. (b) SLA zamanlılığını veri doğruluğuyla karıştırır. (c) nedeni yanlış atfeder; retry'ler geçici hataları ele alır, sessiz mantık/schema sorunlarını değil.