Praėjusiais metais „Twitter“ numetė du bombas. Pirma, jis daugiau nenaudos „Apache Storm“. Antra, ji pakeitė ją namuose sukurta duomenų apdorojimo sistema „Heron“.
Nepaisant to, kad išleistas dokumentas, kuriame išsamiai aprašyta Herono architektūra, „Twitter“ alternatyva „Storm“ išliko paslėpta „Twitter“ duomenų centruose. Viskas pasikeitė praėjusią savaitę, kai „Twitter“ išleido „Heron“ pagal atvirojo kodo licenciją. Taigi, kas yra „Heron“ ir kur jis telpa masto duomenų apdorojimo pasaulyje?
„Heron“ yra nukreiptas aciklinio grafiko (DAG) duomenų apdorojimo variklis - dar vienas įrašas labai perkrautoje srityje. Bet Heronas nėra „žvilgsnis, aš irgi!“ sprendimas arba bandymas paversti DAG variklius didžiųjų duomenų atitikmeniu „FizzBuzz“.
Heronas išaugo iš tikro „Twitter“ rūpesčio dėl didelio „Storm“ topologijų panaudojimo. Tai apėmė sunkumus, susijusius su profilio sudarymu ir samprotavimais apie „Storm“ darbuotojus, kai jie skirstomi duomenų lygmeniu ir topologijos lygmeniu, statinį išteklių paskirstymo pobūdį, palyginti su sistema, veikiančia „Mesos“ arba „YARN“, trūksta priešpriešinio palaikymo ir kt.
Nors „Twitter“ galėjo priimti „Apache Spark“ arba „Apache Flink“, tai būtų reikėję perrašyti visą esamą „Twitter“ kodą. (Nepamirškite, kad „Twitter“ „Storm“ naudojo ilgiau nei bet kas kitas, įsigijęs „Storm“ kūrėją „BackType“ dar 2011 m., Kol nebuvo atviro kodo.) Vietoj to, „Twitter“ pasirinko kitokį požiūrį: naują srauto apdorojimo sistemą su „Storm“ suderinama API .
Šiuo metu, eidamas per naują sistemą, aš paprastai apžvelgsiu keletą pavyzdžių, norėdamas parodyti, koks yra kodavimas sistemoje, tačiau Heronui nėra prasmės - jūs rašote „Storm“ varžtus ir rinkinius lygiai taip pat, kaip ir norėtum su Audra. Viskas, ką jums reikia padaryti norint paleisti „Storm“ kodą „Heron“, yra pridėti šį skyrių prie savo pom.xml priklausomybių:
com.twitter.heron
garnis-api
SNAPSHOT
sudaryti
com.twitter.heron
garnys-audra
SNAPSHOT
sudaryti
Tada pašalinsite savo audros kodo ir „clojure-plugin“ priklausomybes. Perkompiliuokite ir jūsų kodas bus paleistas „Heron“ be jokių papildomų pakeitimų. Paprasta! (Dažniausiai bet kokiu atveju, bet prie to dar grįšime.)
Operatyviai dabartinis Herono diegimas veikia ant „Apache Mesos“, naudojant „Twitter“ sukurtą „Mesos“ planavimo sistemą „Apache Aurora“ (nuostaba!). Perkėlęs visas savo „Storm“ topologijas į „Heron“, „Twitter“ sugebėjo trigubai sumažinti aparatūros išteklius, skirtus topologijoms, padidindamas pralaidumą ir sumažindamas apdorojimo vėlavimą.
Galbūt vienas įdomiausių aspektų apie „Heron“ yra tas, kad nors jo kodas bus parašytas „Java“ (arba „Scala“), o žiniatinklio vartotojo sąsajos komponentai parašyti „Python“, kritinės sistemos dalys, kodas, valdantis topologijas o tinklo ryšiai visai nerašomi JVM kalba.
Iš tikrųjų Herono širdyje rasite kodą kalba, kurios galbūt nesitikėtumėte: C ++. Manau, kad tai yra didžiųjų duomenų pasaulio aspektas, kurį pamatysime daugiau ateinančiais metais.
„Apache Storm“ prižiūrėtojai pašalino daugelį originalaus „Clojure“ kodo elementų naudodamiesi „Java“ atnaujinimu, o „Apache Spark“ projektas šiuo metu generuoja „Java“ kodą, kad pagreitintų „DataFrame“ apdorojimą. Tačiau abu jie vis dar yra susieti su JVM - ir JVM turi masto problemų. Nesupraskite manęs neteisingai, JVM yra nuostabi kūryba, atlaikiusi laiko išbandymą 20 metų, tačiau dirbant mašinose, turinčiose didžiulį RAM kiekį ir apdorojant milžinišką kiekį duomenų, iškyla šiukšlių surinkimo problemų, kad ir kas būtų išgalvota kolekcionieriaus schema, kurią naudojate.
Tuo metu grįžimas prie tokios kalbos kaip C ++ pradeda atrodyti patraukliai. Pavyzdžiui, „Scylla“, „Apache Cassandra“ atnaujinimas C ++, 10 kartų viršija „Cassandra“ pralaidumą, nė viena iš GC pauzių, kuriomis „Cassandra“ garsėja didelių dislokacijų metu. Esu gana įsitikinęs, kad netrukus pamatysime Herono požiūrį į kitas sistemas. Tam gali padėti „Project Panama“ bandymas pagerinti sąsają tarp „Java“ ir kitų kalbų.
Atsižvelgiant į tai, kad „Heron“ reikalauja mažiau išteklių, suteikia daugiau pralaidumo ir mažiau vėlavimo nei „Apache Storm“, dabar turėtumėte perkelti visas savo topologijas į „Heron“, taip? Galbūt. Heronas šiuo metu yra susietas su „Mesos“, taigi, jei neturite esamos „Mesos“ infrastruktūros, turėsite ją taip pat nustatyti, o tai nėra maža įmonė. Be to, jei naudojatės „Storm“ DRPC funkcijomis, jos „Heron“ nebenaudoja.
Iš pliuso pusės, Heronas jau daugiau nei metus tenkina visus „Twitter“ apdorojimo poreikius, todėl turėtų sugebėti susitvarkyti su viskuo, ką galite mesti. Be to, „Twitter“ pabrėžia, kad „Heron“ yra naudojamas „Microsoft“ ir kitose „Fortune 500“ kompanijose, todėl galite būti gana tikri, kad jis laikysis.
Kita vertus, Audra nestovi vietoje. „Apache Storm“ komanda gali aptarinėti „Twitter“ aprašytą Heroną kaip „naujos kartos„ Apache Storm “. Kol „Twitter“ dirbo su „Heron“, „Apache Storm“ pasiekė 1,0 - tai apima palaikomąjį spaudimą, patobulintas derinimo ir profiliavimo parinktis, 60 procentų sumažėjusį vėlavimą ir iki 16 kartų didesnį greitį.
Be to, „Storm 1.0“ prideda širdies stimuliatorių, deimoną, skirtą iškrauti širdies ritmo srautą iš „ZooKeeper“, išlaisvindamas didesnes topologijas nuo liūdnai pagarsėjusio „ZooKeeper“ butelio. Herono greičio pagerėjimas matuojamas pagal „Storm 0.8.x“ kodą, nuo kurio jis skyrėsi, o ne dabartinę versiją; jei jau perėjote prie „Storm 1.0“, galite nematyti daug daugiau patobulinimų, palyginti su dabartinėmis „Storm“ topologijomis, ir gali kilti nesuderinamumų tarp naujų funkcijų, pvz., „Storm“ ir „Heron“ palaikymo, palaikymo.
Apskritai, aš netikiu, kad Heronas greičiausiai sukels daug įtakos duomenų apdorojimo sistemoms, tokioms kaip „Apache Spark“, „Apache Flink“ ar „Apache Beam“. Jų aukštesnio lygio abstrakcijos ir API suteikia kur kas palankesnę kūrėjams patirtį nei žemesnio lygio „Storm / Trident“ API. Tačiau manau, kad JVM kodo ir ne JVM modulių derinimas kritiniams keliams bus populiaresnis požiūris į priekį, ir šiuo aspektu Heronas mums parodo visą kryptį, kuria keliausime mėnesiais ir metais ateiti.
