Ajatus reaaliaikaisesta liiketoimintatiedosta on ollut jo jonkin aikaa (katso aiheen Wikipedia-sivu, joka aloitettiin vuonna 2006). Mutta vaikka ihmiset ovat puhuneet ajatuksesta vuosien ajan, en ole nähnyt monien yritysten tosiasiallisesti omaksuvan vision, ja vielä vähemmän ymmärtäneen sen tarjoamat edut.
Ainakin osa syystä on ollut työkalujen puute BI: n ja analytiikan toteuttamiseksi reaaliajassa. Perinteiset tietovarastoympäristöt suuntautuivat voimakkaasti eräoperaatioihin, joilla on erittäin korkeat viiveet, olivat uskomattoman kalliita tai molemmat.
Useita tehokkaita, helppokäyttöisiä avoimen lähdekoodin alustoja on kehitetty muuttamaan tätä. Kaksi merkittävintä ovat Apache Storm ja Apache Spark, jotka tarjoavat reaaliaikaisia käsittelyominaisuuksia paljon laajemmalle potentiaalisille käyttäjille. Molemmat ovat Apache Software Foundation -säätiön projekteja, ja vaikka molemmat työkalut tarjoavat päällekkäisiä ominaisuuksia, niillä kaikilla on omat ominaisuutensa ja roolinsa.
Storm: Reaaliaikaisen käsittelyn Hadoop
Storm, tapahtumavirran käsittelyn hajautettu laskentakehys, aloitti elämänsä Twitterin vuonna 2011 ostaman markkinointiviestintäyrityksen BackType-projektina. Twitter hankki pian projektin ja lähetti sen GitHubiin, mutta Storm muutti lopulta Apache-yrityshautomoon. ja siitä tuli Apache-huipputason projekti syyskuussa 2014.
Stormia kutsutaan joskus reaaliaikaisen prosessoinnin Hadoopiksi. Storm-dokumentaatio näyttää olevan samaa mieltä: "Stormin avulla rajattomat tietovirrat on helppo käsitellä luotettavasti tekemällä reaaliaikainen käsittely, mitä Hadoop teki eräkäsittelyssä."
Tämän tavoitteen saavuttamiseksi Storm on suunniteltu massiiviseen skaalautuvuuteen, tukee vikasietoisuutta "epäonnistuu nopeasti, automaattinen uudelleenkäynnistys" -menetelmällä ja tarjoaa vahvan takuun jokaisen tuplan käsittelylle. Myrskyn oletusarvo on "ainakin kerran" -takuu viesteille, mutta tarjoaa mahdollisuuden toteuttaa myös "täsmälleen kerran" -prosessin.
Storm on kirjoitettu pääasiassa Clojuressa, ja se on suunniteltu tukemaan "juoksuputkien" (ajattele tulovirtauksia) ja "pulttien" (käsittely- ja lähtömoduulien) johdotusta topologiana kutsuttuina suuntaisina asyklisina kaavioina (DAG). Myrskytopologiat toimivat klustereissa, ja Storm-ajastin jakaa työn solmuihin klusterin ympärillä topologian kokoonpanon perusteella.
Voit ajatella topologioita olevan suunnilleen analogisia Hadoopin MapReduce-työn kanssa, paitsi että kun Storm keskittyy reaaliaikaiseen, stream-pohjaiseen käsittelyyn, topologiat ovat oletusarvoisesti käynnissä ikuisesti tai kunnes ne lopetetaan manuaalisesti. Kun topologia on aloitettu, nokka tuo tiedot järjestelmään ja luovuttaa tiedot pultteille (jotka voivat puolestaan luovuttaa tietoja seuraaville pultteille), missä päälaskentatyö tehdään. Käsittelyn edetessä yksi tai useampi pultti voi kirjoittaa tietoja tietokantaan tai tiedostojärjestelmään, lähettää viestin toiseen ulkoiseen järjestelmään tai muuten saattaa laskennan tulokset käyttäjien saataville.
Yksi Storm-ekosysteemin vahvuuksista on runsas valikoima saatavilla olevia nokia, jotka ovat erikoistuneet tietojen vastaanottamiseen kaikentyyppisistä lähteistä. Vaikka joudut ehkä kirjoittamaan mukautettuja nokia erittäin erikoistuneille sovelluksille, on olemassa hyvät mahdollisuudet löytää olemassa oleva nokka uskomattoman monille lähteille - Twitter-suoratoistosovellusliittymästä Apache Kafkaan JMS-välittäjiin ja kaikkeen siltä väliltä.
Sovittimia on olemassa helpottamaan integrointia HDFS-tiedostojärjestelmiin, mikä tarkoittaa, että Storm voi tarvittaessa toimia helposti Hadoopin kanssa. Stormin toinen vahvuus on sen tuki monikieliselle ohjelmoinnille. Vaikka Storm itsessään perustuu Clojure-sovellukseen ja toimii JVM: llä, siipipyörät ja pultit voidaan kirjoittaa melkein millä tahansa kielellä, mukaan lukien muut kuin JVM-kielet, jotka hyödyntävät protokollaa komponenttien välisessä kommunikoinnissa JSON: n kautta stdin / stdoutin kautta.
Lyhyesti sanottuna Storm on erittäin skaalautuva, nopea, vikasietoista avoimen lähdekoodin järjestelmä hajautettua laskentaa varten ja keskittyy erityisesti virtojen käsittelyyn. Myrsky on erinomainen tapahtumien prosessoinnissa ja inkrementaalilaskennassa, laskemalla liikkuvat mittarit reaaliajassa datavirtojen yli. Vaikka Storm tarjoaa myös primitiivejä yleisen hajautetun RPC: n mahdollistamiseksi ja teoreettisesti sitä voidaan käyttää lähes minkä tahansa hajautetun laskentatehtävän kokoamiseen, sen vahvuus on selvästi tapahtumavirran käsittely.
Spark: Hajautettu käsittely kaikille
Spark, toinen reaaliaikaiseen hajautettuun laskentaan soveltuva projekti, aloitettiin AMPLab-projektina Kalifornian yliopistossa Berkeleyssä, ennen kuin hän liittyi Apache-yrityshautomoon ja valmistui lopulta huipputason projektiksi helmikuussa 2014. Stormin tavoin Spark tukee streamia -suunniteltu käsittely, mutta se on enemmän yleiskäyttöinen hajautettu tietojenkäsittelyalusta.
Sellaisena Spark voidaan nähdä potentiaalisena korvikkeena Hadoopin MapReduce-toiminnoille, kun taas Sparkilla on kyky ajaa olemassa olevan Hadoop-klusterin päällä luottaen resurssien ajoitukseen YARNiin. Hadoop YARNin lisäksi Spark voi kerrosta Mesosin päälle aikataulutusta varten tai toimia erillisenä klusterina sisäänrakennetun ajastimensa avulla. Huomaa, että jos Sparkia ei käytetä Hadoopin kanssa, tietyntyyppinen verkko / hajautettu tiedostojärjestelmä (NFS, AFS ja niin edelleen) vaaditaan silti, jos se suoritetaan klusterissa, joten jokaisella solmulla on pääsy taustalla oleviin tietoihin.
Spark on kirjoitettu Scalassa ja tukee Stormin tavoin monikielistä ohjelmointia, vaikka Spark tarjoaa erityistä API-tukea vain Scalalle, Java: lle ja Pythonille. Sparkilla ei ole erityistä "juoksuputken" abstraktiota, mutta se sisältää sovittimet lukemattomiin lähteisiin, mukaan lukien HDFS-tiedostot, Cassandra, HBase ja S3, tallennettujen tietojen käsittelyyn.
Missä Spark loistaa, tukee useita prosessointiparadigmeja ja niitä tukevia kirjastoja. Kyllä, Spark tukee suoratoistomallia, mutta tämän tuen tarjoaa vain yksi useista Spark-moduuleista, mukaan lukien tarkoitukseen rakennetut moduulit SQL-käyttöä varten, kaaviotoiminnot ja koneoppiminen sekä suoratoisto.
Spark tarjoaa myös erittäin kätevän interaktiivisen kuoren, joka mahdollistaa nopean ja likainen prototyyppien tekemisen ja tutkivan datan analyysin reaaliajassa Scala- tai Python-sovellusliittymien avulla. Interaktiivisessa kuoressa työskennellessäsi havaitset nopeasti toisen suuren eron Sparkin ja Stormin välillä: Sparkilla on enemmän "toiminnallinen" maku, jossa API: n kanssa työskentelyä ohjaa enemmän ketjutamalla peräkkäisiä menetelmäkutsuja primitiivisten toimintojen käynnistämiseksi - toisin kuin Storm-malli, jota ajetaan yleensä luomalla luokkia ja toteuttamalla rajapintoja. Kumpikaan lähestymistapa ei ole parempi tai huonompi, mutta haluamasi tyyli voi vaikuttaa päätökseesi siitä, mikä järjestelmä sopii paremmin tarpeisiisi.
Kuten Storm, Spark on suunniteltu massiiviseen skaalattavuuteen, ja Spark-tiimi on dokumentoinut järjestelmän käyttäjät, jotka käyttävät tuotantoklustereita tuhansilla solmuilla. Lisäksi Spark voitti äskettäin järjestetyn 2014 Daytona GreySort -kilpailun, joka kääntyi parhaimmaksi ajaksi harteille, jotka koostuvat 100 Tt tietojen lajittelusta. Spark-tiimi dokumentoi myös Spark ETL -toiminnot tuotannon kuormituksella useilla Petabyte-alueilla.
Spark on nopea, skaalautuva ja joustava avoimen lähdekoodin hajautettu tietojenkäsittelyalusta, yhteensopiva Hadoopin ja Mesosin kanssa, joka tukee useita laskennallisia malleja, kuten suoratoisto, kaaviokeskeiset toiminnot, SQL-käyttö ja hajautettu koneoppiminen. Spark on dokumentoitu mittakaavassa poikkeuksellisen hyvin, ja Stormin tavoin se on erinomainen foorumi reaaliaikaisen analytiikka- ja yritystietojärjestelmän rakentamiseen.
Päätöksesi tekeminen
Kuinka valitset Stormin ja Sparkin välillä?
Jos vaatimuksesi keskittyvät ensisijaisesti suoratoistokäsittelyyn ja CEP-tyyppiseen käsittelyyn ja aloitat greenfield-projektin tarkoitukseen rakennetulla klusterilla, suosittelen todennäköisesti Stormia - varsinkin kun integraatiovaatimuksiasi vastaavat olemassa olevat Storm-putket ovat käytettävissä . Tämä ei ole suinkaan kova ja nopea sääntö, mutta tällaiset tekijät viittaavat ainakin Stormin aloittamiseen.
Toisaalta, jos hyödynnät olemassa olevaa Hadoop- tai Mesos-klusteria ja / tai jos käsittelytarpeisiisi liittyy huomattavia kaavioiden käsittelyä, SQL-käyttöoikeuksia tai eräkäsittelyä koskevia vaatimuksia, kannattaa ensin tarkastella Sparkia.
Toinen huomioitava tekijä on näiden kahden järjestelmän monikielinen tuki. Esimerkiksi, jos sinun on käytettävä R-koodia tai muuta kieltä, jota Spark ei tue luonnollisesti, Stormilla on etuna laajempi kielituki. Samalla tavoin, jos sinulla on oltava interaktiivinen kuori tietojen etsintään API-puheluiden avulla, Spark tarjoaa sinulle ominaisuuden, jota Storm ei.
Loppujen lopuksi haluat todennäköisesti suorittaa yksityiskohtaisen analyysin molemmista alustoista ennen lopullisen päätöksen tekemistä. Suosittelen, että molemmilla alustoilla rakennat pienen todisteen konseptista - suorita sitten omat vertailuarvosi työmäärällä, joka heijastaa odotetut työmäärät mahdollisimman tarkasti, ennen kuin sitoudut täysin jompaankumpaan.
Tietenkään sinun ei tarvitse tehdä kumpaakaan / tai päätöstä. Työmääristäsi, infrastruktuuristasi ja vaatimuksistasi riippuen saatat huomata, että ihanteellinen ratkaisu on Stormin ja Sparkin sekoitus - yhdessä muiden työkalujen, kuten Kafka, Hadoop, Flume, ja niin edelleen. Siinä on avoimen lähdekoodin kauneus.
Minkä reitin valitsetkin, nämä työkalut osoittavat, että reaaliaikainen BI-peli on muuttunut. Tehokkaat vaihtoehdot, jotka kerran olivat käytettävissä vain harvoille eliiteille, ovat nyt useimpien, ellei kaikkien keskisuurten ja suurten organisaatioiden ulottuvilla. Hyödynnä niitä.
