Yra sena aksioma, kuri pasakoja maždaug taip: jei kam nors pasiūlysite visą savo paramą ir finansinę paramą, kad jis galėtų padaryti kažką kitokio ir novatoriško, jis galų gale padarys tai, ką daro visi kiti.
Taigi tai vyksta su „Hadoop“, „Spark“ ir „Storm“. Visi mano, kad su šiomis naujomis didžiųjų duomenų technologijomis daro kažką ypatingo, tačiau ilgai ir ilgai susiduria su tais pačiais modeliais. Konkretūs įgyvendinimai gali šiek tiek skirtis, tačiau, remiantis mano patirtimi, pateikiame septynis dažniausiai pasitaikančius projektus.
Projektas Nr. 1: duomenų konsolidavimas
Pavadinkime tai „įmonės duomenų centru“ arba „duomenų ežeru“. Idėja yra tai, kad turite skirtingus duomenų šaltinius ir norite juos analizuoti. Šio tipo projektą sudaro tiekimas iš visų šaltinių (realiuoju laiku arba kaip paketas) ir jų įstūmimas į „Hadoop“. Kartais tai yra pirmas žingsnis norint tapti „duomenų valdoma įmone“; kartais tiesiog norisi gražių ataskaitų. Duomenų ežerai dažniausiai įvyksta kaip failai HDFS ir lentelės Hive arba Impala. Yra drąsus, naujas pasaulis, kuriame didžioji dalis to pasirodo „HBase“ ir „Phoenix“ ateityje, nes „Hive“ yra lėtas.
Pardavėjai mėgsta sakyti tokius dalykus kaip „schema perskaityta“, bet iš tikrųjų, kad būtum sėkmingas, turi gerai įsivaizduoti, kokie bus tavo naudojimo atvejai (ta avilio schema neatrodys labai kitokia nei darytum įmonės duomenų saugykla). Tikroji duomenų ežero priežastis yra horizontalus mastelis ir daug mažesnė kaina nei „Teradata“ ar „Netezza“. „Analizei“ daugelis žmonių iš anksto įdiegė „Tableau“ ir „Excel“. Įmantresnės įmonės, turinčios „tikrų duomenų mokslininkų“ (matematikos geekai, rašantys blogą „Python“), naudoja „Zeppelin“ arba „iPython“ užrašų knygutes kaip priekinę dalį.
Projektas Nr. 2: specializuota analizė
Daugelis duomenų konsolidavimo projektų iš tikrųjų prasideda čia, kur jūs turite specialų poreikį ir įtraukiate vieną duomenų rinkinį sistemai, kuri atlieka vienos rūšies analizę. Tai paprastai būna neįtikėtinai būdingi kiekvienai sričiai, pavyzdžiui, likvidumo rizika / Monte Karlo modeliavimas banke. Anksčiau tokia specializuota analizė priklausė nuo senų, nuosavų paketų, kurie negalėjo didėti, nes duomenys buvo dideli, ir dažnai nukentėjo dėl riboto funkcijų rinkinio (iš dalies dėl to, kad programinės įrangos tiekėjas negalėjo žinoti tiek apie domeną, kiek įstaiga paniręs į jį).
„Hadoop“ ir „Spark“ pasaulyje šios sistemos atrodo maždaug taip pat, kaip duomenų konsolidavimo sistemos, tačiau dažnai turi daugiau HBase, pasirinktinį ne SQL kodą ir mažiau duomenų šaltinių (jei ne tik vieną). Vis dažniau jie yra „Spark“ pagrindu.
Projektas Nr. 3: „Hadoop“ kaip paslauga
Bet kurioje didelėje organizacijoje, kurioje vykdomi „specializuotos analizės“ projektai (ir ironiškai vienas ar du „duomenų konsolidavimo“ projektai), jie neišvengiamai pradės jausti „džiaugsmą“ (tai yra skausmą) valdant kelis skirtingai sukonfigūruotus „Hadoop“ klasterius, kartais iš skirtingų pardavėjai. Tada jie pasakys: „Gal turėtume tai sutelkti ir sutelkti išteklius“, o ne pusę savo mazgų pusę laiko sėdėti be darbo. Jie galėtų eiti į debesį, tačiau daugelis įmonių arba negali, arba ne, dažnai dėl saugumo (skaitykite: vidaus politika ir darbo apsauga) priežasčių. Tai paprastai reiškia daugybę virėjų receptų, o dabar - „Docker“ konteinerių pakuotes.
Aš dar nenaudojau, bet atrodo, kad „Blue Data“ yra pats artimiausias dalykas „out-of-the-box“ sprendimui, kuris taip pat patiks mažesnėms organizacijoms, kurioms trūksta galimybių įdiegti „Hadoop“ kaip paslaugą.
Projektas Nr. 4: Srautinė analizė
Daugelis žmonių tai vadintų „srautu“, tačiau srautinio perdavimo analizė skiriasi nuo srautinio perdavimo iš įrenginių. Dažnai srautinė analizė yra realesnio laiko versija to, ką organizacija atliko paketais. Imkitės pinigų plovimo ar sukčiavimo nustatymo: Kodėl gi to nepadarius sandorio pagrindu ir nesuprantant to, kaip tai atsitinka, o ne ciklo pabaigoje? Tas pats pasakytina apie atsargų valdymą ar bet ką kitą.
Kai kuriais atvejais tai yra naujo tipo sandorių sistema, analizuojanti duomenis po truputį, kai jūs juos lygiagrečiai perkeliate į analitinę sistemą. Tokios sistemos pasireiškia kaip „Spark“ arba „Storm“, o „HBase“ yra įprasta duomenų saugykla. Atminkite, kad srautinė analizė nepakeičia visų formų analizės; vis tiek norėsite pateikti istorines tendencijas arba pažvelgti į praeities duomenis apie tai, ko niekada nesvarstėte.
Projektas Nr. 5: Kompleksinis renginių apdorojimas
Čia kalbame apie įvykių apdorojimą realiuoju laiku, kai svarbu sekundės. Nors vis dar nėra pakankamai greitas taikant itin mažos vėlavimo (pikosekundės ar nanosekundės) programas, pvz., Aukščiausios klasės prekybos sistemas, galite tikėtis milisekundžių atsakymo laiko. Tokie pavyzdžiai gali būti telekomunikacijų pokalbių duomenų įrašų įvertinimas realiuoju laiku arba daiktų interneto įvykių apdorojimas. Kartais pamatysite, kad tokios sistemos naudoja „Spark“ ir „HBase“, tačiau paprastai jos nukrenta ant veido ir turi būti paverstos „Storm“, kurios pagrindas yra „Disruptor“ modelis, kurį sukūrė LMAX birža.
Anksčiau tokios sistemos buvo pagrįstos pritaikyta susirašinėjimo programine įranga - arba didelio našumo, nebenaudojamais, kliento ir serverio pranešimų siuntimo produktais, tačiau šiandien duomenų kiekis abiem yra per didelis. Nuo to laiko, kai buvo sukurtos šios senos sistemos, išaugo prekybos apimtys ir žmonių, turinčių mobiliuosius telefonus, skaičius, o medicinos ir pramonės jutikliai išpumpuoja per daug bitų. Aš dar nenaudojau, tačiau „Apex“ projektas atrodo perspektyvus ir teigia esąs greitesnis už „Storm“.
Projektas Nr. 6: srautas kaip ETL
Kartais norite užfiksuoti srautinius duomenis ir juos kur nors sandėliuoti. Šie projektai paprastai sutampa su Nr. 1 arba Nr. 2, tačiau jie prideda savo apimtį ir ypatybes. (Kai kurie žmonės mano, kad jie daro Nr. 4 ar Nr. 5, bet iš tikrųjų jie išmeta diską ir vėliau analizuoja duomenis.) Tai beveik visada yra „Kafka“ ir „Storm“ projektai. Taip pat naudojamas kibirkštis, tačiau be pagrindo, nes atminties analizės jums tikrai nereikia.
Projektas Nr. 7: SAS pakeitimas ar papildymas
SAS yra gerai; SAS yra malonu. SAS taip pat yra brangus ir mes neperkame dėžučių visiems jūsų duomenų mokslininkams ir analitikams, kad galėtumėte „žaisti“ su duomenimis. Be to, jūs norėjote padaryti ką nors kita, nei SAS galėtų, arba sugeneruoti gražesnį grafiką. Čia yra jūsų gražus duomenų ežeras. Čia yra „iPython Notebook“ (dabar) arba „Zeppelin“ (vėliau). Rezultatus pateiksime į SAS ir čia išsaugosime SAS rezultatus.
Nors mačiau kitus „Hadoop“, „Spark“ ar „Storm“ projektus, tai yra „įprasti“ kasdieniai tipai. Jei naudojate „Hadoop“, tikriausiai juos atpažįstate. Kai kuriuos šių sistemų naudojimo atvejus įdiegiau prieš daugelį metų, dirbdamas su kitomis technologijomis.
Jei esate senbuvis, per daug bijote „didelių“ duomenų didžiuosiuose duomenyse ar „daryti“ Hadoope, nebūkite. Kuo daugiau dalykų keičiasi, tuo labiau jie lieka nepakitę. Rasite daug paralelių tarp naudojamų dalykų ir hipsterinių technologijų, besisukančių aplink Hadooposferą.
