Tai antroji straipsnių apie analitines sistemas dalis ().
Šiandien neabejotina, kad tikslus duomenų apdorojimas ir rezultatų interpretavimas gali padėti beveik bet kokiam verslui. Šiuo atžvilgiu analitinės sistemos vis labiau apkraunamos parametrais, programose auga trigerių ir vartotojo įvykių skaičius.
Dėl šios priežasties įmonės pateikia savo analitikams vis daugiau „neapdorotos“ informacijos, kad ji analizuotų ir paverstų ją tinkamais sprendimais. Nereikėtų nuvertinti analitinės sistemos svarbos įmonei, o pati sistema turi būti patikima ir tvari.
Klientų analitikai
Klientų analizė yra paslauga, kurią įmonė prijungia prie savo svetainės ar programos per oficialų SDK, integruoja ją į savo kodų bazę ir pasirenka įvykių aktyviklius. Šis metodas turi akivaizdų trūkumą: dėl bet kurios pasirinktos paslaugos apribojimų visi surinkti duomenys negali būti apdorojami taip, kaip norėtumėte. Pavyzdžiui, vienoje sistemoje nebus lengva paleisti MapReduce užduotis, kitoje negalėsite paleisti savo modelio. Kitas trūkumas bus įprasta (įspūdinga) sąskaita už paslaugas.
Rinkoje yra daug klientų analizės sprendimų, tačiau analitikai anksčiau ar vėliau susiduria su tuo, kad nėra vienos universalios paslaugos, tinkamos kokiai nors užduočiai atlikti (tuo tarpu visų šių paslaugų kainos nuolat auga). Esant tokiai situacijai, įmonės dažnai nusprendžia sukurti savo analizės sistemą su visais reikalingais pasirinktiniais nustatymais ir funkcijomis.
Serverio analitikai
Serverio analizė yra paslauga, kurią galima įdiegti įmonės viduje ir (dažniausiai) įmonės viduje. Šiame modelyje visi vartotojo įvykiai yra saugomi vidiniuose serveriuose, todėl kūrėjai gali išbandyti įvairias duomenų bazes saugojimui ir pasirinkti patogiausią architektūrą. Ir net jei vis tiek norėsite kai kurioms užduotims naudoti trečiosios šalies kliento pusės analizę, tai vis tiek bus įmanoma.
Serverio analizė gali būti įdiegta dviem būdais. Pirma: pasirinkite kai kurias atvirojo kodo priemones, įdiekite jas savo įrenginiuose ir sukurkite verslo logiką.
Argumentai "už"
Trūkumai
Galite pritaikyti bet ką
Dažnai tai būna labai sunku ir reikalingi atskiri kūrėjai
Antra: imkitės SaaS paslaugų („Amazon“, „Google“, „Azure“), o ne diegkite patys. Apie SaaS plačiau pakalbėsime trečioje dalyje.
Argumentai "už"
Trūkumai
Jis gali būti pigesnis esant vidutiniams kiekiams, tačiau labai padidėjus jis vis tiek taps per brangus
Negali valdyti visų parametrų
Administravimas visiškai perkeltas ant paslaugų teikėjo pečių
Ne visada žinoma, kas yra paslaugos viduje (gali būti nereikalinga)
Kaip rinkti serverio analizę
Jei norime atsikratyti klientų analizės ir sukurti savo, pirmiausia turime apgalvoti naujosios sistemos architektūrą. Žemiau žingsnis po žingsnio papasakosiu, į ką reikia atsižvelgti, kodėl reikalingas kiekvienas veiksmas ir kokias priemones galite naudoti.
1. Duomenų gavimas
Kaip ir klientų analizės atveju, įmonių analitikai pirmiausia atsirenka įvykių tipus, kuriuos nori toliau tirti, ir surenka juos į sąrašą. Paprastai šie įvykiai vyksta tam tikra tvarka, kuri vadinama „įvykių schema“.
Be to, įsivaizduokime, kad mobilioji aplikacija (svetainė) turi įprastų vartotojų (įrenginių) ir daug serverių. Norint saugiai perkelti įvykius iš įrenginių į serverius, reikalingas tarpinis sluoksnis. Priklausomai nuo architektūros, gali susidaryti kelios skirtingos įvykių eilės.
- yra , kuri naudojama kaip įvykių rinkimo eilė.
Pagal 2014 m. Apache Kafka kūrėjas nusprendė pavadinti programinę įrangą Franzo Kafkos vardu, nes „tai rašymui optimizuota sistema“ ir todėl, kad jam patiko Kafkos raštai. —
Mūsų pavyzdyje yra daug duomenų gamintojų ir jų vartotojų (įrenginių ir serverių), o Kafka padeda juos sujungti. Išsamiau vartotojai bus aprašyti kituose žingsniuose, kur jie bus pagrindiniai veikėjai. Dabar nagrinėsime tik duomenų gamintojus (įvykius).
Kafka aprėpia eilės ir skaidinio sąvokas, konkrečiau apie tai geriau pasiskaityti kitur (pvz. ). Nesigilindami į detales, įsivaizduokime, kad mobilioji aplikacija paleidžiama dviem skirtingoms operacinėms sistemoms. Tada kiekviena versija sukuria savo atskirą įvykių srautą. Prodiuseriai siunčia renginius į Kafką, jie įrašomi į tinkamą eilę.
(nuotrauka )
Tuo pačiu metu Kafka leidžia skaityti dalimis ir apdoroti įvykių srautą mažomis partijomis. Kafka yra labai patogus įrankis, kuris puikiai prisitaiko prie augančių poreikių (pavyzdžiui, pagal įvykių geografinę vietą).
Paprastai užtenka vienos skeveldros, tačiau keičiant mastelį viskas tampa sudėtingesnė (kaip visada). Tikriausiai niekas nenori gamyboje naudoti tik vienos fizinės skeveldros, nes architektūra turi būti atspari gedimams. Be Kafkos, yra dar vienas gerai žinomas sprendimas – RabbitMQ. Gamyboje jo nenaudojome kaip eilės renginių analitikai (jei turite tokios patirties, pasakykite apie tai komentaruose!). Tačiau buvo naudojamas AWS Kinesis.
Prieš pereinant prie kito žingsnio, reikia paminėti dar vieną papildomą sistemos sluoksnį – neapdorotų rąstų saugojimą. Tai nėra privalomas sluoksnis, bet jis bus naudingas, jei kas nors nutiks ir įvykių eilės Kafkoje bus iš naujo nustatytos į nulį. Neapdorotų žurnalų saugojimui nereikia sudėtingo ir brangaus sprendimo, galite juos tiesiog įrašyti kur nors teisinga tvarka (net į standųjį diską).
2. Įvykių srautų tvarkymas
Paruošę visus įvykius ir sudėję juos į atitinkamas eiles, pereiname prie apdorojimo žingsnio. Čia pakalbėsiu apie dvi dažniausiai pasitaikančias apdorojimo parinktis.
Pirmoji parinktis yra įjungti „Spark Streaming“ „Apache“ sistemoje. Visi „Apache“ produktai veikia HDFS – saugioje kopijų failų sistemoje. „Spark Streaming“ yra paprastas naudoti įrankis, kuris gerai apdoroja srautinio perdavimo duomenis ir keičia mastelį. Tačiau tai gali būti sunku išlaikyti.
Kitas variantas – susikurti savo įvykių tvarkyklę. Norėdami tai padaryti, pavyzdžiui, turite parašyti Python programą, sukurti ją dokeryje ir užsiprenumeruoti Kafkos eiles. Kai paleidikliai pasiekia doko tvarkytojus, bus pradėtas apdorojimas. Naudodami šį metodą turite nuolat veikti programas.
Tarkime, kad pasirinkome vieną iš aukščiau aprašytų variantų ir pereikime prie paties apdorojimo. Procesoriai turėtų pradėti nuo duomenų teisingumo patikrinimo, šiukšlių ir „sugedusių“ įvykių išfiltravimo. Patvirtinimui dažniausiai naudojame . Po to galima atlikti duomenų atvaizdavimą: duomenys iš skirtingų šaltinių yra normalizuojami ir standartizuojami, kad būtų įtraukti į bendrą lentelę.
3. Duomenų bazė
Trečias žingsnis – išsaugoti normalizuotus įvykius. Dirbdami su paruošta analitine sistema dažnai turėsime prie jų prieiti, todėl svarbu pasirinkti patogią duomenų bazę.
Jei duomenys gerai tinka fiksuotoje schemoje, galite pasirinkti ar kita stulpelių duomenų bazė. Taigi agregacijos veiks labai greitai. Neigiama yra tai, kad schema yra griežtai fiksuota, todėl nebus galima pridėti savavališkų objektų be patobulinimų (pavyzdžiui, kai įvyksta nestandartinis įvykis). Bet tai galima padaryti tikrai greitai.
Jei norite gauti nestruktūruotų duomenų, galite naudoti NoSQL, pavyzdžiui, . Jis veikia HDFS, gerai atkuria, galite sukurti daug atvejų ir yra atsparus gedimams.
Galite iškelti ką nors paprastesnio, pvz. . Tai gana lėta net ir mažiems kiekiams. Tačiau pliusas yra tai, kad jis yra labai paprastas ir todėl tinkamas pradžiai.
4. Agregatai
Atidžiai išsaugoję visus įvykius, norime surinkti visą svarbią informaciją iš gautos partijos ir atnaujinti duomenų bazę. Visame pasaulyje norime atitinkamų prietaisų skydelių ir metrikos. Pavyzdžiui, iš įvykių rinkti vartotojo profilį ir kažkaip įvertinti elgesį. Įvykiai kaupiami, renkami ir vėl įrašomi (jau vartotojų lentelėse). Tuo pačiu galima sukurti sistemą taip, kad prie koordinuojančio agregatoriaus būtų prijungtas ir filtras: rinkti vartotojus tik iš tam tikro tipo įvykių.
Po to, jei kam nors iš komandos reikia tik aukšto lygio analizės, galite prijungti išorines analizės sistemas. Galite vėl vartoti Mixpanel. bet kadangi tai gana brangu, ten siunčiami ne visi vartotojo įvykiai, o tik tai, ko reikia. Norėdami tai padaryti, turime sukurti koordinatorių, kuris perkeltų kai kuriuos neapdorotus įvykius ar tai, ką mes patys anksčiau sujungėme į išorines sistemas, API ar reklamos platformas.
5. Frontend
Turite prijungti priekinę dalį prie sukurtos sistemos. Puikus pavyzdys yra aptarnavimas. , yra duomenų bazės GUI, padedanti kurti skydelius. Kaip veikia sąveika:
- Vartotojas pateikia SQL užklausą.
- Atsakydamas jis gauna ženklą.
- Sukuria jam „naują vizualizaciją“ ir gauna gražų grafiką, kurį jau galite išsaugoti patys.
Paslaugoje esančios vizualizacijos atnaujinamos automatiškai, galite konfigūruoti ir sekti stebėjimą. „Redash“ yra nemokamas, jei tai yra savarankiškai, tačiau kaip „SaaS“ tai kainuos 50 USD per mėnesį.
išvada
Atlikę visus aukščiau nurodytus veiksmus, sukursite serverio analizę. Atminkite, kad tai nėra taip paprasta, kaip tiesiog prijungti kliento analizę, nes viską reikia sukonfigūruoti patiems. Todėl prieš kuriant savo sistemą verta palyginti rimtos analitinės sistemos poreikį su resursais, kuriuos esate pasiruošę jai skirti.
Jei atlikote visus skaičiavimus ir pastebėjote, kad išlaidos yra per didelės, kitoje dalyje kalbėsiu apie tai, kaip sukurti pigesnę atgalinės analitikos versiją.
Ačiū, kad skaitėte! Mielai atsakysiu į klausimus komentaruose.
Šaltinis: www.habr.com