Viime vuonna Twitter pudotti kaksi pommia. Ensinnäkin se ei enää käytä Apache Stormia tuotannossa. Toiseksi se oli korvannut sen kotitietojärjestelmällä, Heron.
Huolimatta Heronin arkkitehtuuria kuvaavan paperin julkaisemisesta, Twitterin vaihtoehto Stormille pysyi piilossa Twitterin palvelinkeskuksissa. Kaikki muuttui viime viikolla, kun Twitter julkaisi Heronin avoimen lähdekoodin lisenssillä. Joten mikä on Heron, ja missä se mahtuu mittakaavan tietojenkäsittelymaailmaan?
Suunnatun asyklisen kuvaajan (DAG) tietojenkäsittelymoottori Heron on toinen merkintä tällä hetkellä hyvin tungosta kentästä. Mutta Heron ei ole "katso, minäkin!" ratkaisu tai yritys muuttaa DAG-moottorit big data -vastineeksi FizzBuzzille.
Heron kasvoi todellisista huolista, joita Twitterillä oli laajalla Storm-topologioiden käyttöönotolla. Näihin sisältyivät vaikeudet profiloida ja perustella Storm-työntekijöitä, kun niitä skaalataan tietotasolla ja topologiatasolla, resurssien allokoinnin staattinen luonne verrattuna Mesos- tai YARN-järjestelmään, vastapainetuen puute ja paljon muuta.
Vaikka Twitter olisi voinut ottaa käyttöön Apache Sparkin tai Apache Flinkin, se olisi edellyttänyt kaiken Twitterin nykyisen koodin uudelleenkirjoittamista. (Älä unohda, että Twitter on käyttänyt Stormia kauemmin kuin kukaan muu, hankkinut Stormin luojan BackTypen takaisin vuonna 2011, ennen kuin se oli avoimen lähdekoodin.) Sen sijaan Twitter otti toisenlaisen lähestymistavan: uusi suoratoistonkehys Storm-yhteensopivalla API: lla .
Tässä uudessa kehyksessä käynneissä tässä vaiheessa käyn tavallisesti läpi joitain esimerkkejä osoittaakseni, miltä koodaus puitteissa tuntuu, mutta Heronilla ei ole juurikaan järkeä - kirjoitat Storm-pultteja ja sarakkeita täsmälleen samalla tavalla kuin voisit Stormin kanssa. Storm-koodisi suorittamiseen Heronissa sinun tarvitsee vain lisätä tämä osa pom.xml-tiedostosi riippuvuuksiin:
com.twitter.heron
heron-api
SNAPSHOT
koota
com.twitter.heron
haikara-myrsky
SNAPSHOT
koota
Sitten poistat myrskykoodi- ja clojure-plugin-riippuvuutesi. Käännä uudelleen, ja koodisi toimii Heronissa ilman muita muutoksia. Yksinkertainen! (Enimmäkseen joka tapauksessa, mutta palaamme siihen.)
Operatiivisesti Heronin nykyinen toteutus toimii Apache Mesosin päällä käyttämällä Twitterin kehittämää Apache Auroraa, Mesosin aikataulutuskehystä (yllätys!). Sen jälkeen kun kaikki Storm-topologiat vaihdettiin Heroniin, Twitter onnistui vähentämään topologioille omistettuja laitteistoresursseja kolminkertaiseksi, samalla lisäämällä läpimenoa ja vähentämällä käsittelyn viiveitä - ei huono.
Ehkä yksi mielenkiintoisimmista näkökohdista Heronissa on, että vaikka sen koodi kirjoitetaan Java (tai Scala), ja web-pohjaiset käyttöliittymäkomponentit kirjoitetaan Pythonissa, kehyksen kriittiset osat, koodi, joka hallitsee topologioita ja verkkoviestintää ei ole kirjoitettu lainkaan JVM-kielellä.
Heronin sydämessä on todellakin koodi kielellä, jota et ehkä odota: C ++. Mielestäni tämä on osa big data-maailmaa, josta näemme enemmän tulevina vuosina.
Apache Stormin ylläpitäjät ovat poistaneet monia alkuperäisen Clojure-koodin elementtejä Java-uudistusten hyväksi, ja Apache Spark -projekti tuottaa tällä hetkellä Java-koodia lennon aikana nopeuttaakseen DataFrame-prosessointia. Mutta molemmat ovat edelleen sidoksissa JVM: ään - ja JVM: llä on suuria ongelmia. Älä ymmärrä minua väärin, että JVM on hämmästyttävä luomus, joka on kestänyt ajan testin 20 vuoden ajan, mutta kun sitä käytetään koneissa, joissa on valtava määrä RAM-muistia ja käsiteltäessä valtavia määriä tietoja, syntyy roskien keräysongelmia, ei väliä mitä hieno keräilijärjestelmä, jota käytät.
Siinä vaiheessa siirtyminen takaisin kielelle, kuten C ++, alkaa näyttää houkuttelevalta. Esimerkiksi Scyllalla, Apache Cassandran C ++ -uudistuksella, on 10-kertainen Cassandran läpäisykyky ilman mitään GC-taukoja, joista Cassandra on kuuluisa suurissa käyttöönotoissa. Olen melko varma, että Heronin lähestymistapa leviää pian muihin kehyksiin. Tätä voi auttaa Project Panaman yritys parantaa Java: n ja muiden kielten välistä käyttöliittymää.
Kun otetaan huomioon, että Heron vaatii vähemmän resursseja, tarjoaa enemmän läpäisykykyä ja vähemmän viivettä kuin Apache Storm, sinun pitäisi siirtää kaikki topologiat Heronille heti, kyllä? No ehkä. Heron on tällä hetkellä sidoksissa Mesosiin, joten jos sinulla ei ole Mesos-infrastruktuuria, sinun on myös perustettava se, mikä ei ole pieni yritys. Jos käytät Stormin DRPC-ominaisuuksia, ne ovat vanhentuneita Heronissa.
Plussapuolena on, että Heron on käyttänyt kaikkia Twitterin prosessointitarpeita tuotannossa yli vuoden ajan, joten sen pitäisi pystyä käsittelemään kaikkea mitä voit heittää siihen. Plus, Twitter huomauttaa, että Heronia käytetään Microsoftissa ja muissa Fortune 500 -yrityksissä, joten voit olla suhteellisen varma siitä, että se pysyy kiinni.
Toisaalta Storm ei ole seisonut paikallaan. Apache Storm -tiimi saattaa käydä läpi Twitterin kuvauksen Heronista "seuraavan sukupolven Apache Stormista". Samalla kun Twitter työskenteli Heronin parissa, Apache Storm saavutti 1,0: n, joka sisältää vastapaineen tuen, parannetut virheenkorjaus- ja profilointivaihtoehdot, viiveen 60 prosentin vähenemisen ja jopa 16-kertaisen nopeuden parannuksen.
Lisäksi Storm 1.0 lisää sydämentahdistimen, joka on syke-liikenteen purkamista varten ZooKeeper, vapauttamalla suuremmat topologiat surullisen ZooKeeper-pullonkaulasta. Heronin nopeuden parannukset mitataan Storm 0.8.x -koodista, josta se poikkesi, eikä nykyisestä versiosta; Jos olet jo siirtynyt Storm 1.0: een, et ehkä näe paljon enemmän parannuksia nykyisiin Storm-topologioihisi verrattuna, ja saatat törmätä yhteensopimattomuuteen uusien ominaisuuksien, kuten Stormin ja Heronin välisen vastapainetuen, toteuttamisen välillä.
Kaiken kaikkiaan en usko, että Heron todennäköisesti aiheuttaa paljon haittoja tietojenkäsittelykehysten, kuten Apache Sparkin, Apache Flinkin tai Apache Beamin, käyttöönotossa. Heidän korkeamman tason abstraktiot ja sovellusliittymät tarjoavat paljon kehittäjäystävällisemmän kokemuksen kuin alemman tason Storm / Trident-sovellusliittymät. Uskon kuitenkin, että JVM-koodin sekoitus muiden kuin JVM-moduulien kanssa kriittisille poluille tulee olemaan suositumpi lähestymistapa eteenpäin, ja tässä suhteessa Heron näyttää meille kaiken suunnan, johon kulkemme kuukausina ja vuosina tulla.
