Pastāv veca aksioma, kas izsakās šādi: ja jūs kādam piedāvājat pilnu atbalstu un finansiālu atbalstu, lai izdarītu kaut ko citu un novatorisku, viņi galu galā darīs to, ko dara visi pārējie.
Tā tas notiek ar Hadoop, Spark un Storm. Visi domā, ka viņi ar šīm jaunajām lielo datu tehnoloģijām dara kaut ko īpašu, taču nav vajadzīgs ilgs laiks, lai atkal un atkal saskartos ar vieniem un tiem pašiem modeļiem. Konkrētas realizācijas var nedaudz atšķirties, taču, pamatojoties uz manu pieredzi, šeit ir septiņi visbiežāk sastopamie projekti.
Projekts Nr. 1: Datu apvienošana
Sauciet to par “uzņēmuma datu centru” vai “datu ezeru”. Ideja ir tāda, ka jums ir atšķirīgi datu avoti, un jūs vēlaties tos analizēt. Šāda veida projekts sastāv no plūsmu iegūšanas no visiem avotiem (reāllaikā vai kā partijas) un to ievietošanas Hadoop. Dažreiz tas ir pirmais solis, lai kļūtu par “uz datiem balstītu uzņēmumu”; dažreiz jūs vienkārši vēlaties glītus pārskatus. Datu ezeri parasti materializējas kā faili HDFS un tabulas Hive vai Impala. Ir drosmīga, jauna pasaule, kur liela daļa no tā parādās HBase - un Fīniksā nākotnē, jo Strops ir lēns.
Pārdevēji labprāt saka tādas lietas kā “shēma ir lasīta”, bet patiesībā, lai gūtu panākumus, jums ir labi jāsaprot, kādi būs jūsu lietošanas gadījumi (šī stropu shēma neizskatīsies ļoti atšķirīga no tā, ko jūs darītu uzņēmuma datu noliktava). Datu ezera patiesais iemesls ir horizontāla mērogojamība un daudz zemākas izmaksas nekā Teradata vai Netezza. "Analīzei" daudzi cilvēki priekšējā galā izveidoja Tableau un Excel. Sarežģītāki uzņēmumi ar “reāliem datu zinātniekiem” (matemātikas geeks, kas raksta sliktu Python) kā priekšgalu izmanto Zeppelin vai iPython piezīmjdatoru.
Projekts Nr. 2: specializēta analīze
Daudzi datu konsolidācijas projekti faktiski sākas šeit, kur jums ir īpaša vajadzība un jūs savācat vienu datu kopu sistēmai, kas veic viena veida analīzi. Tie parasti ir neticami specifiski domēniem, piemēram, likviditātes risks / Montekarlo simulācijas bankā. Iepriekš šāda specializēta analīze bija atkarīga no novecojušām, patentētām pakotnēm, kuras nevarēja palielināt, jo dati to darīja, un bieži vien cieta no ierobežotas funkciju kopas (daļēji tāpēc, ka programmatūras pārdevējs nevarēja uzzināt tik daudz par domēnu kā iestāde iegremdēts tajā).
Hadoop un Spark pasaulē šīs sistēmas izskatās aptuveni tādas pašas kā datu konsolidācijas sistēmas, taču tām bieži ir vairāk HBase, pielāgotu kodu, kas nav SQL, un mazāk datu avotu (ja ne tikai viens). Viņi arvien vairāk balstās uz Spark.
Projekts Nr. 3: Hadoop kā pakalpojums
Jebkurā lielā organizācijā, kurā ir “specializētas analīzes” projekti (un ironiski viens vai divi “datu konsolidācijas” projekti), viņi neizbēgami sāks izjust “prieku” (tas ir, sāpes), pārvaldot dažus atšķirīgi konfigurētus Hadoop klasterus, dažreiz no dažādiem pārdevēji. Pēc tam viņi teiks: "Varbūt mums tas būtu jākonsolidē un jāapkopo resursi", nevis puse no viņu mezgliem pusi laika sēž dīkstāvē. Viņi varēja nokļūt mākonī, taču daudzi uzņēmumi vai nu nevar, vai nedarīs, bieži vien drošības (lasīt: iekšpolitika un darba aizsardzība) apsvērumu dēļ. Tas parasti nozīmē daudz šefpavāru receptes un tagad Docker konteineru iepakojumus.
Es to vēl neesmu izmantojis, taču, šķiet, ka Blue Data ir vistuvāk šeit esošajam risinājumam, kas pievilcīgs būs arī tas, kas pievērsīsies arī mazākām organizācijām, kurām trūkst iespējas izvietot Hadoop kā pakalpojumu.
Projekts Nr. 4: straumēšanas analīze
Daudzi cilvēki to dēvētu par straumēšanu, taču straumēšanas analīze drīzāk atšķiras no straumēšanas no ierīcēm. Bieži vien straumēšanas analīze ir reāllaika versija tam, ko organizācija darīja partijās. Veikt naudas atmazgāšanas vai krāpšanas atklāšanu: kāpēc gan to nedarīt, pamatojoties uz darījumu, un nenoķert to tā, kā tas notiek, nevis cikla beigās? Tas pats attiecas uz krājumu pārvaldību vai jebko citu.
Dažos gadījumos tā ir jauna veida darījumu sistēma, kas datus pa daļām analizē, kad jūs tos paralēli pārvietojat analītiskajā sistēmā. Šādas sistēmas izpaužas kā Spark vai Storm ar HBase kā parasto datu krātuvi. Ņemiet vērā, ka straumēšanas analīze neaizstāj visu veidu analīzi; jūs joprojām vēlaties atklāt vēsturiskās tendences vai aplūkot iepriekšējos datus par kaut ko tādu, ko nekad neesat apsvēris.
Projekts Nr. 5: Kompleksa notikumu apstrāde
Šeit mēs runājam par reāllaika notikumu apstrādi, kur ir svarīgas sekundes. Lai gan tas joprojām nav pietiekami ātrs īpaši zemas latentuma (pikosekundes vai nanosekundes) lietojumprogrammām, piemēram, augstas klases tirdzniecības sistēmām, jūs varat sagaidīt milisekunžu atbildes laiku. Piemēri ietver reāllaika zvanu datu ierakstu vērtēšanu telekomunikācijām vai lietu interneta notikumu apstrādi. Dažreiz jūs redzēsiet, ka šādas sistēmas izmanto Spark un HBase, taču parasti tās nokrīt uz sejas un ir jāpārvērš par Storm, kuras pamatā ir LMAX biržas izstrādātais Disruptor modelis.
Iepriekš šādas sistēmas ir balstītas uz pielāgotu ziņojumapmaiņas programmatūru - vai augstas veiktspējas, klientiem pieejamu un klientu - serveru ziņojumapmaiņas produktiem -, taču šodienas datu apjoms nav pārāk liels. Kopš šo mantoto sistēmu izveides ir palielinājies tirdzniecības apjoms un cilvēku ar mobilajiem telefoniem skaits, un medicīnas un rūpniecības sensori izsūknē pārāk daudz bitu. Es to vēl neesmu izmantojis, bet Apex projekts izskatās daudzsološs un apgalvo, ka ir ātrāks par Storm.
Projekts Nr. 6: straumēšana kā ETL
Dažreiz vēlaties sagūstīt straumēšanas datus un tos kaut kur uzglabāt. Šie projekti parasti sakrīt ar Nr. 1 vai Nr. 2, taču tiem ir pievienota sava darbības joma un raksturojums. (Daži cilvēki domā, ka viņi dara 4. vai 5. numuru, bet viņi patiesībā nonāk diskā un vēlāk analizē datus.) Tie gandrīz vienmēr ir Kafka un Storm projekti. Tiek izmantota arī dzirkstele, taču bez pamatojuma, jo atmiņas analītika patiesībā nav nepieciešama.
Projekts Nr. 7: SAS aizstāšana vai papildināšana
SAS ir labi; SAS ir jauks. SAS ir arī dārga, un mēs nepērkam kastes visiem jums, zinātniekiem un analītiķiem, lai jūs varētu “spēlēt” ar datiem. Turklāt jūs gribējāt darīt kaut ko citu, nekā SAS varēja, vai ģenerēt glītāku grafiku. Šeit ir jūsu jaukais datu ezers. Šeit ir iPython Notebook (tagad) vai Zeppelin (vēlāk). Rezultātus mēs ievietosim SAS un šeit glabāsim no SAS.
Lai gan es esmu redzējis citus Hadoop, Spark vai Storm projektus, tie ir “parastie” ikdienas veidi. Ja izmantojat Hadoop, jūs, iespējams, tos atpazīstat. Dažus šo sistēmu izmantošanas gadījumus esmu ieviesis vairākus gadus iepriekš, strādājot ar citām tehnoloģijām.
Ja esat veclaicīgs cilvēks, kurš pārāk nobijies no lielo datu “lielā” vai “dariet” Hadoopā, nedariet to. Jo vairāk lietas mainās, jo vairāk tās paliek nemainīgas. Jūs atradīsit daudz paralēles starp lietām, kuras izmantojāt, un hipsteru tehnoloģijām, kas virpuļo ap Hadooposphere.
