Šī ir otrā daļa rakstu sērijai par analītiskajām sistēmām ().
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.
-Šo , kas tiek izmantota kā notikumu apkopošanas rinda.
Saskaņā ar 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. —
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, ). 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ā.
(bilde )
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ā).
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 . 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.
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 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, . 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, . 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.
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.
5. Frontend
Jums ir jāsavieno priekšgals ar izveidoto sistēmu. Labs piemērs ir apkalpošana , ir datu bāzes GUI, kas palīdz veidot informācijas paneļus. Kā mijiedarbība darbojas:
- Lietotājs veic SQL vaicājumu.
- Atbildot uz to, viņš saņem zīmi.
- 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ī.
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
