Apache Kafka срещу Apache Pulsar: Как да изберем

Понастоящем масово мащабируемите кръчми / под съобщения на практика са синоним на Apache Kafka. Apache Kafka продължава да бъде солидният, с отворен код, избор за разпределени поточни приложения, независимо дали добавяте нещо като Apache Storm или Apache Spark за обработка или използвате инструментите за обработка, предоставени от самия Apache Kafka. Но Кафка не е единствената игра в града.

Разработено от Yahoo и сега проект на Apache Software Foundation, Apache Pulsar се стреми към короната на съобщенията, която Apache Kafka носи в продължение на много години. Apache Pulsar предлага потенциал за по-бърза производителност и по-ниска латентност от Apache Kafka в много ситуации, заедно със съвместим API, който позволява на разработчиците да преминат от Kafka към Pulsar с относителна лекота. 

Как трябва да се избира между почтения твърд Apache Kafka и изскочилия Apache Pulsar? Нека разгледаме техните основни предложения с отворен код и какво предлагат корпоративните издания на поддържащите ядрото.

Apache Kafka

Разработено от LinkedIn и пуснато с отворен код през 2011 г., Apache Kafka се разпространи надалеч и почти се превърна в избор по подразбиране за мнозина, когато мислят за добавяне на сервизна шина или кръчма / подсистема към архитектура. След дебюта на Apache Kafka, екосистемата на Kafka се разраства значително, добавяйки системния регистър за налагане на схеми в съобщенията на Apache Kafka, Kafka Connect за лесно поточно предаване от други източници на данни, като бази данни към Kafka, Kafka Streams за обработка на разпределени потоци и наскоро KSQL за извършване на SQL-подобни заявки по темите на Kafka. (Темата в Kafka е името на определен канал.)

Стандартният случай на използване на много тръбопроводи в реално време, построени през последните няколко години, е да се изтласкват данни в Apache Kafka и след това да се използва поточен процесор като Apache Storm или Apache Spark за изтегляне на данни, извършване и обработка и след това публикуване изход към друга тема за консумация надолу по веригата. С Kafka Streams и KSQL, всичките ви нужди от тръбопровод за данни могат да бъдат обработени, без да се налага да напускате проекта Apache Kafka по всяко време, въпреки че, разбира се, все още можете да използвате външна услуга за обработка на вашите данни, ако е необходимо.

Въпреки че Apache Kafka винаги е бил много приятелски настроен от гледна точка на разработчика, това е нещо като смесена чанта в оперативно отношение. Стартирането и изпълнението на малък клъстер е сравнително лесно, но поддържането на голям клъстер често е изпълнено с проблеми (напр. Размяна на дял на лидера след неуспех на брокера на Kafka).

Освен това, подходът, приет за подпомагане на мулти-наемането, чрез помощна програма, наречена MirrorMaker, е сигурен начин да накарате SRE да извадят косите си. Всъщност MirrorMaker се счита за такъв проблем, че компании като Uber са създали своя собствена система за репликация в центрове за данни (uReplicator). Confluent включва Confluent Replicator като част от корпоративната си оферта на Apache Kafka. Говорейки като човек, който е трябвало да поддържа настройка на MirrorMaker, срамота е, че Replicator не е част от версията с отворен код.

Определено обаче не са всички лоши новини на оперативния фронт. Много работа е свършена в настоящата серия Apache Kafka 1.x, за да се намалят някои от главоболията при управление на клъстер. Напоследък има някои промени, които позволяват на системата да изпълнява големи клъстери от над 200 000 дяла по по-рационализиран начин, а подобрения като добавяне на опашки с „мъртви букви“ в Kafka Connect правят идентифицирането и възстановяването от проблеми в източниците на данни и мивките толкова много по-лесно. Вероятно ще видим и поддръжка на ниво производство за стартиране на Apache Kafka на Kubernetes през 2019 г. (чрез диаграми Helm и оператор Kubernetes).

През 2014 г. трима от първоначалните разработчици на Kafka (Jun Rao, Jay Kreps и Neha Narkhede) формират Confluent, който предоставя допълнителни корпоративни функции в своята Confluent Platform като гореспоменатия репликатор, контролен център, допълнителни приставки за сигурност и обичайните предложения за поддръжка и професионални услуги. Confluent има и облачна оферта, Confluent Cloud, която е напълно управлявана услуга Confluent Platform, която работи на Amazon Web Services или Google Cloud Platform, ако предпочитате да не се справяте с някои от оперативните разходи на работещите клъстери сами.

Ако сте заключени в AWS и използвате услуги на Amazon, имайте предвид, че Amazon въведе публичен визуализация на Amazon Managed Streaming for Kafka (MSK), която е напълно управлявана услуга на Kafka в рамките на екосистемата AWS. (Обърнете внимание също, че Amazon MSK не се предоставя в партньорство с Confluent, така че стартирането на MSK няма да ви осигури всички функции на Confluent Platform, а само това, което е предоставено в Apache Kafka с отворен код.)

Apache Pulsar

Като се има предвид пристрастието на Apache Software Foundation за взимане на проекти, които изглежда дублират функционалност (бихте ли искали Apache Apex, Apache Flink, Apache Heron, Apache Samza, Apache Spark или Apache Storm за вашите насочени нужди от обработка на ациклични графики?), Бихте ли искали? ще ви бъде простено да гледате точно покрай съобщенията за Apache Pulsar, превръщайки се в проект на Apache от първо ниво, преди да изберете Apache Kafka като надеждна опция за вашите нужди за съобщения. Но Apache Pulsar заслужава поглед.

Apache Pulsar е роден в Yahoo, където е създаден, за да отговори на нуждите на организацията, които други предложения с отворен код не могат да предоставят по това време. В резултат на това Pulsar е създаден от нулата, за да обработва милиони теми и дялове с пълна поддръжка за гео-репликация и мулти-наемане.

Под капаците Apache Pulsar използва Apache BookKeeper за поддържане на нуждите си от съхранение, но има обрат: Apache Pulsar има функция, наречена Tiered Storage, която е доста нещо. Един от проблемите на разпределените дневник системи е, че докато искате данните да останат в лог платформата възможно най-дълго, дисковите устройства не са безкрайни по размер. В даден момент вземате решение или да изтриете тези съобщения, или да ги съхранявате на друго място, където потенциално могат да бъдат възпроизведени през конвейера за данни, ако е необходимо в бъдеще. Което работи, но може да бъде оперативно сложно. Apache Pulsar, чрез Tiered Storage, може автоматично да премества по-стари данни в Amazon S3, Google Cloud Storage или Azure Blog Storage и все пак да предоставя прозрачен изглед обратно на клиента;клиентът може да чете от самото начало, точно както всички съобщения са налице в дневника.

Подобно на Apache Kafka, Apache Pulsar е развил екосистема за обработка на данни (въпреки че предлага и адаптери за Apache Spark и Apache Storm). Pulsar IO е еквивалентът на Kafka Connect за свързване към други системи за данни като източници или мивки, а Pulsar Functions осигурява функционалност за обработка на данни. SQL заявките се осигуряват чрез използване на адаптер за отворения източник на Facebook на Presto.

Интересна бръчка е, че Pulsar Functions и Pulsar IO се изпълняват в рамките на стандартен клъстер Pulsar, вместо да бъдат отделни процеси, които потенциално могат да се изпълняват навсякъде. Въпреки че това е намаляване на гъвкавостта, това прави нещата много по-опростени от оперативна гледна точка. (Има режим на локално изпълнение, който може да се злоупотребява, за да се изпълняват функции извън клъстера, но документацията не може да каже „Не прави това!“)

Apache Pulsar предлага и различни методи за изпълнение на функции в рамките на клъстера: Те могат да се изпълняват като отделни процеси, като Docker контейнери или като нишки, изпълнявани в JVM процеса на брокера. Това се свързва с модела за внедряване на Apache Pulsar, който вече поддържа Kubernetes или Mesosphere DC / OS в производството. Едно нещо, което трябва да знаете, е, че Pulsar Functions, Pulsar IO и SQL са сравнително нови допълнения към Apache Pulsar, така че очаквайте няколко остри ръба, ако ги използвате.

Има и ограничена, само за Java, съвместима с Kafka API обвивка, така че можете потенциално да интегрирате съществуващите приложения на Apache Kafka в инфраструктура на Apache Pulsar. Това вероятно е по-подходящо за изследователски тестове и междинен план за миграция, отколкото производствено решение, но е хубаво да го имате!

По подобен начин на Confluent, разработчиците на Apache Pulsar в Yahoo (Matteo Merli и Sijie Guo) са създали spinoff компания Streamlio, където са съоснователи заедно със създателите на Apache Heron (Karthik Ramasamy и Sanjeev Kulkarni) . Предложението на Streamlio за предприятия включва обичайните решения за търговска поддръжка и професионални услуги, заедно с конзола за управление с затворен код, но неща като ефективна и трайна поддръжка за много наематели са част от основния продукт с отворен код.

Apache Kafka или Apache Pulsar?

Apache Kafka е зрял, издръжлив и тестван в битки продукт. Той има клиенти, написани на почти всеки популярен език, както и множество поддържани конектори за различни източници на данни в Kafka Connect. С предлаганите от Amazon и Confluent управлявани услуги е лесно да се получи голям клъстер на Kafka, да се работи и поддържа - много по-лесно, отколкото в предишни години. Продължавам да използвам Apache Kafka в нови проекти и вероятно ще го направя в продължение на много години напред.

Ако обаче ще изграждате система за съобщения, която трябва да бъде мулти-наемателска или гео-реплицирана от самото начало или която има големи нужди от съхранение на данни, плюс необходимостта от лесно заявяване и обработка на всички тези данни, без значение как отдавна в миналото, тогава предлагам да изритам гумите на Apache Pulsar. Определено отговаря на някои случаи на употреба, с които Apache Kafka може да се бори, като същевременно работи добре по отношение на основните функции, от които се нуждаете от разпределена дневник платформа. И ако нямате нищо против да сте на върха по отношение на документацията и отговорите на Stack Overflow въпроси, толкова по-добре!