ProHoster > Blogs > Administrācija > Serveru analītikas sistēmas

Serveru analītikas sistēmas

Šī ir otrā daļa rakstu sērijai par analītiskajām sistēmām (saite uz 1. daļu).

Serveru analītikas sistēmas

MÅ«sdienās vairs nav Å”aubu, ka rÅ«pÄ«ga datu apstrāde un rezultātu interpretācija var palÄ«dzēt gandrÄ«z jebkura veida uzņēmējdarbÄ«bai. Å ajā sakarā analÄ«tiskās sistēmas arvien vairāk tiek noslogotas ar parametriem, un lietojumprogrammās pieaug trigeru un lietotāju notikumu skaits.
Å Ä« iemesla dēļ uzņēmumi sniedz saviem analÄ«tiÄ·iem arvien vairāk neapstrādātas informācijas, lai tos analizētu un pārvērstu saprātÄ«gos lēmumos. AnalÄ«tiskās sistēmas nozÄ«mi uzņēmumam nevajadzētu novērtēt par zemu, un paÅ”ai sistēmai ir jābÅ«t uzticamai un stabilai.

Klientu analītiķi

Klientu analÄ«ze ir pakalpojums, ko uzņēmums savieno ar savu vietni vai lietojumprogrammu, izmantojot oficiālo SDK, integrē savā kodu bāzē un atlasa notikumu aktivizētājus. Å ai pieejai ir acÄ«mredzams negatÄ«vs aspekts: visi savāktie dati var netikt apstrādāti tieÅ”i tā, kā jÅ«s vēlētos, jo jebkura jÅ«su izvēlētā pakalpojuma ierobežojumi. Piemēram, vienā sistēmā nebÅ«s viegli palaist MapReduce uzdevumus, citā nevarēs palaist savu modeli. Vēl viens trÅ«kums bÅ«s regulārais (iespaidÄ«gais) rēķins par pakalpojumiem.
TirgÅ« ir daudz klientu analÄ«tikas risinājumu, taču agri vai vēlu analÄ«tiÄ·i saskaras ar faktu, ka nav neviena universālā pakalpojuma, kas bÅ«tu piemērots katram uzdevumam (kamēr visu Å”o pakalpojumu cenas visu laiku aug). Šādā situācijā uzņēmumi bieži nolemj izveidot savu analÄ«tikas sistēmu ar visiem nepiecieÅ”amajiem pielāgotajiem iestatÄ«jumiem un iespējām.

Serveru analītiķi

Servera puses analÄ«ze ir pakalpojums, ko var izvietot uzņēmumā tā serveros un (parasti) ar saviem centieniem. Å ajā modelÄ« visi lietotāju notikumi tiek glabāti iekŔējos serveros, ļaujot izstrādātājiem izmēģināt dažādas uzglabāŔanas datu bāzes un izvēlēties ērtāko arhitektÅ«ru. Un pat tad, ja dažiem uzdevumiem joprojām vēlaties izmantot treŔās puses klientu analÄ«zi, tas joprojām bÅ«s iespējams.
Servera puses analīzi var izvietot divos veidos. Pirmkārt: izvēlieties dažas atvērtā pirmkoda utilītas, izvietojiet tās savās iekārtās un izstrādājiet biznesa loģiku.

Plusi
MÄ«nusi

Jūs varat pielāgot visu, ko vēlaties
Tas bieži vien ir ļoti sarežģīti un prasa atseviŔķus izstrādātājus

Otrkārt: izmantojiet SaaS pakalpojumus (Amazon, Google, Azure), nevis izvietojiet tos pats. Par SaaS sīkāk runāsim treŔajā daļā.

Plusi
MÄ«nusi

Pie vidējiem apjomiem tas var būt lētāks, bet ar lielu izaugsmi tas joprojām kļūs pārāk dārgs
Nebūs iespējams kontrolēt visus parametrus

AdministrÄ“Å”ana pilnÄ«bā tiek nodota pakalpojumu sniedzēja pleciem
Ne vienmēr ir zināms, kas ir pakalpojuma iekÅ”ienē (var nebÅ«t vajadzÄ«gs)

Kā apkopot servera analīzi

Ja mēs vēlamies atteikties no klientu analÄ«tikas izmantoÅ”anas un izveidot savu, vispirms mums ir jāpārdomā jaunās sistēmas arhitektÅ«ra. Tālāk soli pa solim pastāstÄ«Å”u, kas jāņem vērā, kāpēc katrs solis ir vajadzÄ«gs un kādus rÄ«kus varat izmantot.

1. Datu saņemÅ”ana

Tāpat kā klientu analÄ«tikas gadÄ«jumā, uzņēmuma analÄ«tiÄ·i vispirms izvēlas notikumu veidus, kurus viņi vēlas izpētÄ«t nākotnē, un apkopo tos sarakstā. Parasti Å”ie notikumi notiek noteiktā secÄ«bā, ko sauc par "notikumu modeli".
Tālāk iedomājieties, ka mobilajai lietojumprogrammai (vietnei) ir regulāri lietotāji (ierÄ«ces) un daudzi serveri. Lai droÅ”i pārsÅ«tÄ«tu notikumus no ierÄ«cēm uz serveriem, ir nepiecieÅ”ams starpslānis. AtkarÄ«bā no arhitektÅ«ras var bÅ«t vairākas dažādas notikumu rindas.
Apache Kafka -Å o krodziņu/apakÅ”punktu rinda, kas tiek izmantota kā notikumu apkopoÅ”anas rinda.

Saskaņā ar ziņu vietnē Quora 2014. gadā Apache Kafka radÄ«tājs nolēma nosaukt programmatÅ«ru Franča Kafkas vārdā, jo ā€œtā ir rakstÄ«Å”anai optimizēta sistēmaā€ un tāpēc, ka viņam patika Kafkas darbi. ā€” Wikipedia

MÅ«su piemērā ir daudz datu veidotāju un datu patērētāju (ierīču un serveru), un Kafka palÄ«dz tos savienot savā starpā. Patērētāji tiks sÄ«kāk aprakstÄ«ti turpmākajos posmos, kur viņi bÅ«s galvenie priekÅ”meti. Tagad mēs apskatÄ«sim tikai datu veidotājus (notikumus).
Kafka iekapsulē rindas un nodalÄ«juma jēdzienus; labāk par to sÄ«kāk lasÄ«t citur (piemēram, dokumentācija). Neiedziļinoties detaļās, iedomāsimies, ka mobilā aplikācija tiek palaista divām dažādām OS. Pēc tam katra versija izveido savu atseviŔķu notikumu straumi. Producenti sÅ«ta pasākumus uz Kafku, tie tiek ierakstÄ«ti atbilstoŔā rindā.
Serveru analītikas sistēmas
(bilde tātad)

Tajā paŔā laikā Kafka ļauj lasÄ«t pa daļām un apstrādāt notikumu straumi mini partijās. Kafka ir ļoti ērts rÄ«ks, kas labi pielāgojas pieaugoÅ”ajām vajadzÄ«bām (piemēram, pēc notikumu Ä£eogrāfiskās atraÅ”anās vietas).
Parasti pietiek ar vienu shardu, taču mērogoÅ”anas laikā lietas kļūst sarežģītākas (kā vienmēr). DroÅ”i vien neviens nevēlēsies ražoÅ”anā izmantot tikai vienu fizisku Ŕķembu, jo arhitektÅ«rai jābÅ«t izturÄ«gai pret defektiem. Papildus Kafka ir vēl viens labi zināms risinājums - RabbitMQ. Mēs to neizmantojām ražoÅ”anā kā notikumu analÄ«zes rindu (ja jums ir Ŕāda pieredze, pastāstiet mums par to komentāros!). Tomēr mēs izmantojām AWS Kinesis.

Pirms pāriet uz nākamo soli, mums jāpiemin vēl viens sistēmas papildu slānis - neapstrādāta žurnālu glabāŔana. Tas nav obligāts slānis, taču tas noderēs, ja kaut kas noiet greizi un Kafkas notikumu rindas tiek atiestatÄ«tas. Neapstrādātu žurnālu uzglabāŔanai nav nepiecieÅ”ams sarežģīts un dārgs risinājums, tos var vienkārÅ”i ierakstÄ«t kaut kur pareizā secÄ«bā (pat cietajā diskā).
Serveru analītikas sistēmas

2. Notikumu straumju apstrāde

Pēc tam, kad esam sagatavojuÅ”i visus notikumus un ievietojuÅ”i tos atbilstoÅ”ajās rindās, mēs pārejam uz apstrādes posmu. Å eit es jums pastāstÄ«Å”u par divām visizplatÄ«tākajām apstrādes iespējām.
Pirmā iespēja ir iespējot Spark Streaming Apache sistēmā. Visi Apache produkti darbojas HDFS ā€” droŔā failu sistēmā ar failu replikām. Spark Streaming ir ērti lietojams rÄ«ks, kas labi apstrādā straumÄ“Å”anas datus un mērogo. Tomēr to var bÅ«t grÅ«ti uzturēt.
Vēl viena iespēja ir izveidot savu notikumu apstrādātāju. Lai to izdarÄ«tu, jums ir nepiecieÅ”ams, piemēram, uzrakstÄ«t Python lietojumprogrammu, izveidot to programmā Docker un abonēt Kafka rindu. Kad aktivizētāji nonāk pie doku apdarinātājiem, tiks sākta apstrāde. Izmantojot Å”o metodi, lietojumprogrammas vienmēr ir jādarbina.
Pieņemsim, ka esam izvēlējuÅ”ies kādu no iepriekÅ” aprakstÄ«tajām opcijām, un pāriesim pie paÅ”as apstrādes. Procesoriem jāsāk ar datu derÄ«guma pārbaudi, atkritumu un ā€œbojātuā€ notikumu filtrÄ“Å”anu. ApstiprināŔanai mēs parasti izmantojam Cerberus. Pēc tam varat veikt datu kartÄ“Å”anu: dati no dažādiem avotiem tiek normalizēti un standartizēti, lai tos pievienotu kopējai tabulai.
Serveru analītikas sistēmas

3. Datu bāze

TreÅ”ais solis ir uzturēt normalizētus notikumus. Strādājot ar gatavu analÄ«tisko sistēmu, mums tām bÅ«s bieži jāpiekļūst, tāpēc ir svarÄ«gi izvēlēties ērtu datu bāzi.
Ja dati labi iekļaujas fiksētā shēmā, varat izvēlēties Clickhouse vai kādu citu kolonnu datubāzi. Tādā veidā apkopojumi darbosies ļoti ātri. NegatÄ«vā puse ir tāda, ka shēma ir stingri fiksēta un tāpēc nebÅ«s iespējams pievienot patvaļīgus objektus bez izmaiņām (piemēram, ja notiek nestandarta notikums). Bet jÅ«s varat skaitÄ«t patieŔām ļoti ātri.
Nestrukturētiem datiem varat izmantot NoSQL, piemēram, Apache Cassandra. Tas darbojas ar HDFS, labi atkārtojas, jūs varat izveidot daudzus gadījumus, un tas ir izturīgs pret kļūmēm.
Varat arÄ« izvirzÄ«t kaut ko vienkārŔāku, piemēram, MongoDB. Tas ir diezgan lēns un paredzēts maziem apjomiem. Bet plus ir tas, ka tas ir ļoti vienkārÅ”s un tāpēc piemērots sākumam.
Serveru analītikas sistēmas

4. Apkopojumi

RÅ«pÄ«gi saglabājot visus notikumus, mēs vēlamies apkopot visu svarÄ«go informāciju no saņemtās partijas un atjaunināt datu bāzi. Visā pasaulē mēs vēlamies iegÅ«t atbilstoÅ”us informācijas paneļus un metriku. Piemēram, apkopot lietotāja profilu no notikumiem un kaut kā izmērÄ«t uzvedÄ«bu. Notikumi tiek apkopoti, apkopoti un vēlreiz saglabāti (lietotāju tabulās). Tajā paŔā laikā varat izveidot sistēmu, lai agregatoram-koordinatoram varētu pievienot arÄ« filtru: apkopot lietotājus tikai no noteikta veida notikumiem.
Pēc tam, ja kādam no komandas ir nepiecieÅ”ama tikai augsta lÄ«meņa analÄ«tika, var pieslēgt ārējās analÄ«tikas sistēmas. JÅ«s varat lietot Mixpanel vēlreiz. bet tā kā tas ir diezgan dārgi, tad tur netiek sÅ«tÄ«ti visi lietotāju pasākumi, bet tikai tas, kas nepiecieÅ”ams. Lai to izdarÄ«tu, mums ir jāizveido koordinators, kurÅ” nodos dažus neapstrādātus notikumus vai kaut ko tādu, ko mēs paÅ”i iepriekÅ” apkopojām, uz ārējām sistēmām, API vai reklāmas platformām.
Serveru analītikas sistēmas

5. Frontend

Jums ir jāsavieno priekÅ”gals ar izveidoto sistēmu. Labs piemērs ir apkalpoÅ”ana sarkans, ir datu bāzes GUI, kas palÄ«dz veidot informācijas paneļus. Kā mijiedarbÄ«ba darbojas:

  1. Lietotājs veic SQL vaicājumu.
  2. Atbildot uz to, viņŔ saņem zÄ«mi.
  3. Tas izveido tam ā€œjaunu vizualizācijuā€ un iegÅ«st skaistu grafiku, ko varat saglabāt sev.

Pakalpojumā esoŔās vizualizācijas tiek automātiski atjauninātas, jÅ«s varat pielāgot un izsekot uzraudzÄ«bu. Redash ir bezmaksas, ja tas tiek mitināts pats, taču kā SaaS tas maksās 50 USD mēnesÄ«.
Serveru analītikas sistēmas

Secinājums

Pēc visu iepriekÅ” minēto darbÄ«bu veikÅ”anas jÅ«s izveidosit sava servera analÄ«zi. LÅ«dzu, ņemiet vērā, ka tas nav tik vienkārÅ”i, kā vienkārÅ”i savienot klientu analÄ«zi, jo viss ir jākonfigurē paÅ”am. Tāpēc pirms savas sistēmas izveides ir vērts salÄ«dzināt nepiecieÅ”amÄ«bu pēc nopietnas analÄ«tikas sistēmas ar resursiem, ko esat ar mieru tai atvēlēt.
Ja esat veicis aprēķinus un atklājis, ka izmaksas ir pārāk augstas, nākamajā daļā es runāŔu par to, kā izveidot lētāku servera puses analÄ«tikas versiju.

Paldies, ka izlasījāt! Es labprāt uzdoŔu jautājumus komentāros.

Avots: www.habr.com

Pievieno komentāru