Programmering

Hadde det med Apache Storm? Heron svinger til unnsetning

I fjor la Twitter to bomber. For det første ville det ikke lenger bruke Apache Storm i produksjonen. For det andre hadde den erstattet den med et hjemmelaget databehandlingssystem, Heron.

Til tross for å ha gitt ut et papir som beskriver Herons arkitektur, forble Twitters alternativ til Storm skjult i Twitters datasentre. Alt endret seg forrige uke da Twitter ga ut Heron under en åpen kildekode-lisens. Så hva er Heron, og hvor passer det i databehandlingsverdenen i stor skala?

En dirigert asyklisk graf (DAG) databehandlingsmotor, Heron er en annen oppføring i et veldig overfylt felt akkurat nå. Men Heron er ikke et "blikk, jeg også!" løsning eller et forsøk på å gjøre DAG-motorer til store datakvivalenter for FizzBuzz.

Heron vokste ut av reelle bekymringer Twitter hadde med sin store distribusjon av Storm-topologier. Disse inkluderte vanskeligheter med profilering og resonnement om Storm-arbeidere når de skaleres på datanivå og på et topologinivå, den statiske arten av ressurstildeling i forhold til et system som kjører på Mesos eller YARN, mangel på mottrykkstøtte og mer.

Selv om Twitter kunne ha vedtatt Apache Spark eller Apache Flink, ville det ha involvert omskriving av all Twitters eksisterende kode. (Ikke glem at Twitter har brukt Storm lenger enn noen annen, og anskaffet BackType, Stormens skaper, tilbake i 2011 før det var åpen kildekode.) I stedet tok Twitter en annen tilnærming: et nytt rammebehandlingsrammeverk med et Storm-kompatibelt API .

På dette punktet i vår vandring gjennom et nytt rammeverk, vil jeg normalt gå gjennom noen eksempler for å vise deg hvordan koding i rammeverket føles, men det er lite poeng med Heron - du skriver Stormbolter og tupler på nøyaktig samme måte som du ville med Storm. Alt du trenger å gjøre for å kjøre Storm-koden på Heron er å legge til denne delen i avhengighetene til pom.xml:

com.twitter.heron

hegre-api

STILLBILDE

kompilere

com.twitter.heron

hegre-storm

STILLBILDE

kompilere

Deretter fjerner du avhengighetene for stormkode og clojure-plugin. Kompiler på nytt, og koden din kjører på Heron uten ytterligere endringer. Enkel! (For det meste uansett, men vi kommer tilbake til det.)

Operasjonelt kjører Herons nåværende implementering på toppen av Apache Mesos, ved hjelp av Apache Aurora, Mesos planleggingsrammeverk utviklet av Twitter (overraskelse!). Siden Twitter byttet alle sine Storm-topologier til Heron, klarte hun å redusere maskinvareressurser dedikert til topologiene med en faktor på tre, samtidig som gjennomstrømningen økte og reduserte ventetid i behandlingen - ikke dårlig.

Kanskje en av de mest interessante aspektene ved Heron er at mens kode for den vil bli skrevet i Java (eller Scala), og de nettbaserte brukergrensesnittkomponentene er skrevet i Python, de kritiske delene av rammeverket, koden som styrer topologiene. og nettverkskommunikasjon er ikke skrevet på et JVM-språk i det hele tatt.

Faktisk, i hjertet av Heron, finner du kode på et språk du kanskje ikke forventer: C ++. Jeg tror dette er et aspekt av big data-verdenen som vi vil se mer av i årene som kommer.

Apache Storm-vedlikeholdere har fjernet mange elementer av den opprinnelige Clojure-koden til fordel for Java-reimplementeringer, og Apache Spark-prosjektet genererer for øyeblikket Java-kode på farten for å øke hastigheten på behandlingen av DataFrame. Men begge er fortsatt knyttet til JVM - og JVM har problemer i stor skala. Ikke misforstå, JVM er en fantastisk kreasjon som har stått tidstesten i 20 år, men når du kjører på maskiner med enorme mengder RAM og behandler enorme mengder data, dukker det opp problemer med søppelinnsamling, uansett hva fancy samlerordning du bruker.

På det tidspunktet begynner det å se attraktivt å flytte tilbake til et språk som C ++. Som et eksempel har Scylla, en C ++ reimplementering av Apache Cassandra, 10 ganger gjennomstrømningen av Cassandra uten at noen av GC-pausene som Cassandra er beryktet for ved store distribusjoner. Jeg er ganske sikker på at vi snart vil se Herons tilnærming spre seg til andre rammer. Dette kan bli hjulpet av Project Panamas forsøk på å forbedre grensesnittet mellom Java og andre språk.

Gitt at Heron krever færre ressurser og gir mer gjennomstrømning og mindre ventetid enn Apache Storm, bør du flytte alle topologiene dine til Heron akkurat nå, ja? Vel kanskje. Heron er for tiden knyttet til Mesos, så hvis du ikke har eksisterende Mesos-infrastruktur, må du også sette opp det, noe som ikke er et lite selskap. Også, hvis du bruker Storms DRPC-funksjoner, blir de utfaset i Heron.

På plussiden har Heron kjørt alle Twitters behandlingsbehov i produksjon i mer enn et år, så den skal kunne håndtere alt du kan kaste på det. I tillegg påpeker Twitter at Heron brukes i Microsoft og andre Fortune 500-selskaper, slik at du kan være relativt trygg på at den kommer til å holde seg.

På den annen side har ikke Storm stått stille. Apache Storm-teamet kan krangle med Twitters beskrivelse av Heron som "neste generasjon av Apache Storm." Mens Twitter jobbet med Heron nådde Apache Storm 1.0 - som inkluderer støtte for mottrykk, forbedrede feilsøkings- og profileringsalternativer, en 60 prosent reduksjon i ventetid og opp til en 16-gangs hastighetsforbedring.

I tillegg legger Storm 1.0 til pacemaker, en demon for avlasting av hjerterytmetrafikk fra ZooKeeper, og frigjør større topologier fra den beryktede ZooKeeper-flaskehalsen. Herons hastighetsforbedringer måles fra Storm 0.8.x-koden den avviker fra, ikke den nåværende versjonen; Hvis du allerede har migrert til Storm 1.0, ser du kanskje ikke mye mer forbedring i forhold til dine nåværende Storm-topologier, og du kan komme til å være uforenlig mellom implementeringen av nye funksjoner som mottrykkstøtte mellom Storm og Heron.

Alt i alt tror jeg ikke at Heron sannsynligvis vil forårsake mye buk i opptaket av databehandlingsrammer som Apache Spark, Apache Flink eller Apache Beam. Deres høyere nivå abstraksjoner og APIer gir en mye mer utviklervennlig opplevelse enn Storm / Trident APIer på lavere nivå. Imidlertid tror jeg blandingen av JVM-kode med ikke-JVM-moduler for de kritiske banene kommer til å bli en mer populær tilnærming fremover, og i dette aspektet viser Heron oss all retningen vi skal reise i måneder og år å komme.

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