Günümüzde akan verinin dağıtık işlenmesinde en çok tercih edilen açık kaynak kodlu yazılımlardan olan Apache Spark ile, uzun süre diskte saklanabilen esnek dağıtık kuyruk yapısı sunan Apache Kafka nın entegrasyonu bu yazının konusu. Konu akan veri olunca, bu verinin sistemler arasında akışı ve bu sırada işlenişi ana işlem haline geliyor. Verinin Kafka da bir süre tutulması, Spark da işlenmesi ve sonrasında işlenen verinin saklanması döngüsü süreklilik arz eden ve 7x24 süren bir süreç olduğundan, normal batch veri işleme mantığı ile çözülemeyecek bir problemdir.
Veri okunması
Kafka dan verinin okunması consumers (tüketiciler) aracılığı ile olurken, işlenen verinin Kafka ya yazılması producers (üreticiler) aracılığı ile oluyor. Tüketiciler ile ilgili Spark ın kendi API si içinde
oldukça kullanışlı. Tabii burada eski createStream ile yeni createDirectStream metodları arasındaki farka dikkat edilmeli. Akan verinin işlenmesinde eldeki senaryoya göre, verinin kaybına tahammül olmayan durumlar ile olan durumların geliştirme aşamasına getirdiklerine dikkat etmek gerekiyor. Örnek bir veri akışı başlatıcı örnek bir scala kod satırı şöyle olabiliyor.
val messages = KafkaUtils.createDirectStream[String, Array[Byte],
StringDecoder,
DefaultDecoder](ssc,
kafkaParams,
kafkaTopics)
Veri yazılması
Fakat, Kafka ya veri yazılmasında bu güzel tablo ortadan kayboluyor. Nedeni ise Spark dan Kafka ya yazma konusunda Spark ın bildiğim kadarı ile bir API sunmaması. Bu konuda yaptığım araştırmada, Spark ın sayfasında output-operations-on-dstreams başlığı altında anlatılanlar dışında, en iyi örnekli anlatım Marcin Kuthan ın Spark and Kafka Integration patterns ile garantisiz, Spark and Kafka Integration patterns 2 ile garantili yada güvenilir (reliable) entegrasyonu konu alan yazılarıdır.
Akan verideki kayıpların tolere edilebildiği durumlarda DStream, RDD, RDDPartition derinliğinde uygun yazmalar yapılarak işlem tamamlanabilir. Bu tür bir senaryoya örnek; trafik akışı yoğunluğu için tarasarlanan bir sistem olarak verilebilir. Burada verideki aşanacak kayıplar istenen amaç açısından sonuca etkisi kısıtlı olacaktır. Verideki kayıpların tolere edilemeyeceği durumlarda ise, örnek; paralı otoyol gişelerinden geçen araçların her birinin ürettiği veri işlenmelidir. Aksi durumda müşteri memnuniyetsizliği veya gelir kaybı olarak sonuçlanır.
Operasyon
Büyük ve akan veri dünyasının geliştirme, üretime alma ve operasyonu (devops) birleştiren doğası burada da geçerlidir. Böyle bir geliştirmeye başlarken ilk adım olan Apache Kafka ve Apache Spark cluster larının kurulumu sırasında, gözden geçirilmesi gereken birçok parametre vardır.
Güncelleme
Entegrasyon işlerinin en zor kısımlarından birisi de, üretime alınan sistemin güncellenmesidir. Yolda 80 km/saat hızla giden bir arabanın yağının değiştirilmesi, silecek suyunun eklenmesi, hatta motorunun da değiştirilmesi gibi birçok işin -araba yolda gitmeye devam ederken- yapılması beklenir. Bu nedenle, akan büyük veri dünyasında öğrenecek çok şey ve gidilecek çok yol vardır her zaman ve kullandığınız yazılımlar seneyi devirmeden eskimeye başlar. :)
Hakan Sarıbıyık
Yorumlar