Kafka Streams nedir, ne amaçla kullanılır?

Kafka Streams, Kafka’da depolanan verilerin anlık olarak işlenmesi ve analiz edilmesi için geliştirilmiş bir client kütüphanesidir. Girdi ve çıktı verilerinin Kafka’da saklandığı, ölçeklenebilir, esnek, hataya dayanıklı, dağıtık uygulamalar ve mikro servisler geliştirmek için kullanılır. Kafka Streams API, temel işinize güç katacak gerçek zamanlı uygulamalar oluşturmanıza imkan tanır. Akan veri üzerinden hesaplamalar yapmamızı sağlar. Arkasındaki Kafka Cluster ile entegre çalışır.

Günümüzde stream processing talebi her geçen gün artmaktadır. Bunun arkasındaki temel neden, yalnızca hacimli verilerin işlenmesinin yeterli olmaması, verilerin daha hızlı işlenmesi, analiz edilmesi ve gerçek zamanlı olarak verilerle ilgili değer üretilmesinin çok önemli olması, böylece kuruluşun değişen iş koşullarına gerçek zamanlı olarak tepki verebilmesidir.

Kafka Streams API için kullanım örnekleri:

• Finans sektöründe farklı veri kaynaklarının birleştirilerek potansiyel risklerin gerçek zamanlı görülmesi, fraud işlemlerin tespiti ve azaltılması amacıyla kullanılabilir.
• Seyahat şirketleri, bireysel müşteriler için en uygun fiyatı bulmak, ek hizmetlerin çapraz satışı, rezervasyon ve rezervasyonları işlemek gibi gerçek zamanlı karar verecek uygulamaları Kafka Streams API ile geliştirebilir.
• Lojistik şirketleri gönderilerini hızlı, güvenilir ve gerçek zamanlı izlemek için uygulamalar geliştirebilir.
• Perakendeciler bir sonraki en iyi teklife, kişiselleştirilmiş promosyonlara, fiyatlandırma ve envanter yönetimine gerçek zamanlı olarak karar vermek için kullanabilir.
• Otomotiv ve imalat şirketleri, üretim hatlarının en iyi şekilde çalışmasını sağlamak, tedarik zincirlerine gerçek zamanlı bilgi sağlamak için uygulamalar geliştirebilir.

Kafka Streams API’sinin en önemli özelliklerinden bir tanesi de, onunla oluşturduğunuz uygulamaların normal Java uygulamaları olmasıdır. Bu uygulamalar, benzer amaçla kullanılan ayrı cluster sunucular (Spark vs) veya pahalı altyapı kurmaya gerek kalmadan, diğer uygulamalar gibi paketlenebilir, dağıtılabilir ve izlenebilir.

Kafka Streams, büyük veri özelinde olan Stream Processing (akan veri üzerinden işlem yapma) kavramını uygulama geliştirme dünyasına taşıyarak bu işlemlerin basit ve kolay yapılmasını sağlamıştır. Küçük veya büyük ölçekli stream processing ihtiyaçlarınız için Kafka Streams API kullanarak normal Java uygulamaları geliştirebilir, bu uygulamaları Kafka cluster sunucuları çevresinde client makinelerde koşturabilirsiniz.

• Geliştireceğiniz uygulamalar esnektir: Uygulamanızı tek veya cluster olacak şekilde çalıştırabilirsiniz, bunlar birbirlerini otomatik olarak keşfedecek ve verileri birlikte işleyecektir.
• Geliştireceğiniz uygulamalarınız ayrıca hataya da dayanıklıdır: Uygulama örneklerinden biri ölürse, herhangi bir veri kaybı olmadan kalan örnekler otomatik olarak işini üstlenecektir.

Temel Özellikleri

Aşağıdaki listede Kafka Streams API’ın bazı temel özellikleri ve yönleri vurgulanmaktadır.

Güçlü

• Uygulamalarınızı yüksek ölçeklenebilir, elastik, dağıtılmış, hataya dayanıklı hale getirir
• Exactly Once Processing (tam olarak bir kez işleme) semantiğini destekler
• Stateful processing (window, aggregation işlemleri vs) ve stateless processing (veriyi zenginleştirme, veri transformasyonu vs)
• Windowing, joins, aggregations ile event-time processing
• Streams ve veritabanlarının dünyalarını birleştirmek için Interactive Queries (Etkileşimli Sorguları) destekler
• Basit declarative functional API yada alt seviye imperative API

Lightweight (Hafif)

• Kolay başlangıç
• Küçük, orta, büyük ve çok büyük kullanım durumları için eşit derecede uygulanabilir
• Local geliştirmeden üretime sorunsuz bir geçiş
• Cluster processing sunucuları gerektirmez
• Kafka harici bir bağımlılığı yoktur

Tamamen entegre

• Kafka 0.11+ ile %100 uyumlu
• Mevcut uygulama ve mikro servislere kolaylıkla entegre olabilme
• Uygulamalarınızı paketleme, dağıtma ve izleme için yapay kurallar yoktur
• Her yerde çalışır: şirket içi, genel bulutlar, özel bulutlar, konteynerler, vb.
• Kafka Connect tarafından gerçekleştirilen sürekli değişiklik veri yakalama yöntemi (CDC) ile veritabanlarıyla bütünleşir

Gerçek Zamanlı

• Milisaniye işleme gecikmesi
• Her seferinde bir kayıt işleme (mikro batching yok)
• Geç gelen ve sırası dışındaki verileri sorunsuz bir şekilde işler
• Yüksek throughput

Güvenli

• Aktarılan verilerin şifrelenmesini destekler
• Kimlik doğrulama ve yetkilendirmeyi destekler

Özetle, Kafka Streams API aşağıdaki durumlarda alternatiflerine (Spark, Storm vs) göre ideal çözüm olarak düşünülebilir.

• Stream processing uygulamamız kafka’dan kafka’ya pipeline oluşturuyorsa
• Stream processing amacıyla ayrıca cluster yapılar kurmak istenmiyorsa
• Akan veri üzerinde filtreleme, joins, aggregations, veri zenginleştirme gibi basit stream processing fonksiyonları gerçekleştirilmek isteniyorsa
• Hedef kullanıcılar java geçmişleri olan geliştiricilerse

Bir sonraki yazıda da temel kavramlarını ve mimarisini anlatmayı planlıyorum.

Kaynaklar:

https://docs.confluent.io/

https://kafka.apache.org/

Apache Kafka ile ilgili önceki yazılarım:

• Apache Kafka’ya Giriş
• Apache Kafka’ya Giriş -2

Kafka Streams Giriş was originally published in Devops & AI Türkiye☁️ 🐧 🐳 ☸️ on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Apache Kafka’ya Giriş” yazımızın ilk bölümünde broker, topic, partition, offsets, producer, consumer ve consumer group kavramlarını açıklamıştık.

Consumer Offsets

Kafka, consumer offset bilgilerini “__consumer_offsets” topic içerisinde tutar. Consumer, Kafka topic’ten mesajı okur, mesajı işler ve mesajın offset değerini “__consumer_offsets” topic’ine yazar. Offset bilgilerininin topic’e yazılma işlemi consumer tarafından otomatik yapılır yada programlanabilir. Bir consumer kaybedilse bile, tekrar ayağa kalktığında “__consumer_offsets” içerisinde en son hangi mesajı okuduğu kayıtlı olduğu için kaldığı yerden devam edebilir.

Message Delivery Semantics

Consumer’ların offset bilgilerini ne zaman yazacağına göre değişen, Kafka tarafından sağlanan 3 farklı mesaj teslim garantisi vardır.

At most once: Offset bilgisi mesaj alınır alınmaz yazılır. Mesaj, işlenmesi sırasında bir hata oluşursa kaybedilir. En performanslı ama mesaj kaybı söz konusu olabileceği için pek tercih edilen bir yöntem değildir.

At least once: Offset bilgisi mesaj işlendikten sonra yazılır. Mesaj, işlenmesi sırasında bir hata oluşursa tekrar okunur. Mesaj kaybı oluşmaz ama birden fazla mesajları okuma olasılığı vardır. Bu nedenle mesaj işleme sürecimiz idempotent olmalıdır yani duplike durumlarında sistemimiz etkilenmemelidir. En çok tercih edilen yöntemdir.

Exactly once: Bu model sadece Kafka - Kafka arasındaki iş akışlarında Kafka Streams API ile sağlanıyor. Mesaj, Kafka topic’ler arasında transfer olurken ve işlenirken transactional producer ve consumer kullanılıyor.

Kafka Broker Discovery

Yazımızın ilk bölümünde, producer ve comsumer’lar için cluster içerisindeki hangi broker’a yazacağını veya hangi broker’dan okuyucağını bildiklerini belirtmiştik. Cluster içerisindeki her Kafka broker aslında bir “Bootstrap Server” dır. Diğer broker, topic ve partition bilgilerini bilir ve bir consumer veya producer kendisine bağlandığında bu bilgileri paylaşır. Bu bilgiler metadata olarak adlandırılır. Yani, bir Kafka broker’a bağlanmak tüm Kafka cluster’ına bağlanmak anlamına gelir.

Zookeeper

Kafka broker’larını yönetir. Topic partition’ları için broker lider seçiminine yardımcı olur. Yeni bir broker ayağa kalktığında veya düştüğünde, topic oluşturulduğunda veya silindiğinde, Zookeeper Kafka broker’lara bildirim gönderir. Kafka, ayağa kalkmak için Zookeeper’a ihtiyaç duyar. Bu nedenle önce Zookeeper, sonra Kafka broker ayağa kaldırılır. Kural olarak cluster içerisindeki Zookeeper sayısı tek sayı olmalıdır. Bir lider ve takipçileri vardır. Kafka, cluster içerisindeki herhangi bir Zookeeper’a bağlanması yeterlidir.

Kafka neleri garanti ediyor?

Mesajlar, topic partition’a gönderildiği sırada eklenir.

Consumer’lar, mesajları topic partition’dan saklandığı sırada okur.

Kafka, replication factor N parametresi ile ayağa kaldırıldı ise, producer ve consumer’lar N-1 Kafka broker’a kalana kadar çalışmaya devam ederler. Replication factor için 3 uygun bir seçenek olacaktır. Bir Kafka broker bakım için, bir broker beklenmedik bir hata durumu kapsamında ayakta olmayabilir. Bu durumda tek bir Kafka broker ile o topic işlemleri devam ediyor olacaktır.

Aynı mesaj anahtarına sahip kayıtlar, aynı topic partition’a yazılır.

Kaynak:

1. https://kafka.apache.org/

Apache Kafka’ya Giriş -2 was originally published in Devops & AI Türkiye☁️ 🐧 🐳 ☸️ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Apache Kafka nedir, ne amaçla kullanılır?

Sadece bir kaynak sisteminiz ve bir hedef sisteminiz olduğunda, bu sistemler arası veri transferi yapmanız gerektiğinde çözüm basittir. Ancak birçok kaynak, birçok hedef sisteminiz olduğunda ve hepsinin birbirleriyle veri transferi yapması gerektiğinde işler gerçekten karmaşık hale gelecek ve herbir sistemin birbiri ile entegrasyonu gerekecektir. Bu entegrasyonlar . protokol seçimi, verilerin nasıl aktarılacağı (TCP, HTTP, FTP, JDBC, REST, SOAP vb), veri formatı, verilerin nasıl parse edileceği (JSON, CSV, XML, Avro, Thrift vb) gibi birçok zorluğu beraberinde getirir. Bunlara ek olarak bir kaynak sisteme yapılan her entegrasyon o sistem üzerinde ek yük yaratacaktır. Apache Kafka bu sorunları aşmak için doğru çözüm olacaktır. Sistemlerin birbirlerine bağımlıklıklarını ortadan kaldırarak, üzerlerindeki yüklerini de düşürür. Apache Kafka, LinkedIn tarafından geliştirilmiş, şu an Apache yönetiminde açık kaynak olarak çoğunlukla Confluent şirketi tarafından bakımı ve geliştirimi yapılan bir projedir. Dağıtık (distrubuted) bir veri akış (streaming) platformudur. Hataya dayanıklı, yatay olarak ölçeklenebilen, esnek bir mimariye sahiptir. Son derece yüksek performans ile bir sistemden diğer sisteme 10 ms’den az bir gecikme(latency) ile neredeyse gerçek zamanlı olarak veri transferini mümkün kılmaktadır. Mesajlaşma sistemi (messaging system) olabilir, etkinlik takibi(activity tracking) için, uygulama loglarını toplamak için, sağladığı API ile stream processing amacıyla kullanılabilir. Big Data entegrasyonları için kullanılabilir. Gerçek zamanlı öneriler, kararlar ve bilgiler(insights) oluşturmak için kullanılabilir.

Apache Kafka ile ilgili temel kavramlar:

Topics, Partitions, Offsets

Topic kullanıcı tanımlı kategori ismidir. Mesajların tutulduğu yerdir. Veritabınındaki tabloya benzer. Kafka içerisinde birçok topic olabilir, isim ile tanımlanırlar. Bir veya birden fazla bölümden(partitions) meydana gelirler. Her partition’ın 0 dan başlayan numaraları vardır. Resimde bir topic üzerinde 3 partitions (0, 1 ve 2) görüyoruz. Mesajlar partition’lara sıralı olarak ve değiştirilemez olarak eklenirler ve artan şekilde bir kimlik değeri alırlar. Bu değere offset denir. Bir mesajın partition ve offset değeri değişmez. Mesaj okuma işleminden sonra kaybolmaz, tekrar erişim mümkündür. Topiclerin bu partition özelliği sayesinde yazma ve okuma işlemleri paralel bir şekilde yapılabilir. Topic’ler oluşturulurken kaç partition olacağı belirlenir, istenirse sonradan da değiştirilebilir. Kafka’da mesajların sırası partition içinde garanti edilir. Yani partition 0 daki 4 nolu offset değerine sahip bir mesaj, partition 0 daki 5 no lu offset değerine sahip mesajdan önce yazılmıştır ve önce okunacaktır, Kafka bunu garanti eder. Partition 1 deki 8 no lu offset değerine sahip mesaj ise daha önce yazılmış olabilir. Partition’lar arası mesaj sırası için garanti verilmez.

Kafka’da veriler sadece sınırlı bir süre saklanırlar. Varsayılan olarak 1 hafta. Sonrasında bu veriler ve offset değerleri silinecektir. Topic’e eklenen yeni mesajlar bir kural (anahtar) belirtilmemişse rastgele bir partition’a atanır, her zaman partition’ın sonuna eklenir ve eklendikçe offset sürekli artmaya devam eder, 0 a hicbir zaman dönmez.

Brokers

Broker, topic ve partition’ları tutan sunuculardır. Birçok broker birlikte kafka cluster’ı oluşturur. Bir broker’a bağlandığınızda, buna “bootstrap broker” denir ve tüm cluster’a bağlanmış olursunuz. Her broker sadece belirli topic partitionlarını içerir. Yani tüm veriyi tutmaz, çünkü Kafka dağıtık bir yapıdadır. 3 broker’dan oluşan bir kafka cluster’a sahip olduğumuzu düşünelim. İsimleri Broker 1, Broker 2 ve Broker 3 olsun. 3 partition’dan oluşan transaction-events isminde bir topic oluşturduğumuzda, herbir broker topic’in bir partition’ını tutacak şekilde dağılım yapılır. transaction-events topic’i 5 partition’dan oluşsaydi 2 broker’a 2 partition, 1 broker a 1 partition tutacak şekilde dağılım yapılırdı.

Topic Replication

Kafka dağıtık(distrubuted) bir sistemdir, bir broker çökse bile veri kaybı olmaması ve işlemlerin devam ediyor olması gereklidir. Replikasyon bu işi yapar. Replication Factor genellikle 2 yada 3 olarak belirlenir, 2 olarak belirlenmesi biraz risklidir. Aşağıdaki resimdeki gibi 3 broker dan oluşan bir kafka cluster yapımız olduğunu düşünelim. 2 partition’dan oluşan Topic-A’i yaratırken, ayrıca replike olmasını istiyoruz. Bu nedenle replication factor bilgisini 2 olarak set ediyoruz. Partition 0, broker 101 e atanıyor, partition 1 ise broker 102 ye atanıyor. Replication factor 2 olarak set edildiği için partition’ların birer kopyası farklı bir broker üzerinde daha tutulacaktır. Resimdeki gibi bir dağılım oluşacaktır. Broker 102 yi keybettiğimizi düşünelim, bu durumda veriler 101 ve 103 te olduğu için kayıp olmayacak, işlemler devam edecektir.

Kafka’da belirli bir zamanda bir partition için sadece bir lider(Leader) kavramı vardır. Lider olan broker veriyi alır ve sunar, diğer brokerlar pasif kopyalar olur, sadece verileri senkronize ederler. Yani her partition için bir lider, birçok ISR(in-sync replica) olur. Lider ve ISR’lara karar veren Zookeeper’dir.

Producer & Message Keys

Topic’lere veriyi yazarlar. Hangi broker ve partitiona yazacağını bilirler, cluster içerisindeki bir broker’a bağlanması yeterlidir. Broker çökse bile otomatik olarak recover olur. Mesaj anahtarı (message key) belirtilmişse, partition’a yazma işlemi anahtar değerine göre yapılır. Aynı anahtar değerine sahip mesajlar, aynı partition’a yazılır. Kafka partition bazında yazma ve okuma işlemini garanti ettiği için, sıranın önemli olduğu durumlarda kullanılabilir. Mesaj anahtarı belirtilmediği durumlarda partition’lara yükü dengelemek için round robin ile yazacaktır.

Consumer & Consumer Groups

Topic’lerden veriyi okurlar. Hangi broker’dan okuyacağını bilir, broker çökse bile otomatik recover olur. Ayni Partition içerisindeki mesajları sıralı bir şekilde okur. Birden fazla partition’dan okuyabilir. Resimde de görüldüğü gibi her bir consumer, bir consumer group’a aittir. Bir partition’ı bir consumer group içerisinde sadece bir consumer okuyabilir.

Yazının devamı:

https://medium.com/@serkaneren_77558/apache-kafkaya-giri%C5%9F-2-9455e45d4c0f

Kaynak:

1. https://kafka.apache.org/

Apache Kafka’ya Giriş was originally published in Devops & AI Türkiye☁️ 🐧 🐳 ☸️ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blokchain nedir?

Blockchain teknolojisi, bitcoin ve diğer kripto paraların arkasındaki teknolojidir. Blockchain, verinin bütünlüğünü sağlayan, merkezi olmayan dağıtılmış bir veritabanıdır. Daha detaylı bilgi için Ahmet Usta ve Serkan Doğantekin tarafından yazılan “Blockchain 101” kitabını okumanızı tavsiye ederim. https://bkm.com.tr/blockchain-101/ adresinden dilediğiniz tutarda bağış yaparak kitabı indirebilirsiniz. Ben daha çok Java ile blockchain gerçekleştirimi konusunu anlatmaya çalışacağım.

BKM on Twitter

Ahmet Usta ve Serkan Doğantekin tarafından kaleme alınan "Blockchain 101″ kitabı yeni versiyonu ile BKM Yayınlarında! @BKMExpress ile dilediğiniz tutarda bağış yaparak bu kitaba sahip olabilirsiniz. https://t.co/zvaZzXNbx6

Blockchain, çok basit olarak bir blok listesidir. Bloklar birbirlerine kriptografi kullanılarak bağlanır. Her blok önceki bloğun hash değerini, bir zaman bilgisi, data ve kendi hash değerini içerir. Kendi hash değeri, içerik ve önceki bloğun hash değeri kullanılarak hesaplanır. Listedeki bir datanın değişmesi hash değerini değiştireceği için, blockchain in geçersiz olmasını sağlayacaktır. Bu şekilde güvenli, değiştirilemeyen bir yapı sağlar. Bu bilgiler kapsamında blockchain i oluşturacak Block sınıfımızı tasarlayalım.

Bir blok oluşturulduğunda bloğun hash değeri(digital imzası), sınıfının yapılandırıcısında SHA-256 kriptografi algoritması kullanılarak generateHash metodu çağırılarak hesaplanıyor. Secure hash algoritmaları ile ilgili detaylar için Wikipedia: https://en.wikipedia.org/wiki/SHA-2

Java, bu algoritma için MessageDigest sınıfı üzerinden bir implementasyon sağlıyor, aşağıdaki şekilde generateHash metodunu yazıyoruz.

Mining (madencilik) İşlemi:

Bitcoin dünyasında mining işlemi, işlemleri bir blok haline getirme ve sonrasında blockchain üyeleri tarafından doğrulanması için gönderme süreci olarak tanımlanıyor. Blockchain teknolojisinde buna mutabakat(consensus) denir. Birçok farklı dağıtık consensus algoritması vardır. Örneğimizde proof-of-work consensus protokolünü kullanacağız.

Block sınıfımıza mining işlemini gerçekleştirebilmek için yeni bir metod ekliyoruz. Algoritma basitçe döngü içinde hash hesaplar, gönderilen zorluk seviyesi parametresi kadar ‘0’ ile başlayan hash bulduğunda işlem tamamlanır.

Blockchain sınıfımızın tasarımına geçelim. Blockchain sınıfımız, proof-of-work un çözümünde mining işlemi için zorluk seviyesini tanımlayan bir değişkeni ve block sınıfı listesini tutuyor olacak.

Blockchain sınıfımıza blok işlemleri için yeni metodlar ekliyoruz. Blockchain sınıfımızın yapılandırıcısında createFirstBlock() metodu ile başlangıç(genesis) bloğu oluşturuluyor. İlk blok(genesis) sadece kendi dijital imzasını taşır. newBlock() metodunda, son blok ile ilişkilendirilip yeni bir blok oluşturuluyor. addBlock() metodunda madencilik işlemi yapıldıktan sonra blok listeye ekleniyor.

Blockchain, geçerli olabilmesi için içindeki blok verilerinin bütünlüğünü garanti etmelidir. Doğrulama işlemleri için blockchain sınıfımıza, ilk bloğu kontrol eden, yeni eklenenin bloğu önceki blok bilgisi ile kontrol eden ve blockchain in doğruluğunu kontrol eden metodları ekliyoruz.

Blockchain sınıfımızı bu şekilde tamamlamış olduk. Şimdi de birkaç blok oluşturup, blockchain e ekleyen ve sonra doğruluğunu kontrol eden sınıfımızı yazalım.

Uygulamayı çalıştırdığımızda aşağıdaki gibi bir çıktı oluşacaktır, oluşan çıktıda blockchain in geçerliliğini ve blockchain içerisindeki blokların hash değerleri üzerinden birbirlerine bağlantıları görülebilir.

Java ile blockchain konusuna basit bir giriş yapmış olduk. Detayları öğrendikçe, sonraki yazılarımda P2P networking, wallet, transaction, merkel tree gibi yapıları da ekleyerek kodu ilerletmeyi planlıyorum.

Kaynak:

• Blockchain 101: Ahmet Usta, Serkan Doğantekin