Optimalizace výkonu pro clustery Apache Kafka HDInsight

Článek
10/18/2023

Tento článek nabízí několik návrhů pro optimalizaci výkonu úloh Apache Kafka ve službě HDInsight. Zaměřuje se na úpravu konfigurace producenta, zprostředkovatele a příjemce. Někdy je také potřeba upravit nastavení operačního systému, aby se vyladil výkon s velkým zatížením. Existují různé způsoby měření výkonu a optimalizace, které použijete, závisí na vašich obchodních potřebách.

Přehled architektury

Témata Kafka se používají k uspořádání záznamů. Producenti vytvářejí záznamy a spotřebitelé je spotřebovávají. Producenti odesílají záznamy do zprostředkovatelů Kafka, které pak ukládají data. Každý pracovní uzel v clusteru HDInsight je zprostředkovatelem Kafka.

Témata rozdělují záznamy do oddílů napříč zprostředkovateli. Při využívání záznamů můžete dosáhnout paralelního zpracování dat díky použití až jednoho konzumenta pro každý oddíl.

Replikace se používá k duplikování oddílů napříč uzly. Tento oddíl chrání před výpadky uzlů (zprostředkovatele). Jako vedoucí oddíl je určen jeden oddíl mezi skupinou replik. Provoz producenta se směruje do vedoucích jednotlivých uzlů pomocí stavu, který spravuje ZooKeeper.

Určení scénáře

Výkon Apache Kafka má dva hlavní aspekty – propustnost a latenci. Propustnost je maximální rychlost zpracování dat. Vyšší propustnost je lepší. Latence je doba, která trvá uložení nebo načtení dat. Nižší latence je lepší. Nalezení správné rovnováhy mezi propustností, latencí a náklady na infrastrukturu aplikace může být náročné. Požadavky na výkon by se měly shodovat s jednou z následujících tří běžných situací na základě toho, jestli požadujete vysokou propustnost, nízkou latenci nebo obojí:

Vysoká propustnost, nízká latence. Tento scénář vyžaduje vysokou propustnost i nízkou latenci (přibližně 100 milisekund). Příkladem tohoto typu aplikace je monitorování dostupnosti služeb.
Vysoká propustnost, vysoká latence. Tento scénář vyžaduje vysokou propustnost (přibližně 1,5 GB/s), ale dokáže tolerovat vyšší latenci (< 250 ms). Příkladem tohoto typu aplikace je příjem telemetrických dat pro procesy téměř v reálném čase, jako jsou aplikace pro detekci zabezpečení a neoprávněných vniknutí.
Nízká propustnost, nízká latence. Tento scénář vyžaduje nízkou latenci (< 10 ms) pro zpracování v reálném čase, ale dokáže tolerovat nižší propustnost. Příkladem tohoto typu aplikace je online kontrola pravopisu a gramatiky.

Konfigurace producenta

Následující části zvýrazňují některé z nejdůležitějších obecných vlastností konfigurace pro optimalizaci výkonu vašich výrobců Kafka. Podrobné vysvětlení všech vlastností konfigurace najdete v dokumentaci k Apache Kafka v konfiguracích producenta.

Velikost dávky

Producenti Apache Kafka sestavují skupiny zpráv (označované jako dávky), které se odesílají jako jednotka, která se uloží do jednoho oddílu úložiště. Velikost dávky znamená počet bajtů, které musí být přítomné před přenosem této skupiny. Zvýšením parametru batch.size se může zvýšit propustnost, protože snižuje režijní náklady na zpracování ze síťových a vstupně-výstupních požadavků. Při lehkém zatížení může zvýšená velikost dávky zvýšit latenci odesílání Kafka, protože producent čeká, až bude dávka připravená. V případě velkého zatížení se doporučuje zvětšit velikost dávky, aby se zlepšila propustnost a latence.

Potvrzení požadovaného producenta

Požadovaná acks konfigurace producenta určuje počet potvrzení vyžadovaných vedoucím oddílem před tím, než se žádost o zápis považuje za dokončenou. Toto nastavení má vliv na spolehlivost dat a přebírá hodnoty 0, 1nebo -1. Hodnota -1 znamená, že potvrzení musí být přijato ze všech replik před dokončením zápisu. Nastavení acks = -1 poskytuje silnější záruky proti ztrátě dat, ale také vede k vyšší latenci a nižší propustnosti. Pokud vaše aplikace vyžaduje vyšší propustnost, zkuste nastavit acks = 0 nebo acks = 1. Mějte na paměti, že potvrzení všech replik může snížit spolehlivost dat.

Komprese

Producent Kafka je možné nakonfigurovat tak, aby komprimoval zprávy před jejich odesláním do zprostředkovatelů. Nastavení compression.type určuje kodek komprese, který se má použít. Podporované komprimační kodeky jsou gzip, snappy a lz4. Komprese je výhodná a měla by být považována za omezení kapacity disku.

Mezi dvěma běžně používanými komprimačními kodeky gzip a snappy, gzip má vyšší poměr komprese, což vede k nižšímu využití disku za cenu vyššího zatížení procesoru. Kodek snappy poskytuje menší kompresi s menší režií procesoru. Můžete se rozhodnout, který kodek se má použít na základě omezení procesoru zprostředkovatele disku nebo producenta. gzip může komprimovat data rychlostí pětkrát vyšší než snappy.

Komprese dat zvyšuje počet záznamů, které lze uložit na disk. Může také zvýšit režii procesoru v případech, kdy dochází k neshodě mezi formáty komprese používané producentem a zprostředkovatelem. protože data musí být před odesláním a dekomprimována před zpracováním.

Nastavení zprostředkovatele

Následující části zvýrazňují některá z nejdůležitějších nastavení pro optimalizaci výkonu zprostředkovatelů Kafka. Podrobné vysvětlení všech nastavení zprostředkovatele najdete v dokumentaci k Apache Kafka v konfiguracích zprostředkovatele.

Počet disků

Disky úložiště mají omezené IOPS (vstupně-výstupní operace za sekundu) a bajty pro čtení a zápis za sekundu. Při vytváření nových oddílů kafka ukládá každý nový oddíl na disku s nejmenšími existujícími oddíly, aby je vyvážit mezi dostupnými disky. I přes strategii úložiště může kafka při zpracování stovek replik oddílů na každém disku snadno sytit dostupnou propustnost disku. Kompromis je mezi propustností a náklady. Pokud vaše aplikace vyžaduje větší propustnost, vytvořte cluster s více spravovanými disky na zprostředkovatele. HDInsight v současné době nepodporuje přidávání spravovaných disků do spuštěného clusteru. Další informace o konfiguraci počtu spravovaných disků najdete v tématu Konfigurace úložiště a škálovatelnosti pro Apache Kafka ve službě HDInsight. Seznamte se s náklady na zvýšení prostoru úložiště pro uzly v clusteru.

Počet témat a oddílů

Producenti Kafka píší do témat. Příjemci Kafka čtou z témat. Téma je přidružené k protokolu, což je datová struktura na disku. Kafka připojí záznamy od producenta k konci protokolu témat. Protokol tématu se skládá z mnoha oddílů, které jsou rozloženy do více souborů. Tyto soubory se zase rozprostírají mezi několik uzlů clusteru Kafka. Uživatelé čtou témata Kafka v tempu a můžou si vybrat svoji pozici (posun) v protokolu témat.

Každý oddíl Kafka je soubor protokolu v systému a vlákna producenta můžou zapisovat do více protokolů současně. Podobně platí, že vzhledem k tomu, že každé vlákno příjemce čte zprávy z jednoho oddílu, zpracovává se také paralelně spotřeba z více oddílů.

Zvýšení hustoty oddílů (počet oddílů na zprostředkovatele) přidává režii související s operacemi metadat a každou žádost o oddíl a odpověď mezi vedoucím oddílem a sledujícími. I když chybí tok dat, repliky oddílů stále načítají data z vedení, což vede k dodatečnému zpracování pro odesílání a přijímání požadavků přes síť.

Pro clustery Apache Kafka 2.1 a 2.4 a jak je uvedeno dříve ve službě HDInsight, doporučujeme mít maximálně 2 000 oddílů na zprostředkovatele, včetně replik. Zvýšení počtu oddílů na zprostředkovatele snižuje propustnost a může také způsobit nedostupnost tématu. Další informace o podpoře oddílů Kafka najdete v oficiálním blogovém příspěvku Apache Kafka o zvýšení počtu podporovaných oddílů ve verzi 1.1.0. Podrobnosti o úpravách témat najdete v tématu Apache Kafka: úprava témat.

Počet replik

Vyšší faktor replikace vede k dalším požadavkům mezi vedoucím oddílem a sledujícími. V důsledku toho vyšší faktor replikace spotřebovává více disku a procesoru ke zpracování dalších požadavků, což zvyšuje latenci zápisu a snižuje propustnost.

Doporučujeme použít aspoň 3x replikaci pro Kafka ve službě Azure HDInsight. Většina oblastí Azure má tři domény selhání, ale v oblastech s pouze dvěma doménami selhání by uživatelé měli používat 4x replikaci.

Další informace o replikaci najdete v tématu Apache Kafka: replikace a Apache Kafka: zvýšení faktoru replikace.

Konfigurace uživatelů

V následující části jsou zvýrazněny některé důležité obecné konfigurace pro optimalizaci výkonu uživatelů Kafka. Podrobné vysvětlení všech konfigurací najdete v dokumentaci k Apache Kafka o konfiguracích příjemců.

Počet příjemců

Osvědčeným postupem je mít počet oddílů, které se rovnají počtu příjemců. Pokud je počet příjemců menší než počet oddílů, pak několik příjemců čte z více oddílů, což zvyšuje latenci příjemce.

Pokud je počet příjemců větší než počet oddílů, dochází k plýtvání uživatelskými prostředky, protože tito příjemci jsou nečinní.

Vyhněte se častému vyrovnávání spotřebitelů

Vyvážení příjemců se aktivuje změnou vlastnictví oddílu (tj. škálováním na více instancí nebo snížením kapacity), chybovým ukončením zprostředkovatele (protože zprostředkovatelé jsou koordinátorem skupin pro skupiny příjemců), chybovým ukončením příjemce, přidáním nového tématu nebo přidáním nových oddílů. Během vyrovnávání nemohou spotřebitelé spotřebovávat, a tím zvýšit latenci.

Spotřebitelé jsou považováni za živé, pokud mohou odeslat prezenčních signálů do zprostředkovatele v rámci session.timeout.ms. V opačném případě se spotřebitel považuje za mrtvý nebo selhal. Toto zpoždění vede k opětovnému vyvážení spotřebitele. Snížit spotřebitele session.timeout.ms, rychleji můžeme zjistit tyto chyby.

Pokud je příliš session.timeout.ms nízká, může spotřebitel zaznamenat opakované zbytečné vyvážení, a to kvůli scénářům, jako je například v případě, že zpracování dávky zpráv trvá déle nebo když pozastavení GC prostředí JVM trvá příliš dlouho. Pokud máte příjemce, který tráví příliš mnoho času zpracováním zpráv, můžete to vyřešit tak, že zvýšíte horní mez doby, po kterou může být spotřebitel nečinný, než načte více záznamů, max.poll.interval.ms nebo snížením maximální velikosti dávek vrácených pomocí parametru max.poll.recordskonfigurace .

Dávkování

Podobně jako producenti můžeme přidat dávky pro spotřebitele. Velikost příjemců dat může být v každém požadavku na načtení nakonfigurována změnou konfigurace fetch.min.bytes. Tento parametr definuje minimální bajty očekávané od odpovědi na načtení příjemce. Zvýšením této hodnoty se sníží počet požadavků na načtení provedených u zprostředkovatele, a tím se sníží režijní náklady navíc. Ve výchozím nastavení je tato hodnota 1. Podobně existuje další konfigurace fetch.max.wait.ms. Pokud požadavek na načtení nemá dostatek zpráv podle velikosti fetch.min.bytes, čeká na vypršení doby čekání na základě této konfigurace fetch.max.wait.ms.

Poznámka:

V několika scénářích se může zdát, že spotřebitelé jsou pomalí, když zprávu nezpracují. Pokud posun po výjimce nepopíšete, spotřebitel se zablokuje na určitém posunu v nekonečné smyčce a nepřesune se dopředu, což zvýší prodlevu na straně příjemce.

Ladění operačního systému Linux s velkým zatížením

Mapy paměti

vm.max_map_count definuje maximální počet mmap, který může mít proces. Ve výchozím nastavení je hodnota na virtuálním počítači s Linuxem clusteru Apache Kafka hdInsight 65535.

V Apache Kafka vyžaduje každý segment protokolu dvojici souborů indexu a časového indexu a každý z těchto souborů využívá jednu mmapu. Jinými slovy, každý segment protokolu používá dvě mmap. Pokud tedy každý oddíl hostuje jeden segment protokolu, vyžaduje minimálně dva mmap. Počet segmentů protokolu na oddíl se liší v závislosti na velikosti segmentu, intenzitě zatížení, zásadách uchovávání informací, postupném období a obecně je to více než jeden. Mmap value = 2*((partition size)/(segment size))*(partitions)

Pokud požadovaná hodnota mmap překročí vm.max_map_counthodnotu , zprostředkovatel vyvolá výjimku Map se nezdařilo .

Pokud se chcete této výjimce vyhnout, pomocí následujících příkazů zkontrolujte velikost mmap ve virtuálním počítači a v případě potřeby na každém pracovním uzlu zvětšete velikost.

# 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