Programmering

Havde det med Apache Storm? Hejre svømmer til undsætning

Sidste år kastede Twitter to bomber. For det første ville det ikke længere bruge Apache Storm i produktionen. For det andet havde det erstattet det med et hjemmebrugt databehandlingssystem, Heron.

På trods af udgivelsen af ​​et papir, der beskriver Herons arkitektur, forblev Twitters alternativ til Storm skjult i Twitters datacentre. Det hele ændrede sig i sidste uge, da Twitter frigav Heron under en open source-licens. Så hvad er Heron, og hvor passer det ind i databehandlingsverdenen i stor skala?

En styret acyklisk graf (DAG) databehandlingsmotor, Heron er en anden post i et meget overfyldt felt lige nu. Men Heron er ikke et "kig, også jeg!" løsning eller et forsøg på at gøre DAG-motorer til big data svarende til FizzBuzz.

Heron voksede ud af reelle bekymringer, som Twitter havde med sin store implementering af Storm-topologier. Disse omfattede vanskeligheder med profilering og ræsonnement om Storm-arbejdere, når de skaleres på dataniveau og på et topologiniveau, den statiske karakter af ressourcetildeling i sammenligning med et system, der kører på Mesos eller YARN, mangel på understøttelse af modtryk og mere.

Selvom Twitter kunne have vedtaget Apache Spark eller Apache Flink, ville det have involveret omskrivning af al Twitters eksisterende kode. (Glem ikke, Twitter har brugt Storm længere end nogen anden, idet han erhvervede BackType, Storms skaber, tilbage i 2011, før den var open source.) I stedet tog Twitter en anden tilgang: en ny streambehandlingsramme med en Storm-kompatibel API .

På dette tidspunkt i vores gåtur gennem en ny ramme vil jeg normalt gennemgå nogle eksempler for at vise dig, hvordan kodning i rammen føles, men der er ikke meget mening med Heron - du skriver Stormbolte og tuples på nøjagtig samme måde som du ville med Storm. Alt hvad du skal gøre for at køre din Storm-kode på Heron er at tilføje dette afsnit til din pom.xml's afhængighed:

com.twitter.heron

hejre-api

SNAPSHOT

udarbejde

com.twitter.heron

hegre-storm

SNAPSHOT

udarbejde

Derefter fjerner du dine storm-kode og clojure-plugin afhængigheder. Kompilér igen, og din kode kører på Heron uden yderligere ændringer nødvendige. Enkel! (For det meste under alle omstændigheder, men vi kommer tilbage til det.)

Operativt kører Herons nuværende implementering oven på Apache Mesos ved hjælp af Apache Aurora, Mesos planlægningsramme udviklet af Twitter (overraskelse!). Da Twitter skiftede alle sine Storm-topologier til Heron, formåede det at reducere hardware-ressourcer dedikeret til topologierne med en faktor på tre og samtidig øge kapaciteten og reducere latenstiden i behandlingen - ikke dårligt.

Et af de mest interessante aspekter ved Heron er måske, at mens kode til det vil blive skrevet i Java (eller Scala), og de webbaserede UI-komponenter er skrevet i Python, de kritiske dele af rammen, koden, der styrer topologierne og netværkskommunikation er slet ikke skrevet på et JVM-sprog.

I hjertet af Heron finder du faktisk kode på et sprog, som du måske ikke forventer: C ++. Jeg tror, ​​dette er et aspekt af big data-verdenen, som vi vil se mere af i de kommende år.

Apache Storm-vedligeholdere har fjernet mange elementer i sin oprindelige Clojure-kode til fordel for Java-reimplementeringer, og Apache Spark-projektet genererer i øjeblikket Java-kode on-the-fly for at fremskynde sin DataFrame-behandling. Men begge er stadig bundet til JVM - og JVM har store problemer. Gør mig ikke forkert, JVM er en fantastisk skabelse, der har stået tidstesten i 20 år, men når du kører på maskiner med enorme mængder RAM og behandler enorme mængder data, opstår der problemer med affaldsindsamling, uanset hvad fancy samler ordning du bruger.

På hvilket tidspunkt flytter tilbage til et sprog som C ++ begynder at se tiltalende ud. Som et eksempel har Scylla, en C ++ - genimplementering af Apache Cassandra, 10 gange gennemstrømningen af ​​Cassandra uden nogen af ​​GC-pauser, som Cassandra er berygtet for ved store implementeringer. Jeg er ret sikker på, at vi snart vil se Herons tilgang sprede sig til andre rammer. Dette kan blive hjulpet af Project Panamas forsøg på at forbedre grænsefladen mellem Java og andre sprog.

I betragtning af at Heron kræver færre ressourcer og giver mere gennemstrømning og mindre latenstid end Apache Storm, skal du flytte alle dine topologier til Heron lige nu, ja? Tja, måske. Heron er i øjeblikket bundet til Mesos, så hvis du ikke har eksisterende Mesos-infrastruktur, skal du også konfigurere det, hvilket ikke er en lille virksomhed. Også, hvis du bruger Storm's DRPC-funktioner, er de udfaset i Heron.

På plussiden har Heron kørt alle Twitters behandlingsbehov i produktion i mere end et år, så det skal være i stand til at håndtere alt, hvad du kan kaste på det. Plus påpeger Twitter, at Heron bruges i Microsoft og andre Fortune 500-virksomheder, så du kan være relativt sikker på, at den holder fast.

På den anden side har Storm ikke stå stille. Apache Storm-teamet kan kvæle med Twitters beskrivelse af Heron som den "næste generation af Apache Storm." Mens Twitter arbejdede på Heron, nåede Apache Storm 1.0 - hvilket inkluderer understøttelse af modtryk, forbedrede fejlretnings- og profileringsindstillinger, et fald på 60 procent i latenstid og op til en 16 gange hurtigere forbedring.

Derudover tilføjer Storm 1.0 pacemaker, en dæmon til aflæsning af hjerterytmetrafik fra ZooKeeper, hvilket frigør større topologier fra den berygtede ZooKeeper-flaskehals. Herons hastighedsforbedringer måles fra Storm 0.8.x-koden, den afveg fra, ikke den nuværende version; hvis du allerede er overflyttet til Storm 1.0, ser du muligvis ikke meget mere forbedring i forhold til dine nuværende Storm-topologier, og du kan komme ud for uforenelighed mellem implementeringen af ​​nye funktioner som modtryksstøtte mellem Storm og Heron.

Alt i alt tror jeg ikke, at Heron sandsynligvis vil forårsage en stor buk i optagelsen af ​​databehandlingsrammer som Apache Spark, Apache Flink eller Apache Beam. Deres abstraktioner og API'er på højere niveau giver en meget mere udviklervenlig oplevelse end Storm / Trident API'erne på lavere niveau. Jeg tror dog, at blandingen af ​​JVM-kode med ikke-JVM-moduler til de kritiske stier vil være en mere populær tilgang fremadrettet, og i dette aspekt viser Heron os hele den retning, vi vil rejse i måneder og år at komme.