Дали с Apache Storm? Херон се нахвърля на помощ

Миналата година Twitter пусна две бомби. Първо, той вече няма да използва Apache Storm в производството. Второ, беше го заменил със собствена система за обработка на данни, Heron.

Въпреки публикуването на хартия, описваща архитектурата на Heron, алтернативата на Twitter на Storm остава скрита в центровете за данни на Twitter. Всичко това се промени миналата седмица, когато Twitter пусна Heron под лиценз с отворен код. И така, какво е Heron и къде се вписва в света на мащабна обработка на данни?

Двигател за обработка на данни с насочена ациклична графика (DAG), Heron е поредният запис в много пренаселено поле в момента. Но Херон не е „погледнете и аз!“ решение или опит да се превърнат DAG двигателите в еквивалент на големи данни на FizzBuzz.

Heron израсна от истинските притеснения, които Twitter имаше с широкото си внедряване на топологии Storm. Те включват трудности с профилирането и разсъжденията за работниците на Storm, когато се мащабират на ниво данни и на ниво топология, статичния характер на разпределението на ресурсите в сравнение със система, която работи на Mesos или YARN, липса на поддръжка на обратен натиск и др.

Въпреки че Twitter би могъл да приеме Apache Spark или Apache Flink, това би включвало пренаписване на целия съществуващ код на Twitter. (Не забравяйте, че Twitter използва Storm по-дълго от всеки друг, придобивайки BackType, създателят на Storm, още през 2011 г., преди да е с отворен код.) Вместо това, Twitter възприе различен подход: нова рамка за обработка на потоци със съвместим с Storm API .

На този етап от нашата разходка през нова рамка, обикновено бих разгледал някои примери, за да ви покажа какво е кодирането в рамката, но с Heron няма смисъл - пишете болтове и кортежи на Storm по абсолютно същия начин като бихте с Буря. Всичко, което трябва да направите, за да стартирате своя код на Storm на Heron, е да добавите този раздел към зависимостите на вашия pom.xml:

 com.twitter.heron

 heron-api

 SNAPSHOT

 compile

 com.twitter.heron

 heron-storm

 SNAPSHOT

 compile

След това премахвате вашите зависимости от буря-код и clojure-plugin. Прекомпилирайте и вашият код ще работи на Heron без допълнителни промени. Просто! (Най-вече така или иначе, но ще се върнем към това.)

Оперативно, текущата реализация на Heron работи върху Apache Mesos, използвайки Apache Aurora, рамката за планиране на Mesos, разработена от Twitter (изненада!) Тъй като превключи всичките си топологии Storm на Heron, Twitter успя да намали хардуерните ресурси, посветени на топологиите, с фактор три, като същевременно увеличи пропускателната способност и намали латентността в обработката - не е лошо.

Може би един от най-интересните аспекти на Heron е, че докато кодът за него ще бъде написан на Java (или Scala), а уеб базираните UI компоненти са написани на Python, критичните части на рамката, кодът, който управлява топологиите и мрежовите комуникации изобщо не са написани на JVM език.

Всъщност в сърцето на Heron ще намерите код на език, който може да не очаквате: C ++. Мисля, че това е аспект от света на големите данни, който ще видим повече през следващите години. 

Поддръжниците на Apache Storm са премахнали много елементи от оригиналния си код Clojure в полза на преиздаване на Java, а проектът Apache Spark в момента генерира Java код в движение, за да ускори обработката на DataFrame. Но и двете са все още свързани с JVM - и JVM има проблеми в мащаба. Не ме разбирайте погрешно, JVM е невероятно творение, което е издържало изпитанието на времето в продължение на 20 години, но когато работи на машини с огромно количество RAM и обработва огромно количество данни, възникват проблеми със събирането на боклука, независимо какво фантастична колекторска схема, която използвате.

В този момент връщането към език като C ++ започва да изглежда привлекателно. Като пример, Scylla, преиздаване на C ++ на Apache Cassandra, има 10 пъти по-голяма производителност от Cassandra, като нито една от GC паузите не е известна при големи внедрявания. Доста уверен съм, че скоро ще видим, че подходът на Херон се разпространява и в други рамки. За това може да помогне опитът на Project Panama да подобри интерфейса между Java и други езици.

Като се има предвид, че Heron изисква по-малко ресурси и осигурява по-голяма производителност и по-малко латентност от Apache Storm, трябва да преместите всичките си топологии към Heron точно сега, нали? Добре може би. Понастоящем Heron е обвързан с Mesos, така че ако нямате съществуваща инфраструктура на Mesos, ще трябва да настроите и тази, което не е малко начинание. Освен това, ако използвате DRPC функциите на Storm, те са оттеглени в Heron.

Положителното е, че Heron изпълнява всички производствени нужди на Twitter в продължение на повече от година, така че трябва да може да се справи с всичко, което можете да хвърлите в него. Освен това Twitter посочва, че Heron се използва в Microsoft и други компании от Fortune 500, така че можете да бъдете относително уверени, че ще остане.

От друга страна, Буря не е стояла на едно място. Екипът на Apache Storm може да се усъвършенства с описанието на Twitter на Heron като „следващото поколение на Apache Storm“. Докато Twitter работеше върху Heron, Apache Storm достигна 1.0 - което включва поддръжка за обратно налягане, подобрени опции за отстраняване на грешки и профилиране, 60% намаление на латентността и до 16 пъти подобрение на скоростта.

В допълнение, Storm 1.0 добавя пейсмейкър, демон за разтоварване на сърдечния ритъм от ZooKeeper, освобождавайки по-големи топологии от скандалното тесно място на ZooKeeper. Подобренията на скоростта на Херон се измерват от кода на Storm 0.8.x, от който се отклонява, а не от текущата версия; ако вече сте мигрирали към Storm 1.0, може да не забележите много повече подобрения спрямо текущите си топологии на Storm и може да срещнете несъвместимости между внедряването на нови функции като поддръжка на обратен натиск между Storm и Heron.

Като цяло не вярвам, че Херон вероятно ще причини големи проблеми с усвояването на рамки за обработка на данни като Apache Spark, Apache Flink или Apache Beam. Техните абстракции и API на по-високо ниво осигуряват много по-удобно за разработчици изживяване от API на Storm / Trident от по-ниско ниво. Вярвам обаче, че комбинацията от JVM код с не-JVM модули за критичните пътища ще бъде по-популярен подход за напред и в този аспект Херон ни показва цялата посока, по която ще пътуваме през месеците и годините да дойде.