Pagājušajā gadā čivināt nometa divas bumbas. Pirmkārt, tā vairs neizmantotu Apache Storm ražošanā. Otrkārt, tas to bija aizstājis ar pašmāju datu apstrādes sistēmu Heron.
Neskatoties uz papīra izdošanu, kurā sīki aprakstīta Herona arhitektūra, Twitter alternatīva Storm palika slēpta Twitter datu centros. Tas viss mainījās pagājušajā nedēļā, kad čivināt atbrīvoja Heronu ar atvērtā pirmkoda licenci. Kas tad ir Herons un kur tas ietilpst apjomīgas datu apstrādes pasaulē?
Orientēts aciklisko grafu (DAG) datu apstrādes dzinējs Herons šobrīd ir vēl viens ieraksts ļoti pārpildītā jomā. Bet Herons nav "izskats, arī es!" risinājums vai mēģinājums pārvērst DAG dzinējus par lielo datu ekvivalentu FizzBuzz.
Gārnis izauga no reālām bažām, ko Twitter sagādāja, plaši izmantojot vētras topoloģijas. Tās ietvēra grūtības ar Storm darbinieku profilēšanu un pamatošanu, mērogojot datu līmenī un topoloģijas līmenī, resursu sadales statisko raksturu salīdzinājumā ar sistēmu, kas darbojas ar Mesos vai YARN, pretspiediena atbalsta trūkumu un daudz ko citu.
Lai gan Twitter varēja pieņemt Apache Spark vai Apache Flink, tas būtu saistīts ar visa esošā Twitter koda pārrakstīšanu. (Neaizmirstiet, ka Twitter ir lietojis Storm ilgāk nekā jebkurš cits, iegādājoties Storm veidotāju BackType jau 2011. gadā, pirms tas bija atvērts.) Tā vietā Twitter izmantoja citu pieeju: jaunu straumes apstrādes sistēmu ar Storm savietojamu API .
Šajā mūsu jaunās ietvara posmā es parasti izietu dažus piemērus, lai parādītu, kā jūtas kodēšana sistēmā, taču Heronam nav lielas jēgas - jūs rakstāt Storm skrūves un vienumus tieši tāpat kā jūs to darītu ar Storm. Viss, kas jums jādara, lai palaistu Storm kodu Heron, ir pievienot šo sadaļu jūsu pom.xml atkarībām:
com.twitter.heron
gārnis-api
SNAPSHOT
sastādīt
com.twitter.heron
gārnis-vētra
SNAPSHOT
sastādīt
Tad jūs noņemat savas vētra koda un clojure-plugin atkarības. Pārkompilējiet, un jūsu kods darbosies Heron bez papildu izmaiņām. Vienkārši! (Pārsvarā jebkurā gadījumā, bet mēs pie tā atgriezīsimies.)
Operacionāli Herona pašreizējā ieviešana darbojas virs Apache Mesos, izmantojot Apache Aurora, Mesos plānošanas sistēmu, ko izstrādājis Twitter (pārsteigums!). Kopš visu savu Storm topoloģiju nomaiņas uz Heron, Twitter izdevās trīs reizes samazināt aparatūras resursus, kas veltīti topoloģijām, vienlaikus palielinot caurlaidspēju un samazinot apstrādes latentumu - tas nav slikti.
Varbūt viens no interesantākajiem Herona aspektiem ir tas, ka, kamēr tā kods tiks rakstīts Java (vai Scala) valodā, bet tīmekļa lietotāja interfeisa komponenti tiek rakstīti Python, ietvara kritiskās daļas ir kods, kas pārvalda topoloģijas. un tīkla sakari vispār netiek rakstīti JVM valodā.
Patiešām, Herona centrā jūs atradīsit kodu valodā, kuru, iespējams, negaidīsit: C ++. Es domāju, ka tas ir lielo datu pasaules aspekts, ko mēs nākamajos gados redzēsim vairāk.
Apache Storm uzturētāji ir noņēmuši daudzus tā sākotnējā Clojure koda elementus par labu Java atjaunošanai, un Apache Spark projekts pašlaik lidojuma laikā ģenerē Java kodu, lai paātrinātu tā DataFrame apstrādi. Bet abi joprojām ir saistīti ar JVM - un JVM ir plašas problēmas. Nepārprotiet, JVM ir pārsteidzošs radījums, kas izturējis laika pārbaudi 20 gadus, taču, darbojoties mašīnās ar milzīgu RAM apjomu un apstrādājot milzīgu datu daudzumu, rodas problēmas ar atkritumu savākšanu neatkarīgi no tā iedomātā kolekcionāra shēma, kuru izmantojat.
Tajā brīdī pāreja atpakaļ uz valodu, piemēram, C ++, sāk izskatīties pievilcīga. Piemēram, Scylla, Apache Cassandra C ++ atkārtota ieviešana, ir 10 reizes lielāka par Cassandra caurlaidspēju, un neviena no GC pauzēm nav tā, ko Kasandra ir pazīstama lielās izvietošanas reizēs. Esmu diezgan pārliecināts, ka drīz redzēsim, kā Herona pieeja izplatīsies citās sistēmās. Tam var palīdzēt Project Panama mēģinājums uzlabot saskarni starp Java un citām valodām.
Ņemot vērā to, ka Heron prasa mazāk resursu, nodrošina lielāku caurlaidspēju un mazāku latentumu nekā Apache Storm, jums visas savas topoloģijas jāpārvieto uz Heronu tieši tagad, jā? Nu varbūt. Herons pašlaik ir saistīts ar Mesos, tāpēc, ja jums nav esošas Mesos infrastruktūras, jums tas būs jāiestata arī, kas nav mazs uzņēmums. Turklāt, ja jūs izmantojat Storm DRPC funkcijas, tās Heron ir novecojušas.
Pozitīvi ir tas, ka Herons jau vairāk nekā gadu ražošanā izpilda visas čivināt apstrādes vajadzības, tāpēc tam vajadzētu būt spējīgam rīkoties ar visu, ko vien var iemest. Plus, čivināt norāda, ka Herons tiek izmantots Microsoft un citos Fortune 500 uzņēmumos, tāpēc jūs varat būt relatīvi pārliecināts, ka tas pieturēsies.
No otras puses, Storm nav stāvējis uz vietas. Apache Storm komanda varētu čivināt ar Twitter aprakstīto Heronu kā "Apache Storm nākamo paaudzi". Kamēr Twitter strādāja pie Heron, Apache Storm sasniedza 1.0 - kas ietver atbalstu pretspiedienam, uzlabotas atkļūdošanas un profilēšanas iespējas, latentuma samazinājumu par 60 procentiem un ātruma uzlabojumu līdz 16 reizēm.
Turklāt Storm 1.0 papildina elektrokardiostimulatoru - dēmonu sirdsdarbības trafika izkraušanai no ZooKeeper, atbrīvojot lielākas topoloģijas no bēdīgi slavenā ZooKeeper sastrēguma. Herona ātruma uzlabojumus mēra no Storm 0.8.x koda, no kura tas novirzījās, nevis no pašreizējās versijas; ja esat jau pārcēlies uz Storm 1.0, iespējams, ka neredzēsit daudz vairāk uzlabojumu salīdzinājumā ar pašreizējām Storm topoloģijām, un var rasties nesaderība starp tādu jaunu funkciju ieviešanu kā pretspiediena atbalsts starp Storm un Heron.
Kopumā es neticu, ka Herons, visticamāk, radīs lielu iespaidu tādu datu apstrādes ietvaru pārņemšanā kā Apache Spark, Apache Flink vai Apache Beam. Viņu augstākā līmeņa abstrakcijas un API nodrošina daudz attīstītājam draudzīgāku pieredzi nekā zemākā līmeņa Storm / Trident API. Tomēr es uzskatu, ka JVM koda apvienošana ar moduļiem, kas nav JVM, kritiskajiem ceļiem nākotnē būs populārāka pieeja, un šajā aspektā Herons mums parāda visu virzienu, pa kuru mēs ceļosim mēnešos un gados nākt.
