Apache Kafka HDInsight kümeleri için performans iyileştirme

Makale
09/06/2024

Bu makalede, HDInsight'ta Apache Kafka iş yüklerinizin performansını iyileştirmeye yönelik bazı öneriler sağlanır. Odak, üretici, aracı ve tüketici yapılandırmasını ayarlamaktır. Bazen yoğun iş yüküyle performansı ayarlamak için işletim sistemi ayarlarını da yapmanız gerekir. Performansı ölçmenin farklı yolları vardır ve uyguladığınız iyileştirmeler iş gereksinimlerinize bağlıdır.

Mimariye genel bakış

Kafka konuları kayıtları düzenlemek için kullanılır. Üreticiler kayıtlar üretir ve tüketiciler bunları tüketir. Üreticiler kafka aracılarına kayıt gönderir ve ardından verileri depolar. HDInsight kümenizdeki her çalışan düğümü bir Kafka aracısıdır.

Aracılar arasında konuların bölüm kayıtları. Kayıtları tüketirken, verilerin paralel işlemesini elde etmek için bölüm başına en fazla bir tüketici kullanabilirsiniz.

Çoğaltma, düğümler arasında bölümleri çoğaltmak için kullanılır. Bu bölüm düğüm (aracı) kesintilerine karşı koruma sağlar. Çoğaltma grubu arasında tek bir bölüm bölüm lideri olarak atanır. Üretici trafiği ZooKeeper tarafından yönetilen durum kullanılarak her düğümün liderine yönlendirilir.

Senaryonuzu tanımlama

Apache Kafka performansının iki ana yönü vardır: aktarım hızı ve gecikme süresi. Aktarım hızı, verilerin işlenebileceği en yüksek hızdır. Daha yüksek aktarım hızı daha iyidir. Gecikme süresi, verilerin depolanması veya alınması için geçen süredir. Düşük gecikme süresi daha iyidir. Aktarım hızı, gecikme süresi ve uygulama altyapısının maliyeti arasında doğru dengeyi bulmak zor olabilir. Performans gereksinimleriniz, yüksek aktarım hızı, düşük gecikme süresi veya her ikisini birden gerektirip gerektirmediğinize bağlı olarak aşağıdaki üç yaygın durumdan biriyle eşleşmelidir:

Yüksek aktarım hızı, düşük gecikme süresi. Bu senaryo hem yüksek aktarım hızı hem de düşük gecikme süresi (yaklaşık 100 milisaniye) gerektirir. Bu tür bir uygulamaya örnek olarak hizmet kullanılabilirliği izlemesi örnek olarak verilmiştir.
Yüksek aktarım hızı, yüksek gecikme süresi. Bu senaryo yüksek aktarım hızı (yaklaşık 1,5 GBps) gerektirir ancak daha yüksek gecikme süresini (< 250 ms) tolere edebilir. Bu tür uygulamalara örnek olarak, güvenlik ve yetkisiz erişim algılama uygulamaları gibi neredeyse gerçek zamanlı işlemler için telemetri verileri alımı örnek olarak verilmiştir.
Düşük aktarım hızı, düşük gecikme süresi. Bu senaryo gerçek zamanlı işleme için düşük gecikme süresi (< 10 ms) gerektirir, ancak daha düşük aktarım hızına dayanabilir. Bu tür bir uygulama örneği, çevrimiçi yazım ve dil bilgisi denetimleridir.

Üretici yapılandırmaları

Aşağıdaki bölümlerde Kafka üreticilerinizin performansını iyileştirmek için en önemli genel yapılandırma özelliklerinden bazıları vurgulanmıştır. Tüm yapılandırma özelliklerinin ayrıntılı açıklaması için üretici yapılandırmalarıyla ilgili Apache Kafka belgelerine bakın.

Toplu iş boyutu

Apache Kafka üreticileri, tek bir depolama bölümünde depolanmak üzere birim olarak gönderilen ileti gruplarını (toplu iş olarak adlandırılır) bir araya getirmektedir. Toplu iş boyutu, grup iletilmeden önce mevcut olması gereken bayt sayısı anlamına gelir. Parametrenin batch.size artırılması, ağ ve GÇ isteklerinin işleme ek yükünü azalttığı için aktarım hızını artırabilir. Hafif yük altında, üretici bir toplu iş için hazır olmasını beklediğinden, artan toplu iş boyutu Kafka gönderme gecikme süresini artırabilir. Yoğun yük altında, aktarım hızını ve gecikme süresini geliştirmek için toplu iş boyutunun artırılması önerilir.

Üretici gerekli bildirimler

Üreticinin gerekli acks yapılandırması, bir yazma isteğinin tamamlandığı kabul edilmeden önce bölüm lideri tarafından gereken onay sayısını belirler. Bu ayar veri güvenilirliğini etkiler ve , 1veya -1değerlerini 0alır. değeri -1 , yazma işlemi tamamlanmadan önce tüm çoğaltmalardan bir onay alınması gerektiği anlamına gelir. Ayar acks = -1 , veri kaybına karşı daha güçlü garantiler sağlar, ancak daha yüksek gecikme süresi ve daha düşük aktarım hızıyla da sonuçlanır. Uygulama gereksinimleriniz daha yüksek aktarım hızı gerekiyorsa veya acks = 1ayarını acks = 0 deneyin. Tüm çoğaltmaları onaylanmamanın veri güvenilirliğini azaltabileceğini unutmayın.

Sıkıştırma

Kafka üreticisi, iletileri aracılara göndermeden önce sıkıştıracak şekilde yapılandırılabilir. compression.type ayarı, kullanılacak sıkıştırma codec'ini belirtir. Desteklenen sıkıştırma codec'leri şunlardır: "gzip," "snappy" ve "lz4." Sıkıştırma faydalıdır ve disk kapasitesinde bir sınırlama varsa dikkate alınmalıdır.

yaygın olarak kullanılan iki sıkıştırma codec'i gzip ve arasında daha yüksek sıkıştırma oranı vardır ve snappygzip bu da daha yüksek CPU yükü maliyetinde daha düşük disk kullanımına neden olur. Codec snappy bileşeni daha az CPU yüküyle daha az sıkıştırma sağlar. Aracı disk veya üretici CPU sınırlamalarına göre hangi codec bileşenini kullanacağınıza karar vekleyebilirsiniz. gzip , verileri değerinden snappybeş kat daha yüksek bir hızda sıkıştırabilir.

Veri sıkıştırma, diskte depolanabilecek kayıt sayısını artırır. Üretici ve aracı tarafından kullanılan sıkıştırma biçimleri arasında uyuşmazlık olduğu durumlarda da CPU ek yükünü artırabilir. verilerin gönderilmeden önce sıkıştırılması ve sonra işlemden önce sıkıştırmasını açması gerekir.

Aracı ayarları

Aşağıdaki bölümlerde Kafka aracılarınızın performansını iyileştirmek için en önemli ayarlardan bazıları vurgulanmıştır. Tüm aracı ayarlarının ayrıntılı açıklaması için aracı yapılandırmalarıyla ilgili Apache Kafka belgelerine bakın.

Disk sayısı

Depolama diskler sınırlı IOPS (Saniyede Giriş/Çıkış İşlemleri) ve saniye başına okuma/yazma baytlarına sahiptir. Kafka, yeni bölümler oluştururken her yeni bölümü kullanılabilir diskler arasında dengelemek için en az mevcut bölüme sahip diskte depolar. Depolama stratejisine rağmen, her diskte yüzlerce bölüm çoğaltması işlenirken Kafka, kullanılabilir disk aktarım hızını kolayca doygunluğa taşıyabilir. Burada aktarım hızı ile maliyet arasında bir denge vardır. Uygulamanız daha yüksek aktarım hızı gerektiriyorsa, aracı başına daha fazla yönetilen disk içeren bir küme oluşturun. HDInsight şu anda çalışan bir kümeye yönetilen disk eklemeyi desteklememektedir. Yönetilen disk sayısını yapılandırma hakkında daha fazla bilgi için bkz . HDInsight üzerinde Apache Kafka için depolama ve ölçeklenebilirlik yapılandırma. Kümenizdeki düğümler için depolama alanını artırmanın maliyet etkilerini anlayın.

Konu ve bölüm sayısı

Kafka yapımcıları konulara yazar. Kafka tüketicileri konu başlıklarından okur. Konu, disk üzerindeki bir veri yapısı olan günlükle ilişkilendirilir. Kafka, üreticilerden kayıtları konu günlüğünün sonuna ekler. Konu günlüğü, birden çok dosyaya yayılmış birçok bölümden oluşur. Bu dosyalar da birden çok Kafka kümesi düğümüne yayılır. Tüketiciler Kafka konu başlıklarını kendi tempolarında okur ve konu günlüğündeki konumlarını (uzaklık) seçebilir.

Her Kafka bölümü sistemdeki bir günlük dosyasıdır ve üretici iş parçacıkları aynı anda birden çok günlüğe yazabilir. Benzer şekilde, her tüketici iş parçacığı bir bölümdeki iletileri okuduğundan, birden çok bölümden gelen kullanım da paralel olarak işlenir.

Bölüm yoğunluğunun artırılması (aracı başına bölüm sayısı), meta veri işlemleriyle ve bölüm lideri ile takipçileri arasındaki bölüm isteği/yanıtı başına ek yük getirir. Veri akışı olmadığında bile bölüm çoğaltmaları liderlerden veri almaya devam eder ve bu da ağ üzerinden istek gönderme ve alma işlemleri için ek işlemeye neden olur.

Apache Kafka kümeleri 2.1 ve 2.4 için ve HDInsight'ta daha önce belirtildiği gibi, çoğaltmalar dahil olmak üzere aracı başına en fazla 2000 bölüme sahip olmanız önerilir. Aracı başına bölüm sayısını artırmak aktarım hızını azaltır ve konu başlığının kullanılamamasına da neden olabilir. Kafka bölüm desteği hakkında daha fazla bilgi için sürüm 1.1.0'da desteklenen bölüm sayısındaki artışla ilgili resmi Apache Kafka blog gönderisine bakın. Konuları değiştirme hakkında ayrıntılı bilgi için bkz . Apache Kafka: konuları değiştirme.

Çoğaltma sayısı

Daha yüksek çoğaltma faktörü, bölüm lideri ile takipçiler arasında ek isteklere neden olur. Sonuç olarak, daha yüksek bir çoğaltma faktörü ek istekleri işlemek için daha fazla disk ve CPU tüketerek yazma gecikme süresini artırır ve aktarım hızını kısaltır.

Azure HDInsight'ta Kafka için en az 3 kat çoğaltma kullanmanızı öneririz. Çoğu Azure bölgesinde üç hata etki alanı vardır, ancak yalnızca iki hata etki alanı olan bölgelerde kullanıcıların 4 kat çoğaltma kullanması gerekir.

Çoğaltma hakkında daha fazla bilgi için bkz . Apache Kafka: çoğaltma ve Apache Kafka: çoğaltma faktörünü artırma.

Tüketici yapılandırmaları

Aşağıdaki bölümde Kafka tüketicilerinizin performansını iyileştirmek için bazı önemli genel yapılandırmalar vurgulanmıştır. Tüm yapılandırmaların ayrıntılı açıklaması için bkz . Tüketici yapılandırmalarıyla ilgili Apache Kafka belgeleri.

Tüketici sayısı

Bölüm sayısının tüketici sayısına eşit olması iyi bir uygulamadır. Tüketici sayısı bölüm sayısından azsa, tüketicilerin birkaçı birden çok bölümden okuyarak tüketici gecikme süresini artırır.

Tüketici sayısı bölüm sayısından fazlaysa, bu tüketiciler boşta olduğundan tüketici kaynaklarınızı boşa harcamış olursunuz.

Tüketicinin sık yeniden dengelenmesinden kaçının

Tüketici yeniden dengelemesi, bölüm sahipliği değişikliği (tüketiciler ölçeği genişleterek veya küçülerek), aracı kilitlenmesi (aracılar tüketici grupları için grup koordinatörü olduğundan), tüketici kilitlenmesi, yeni konu ekleme veya yeni bölümler ekleme ile tetiklenir. Yeniden dengeleme sırasında tüketiciler tüketemez ve bu nedenle gecikme süresini artırır.

tüketicileri, içindeki session.timeout.msbir aracıya sinyal gönderebiliyorsa canlı olarak kabul edilir. Aksi takdirde tüketicinin ölü veya başarısız olduğu kabul edilir. Bu gecikme, tüketicinin yeniden dengelenmesine yol açar. Tüketiciyi session.timeout.msdüşür , bu hataları daha hızlı algılayabiliriz.

session.timeout.ms değeri çok düşükse, bir grup iletinin işlenmesinin uzun sürmesi veya JVM GC duraklatma işleminin çok uzun sürmesi gibi senaryolar nedeniyle tüketici gereksiz yeniden dengelemeleri tekrarlayabilir. İletileri işlemek için çok fazla zaman harcayan bir tüketiciniz varsa, ile daha fazla kayıt max.poll.interval.ms getirmeden önce tüketicinin boşta olabileceği sürenin üst sınırını artırarak veya yapılandırma parametresiyle max.poll.recordsdöndürülen toplu işlemlerin maksimum boyutunu azaltarak bu sorunu giderebilirsiniz.

İşlem grubu oluşturma

Üreticiler gibi tüketiciler için toplu işlem de ekleyebiliriz. Tüketicilerin her getirme isteğinde elde ettiği veri miktarı, yapılandırması fetch.min.bytesdeğiştirilerek yapılandırılabilir. Bu parametre, tüketicinin getirme yanıtından beklenen en düşük bayt sayısını tanımlar. Bu değerin artırılması, aracıya yapılan getirme isteklerinin sayısını azaltır ve bu nedenle ek yükü azaltır. Varsayılan olarak, bu değer 1'dir. Benzer şekilde, başka bir yapılandırma fetch.max.wait.msvardır. Getirme isteği boyutuna fetch.min.bytesgöre yeterli ileti içermiyorsa, bu yapılandırmaya fetch.max.wait.msgöre bekleme süresinin dolmasını bekler.

Dekont

Birkaç senaryoda tüketiciler, iletiyi işleyemediğinde yavaş görünebilir. Bir özel durumdan sonra uzaklığı işlemezseniz, tüketici sonsuz döngüde belirli bir uzaklıkta takılır ve ileriye doğru ilerlemez ve sonuç olarak tüketici tarafındaki gecikmeyi artırır.

Yoğun iş yüküyle Linux işletim sistemi ayarlama

Bellek eşlemeleri

vm.max_map_count bir işlemin sahip olabileceği en fazla mmap sayısını tanımlar. Varsayılan olarak, HDInsight Apache Kafka kümesi linux VM'sinde değer 65535'tir.

Apache Kafka'da her günlük kesimi bir çift dizin/timeindex dosyası gerektirir ve bu dosyaların her biri bir mmap tüketir. Başka bir deyişle, her günlük kesimi iki mmap kullanır. Bu nedenle, her bölüm tek bir günlük kesimi barındırıyorsa en az iki mmap gerektirir. Bölüm başına günlük segmentlerinin sayısı segment boyutuna, yük yoğunluğuna, bekletme ilkesine, sıralı döneme bağlı olarak değişir ve genellikle birden fazla olma eğilimindedir. Mmap value = 2*((partition size)/(segment size))*(partitions)

Gerekli mmap değeri değerini aşarsavm.max_map_count, aracı "Eşleme başarısız oldu" özel durumunu tetikler.

Bu özel durumu önlemek için, vm'de mmap boyutunu denetlemek ve her çalışan düğümünde gerekirse boyutu artırmak için aşağıdaki komutları kullanın.

# command to find number of index files:
find . -name '*index' | wc -l

# command to view vm.max_map_count for a process:
cat /proc/[kafka-pid]/maps | wc -l

# command to set the limit of vm.max_map_count:
sysctl -w vm.max_map_count=<new_mmap_value>

# This will make sure value remains, even after vm is rebooted:
echo 'vm.max_map_count=<new_mmap_value>' >> /etc/sysctl.conf
sysctl -p