Lani je Twitter izpustil dve bombi. Prvič, Apache Storm ne bi več uporabljal v proizvodnji. Drugič, zamenjal ga je z domačim sistemom za obdelavo podatkov, Heron.
Kljub temu, da je objavil članek, v katerem je podrobno opisana Heronova arhitektura, je Twitterjeva alternativa Stormu ostala skrita v podatkovnih centrih Twitterja. Vse se je spremenilo prejšnji teden, ko je Twitter Heron izdal pod odprtokodno licenco. Kaj je torej Heron in kje se v svetu obdelave podatkov obsežno uvršča?
Heron je usmerjevalnik za obdelavo podatkov acikličnega grafa (DAG), ki je trenutno še en vnos na zelo obljudenem polju. Toda Heron ni "pogled, tudi jaz!" rešitev ali poskus pretvorbe motorjev DAG v enakovreden FizzBuzz za velike podatke.
Heron je zrasel iz resničnih skrbi, ki jih je imel Twitter zaradi velike uporabe topologij Storm. Sem so spadale težave s profiliranjem in sklepanjem o storilcih Storma, če so lestvice prilagojene na ravni podatkov in na ravni topologije, statična narava dodeljevanja virov v primerjavi s sistemom, ki deluje na Mesosu ali YARN, pomanjkanje podpornega pritiska in drugo.
Čeprav bi Twitter lahko sprejel Apache Spark ali Apache Flink, bi to vključevalo prepisovanje celotne obstoječe kode Twitterja. (Ne pozabite, Twitter je storm uporabljal Storm dlje kot kdorkoli drug, pri čemer je BackType, ustvarjalec Storma, pridobil že leta 2011, preden je bil odprtokoden.) Namesto tega je Twitter uporabil drugačen pristop: nov okvir za obdelavo tokov z Storm združljivim API .
Na tej točki našega sprehoda po novem ogrodju bi si navadno ogledal nekaj primerov, da bi vam pokazal, kakšno je kodiranje v ogrodju, toda s Heronom je malo smisla - vijake in komplete Storm pišete popolnoma enako bi z Storm. Vse, kar morate storiti, da zaženete kodo Storm na Heron, je dodati ta razdelek v odvisnosti pom.xml:
com.twitter.heron
čaplja-api
PREGLED
sestavi
com.twitter.heron
čaplja-nevihta
PREGLED
sestavi
Nato odstranite odvisnosti od nevihtne kode in vtičnika clojure. Znova prevedite in vaša koda se bo izvajala na Heron brez dodatnih sprememb. Preprosto! (Večinoma vseeno, vendar se bomo k temu še vrnili.)
Trenutna Heronova izvedba deluje nad Apache Mesos, pri čemer uporablja Apache Aurora, Mesosov okvir za razporejanje, ki ga je razvil Twitter (presenečenje!). Od preklopa vseh svojih topologij Storm na Heron je Twitter uspel za trikrat zmanjšati strojne vire, namenjene topologijam, hkrati pa povečati pretočnost in zmanjšati zakasnitev pri obdelavi - ni slabo.
Morda je eden najbolj zanimivih vidikov Herona ta, da bo koda zanj napisana v Javi (ali Scali), komponente spletnega uporabniškega vmesnika pa v Pythonu, kritičnih delih ogrodja, kodi, ki upravlja topologije. in omrežne komunikacije sploh niso napisane v jeziku JVM.
V resnici Herona boste našli kodo v jeziku, ki ga morda ne pričakujete: C ++. Mislim, da je to vidik sveta velikih podatkov, ki ga bomo v prihodnjih letih še videli.
Vzdrževalci Apache Storm so odstranili številne elemente izvirne kode Clojure v korist ponovnega izvajanja Jave, projekt Apache Spark pa trenutno sproti ustvarja kodo Java, da pospeši obdelavo podatkovnega okvira. Toda oba sta še vedno vezana na JVM - in JVM ima težave v obsegu. Ne razumite me narobe, JVM je neverjetna stvaritev, ki je 20 let prestala preizkušnjo časa, toda pri zagonu na strojih z ogromno RAM-a in obdelavi ogromnih količin podatkov se pojavijo težave z zbiranjem smeti, ne glede na to, kaj modna zbiralna shema, ki jo uporabljate.
Na tej točki se zdi vrnitev v jezik, kot je C ++, privlačna. Kot primer je Scylla, ponovna izvedba Apache Cassandre s C ++, desetkrat večja od zmogljivosti Cassandre, pri čemer nobena od GC-pavz ni znana po Cassandri pri velikih postavitvah. Prepričan sem, da bomo Heronov pristop kmalu razširili tudi na druge okvire. K temu lahko pomaga poskus projekta Panama, da izboljša vmesnik med Javo in drugimi jeziki.
Glede na to, da Heron zahteva manj sredstev in zagotavlja večjo prepustnost in manj zakasnitev kot Apache Storm, bi morali vse svoje topologije zdaj premakniti na Heron, kajne? No, mogoče. Heron je trenutno povezan z Mesosom, tako da, če nimate obstoječe infrastrukture Mesos, boste morali to nastaviti tudi, kar ni majhno podjetje. Če uporabljate Storm-ove funkcije DRPC, so v Heron zastarele.
Pozitivna stran je, da Heron že več kot eno leto izvaja vse potrebe po obdelavi Twittera v proizvodnji, zato bi moral biti sposoben obvladati vse, kar lahko v to vržete. Poleg tega Twitter poudarja, da se Heron uporablja v Microsoftu in drugih podjetjih Fortune 500, zato ste lahko razmeroma prepričani, da se bo ohranil.
Po drugi strani pa Storm ne stoji mirno. Skupina Apache Storm bi se lahko prepirala s Twitterjevim opisom Heron kot "naslednje generacije Apache Storm." Medtem ko je Twitter delal na Heron, je Apache Storm dosegel 1,0 - kar vključuje podporo za povratni pritisk, izboljšane možnosti odpravljanja napak in profiliranje, 60-odstotno zmanjšanje zakasnitve in do 16-kratno izboljšanje hitrosti.
Poleg tega Storm 1.0 dodaja srčni spodbujevalnik, demon za razbremenitev srčnega utripa iz ZooKeeperja, ki večje topologije osvobaja zloglasnega ozkega grla ZooKeeper. Izboljšave Heronove hitrosti se merijo glede na kodo Storm 0.8.x, od katere se je oddaljil, in ne trenutna različica; če ste že prešli na Storm 1.0, morda ne boste opazili veliko večjih izboljšav glede na svoje trenutne topologije Storm in lahko naletite na nezdružljivosti med izvajanjem novih funkcij, kot je podpora za povratni pritisk med Storm in Heron.
Na splošno ne verjamem, da bo Heron verjetno povzročil veliko težav pri sprejemanju okvirov za obdelavo podatkov, kot so Apache Spark, Apache Flink ali Apache Beam. Njihove abstrakcije in API-ji na višji ravni nudijo veliko bolj prijazno izkušnjo za razvijalce kot API-ji Storm / Trident na nižji ravni. Verjamem pa, da bo mešanica kode JVM z moduli, ki niso JVM za kritične poti, bolj priljubljen pristop za naprej in v tem pogledu nam Heron pokaže v katero smer bomo potovali v mesecih in letih priti.
