Örnek sorular
St Flink Time Watermarks WindowsZorluk 1
Flink DataStream API'sinde TumblingEventTimeWindows.of(Time.seconds(10)) çağrısındaki tek süre parametresi neyi belirtir?
- aStream için watermark üretim aralığını
- bHer pencerenin sabit uzunluğunu✓
- cPencere kapandıktan sonra geç olayların hâlâ kabul edileceği süreyi
- dPencere sınırlarını epoch'tan kaydırmak için kullanılan offset'i
Açıklama:Tumbling window assigner tek bir boyut parametresi alır ve bu, her pencerenin ne kadar süreceğini belirler; tumbling pencerelerde ayrı bir slide yoktur çünkü slide=size'dır. Watermark üretim aralığı ayrı bir execution config'dir, izin verilen geç kalış süresi başka bir metotla ayarlanır, sınır offset'i de ayrı, opsiyonel bir parametredir — bunların hiçbiri bu tek argümanın kontrol ettiği şey değildir.
St Flink Time Watermarks WindowsZorluk 2
SlidingEventTimeWindows.of(Time.minutes(1), Time.seconds(15)) tanımıyla tek bir olay kaç çakışan pencereye atanır?
- a4 — pencere boyutu (60sn) slide değerine (15sn) bölünür✓
- b1, çünkü her olay yalnızca tek bir sliding window'a ait olabilir
- c15, slide değerinin kendisini çakışma sayısı sanarak
- d60, pencere boyutu değerinin kendisini çakışma sayısı sanarak
Açıklama:Sliding pencereler çakışır: bir olay, zaman damgasını kapsayan HER pencereye düşer ve bu sayı size/slide'a eşittir (60000ms/15000ms=4). Sliding window'u tumbling gibi düşünüp her olayın tek pencereye düştüğünü varsaymak çakışmayı görmezden gelir; slide ya da size değerini doğrudan cevap sanmak parametreleri türetilmiş sayıyla karıştırır.
St Flink Time Watermarks WindowsZorluk 1
EventTimeSessionWindows.withGap(Time.minutes(5)) tanımıyla, bir key için session window hangi koşulda kapanmaya (ateşlenmeye) hak kazanır?
- aPencere açıldıktan tam 5 dakika sonra, sonraki olaylardan bağımsız olarak
- bTüm stream, tüm key'ler genelinde 5 dakika boyunca boşta kaldığında
- cO key için tam olarak 5 olay biriktiğinde
- dWatermark, o key'in
maxTimestamp'ine (son olay + 5dk − 1ms) ulaştığında✓
Açıklama:Session pencereleri gap tabanlıdır ve key başına çalışır. Her olay session sonunu kendi zaman damgası artı yapılandırılmış gap'e uzatır; pencereler yarı-açık olduğundan ([start, end)), pencerenin maxTimestamp() değeri bu sondan 1 ms öncesidir, ve event-time trigger, watermark bu maxTimestamp'e ulaştığında ateşlenir. Flink'in boşluğun geçtiğini kanıtlamak için daha sonraki bir olay görmesi gerekmez. Bu; ilk olaydan başlayan sabit süre, global stream idleness ya da olay sayısı kuralı değildir.
St Flink Time Watermarks WindowsZorluk 2
Bir stream'i GlobalWindows.create() ile pencereleyip özel bir Trigger EKLEMEZSENİZ ne olur?
- aFlink sessizce sabit 1 dakikalık tumbling window davranışına geri döner
- bGelen her tek olay pencereyi anında ateşler ve bir sonuç emit eder
- cPencere hiç sonuç emit etmez, çünkü varsayılan trigger asla FIRE dönmez✓
- dJob başlamadan derleme zamanında hatayla reddedilir
Açıklama:GlobalWindows, her elemanı tek ve hiç bitmeyen bir pencereye atar ve ne zaman ateşleneceğine tamamen açık bir Trigger karar verir; trigger verilmezse yerleşik varsayılan trigger hiçbir zaman FIRE dönmez, dolayısıyla hiçbir şey emit edilmez. Başka bir pencere tipine otomatik geri dönüş yoktur, olay başına ateşleme yoktur ve bu bir çalışma-zamanı davranışıdır, derleyicinin yakalayabileceği bir şey değildir.
St Flink Time Watermarks WindowsZorluk 1
WatermarkStrategy.forMonotonousTimestamps() hangi tür kaynak için uygun bir seçimdir?
- aZaman damgaları kaynakta zaten azalmayan sırada üretilen bir stream✓
- bOlayların birbirine göre düzenli olarak birkaç saniye sırasız geldiği bir stream
- cHiç zaman damgası taşımayan, tamamen processing-time'a dayanan bir stream
- dAralarında hiçbir sıralama garantisi olmayan birden fazla partition'dan beslenen bir stream
Açıklama:Monotonic strateji watermark'ı o ana kadarki en büyük zaman damgasının kendisi olarak üretir, yani out-of-orderness'ı sıfır varsayar; zaman damgaları gerçekten sırasız geliyorsa bu strateji her yeni maksimumdan sonra watermark'ı hemen ileri iter, bu yüzden daha büyük bir zaman damgası görüldükten sonra gelen daha küçük zaman damgalı olaylar watermark'ın gerisinde kalır ve aslında geçerli olsalar da geç sayılır. Gerçek sırasızlık taşıyan ya da partition'lar arası sıralama garantisi olmayan kaynaklar bounded-out-of-orderness stratejisi ister; hiç zaman damgası taşımayan kaynağın da zaman damgası tabanlı bir watermark stratejisine ihtiyacı yoktur.
St Flink Time Watermarks WindowsZorluk 2
WatermarkStrategy
.<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5))
.withTimestampAssigner((e, ts) -> e.eventTime);
Bu tanım watermark üretimini nasıl etkiler?
- a5 saniyeden eski her olay kaynakta filtrelenir
- bWatermark, o ana kadarki en büyük event-time'dan yaklaşık 5 saniye geride kalır✓
- cCheckpoint aralığı artık sabit olarak tam 5 saniyeye kilitlenir
- dHer bir olay geldikten tam 5 saniye sonra o olay için bir watermark emit edilir
Açıklama:Bound, o ana kadarki en büyük zaman damgasından çıkarılan bir gecikme payıdır, yani watermark bu miktar kadar geride kalır; hiçbir veriyi filtrelemez, checkpoint ile ilgisi yoktur ve olay başına sabit bir gecikme de değildir — periyodik watermark emisyon aralığına bağlıdır, olaydan tam 5 saniye sonra değil.