Obstaja stari aksiom, ki gre nekako takole: če nekomu ponudite svojo polno podporo in finančno podporo, da naredi nekaj drugačnega in inovativnega, bo na koncu počel to, kar počnejo vsi ostali.
Torej gre za Hadoop, Spark in Storm. Vsi mislijo, da s temi novimi tehnologijami za velike podatke delajo nekaj posebnega, vendar ne traja dolgo, da se vedno znova srečujemo z enakimi vzorci. Specifične izvedbe se lahko nekoliko razlikujejo, toda na podlagi mojih izkušenj je tu sedem najpogostejših projektov.
Projekt št. 1: Konsolidacija podatkov
Pokličite ga "podatkovno vozlišče podjetja" ali "podatkovno jezero". Zamisel je v tem, da imate različne vire podatkov in želite na njih analizirati. Ta vrsta projekta je sestavljena iz pridobivanja virov iz vseh virov (bodisi v realnem času bodisi v paketu) in vstavljanja v Hadoop. Včasih je to prvi korak, da postanemo "podjetje, ki temelji na podatkih"; včasih preprosto želite lepa poročila. Podatkovna jezera se ponavadi materializirajo kot datoteke na HDFS in tabele v Hive ali Impala. Obstaja drzen, nov svet, kjer se večina tega pokaže v HBase - in Phoenixu v prihodnosti, ker je panj počasen.
Prodajalci radi govorijo stvari, kot je »shema ob branju«, v resnici pa morate, da bi bili uspešni, dobro vedeti, kakšni bodo vaši primeri uporabe (ta shema Hive ne bo videti strašno drugačna od tiste, ki bi jo počeli v skladišče podatkov v podjetju). Pravi razlog za podatkovno jezero je vodoravna razširljivost in veliko nižji stroški kot Teradata ali Netezza. Za "analizo" je veliko ljudi na sprednji strani postavilo Tableau in Excel. Prefinjenejša podjetja z "resničnimi podatkovnimi znanstveniki" (matematiki, ki pišejo slab Python) uporabljajo Zeppelin ali iPython zvezek kot prednji del.
Projekt št. 2: Specializirana analiza
Številni projekti konsolidacije podatkov se dejansko začnejo tukaj, kjer imate posebno potrebo in vnesete en nabor podatkov za sistem, ki izvaja eno vrsto analize. Te so ponavadi neverjetno specifične za področje, na primer likvidnostno tveganje / simulacije Monte Carlo v banki. V preteklosti so bile takšne specializirane analize odvisne od zastarelih lastniških paketov, ki se niso mogli razširiti kot podatki in so pogosto trpeli zaradi omejenega nabora funkcij (delno zato, ker prodajalec programske opreme ni mogel vedeti toliko o domeni kot institucija potopljen vanjo).
V svetu Hadoop in Spark so ti sistemi približno enaki sistemom za konsolidacijo podatkov, vendar imajo pogosto več HBase, kodo, ki ni SQL po meri, in manj virov podatkov (če ne le enega). Vedno bolj temeljijo na Iskri.
Projekt št. 3: Hadoop kot storitev
V vsaki veliki organizaciji s projekti "specializirane analize" (in ironično enim ali dvema projektoma "konsolidacije podatkov") bodo neizogibno začeli čutiti "veselje" (to je bolečino) upravljanja z nekaj različno konfiguriranimi grozdi Hadoop, včasih iz različnih prodajalci. Nato bodo rekli: "Mogoče bi morali to združiti in združiti vire," namesto da bi polovica njihovih vozlišč polovico časa delala brez dela. Lahko bi šli v oblak, vendar številna podjetja bodisi ne morejo ali nočejo, pogosto iz varnostnih razlogov (beri: notranja politika in zaščita delovnih mest). To na splošno pomeni veliko kuharskih receptov in zdaj pakete zabojnikov Docker.
Nisem je še uporabljal, vendar se zdi, da ima Blue Data tukaj najbližjo rešitev, ki je na voljo, kar bo pritegnilo tudi manjše organizacije, ki nimajo dovolj možnosti, da Hadoop uvedejo kot storitev.
Projekt št. 4: Pretočna analitika
Mnogi bi temu rekli "pretakanje", vendar se pretočna analitika precej razlikuje od pretakanja iz naprav. Pretočna analitika je pogosto bolj sprotna različica tega, kar je organizacija storila po skupinah. Zavzemite se za pranje denarja ali odkrivanje goljufij: Zakaj tega ne bi storili na podlagi transakcije in ga ujeli, kot se zgodi, namesto na koncu cikla? Enako velja za upravljanje zalog ali kar koli drugega.
V nekaterih primerih gre za nov tip transakcijskega sistema, ki podatke analizira bit za bitom, ko jih vzporedno preusmerite v analitični sistem. Takšni sistemi se kažejo kot Spark ali Storm s HBase kot običajno shrambo podatkov. Upoštevajte, da pretočna analitika ne nadomešča vseh oblik analitike; še vedno boste želeli razkriti zgodovinske trende ali pogledati pretekle podatke za nekaj, česar niste nikoli upoštevali.
Projekt št. 5: Kompleksna obdelava dogodkov
Tu govorimo o obdelavi dogodkov v realnem času, kjer so pomembne podsekunde. Čeprav še vedno ni dovolj hiter za aplikacije z zelo nizko zakasnitvijo (pikosekundo ali nanosekundo), kot so vrhunski trgovski sistemi, lahko pričakujete milisekundni odzivni čas. Primeri vključujejo oceno zapisov podatkov o klicih v realnem času za telekomunikacije ali obdelavo dogodkov na internetu stvari. Včasih boste videli, da takšni sistemi uporabljajo Spark in HBase - na splošno pa padejo na obraz in jih je treba pretvoriti v Storm, ki temelji na vzorcu Disruptor, ki ga je razvila borza LMAX.
V preteklosti so takšni sistemi temeljili na prilagojeni programski opremi za sporočanje - ali na visokozmogljivih, gotovih izdelkih za sporočanje med odjemalci in strežniki - današnji obseg podatkov pa je preveč za nobeno. Obseg trgovanja in število ljudi z mobilnimi telefoni sta se povečala, odkar so bili ustvarjeni ti stari sistemi, medicinski in industrijski senzorji pa izčrpajo preveč bitov. Nisem ga še uporabljal, vendar se projekt Apex zdi obetaven in trdi, da je hitrejši od Storma.
Projekt št. 6: Pretakanje kot ETL
Včasih želite zajeti pretočne podatke in jih nekje shraniti. Ti projekti običajno sovpadajo s št. 1 ali št. 2, vendar dodajo svoj obseg in značilnosti. (Nekateri mislijo, da delajo št. 4 ali št. 5, vendar dejansko odlagajo podatke na disk in kasneje analizirajo podatke.) To so skoraj vedno projekti Kafke in Storm. Uporablja se tudi Spark, vendar brez utemeljitve, saj v resnici ne potrebujete analitike v pomnilniku.
Projekt št. 7: Zamenjava ali povečanje SAS
SAS je v redu; SAS je prijazen. SAS je tudi drag in ne kupujemo polj za vse vaše podatkovne znanstvenike in analitike, da bi se lahko "igrali" s podatki. Poleg tega ste želeli narediti nekaj drugačnega, kot bi lahko storil SAS, ali ustvariti lepši graf. Tu je vaše lepo podatkovno jezero. Tukaj je iPython Notebook (zdaj) ali Zeppelin (kasneje). Rezultate bomo posredovali v SAS in tukaj shranili rezultate iz SAS.
Čeprav sem videl še druge projekte Hadoop, Spark ali Storm, so to "običajni" vsakdanji tipi. Če uporabljate Hadoop, jih verjetno prepoznate. Nekatere primere uporabe teh sistemov sem že leta uporabljal v sodelovanju z drugimi tehnologijami.
Če ste starodobnik, ki se preveč bojite "velikega" pri velikih podatkih ali "storite" v Hadoopu, ne bodite. Bolj ko se stvari spreminjajo, bolj ostajajo enake. Našli boste veliko vzporednic med stvarmi, ki ste jih uporabili za razporeditev, in hipsterskimi tehnologijami, ki se vrtijo po Hadooposferi.
