Programování

Mělo to s Apache Storm? Heron se vrhne na záchranu

V loňském roce Twitter odhodil dvě bomby. Nejprve by už nepoužíval Apache Storm ve výrobě. Zadruhé jej nahradil domácím systémem zpracování dat, Herone.

Navzdory vydání článku popisujícího architekturu Heronu zůstala alternativa Twitteru k Stormu skryta v datových centrech Twitteru. To se minulý týden změnilo, když Twitter vydal Heron pod licencí open source. Co je tedy Heron a kam to zapadá do světa zpracování dat v měřítku?

Stroj na zpracování dat s řízeným acyklickým grafem (DAG), Heron je právě teď další položka ve velmi přeplněném poli. Ale Heron není „pohled, já taky!“ řešení nebo pokus přeměnit motory DAG na ekvivalent velkých dat FizzBuzz.

Heron vyrostl ze skutečných obav, které Twitter měl s velkým nasazením Storm topologií. Jednalo se o obtíže s profilováním a uvažováním o pracovnících Storm při škálování na úrovni dat a na úrovni topologie, statická povaha alokace prostředků ve srovnání se systémem, který běží na platformách Mesos nebo YARN, nedostatek podpory protitlaku a další.

Ačkoli Twitter mohl přijmout Apache Spark nebo Apache Flink, znamenalo by to přepsání veškerého stávajícího kódu Twitteru. (Nezapomeňte, že Twitter používá Storm déle než kdokoli jiný, získává BackType, tvůrce Stormu, ještě v roce 2011, než byl otevřený zdroj.) Místo toho Twitter zvolil jiný přístup: nový rámec zpracování streamu s API kompatibilním se Storm .

V tomto bodě našeho procházení novým rámcem bych normálně prošel několika příklady, abych vám ukázal, jaké je kódování v rámci, ale s Heronem to nemá smysl - píšete šrouby a n-tice Storm přesně stejným způsobem jako byste s Storm. Vše, co musíte udělat, abyste spustili svůj Storm kód na Heronu, je přidání této sekce do závislostí vašeho pom.xml:

com.twitter.heron

heron-api

MOMENTKA

kompilovat

com.twitter.heron

heron-storm

MOMENTKA

kompilovat

Poté odeberete závislosti na bouřkovém kódu a clojure-pluginu. Překompilujte a váš kód bude spuštěn na Heronu bez nutnosti dalších změn. Jednoduchý! (Většinou tak jako tak, ale k tomu se ještě vrátíme.)

Aktuálně je implementace Heronu provozována na vrcholu Apache Mesos a využívá Apache Aurora, plánovací rámec Mesos vyvinutý společností Twitter (překvapení!). Od přepnutí všech svých topologií Storm na Heron se Twitteru podařilo snížit hardwarové prostředky vyhrazené pro topologie o faktor tři a zároveň zvýšit propustnost a snížit latenci ve zpracování - není to špatné.

Snad jedním z nejzajímavějších aspektů Herona je, že zatímco jeho kód bude napsán v Javě (nebo Scale) a webové komponenty uživatelského rozhraní jsou napsány v Pythonu, kritických částech rámce, kódu, který spravuje topologie a síťová komunikace není vůbec napsána v jazyce JVM.

Ve skutečnosti v srdci Heronu najdete kód v jazyce, který byste možná nečekali: C ++. Myslím, že toto je aspekt světa velkých dat, kterého se v následujících letech dočkáme více.

Správci Apache Storm odebrali mnoho prvků svého původního kódu Clojure ve prospěch reimplementací prostředí Java a projekt Apache Spark v současné době generuje kód Java za běhu, aby urychlil jeho zpracování DataFrame. Ale oba jsou stále spojeni s JVM - a JVM má problémy v měřítku. Nechápejte mě špatně, JVM je úžasný výtvor, který obstál ve zkoušce času po dobu 20 let, ale při běhu na strojích s velkým množstvím RAM a zpracováním obrovského množství dat se objeví problémy se sběrem odpadu, bez ohledu na to efektní sběratelské schéma, které používáte.

V tomto okamžiku začíná přechod zpět do jazyka, jako je C ++, přitažlivě vypadat. Například Scylla, reimplementace Apache Cassandra v C ++, má desetinásobnou propustnost Cassandry bez žádné pauzy GC, kterou Cassandra proslavila při velkých nasazeních. Jsem si docela jistý, že brzy uvidíme, jak se Heronův přístup rozšíří do dalších rámců. Tomu může pomoci pokus Project Panama vylepšit rozhraní mezi Javou a jinými jazyky.

Vzhledem k tomu, že Heron vyžaduje méně zdrojů a poskytuje větší propustnost a menší latenci než Apache Storm, měli byste hned přesunout všechny své topologie do Heronu, ano? No, možná. Heron je v současné době spojen s Mesosem, takže pokud nemáte existující infrastrukturu Mesos, budete ji muset také nastavit, což není žádný malý podnik. Také, pokud využíváte funkce DRPC společnosti Storm, jsou v Heronu zastaralé.

Pozitivní je, že Heron provozuje všechny potřeby zpracování Twitteru ve výrobě již více než rok, takže by měl být schopen zvládnout vše, co na něj můžete hodit. Twitter navíc poukazuje na to, že Heron se používá u Microsoftu a dalších společností ze žebříčku Fortune 500, takže si můžete být relativně jisti, že se bude držet.

Na druhou stranu Storm nestál na místě. Tým Apache Storm by se mohl hádat s popisem Herona na Twitteru jako „nové generace Apache Storm“. Zatímco Twitter pracoval na Heronu, Apache Storm dosáhl 1,0 - což zahrnuje podporu protitlaku, vylepšené možnosti ladění a profilování, 60% snížení latence a až 16násobné zlepšení rychlosti.

Storm 1.0 navíc přidává kardiostimulátor, démona pro snižování provozu prezenčního signálu ze ZooKeeper, čímž uvolňuje větší topologie z nechvalně známého úzkého hrdla ZooKeeper. Vylepšení rychlosti Heronu se měří z kódu Storm 0.8.x, od kterého se lišil, nikoli z aktuální verze; pokud jste již migrovali na Storm 1.0, možná neuvidíte mnohem větší zlepšení oproti vašim současným topologiím Storm a můžete narazit na nekompatibility mezi implementací nových funkcí, jako je podpora protitlaku mezi Storm a Heron.

Celkově vzato nevěřím, že Heron pravděpodobně způsobí velkou škodu při zavádění rámců pro zpracování dat, jako jsou Apache Spark, Apache Flink nebo Apache Beam. Jejich abstrakce a rozhraní API na vyšší úrovni poskytují vývojářsky příjemnější prostředí než rozhraní API Storm / Trident nižší úrovně. Věřím však, že kombinace kódu JVM s moduly, které nejsou JVM pro kritické cesty, bude v budoucnu populárnějším přístupem a v tomto aspektu nám Heron ukazuje všechny směry, kterými se budeme pohybovat v měsících a letech přijít.

$config[zx-auto] not found$config[zx-overlay] not found