Siellä on vanha aksioma, joka on suunnilleen näin: Jos tarjoat jollekulle täyden tuen ja taloudellisen tuen tehdä jotain erilaista ja innovatiivista, he lopulta tekevät sen, mitä kaikki muutkin tekevät.
Joten se pätee Hadoopiin, Sparkiin ja Stormiin. Kaikki luulevat tekevänsä jotain erityistä näiden uusien isojen tietotekniikoiden avulla, mutta samojen mallien kohtaaminen kestää kauan. Erityiset toteutukset voivat vaihdella jonkin verran, mutta kokemukseni perusteella tässä on seitsemän yleisintä projektia.
Projekti nro 1: Tietojen yhdistäminen
Kutsu sitä "yritystietokeskukseksi" tai "datajärveksi". Ajatuksena on, että sinulla on erilaiset tietolähteet ja haluat analysoida niitä. Tämän tyyppinen projekti koostuu syötteiden hankkimisesta kaikista lähteistä (joko reaaliajassa tai eränä) ja työntämällä ne Hadoopiin. Joskus tämä on vaihe ensimmäiseksi tullessa ”datapohjaiseksi yritykseksi”; joskus haluat yksinkertaisesti kauniita raportteja. Datajärvet materialisoituvat yleensä tiedostoina HDFS: ssä ja taulukoissa Hive tai Impala. Siellä on rohkea, uusi maailma, jossa suuri osa tästä näkyy HBasessa - ja Phoenixissa tulevaisuudessa, koska Hive on hidas.
Myyjät haluavat sanoa esimerkiksi "skeema luettuina", mutta todellisuudessa menestyäksesi sinulla on oltava hyvä käsitys käyttötapauksistasi (Hive-skeema ei näytä hirvittävän erilaiselta kuin mitä tekisit yrityksen tietovarasto). Todellinen syy datajärvelle on vaakasuuntainen skaalautuvuus ja paljon halvemmat kuin Teradata tai Netezza. "Analyysiä" varten monet ihmiset perustivat Tableaun ja Excelin käyttöliittymään. Kehittyneemmät yritykset, joilla on todellisia datatieteilijöitä (matematiikkanekit, jotka kirjoittavat huonoa Pythonia), käyttävät Zeppelin- tai iPython-muistikirjaa käyttöliittymänä.
Projekti nro 2: Erikoisanalyysi
Monet tiedonkonsolidointiprojektit todella alkavat täällä, missä sinulla on erityistarve ja vedät yhteen tietojoukkoon järjestelmää, joka tekee eräänlaisen analyysin. Nämä ovat yleensä uskomattoman toimialakohtaisia, kuten likviditeettiriski / Monte Carlon simulaatiot pankissa. Aikaisemmin tällaiset erikoistuneet analyysit riippuivat vanhentuneista, omistetuista paketeista, jotka eivät voineet laajentua tietojen tavoin ja kärsivät usein rajoitetusta ominaisuuksista (osittain siksi, että ohjelmistotoimittaja ei voinut tietää niin paljon verkkotunnuksesta kuin instituutio upotettu siihen).
Hadoop- ja Spark-maailmassa nämä järjestelmät näyttävät suunnilleen samoilta kuin tietojen yhdistämisjärjestelmät, mutta niillä on usein enemmän HBase, mukautettua muuta kuin SQL-koodia ja vähemmän tietolähteitä (ellei vain yksi). He ovat yhä enemmän Spark-pohjaisia.
Projekti nro 3: Hadoop palveluna
Kaikissa suurissa organisaatioissa, joissa on erikoistuneita analyysiprojekteja (ja ironisesti yksi tai kaksi "tietojen konsolidointiprojektia"), he alkavat väistämättä tuntea "iloa" (toisin sanoen kipua) hallita muutamia eri tavalla konfiguroituja Hadoop-klustereita, joskus eri myyjät. Seuraavaksi he sanovat: "Ehkä meidän pitäisi vahvistaa tämä ja yhdistää resurssit" sen sijaan, että puolet heidän solmuistaan olisivat käyttämättömiä puolet ajasta. He voivat mennä pilveen, mutta monet yritykset joko eivät voi tai eivät, usein turvallisuussyistä (lue: sisäpolitiikka ja työsuojelu). Tämä tarkoittaa yleensä paljon kokin reseptejä ja nyt Docker-pakkauspaketteja.
En ole vielä käyttänyt sitä, mutta Blue Data näyttää olevan lähinnä out-of-the-box-ratkaisua, joka vetoaa myös pienempiin organisaatioihin, joilla ei ole mahdollisuutta ottaa Hadoopia käyttöön palveluna.
Projekti nro 4: Suoratoistoanalytiikka
Monet ihmiset kutsuvat tätä "suoratoistoksi", mutta suoratoistoanalytiikka eroaa pikemminkin kuin suoratoisto laitteista. Suoratoistoanalytiikka on usein reaaliaikaisempi versio siitä, mitä organisaatio teki erissä. Otetaan rahanpesun tai petosten havaitseminen: Miksi et tekisi niin tapahtumaperusteisesti ja saisi sen kiinni, koska se tapahtuu pikemminkin kuin syklin lopussa? Sama koskee varastohallintaa tai muuta.
Joissakin tapauksissa tämä on uudentyyppinen transaktiojärjestelmä, joka analysoi tietoja vähitellen, kun vaihdat ne samanaikaisesti analyyttiseksi järjestelmäksi. Tällaiset järjestelmät ilmaisevat itseään Spark tai Storm, HBase tavallisena tietovarastona. Huomaa, että suoratoistoanalytiikka ei korvaa kaikkia analytiikan muotoja; haluat silti näyttää historiallisia trendejä tai tarkastella aiempia tietoja sellaisesta, jota et ole koskaan ajatellut.
Projekti nro 5: Monimutkainen tapahtumien käsittely
Tässä puhumme reaaliaikaisesta tapahtumien prosessoinnista, jossa ala-sekunnilla on merkitystä. Vaikka se ei vieläkään ole tarpeeksi nopea erittäin matalan viiveen (pikosekunnin tai nanosekunnin) sovelluksiin, kuten huippuluokan kaupankäyntijärjestelmiin, voit odottaa millisekunnin vasteaikoja. Esimerkkejä ovat puhelutietojen reaaliaikainen luokittelu puhelimille tai esineiden internet-tapahtumien käsittely. Joskus näet, että tällaiset järjestelmät käyttävät Sparkia ja HBasea - mutta yleensä ne putoavat kasvoilleen ja ne on muunnettava Stormiksi, joka perustuu LMAX-pörssin kehittämään Disruptor-malliin.
Aikaisemmin tällaiset järjestelmät ovat perustuneet räätälöityihin viestintäohjelmistoihin - tai tehokkaisiin, valmiisiin, asiakas-palvelin -viestintätuotteisiin -, mutta nykypäivän datamäärät ovat liikaa kummallekaan. Kaupankäyntimäärät ja matkapuhelimia käyttävien ihmisten määrä ovat nousseet siitä lähtien, kun nämä vanhat järjestelmät luotiin, ja lääketieteelliset ja teolliset anturit pumppaavat liian monta bittiä. En ole vielä käyttänyt sitä, mutta Apex-projekti näyttää lupaavalta ja väittää olevansa nopeampi kuin Storm.
Projekti nro 6: Suoratoisto ETL: nä
Joskus haluat kaapata suoratoistotiedot ja varastoida ne jonnekin. Nämä projektit ovat yleensä yhtäpitäviä numeroiden 1 tai 2 kanssa, mutta lisäävät omat laajuutensa ja ominaisuutensa. (Jotkut ihmiset ajattelevat tekevänsä nro 4 tai nro 5, mutta he todella dumppaavat levylle ja analysoivat tietoja myöhemmin.) Nämä ovat melkein aina Kafka- ja Storm-hankkeita. Sparkia käytetään myös, mutta ilman perusteluja, koska et todellakaan tarvitse muistin sisäistä analytiikkaa.
Projekti nro 7: SAS: n korvaaminen tai täydentäminen
SAS on kunnossa; SAS on mukava. SAS on myös kallista, emmekä osta laatikoita kaikille tiedetieteilijöille ja analyytikoille, jotta voit "leikkiä" datalla. Lisäksi halusit tehdä jotain erilaista kuin SAS voisi tehdä tai luoda kauniimpi kaavio. Tässä on mukava tietojärvi. Tässä on iPython Notebook (nyt) tai Zeppelin (myöhemmin). Syötämme tulokset SAS: ään ja tallennamme SAS: n tulokset täältä.
Vaikka olen nähnyt muita Hadoop-, Spark- tai Storm-projekteja, nämä ovat "normaalia" jokapäiväistä tyyppiä. Jos käytät Hadoopia, tunnistat ne todennäköisesti. Joitakin näiden järjestelmien käyttötapauksista olen toteuttanut vuosia aiemmin työskennellessäni muiden tekniikoiden kanssa.
Jos olet vanhanaikainen liian peloissaan big datan "suuresta" tai "tee" Hadoopissa, älä. Mitä enemmän asiat muuttuvat, sitä enemmän ne pysyvät ennallaan. Löydät paljon yhtäläisyyksiä käyttämiesi tavaroiden ja hipsteritekniikoiden välillä, jotka pyörivät Hadooposfäärin ympärillä.
