1. Stream Processing Mimarileri
Şükrü Hasdemir
Spark Day 2016

2. İçerik
• Büyük Veri mimarileri: Batch vs Streaming
• Olay kayıtları (event log) ve mesaj
kuyrukları
• Sonsuz veri setleri nasıl analiz edilir?
• Spark Streaming ve diğer akış işleme
araçları
• Gerçek dünyadan tavsiyeler

4. Büyük Veri Mimarileri
• Büyük Veri işleme mimarileri üç temel
bileşene ihtiyaç duyar:
– Ölçeklenebilir ve erişilebilir bir depolama
mekanizması (dağıtık dosya sistemi veya
veritabanı)
– Dağıtık veri işleme araçları
– Bu sistemleri oluşturmak için gereken kaynak
ve hizmetleri yöneten araçlar

5. Toplu (Batch) Veri İşleme Mimarisi
Fast Data Architectures for Streaming Applications, Dean Wampler, 2016

6. Stream Processing
• En güncel verileri kullanma olanağı sağlar
– Hem raporlama, hem ürün geliştirmede
rekabet avantajı
• Toplu işlemeden farklı zorlukları var: Veri
bütünlüğü semantiği

7. Akış İşleme Mimarileri

8. Temel Noktalar
• Veri akışı: Giriş -> Kafka -> Spark
Streaming -> Depolama
• Depolama: SQL/NoSQL/Dağıtık Dosya S.
• Spark + depolama mevcut: Toplu
işlemeye/interaktif analize devam
edebiliyoruz

9. Lambda Mimarisi
• Batch + Streaming + Serving
• Spark sayesinde toplu ve akış işleme kodu
büyük oranda örtüşür
• İhtiyaç: Akış işleme sonuçlarının doğruluk
oranı daha düşük(tü…) ML, vb.
• Artık akış işlemede istenen doğruluk
oranlarına nasıl ulaşabileceğimizi biliyoruz!

10. Olay Kayıtları (Event Log) ve Mesaj
Kuyrukları
• Temel soyutlama:
– “Her şey bir dosyadır” -> “her şey bir olay
kaydıdır”
• Event log
– Veritabanı işlemleri
– IoT metrikleri
– Clickstream
– Durum değişimleri

11. ES ve CQRS
• Event Sourcing: Geçmiş olay kayıtlarını
baştan oynatarak sistemin son durumu
replike edilebilir
• CQRS: Yazma ve okuma için farklı
depolama ortamları kullanmak
– Bağımsız ölçeklenebilirlik
– Daha yüksek erişilebilirlik
– Eventual consistency

12. Mesaj Kuyrukları (1)
• Kayıt işlemek için doğal bir yöntem
• Her konu (topic) için ayrı kuyruk
– Kolay paralelleştirme
• Çoklu üretici/tüketici
• İletim semantikleri
– En fazla bir, en az bir, tam olarak bir
• Deduplication, ID, idempotency
• Kafka: Tüketilen mesajlar silinmediği için
tüketiciler durumsal (stateful) olabilir
– Durum Kafka’ya geri yazılabilir

13. Mesaj Kuyrukları (2)
• Avantajlar:
– Üreticiler ile tüketiciler birbirlerinden ayrılır,
bağımsız olarak eklenip çıkarılabilirler
– Her topic için istenen sayıda üretici ve tüketici
olabilir: Ölçeklenebilirlik
– Çok küçük bir soyutlama sunarlar: Pek çok
ölçeklenebilirlik ve dayanıklılık özellikleri
perdenin arkasında kalır

14. Sonsuz Veri Setleri Nasıl Analiz
Edilir?
• GROUP BY? JOIN?
• Tekil olay işleme vs birleştirme
• Event time vs. processing time
• Spark Streaming mini-batch <- proc. Time
– Spark 2.0: Event time desteği

15. Olay vs. İşlem Zamanı

16. İşlem Zaman Dilimi Tanımları
• Watermark: Bir bağlama ait bütün olayların
toplanmış olduğunu bildirir.
• Trigger: İşlem başlatıcılar – eksik sonuçlar
oluşturulabilir
– Watermark
– Zamanlama
– Limit
• Accumulation mode: Aynı zaman dilimindeki
farklı gözlemleri nasıl birleştireceğiz? Bağımsızlar
mı? Sonra gelen öncelikli mi olacak? Birleşim?

17. Sonsuz Akışları Zamanında
İşlemek
• İstekler:
– Doğruluk
– Dirençlilik
– Süreklilik
• Örnek: Bir dashboard uygulaması yaklaşık
sonuçları hemen gösterip sonradan gelen
verilerle update edebilir.
Finansal uygulamalarda bu kabul edilmez:
“Düzeltme” mekanizmaları gerekli.

18. Spark Streaming vs Diğer Akış
İşleme Araçları
• Spark 2.0: Structured Streaming ile
bahsedilen bütün akış işleme
semantiklerini desteklemeye doğru gidiş.
– Sürekli uygulamalar
• Flink, Gearpump -> Apache Beam
• Kafka Streams, Akka Streams

19. Gerçek Dünya
• Akış işleme 7/24 çalışmalı… Reaktif
sistemler:
– Responsive
– Resilient (replication, isolation)
– Elastic
– Mesage driven

20. Bazı Tavsiyeler
• Veriler önce Kafka ile alınıp sonra akış
işlemeye gönderilmeli
• Sonraki servislerin ihtiyaç duyacağı işlem
sonuçları Kafka’ya geri yazılmalı
• Entegrasyon mikroservisleri için reaktif
protokoller kullanılmalı: Backpressure, flow
control
• Mesos, YARN vb. kullanılmalı
• Doğru veritabanı seçimi: Dağıtık
ölçeklenebilirlik, bileşen arızalarına
dayanıklılık, CAP trade-off

21. Teşekkürler
sukru@fikrimuhal.com