![\"apache_kafka\"](\"\/wp-content\/uploads\/2016\/10\/Apache_kafka.png\")
<\/a><\/p>\nDistributed messaging system konusuna girmeden \u00f6nce, her \u015feyin temeli olan\u00a0big data<\/strong> olay\u0131na biraz de\u011finelim.\u00a0G\u00fcn\u00fcm\u00fcz teknolojisinde big data denilen \u015fey, git gide h\u0131zla b\u00fcy\u00fcmeye ve her an olu\u015fabilen bir hale gelmi\u015ftir. En basit \u00f6rnek olarak Google \u00fczerinde bizler her saniye yeni veriler olu\u015fturmaktay\u0131z. \u0130statistiklere g\u00f6re sadece Google \u00fczerinde anl\u0131k 40.000 civar\u0131nda arama sonu\u00e7lar\u0131 olu\u015fmaktad\u0131r. Buda g\u00fcnl\u00fck olarak yakla\u015f\u0131k 3.4 civar\u0131na ve y\u0131ll\u0131k olarak ise 1.2\u00a0trillion search verisi yapmaktad\u0131r.<\/p>\n Bu verilerin anl\u0131k olarak devasa boyutlara ula\u015fmas\u0131yla beraber ise, real-time’a yak\u0131n bir s\u00fcrede geri ula\u015f\u0131labilme ihtiya\u00e7lar\u0131 do\u011fmu\u015ftur. \u0130\u015fte bu noktada Apache Kafka<\/strong>‘n\u0131n temel \u00f6nemi, big data<\/strong> ak\u0131\u015f\u0131n\u0131 d\u00fc\u015f\u00fck bir latency<\/strong> ile\u00a0sa\u011flamaya \u00e7al\u0131\u015fmas\u0131d\u0131r. Bu proje ilk ba\u015fta LinkedIn b\u00fcnyesinde geli\u015ftirilip, sonras\u0131nda ise open-source bir hale gelmi\u015ftir.\u00a0Apache Kafka d\u00fc\u015f\u00fck latency<\/strong> oran\u0131 ile real-time<\/strong> veri ak\u0131\u015f\u0131n\u0131 sa\u011flayabilmek i\u00e7in verileri log kayd\u0131na benzer bir yap\u0131da tutarak, farkl\u0131 sistemlere MQ(Messaging Queue) \u015feklinde sunmaktad\u0131r. Dilerseniz Kafka terminolojisine biraz giri\u015f yapal\u0131m.<\/p>\n Kafka’n\u0131n genel terminolojisine bakt\u0131ktan sonra, dilerseniz Topic<\/strong> konusunu biraz a\u00e7al\u0131m.<\/p>\n Kafka’da message’lar\u0131n tutuldu\u011fu yerin, topic’ler oldu\u011funu s\u00f6ylemi\u015ftik. Bu topic’ler bir veya birden fazla partition’lardan yani b\u00f6l\u00fcmlerden meydana gelirler.\u00a0Message’lar ise\u00a0partition’lara yukar\u0131daki \u015fekilde de g\u00f6r\u00fclebilece\u011fi \u00fczere\u00a0s\u0131ral\u0131\u00a0<\/strong>ve immutable<\/strong> olarak eklenirler. Topic’ler i\u00e7erisindeki bu message’lar, unique olarak belirlenir ve her bir s\u0131raya offset<\/strong> ad\u0131 verilir.\u00a0Topic’lere gelen her bir message, yukar\u0131da \u015fekilde oldu\u011fu gibi dizi sonuna s\u0131ral\u0131 bir \u015fekilde ekleniyor ve\u00a0offset numaras\u0131 s\u0131ras\u0131yla\u00a0art\u0131yor. Ekleme i\u015flemi ise immutable olarak ger\u00e7ekle\u015fti\u011fi i\u00e7in\u00a0ilgili message’\u0131n partition ve offset bilgisi\u00a0de\u011fi\u015fmiyor. Bu i\u015flem sayesinde istenilen message, herhangi bir okuma i\u015fleminden\u00a0sonra bile kaybolmuyor,\u00a0tekrar\u00a0eri\u015febilmek m\u00fcmk\u00fcn oluyor.<\/p>\n Kafka’n\u0131n distributed taraf\u0131ndaki harika bir \u00f6zelli\u011fi ise\u00a0her bir client, ayr\u0131 bir b\u00f6l\u00fcme\u00a0yazabilir veya ayr\u0131 bir b\u00f6l\u00fcm\u00a0\u00fczerinden okuma i\u015flemini\u00a0ger\u00e7ekle\u015ftirebilmektedir.\u00a0Kafka’n\u0131n bu partitioning mimarisi sayesinde paralel okuyabilme ve yazabilme i\u015flemleri de\u00a0m\u00fcmk\u00fcn\u00a0olabilmektedir.<\/p>\n Her bir b\u00f6l\u00fcm cluster’daki di\u011fer broker’lara, istenildi\u011fi taktirde yedekleme i\u00e7in kopyalanabilirler. Yukar\u0131da g\u00f6rselde oldu\u011fu gibi her bir b\u00f6l\u00fcm\u00fcn, bir leader’\u0131 olur ve di\u011ferleri(follower) bu\u00a0leader’\u0131 takip ederler. D\u0131\u015far\u0131dan okuma yazma i\u015flemleri de sadece leader b\u00f6l\u00fcme yap\u0131l\u0131r. Ayr\u0131ca leader, gelen t\u00fcm yazma i\u015flemlerini s\u0131raya koymakla ve bu yazma i\u015flemlerini di\u011fer replica’lara(followers) ayn\u0131 s\u0131rayla yaymakla sorumludur. Failure durumu i\u00e7in ise bir broker’da herhangi bir b\u00f6l\u00fcm hata verirse, o b\u00f6l\u00fcm\u00fcn di\u011fer follower’lar\u0131ndan birisi leader haline gelir ve hizmet vermeye devam eder.<\/p>\n Topic’lere message g\u00f6nderenlerin de,\u00a0Producer’lar oldu\u011funu s\u00f6ylemi\u015ftik. Producer’lar hangi message’in hangi b\u00f6l\u00fcme gidece\u011fine karar verebilirler. Bu karar verme i\u015flemini bir scheduling algoritmas\u0131 olan round-robin<\/strong> \u015feklinde veya semantic partitioning<\/strong> ile ger\u00e7ekle\u015ftirir.<\/p>\n \u00d6rne\u011fin bir message\u00a0g\u00f6nderilirken\u00a0message key verilmi\u015f ise g\u00f6nderilen bu message, message key’e g\u00f6re ilgili topic’in semantic partitioning b\u00f6l\u00fcm\u00fcne\u00a0yaz\u0131lmaktad\u0131r. Yani\u00a0istedi\u011fimiz message’lar\u0131 ayn\u0131 partition i\u00e7erisine g\u00f6ndermek istedi\u011fimizde kullanabiliriz.<\/p>\n Kafka, i\u00e7erisinde Message Queue<\/strong> ve Publish-Subscribe<\/strong> olmak \u00fczere iki\u00a0model bar\u0131nd\u0131r\u0131r. Queue modelinde consumer’lar server’dan tek tek okumaktad\u0131r ve her bir kay\u0131t bu consumer’lardan birisine gitmektedir. Publish-Subscribe modelinde ise kay\u0131tlar, t\u00fcm consumer’lara broadcast olmaktad\u0131r.<\/p>\n Bu iki modelin g\u00fc\u00e7l\u00fc yanlar\u0131n\u0131n oldu\u011fu gibi zay\u0131f yanlar\u0131 da mevcuttur:<\/p>\n Yukar\u0131da \u015fekilde g\u00f6r\u00fcld\u00fc\u011f\u00fc gibi her bir consumer, bir consumer group’a aittir. Bunlara ek olarak group i\u00e7erisindeki consumer say\u0131s\u0131 b\u00f6l\u00fcm say\u0131s\u0131ndan fazla olsa bile, kafka en fazla b\u00f6l\u00fcm say\u0131s\u0131 kadar bir group i\u00e7erisindeki consumer’\u0131n okumas\u0131na izin\u00a0vermektedir.<\/p>\n ve web activity tracking i\u015flemlerinde g\u00fc\u00e7l\u00fc bir \u015fekilde kullan\u0131labilmektedir.<\/p>\n Kimler kullan\u0131yor k\u0131sm\u0131na bakt\u0131\u011f\u0131m\u0131zda ise tabi ilk olarak LinkedIn,\u00a0Yahoo, Twitter, Netflix, Spotify, Uber, PayPal ve Foursquare gibi b\u00fcy\u00fck verilere sahip olan firmalar kar\u015f\u0131m\u0131za \u00e7\u0131kmaktad\u0131r.<\/p>\n Apache Kafka konusunda de\u011fineceklerim \u015fimdilik bu kadar. Apache Kafka’n\u0131n kurulumu ve \u00f6rnek kullan\u0131m\u0131 hakk\u0131ndaki konular\u0131 ise bir sonraki makale serisinde ele almay\u0131 planl\u0131yorum.<\/p>\n Umar\u0131m keyifli\u00a0bir giri\u015f bilgisi olmu\u015ftur.<\/p>\n Takipte kal\u0131n.<\/p>\n http:\/\/www.forbes.com\/sites\/bernardmarr\/2015\/09\/30\/big-data-20-mind-boggling-facts-everyone-must-read\/#703040d6c1d3 Message Distribution and Topic Partitioning in Kafka<\/a><\/p><\/blockquote>\nKafka Terminolojisi<\/h4>\n
<\/a><\/p>\n\n
Topic Yap\u0131s\u0131<\/h4>\n
<\/a><\/h4>\nReplication & Failure<\/h4>\n
<\/a><\/p>\nProducer Yap\u0131s\u0131<\/h4>\n
Consumer Yap\u0131s\u0131<\/h4>\n
<\/a><\/p>\n\n
Peki ne\u00a0zaman kullan\u0131lmal\u0131?<\/h4>\n
\n
Kaynaklar<\/h5>\n
\nhttps:\/\/engineering.linkedin.com\/kafka\/intra-cluster-replication-apache-kafka<\/p>\n