Ideja par reāllaika biznesa inteliģenci ir bijusi jau kādu laiku (skatiet Wikipedia lapu par tēmu, kas sākta 2006. gadā). Bet, kamēr cilvēki par šo ideju runā jau daudzus gadus, es neesmu redzējis, ka daudzi uzņēmumi patiešām uztver šo redzējumu, vēl jo mazāk saprotot, kādus ieguvumus tas dod.
Vismaz daļa iemesla ir bijusi rīku trūkums BI un analīzes ieviešanai reāllaikā. Tradicionālās datu glabāšanas vides bija ļoti orientētas uz pakešdarbībām ar ārkārtīgi lielu latentumu, bija neticami dārgas vai abas.
Lai to mainītu, ir izveidojušās vairākas spēcīgas, viegli lietojamas atvērtā koda platformas. Divas no ievērojamākajām ir Apache Storm un Apache Spark, kas reāllaika apstrādes iespējas piedāvā daudz plašākam potenciālo lietotāju lokam. Abi ir Apache programmatūras fonda projekti, un, lai gan abi rīki nodrošina iespējas, kas pārklājas, katram no tiem ir atšķirīgas iezīmes un lomas.
Vētra: reāllaika apstrādes Hadoop
Storm, kas ir izplatīta notikumu straumes apstrādes aprēķinu sistēma, uzsāka savu darbību kā BackType, mārketinga izlūkošanas uzņēmuma, kuru Twitter nopirka 2011. gadā, Twitter drīz atklāja projekta avotu un ievietoja to GitHub, taču Storm galu galā pārcēlās uz Apache inkubatoru. un 2014. gada septembrī kļuva par Apache augstākā līmeņa projektu.
Vētru dažreiz dēvē par reāllaika apstrādes Hadoop. Storm dokumentācija, šķiet, piekrīt: "Storm ļauj viegli droši apstrādāt neierobežotas datu plūsmas, reāllaikā apstrādājot to, ko Hadoop darīja pakešapstrādei."
Lai sasniegtu šo mērķi, Storm ir paredzēts masīvai mērogojamībai, atbalsta kļūdu toleranci ar “ātras kļūmes, automātiskas restartēšanas” pieeju procesiem un nodrošina stingru garantiju, ka katrs kopums tiks apstrādāts. Storm pēc noklusējuma ziņojumiem garantē “vismaz vienu reizi”, taču piedāvā iespēju ieviest arī “tieši vienu reizi” apstrādi.
Storm galvenokārt ir rakstīts Clojure un ir paredzēts, lai atbalstītu vadu “iztekas” (domājiet par ievades plūsmām) un “skrūvēm” (apstrādes un izvades moduļiem) kopā kā virzītu aciklisku grafiku (DAG), ko sauc par topoloģiju. Storm topoloģijas darbojas kopās, un Storm plānotājs izplata darbu mezgliem ap klasteri, pamatojoties uz topoloģijas konfigurāciju.
Jūs varat domāt par topoloģijām, kas ir aptuveni līdzīgas MapReduce darbam Hadoop, izņemot to, ka, ņemot vērā, ka Storm koncentrējas uz reāllaika, plūsmā balstītu apstrādi, topoloģijas pēc noklusējuma darbojas uz visiem laikiem vai līdz brīdim, kad manuāli tiek pārtraukta. Kad topoloģija ir sākta, snīpi ievada datus sistēmā un nodod tos skrūvēm (kas savukārt var nodot datus nākamajām skrūvēm), kur tiek veikts galvenais skaitļošanas darbs. Apstrādes gaitā viena vai vairākas skrūves var ierakstīt datus datu bāzē vai failu sistēmā, nosūtīt ziņojumu citai ārējai sistēmai vai citādi padarīt aprēķina rezultātus pieejamus lietotājiem.
Viena no Storm ekosistēmas priekšrocībām ir bagātīgs pieejamo snīpu klāsts, kas specializēts datu saņemšanai no visu veidu avotiem. Lai gan jums, iespējams, būs jāraksta pielāgotas snīpi ļoti specializētām lietojumprogrammām, pastāv liela iespēja, ka jūs varat atrast esošu snīpi neticami lielam avotu klāstam - sākot no Twitter straumēšanas API līdz Apache Kafka līdz JMS brokeriem un beidzot ar visu, kas notiek starp tiem.
Adapteri pastāv, lai padarītu vienkāršu integrāciju ar HDFS failu sistēmām, tas nozīmē, ka Storm vajadzības gadījumā var viegli sadarboties ar Hadoop. Vēl viens Storm stiprums ir atbalsts daudzvalodu programmēšanai. Kaut arī pati Storm pamatā ir Clojure un darbojas ar JVM, snīpi un skrūves var rakstīt gandrīz jebkurā valodā, ieskaitot valodas, kas nav JVM, kas izmanto protokola priekšrocības saziņai starp komponentiem, izmantojot JSON, izmantojot stdin / stdout.
Īsāk sakot, Storm ir ļoti mērogojama, ātra, izturīga pret traucējumiem atklātā pirmkoda sistēma izplatītai skaitļošanai, īpašu uzmanību pievēršot straumes apstrādei. Storm izceļas ar notikumu apstrādi un inkrementālo aprēķinu, reāllaikā aprēķinot slīdošo metriku, izmantojot datu plūsmas. Lai gan Storm piedāvā arī primitīvus, lai iespējotu vispārēju izplatītu RPC, un teorētiski to var izmantot, lai apkopotu gandrīz jebkuru sadalītu skaitļošanas darbu, tā stiprā puse viennozīmīgi ir notikumu plūsmas apstrāde.
Spark: izplatīta apstrāde visiem
Spark, vēl viens projekts, kas piemērots reāllaika izplatītai skaitļošanai, sākās kā AMPLab projekts Kalifornijas universitātē Berkelijā, pirms pievienojās Apache inkubatoram un galu galā pabeidza augstākā līmeņa projektu 2014. gada februārī. Tāpat kā Storm, arī Spark atbalsta straumi orientēta apstrāde, bet tā drīzāk ir vispārējas nozīmes izplatīta skaitļošanas platforma.
Kā tādu Spark var uzskatīt par potenciālu Hadoop MapReduce funkciju aizstājēju, savukārt Spark ir iespēja darboties virs esošas Hadoop klastera, resursu plānošanā paļaujoties uz YARN. Papildus Hadoop YARN, Spark var slāņot virs Mesos plānošanai vai darboties kā atsevišķs kopa, izmantojot iebūvēto plānotāju. Ņemiet vērā, ka, ja Spark netiek izmantots kopā ar Hadoop, joprojām darbojas kāda veida tīkla / izplatītā failu sistēma (NFS, AFS un tā tālāk), ja tā darbojas klasterī, tāpēc katram mezglam būs piekļuve pamatā esošajiem datiem.
Spark ir rakstīts Scala un, tāpat kā Storm, atbalsta daudzvalodu programmēšanu, lai gan Spark nodrošina īpašu API atbalstu tikai Scala, Java un Python. Spark nav specifiskas “snīpas” abstrakcijas, taču tajā ietilpst adapteri darbam ar datiem, kas saglabāti daudzos atšķirīgos avotos, tostarp HDFS failos, Cassandra, HBase un S3.
Kur Spark spīd, tas atbalsta vairākas apstrādes paradigmas un atbalstošās bibliotēkas. Jā, Spark atbalsta straumēšanas modeli, taču šo atbalstu nodrošina tikai viens no vairākiem Spark moduļiem, tostarp mērķa vajadzībām izveidoti moduļi piekļuvei SQL, grafiku darbībām un mašīnmācībai, kā arī straumes apstrāde.
Spark nodrošina arī ļoti ērtu interaktīvu apvalku, kas ļauj ātri un netīri prototipēt un izpētīt datus reāllaikā, izmantojot Scala vai Python API. Strādājot interaktīvajā apvalkā, jūs ātri pamanāt vēl vienu būtisku atšķirību starp Spark un Storm: Spark ir vairāk “funkcionāls” aromāts, kurā darbs ar API tiek virzīts vairāk, izmantojot virknes paņēmienu izsaukumus, lai izsauktu primitīvas darbības, atšķirībā no Storm modelis, kuru mēdz vadīt, veidojot klases un ieviešot saskarnes. Neviena pieeja nav labāka vai sliktāka, taču jūsu izvēlētais stils var ietekmēt jūsu lēmumu par to, kura sistēma ir labāk piemērota jūsu vajadzībām.
Tāpat kā Storm, arī Spark ir paredzēts lielai mērogošanai, un Spark komanda ir dokumentējusi sistēmas lietotājus, kas vada ražošanas kopas ar tūkstošiem mezglu. Turklāt Spark uzvarēja nesenajā 2014. gada Daytona GraySort konkursā, labākajā laikā pievēršoties slodzei, kas sastāv no 100 TB datu šķirošanas. Spark komanda arī dokumentē Spark ETL darbības ar ražošanas slodzēm vairākos Petabyte diapazonos.
Spark ir ātra, mērogojama un elastīga atvērtā koda izplatītā skaitļošanas platforma, kas ir saderīga ar Hadoop un Mesos un atbalsta vairākus skaitļošanas modeļus, tostarp straumēšanu, uz diagrammu vērstas darbības, piekļuvi SQL un dalītu mašīnmācīšanos. Spark ir dokumentēts ārkārtīgi labi, un, tāpat kā Storm, tā ir lieliska platforma, uz kuras veidot reāllaika analīzes un biznesa inteliģences sistēmu.
Pieņemot lēmumu
Kā jūs izvēlaties starp Storm un Spark?
Ja jūsu prasības galvenokārt ir vērstas uz straumes apstrādi un CEP stila apstrādi un jūs sākat zaļā lauka projektu ar šim mērķim izveidotu kopu, es droši vien atbalstītu Storm - it īpaši, ja ir pieejami esošie Storm snīpi, kas atbilst jūsu integrācijas prasībām . Tas nekādā ziņā nav stingrs un ātrs noteikums, taču šādi faktori vismaz ieteiktu sākt ar Storm.
No otras puses, ja jūs izmantojat esošu Hadoop vai Mesos kopu un / vai ja jūsu apstrādes vajadzībām ir nepieciešamas būtiskas prasības diagrammu apstrādei, SQL piekļuvei vai pakešu apstrādei, vispirms ieteicams apskatīt Spark.
Vēl viens faktors, kas jāņem vērā, ir abu sistēmu daudzvalodu atbalsts. Piemēram, ja jums ir nepieciešams izmantot kodu, kas rakstīts R vai kādā citā valodā, kuru Spark neatbalsta, tad Storm priekšrocība ir plašāks valodas atbalsts. Tādā pašā nozīmē, ja datu izpētei, izmantojot API izsaukumus, ir jābūt interaktīvai čaulai, Spark piedāvā funkciju, kuras Storm nav.
Galu galā, iespējams, vēlēsities pirms galīgā lēmuma pieņemšanas veikt detalizētu abu platformu analīzi. Es iesaku izmantot abas platformas, lai izveidotu nelielu koncepcijas pierādījumu - pēc tam, pirms pilnībā apņematies, izpildiet savus etalonus ar darba slodzi, kas pēc iespējas tuvāk atspoguļo jūsu paredzamās slodzes.
Protams, jums nav jāpieņem ne lēmums, ne lēmums. Atkarībā no jūsu darba slodzes, infrastruktūras un prasībām, iespējams, atradīsit, ka ideāls risinājums ir Storm un Spark maisījums - kopā ar citiem rīkiem, piemēram, Kafka, Hadoop, Flume un tā tālāk. Tajā slēpjas atvērtā koda skaistums.
Neatkarīgi no izvēlētā maršruta šie rīki parāda, ka reāllaika BI spēle ir mainījusies. Kādreiz jaudīgas iespējas, kas pieejamas tikai nedaudzām elitēm, tagad ir pieejamas lielākajai daļai, ja ne visām vidēja lieluma organizācijām. Izmantojiet tos.
