See on analüütilisi süsteeme käsitlevate artiklite sarja teine osa ().
Tänapäeval pole enam kahtlust, et hoolikas andmetöötlus ja tulemuste tõlgendamine võib aidata peaaegu igat tüüpi äritegevust. Sellega seoses on analüütilised süsteemid parameetritega üha enam koormatud ning rakenduste käivitajate ja kasutajasündmuste arv kasvab.
Seetõttu annavad ettevõtted oma analüütikutele analüüsimiseks ja mõistlikeks otsusteks muutmiseks üha rohkem toores teavet. Analüütikasüsteemi tähtsust ettevõtte jaoks ei tasu alahinnata ning süsteem ise peab olema töökindel ja stabiilne.
Kliendianalüütikud
Kliendianalüütika on teenus, mille ettevõte loob ametliku SDK kaudu oma veebisaidi või rakendusega ühenduse, integreerib oma koodibaasi ja valib sündmuste käivitajad. Sellel lähenemisviisil on ilmne negatiivne külg: kõiki kogutud andmeid ei pruugita teie valitud teenuse piirangute tõttu töödelda täpselt nii, nagu soovite. Näiteks ühes süsteemis ei ole MapReduce'i ülesannete käivitamine lihtne, teises ei saa te oma mudelit käivitada. Teine puudus on tavaline (muljetavaldav) teenuste arve.
Kliendianalüütika lahendusi on turul palju, kuid varem või hiljem seisavad analüütikud silmitsi tõsiasjaga, et iga ülesande jaoks sobivat universaalteenust pole (samas kõigi nende teenuste hinnad kogu aeg tõusevad). Sellises olukorras otsustavad ettevõtted sageli luua oma analüüsisüsteemi koos kõigi vajalike kohandatud sätete ja võimalustega.
Serveri analüütikud
Serveripoolne analüütika on teenus, mida saab juurutada ettevõtte sees oma serverites ja (tavaliselt) oma jõupingutustega. Selles mudelis salvestatakse kõik kasutaja sündmused siseserveritesse, mis võimaldab arendajatel proovida erinevaid salvestusandmebaase ja valida kõige mugavama arhitektuuri. Ja isegi kui soovite mõne ülesande jaoks siiski kasutada kolmanda osapoole kliendianalüüsi, on see siiski võimalik.
Serveripoolset analüüsi saab juurutada kahel viisil. Esiteks: valige mõned avatud lähtekoodiga utiliidid, juurutage need oma masinatesse ja arendage äriloogikat.
Plusse
Miinused
Saate kohandada kõike, mida soovite
See on sageli väga keeruline ja nõuab eraldi arendajaid
Teiseks: kasutage SaaS-i teenuseid (Amazon, Google, Azure), selle asemel, et seda ise juurutada. SaaS-ist räägime lähemalt kolmandas osas.
Plusse
Miinused
Keskmiste mahtude juures võib see odavam olla, aga suure kasvu korral läheb ikka liiga kalliks
Kõiki parameetreid ei ole võimalik juhtida
Haldamine läheb täielikult teenusepakkuja õlule
Alati pole teada, mis teenuse sees on (seda ei pruugi vaja minna)
Kuidas koguda serverianalüüsi
Kui tahame kliendianalüütika kasutamisest eemalduda ja enda oma üles ehitada, tuleb ennekõike läbi mõelda uue süsteemi arhitektuur. Allpool räägin teile samm-sammult, millega peate arvestama, miks iga samm on vajalik ja milliseid tööriistu saate kasutada.
1. Andmete vastuvõtmine
Nii nagu kliendianalüütika puhul, valivad ettevõtte analüütikud esmalt välja sündmusetüübid, mida nad edaspidi uurida soovivad, ja koondavad need nimekirja. Tavaliselt toimuvad need sündmused kindlas järjekorras, mida nimetatakse "sündmusmustriks".
Järgmiseks kujutage ette, et mobiilirakendusel (veebisaidil) on tavakasutajaid (seadmeid) ja palju servereid. Sündmuste turvaliseks ülekandmiseks seadmetest serveritesse on vaja vahekihti. Sõltuvalt arhitektuurist võib olla mitu erinevat sündmuste järjekorda.
- Kas , mida kasutatakse sündmuste kogumise järjekorrana.
Vastavalt 2014. aastal otsustas Apache Kafka looja anda tarkvarale nime Franz Kafka järgi, kuna "see on kirjutamiseks optimeeritud süsteem" ja kuna ta armastas Kafka teoseid. —
Meie näites on palju andmetootjaid ja andmetarbijaid (seadmed ja serverid) ning Kafka aitab neid omavahel ühendada. Tarbijaid kirjeldatakse üksikasjalikumalt järgmistes etappides, kus nemad on peamised teemad. Nüüd käsitleme ainult andmetootjaid (sündmusi).
Kafka kapseldab järjekorra ja partitsiooni mõisted, parem on selle kohta täpsemalt lugeda mujalt (näiteks ). Detailidesse laskumata kujutame ette, et mobiilirakendus käivitatakse kahe erineva OS-i jaoks. Seejärel loob iga versioon oma eraldi sündmustevoo. Produtsendid saadavad üritused Kafkale, need salvestatakse sobivasse järjekorda.
(pilt )
Samal ajal võimaldab Kafka lugeda tükkidena ja töödelda sündmuste voogu minipartiidena. Kafka on väga mugav tööriist, mis sobib hästi kasvavate vajadustega (näiteks sündmuste geograafilise asukoha järgi).
Tavaliselt piisab ühest killust, aga skaleerimisel läheb asi keerulisemaks (nagu ikka). Tõenäoliselt ei taha keegi tootmises kasutada ainult ühte füüsilist kildu, kuna arhitektuur peab olema veakindel. Lisaks Kafkale on veel üks tuntud lahendus - RabbitMQ. Tootmises me seda sündmuste analüütika järjekorrana ei kasutanud (kui teil on selline kogemus, andke sellest kommentaarides teada!). Küll aga kasutasime AWS Kinesist.
Enne järgmise sammu juurde asumist peame mainima veel üht süsteemi lisakihti – toorpalgihoidla. See ei ole kohustuslik kiht, kuid see on kasulik, kui midagi läheb valesti ja Kafka sündmuste järjekorrad lähtestatakse. Töötlemata logide salvestamine ei nõua keerulist ja kallist lahendust, need saab lihtsalt kuskile õiges järjekorras kirjutada (kasvõi kõvakettale).
2. Sündmuste voogude töötlemine
Kui oleme kõik sündmused ette valmistanud ja vastavatesse järjekordadesse paigutanud, liigume edasi töötlemisetapi juurde. Siin räägin teile kahest kõige tavalisemast töötlemisvalikust.
Esimene võimalus on lubada Apache süsteemis Spark Streaming. Kõik Apache tooted töötavad HDFS-is, mis on failide koopiatega turvaline failisüsteem. Spark Streaming on lihtsalt kasutatav tööriist, mis käsitleb voogesituse andmeid ja skaleerib hästi. Selle hooldamine võib aga olla keeruline.
Teine võimalus on luua oma sündmuste käitleja. Selleks on vaja näiteks kirjutada Pythoni rakendus, ehitada see Dockeris ja tellida Kafka järjekord. Kui päästikud jõuavad dokkide käitlejatele, algab töötlemine. Selle meetodi puhul peate rakendused pidevalt töötama.
Oletame, et oleme valinud ühe ülalkirjeldatud valikutest ja liigume edasi töötlemise enda juurde. Protsessorid peaksid alustama andmete õigsuse kontrollimisest, prügi ja "katkiste" sündmuste filtreerimisest. Tavaliselt kasutame valideerimiseks . Pärast seda saate teha andmete kaardistamist: erinevatest allikatest pärinevad andmed normaliseeritakse ja standarditakse, et need ühisesse tabelisse lisada.
3. Andmebaas
Kolmas samm on normaliseeritud sündmuste säilitamine. Valmis analüütilise süsteemiga töötades peame neile sageli juurde pääsema, seega on oluline valida mugav andmebaas.
Kui andmed sobivad hästi fikseeritud skeemi, saate valida või mõni muu veeruline andmebaas. Nii toimivad liited väga kiiresti. Negatiivne külg on see, et skeem on jäigalt fikseeritud ja seetõttu ei ole võimalik suvalisi objekte ilma muutmata lisada (näiteks ebastandardse sündmuse korral). Aga sa oskad tõesti väga kiiresti lugeda.
Struktureerimata andmete jaoks võite võtta näiteks NoSQL-i . See töötab HDFS-is, paljuneb hästi, saate esitada palju juhtumeid ja on tõrketaluv.
Võite tõstatada ka midagi lihtsamat, näiteks . See on üsna aeglane ja väikeste mahtude jaoks. Kuid pluss on see, et see on väga lihtne ja seetõttu sobib alustamiseks.
4. Agregaadid
Olles kõik sündmused hoolikalt salvestanud, soovime koguda saabunud partiist kogu olulise teabe ja uuendada andmebaasi. Ülemaailmselt tahame saada asjakohaseid armatuurlaudu ja mõõdikuid. Näiteks koguge sündmustest kasutajaprofiil ja mõõtke käitumist. Sündmused koondatakse, kogutakse ja salvestatakse uuesti (kasutajate tabelitesse). Samal ajal saab ehitada süsteemi nii, et saad ühendada ka filtri koondaja-koordinaatoriga: koguda kasutajaid ainult teatud tüüpi sündmustelt.
Pärast seda, kui keegi meeskonnast vajab ainult kõrgetasemelist analüütikat, saab ühendada välised analüüsisüsteemid. Võite Mixpaneli uuesti võtta. aga kuna see on üsna kallis, siis ei saadeta sinna kõiki kasutaja sündmusi, vaid ainult seda, mida vaja. Selleks peame looma koordinaatori, kes kannab mõne toore sündmuse või midagi, mille me ise varem koondasime, üle välistele süsteemidele, API-dele või reklaamiplatvormidele.
5. Frontend
Peate ühendama kasutajaliidese loodud süsteemiga. Hea näide on teenindus , on andmebaasi GUI, mis aitab luua armatuurlaudu. Kuidas interaktsioon toimib:
- Kasutaja teeb SQL-päringu.
- Vastuseks saab ta märgi.
- See loob selle jaoks "uue visualiseerimise" ja saab ilusa graafiku, mille saate ise salvestada.
Teenuse visualiseeringud uuenevad automaatselt, saate oma jälgimist kohandada ja jälgida. Redash on isehostituna tasuta, kuid SaaS-ina maksab see 50 dollarit kuus.
Järeldus
Pärast kõigi ülaltoodud sammude täitmist loote oma serveri analüüsi. Pange tähele, et see pole nii lihtne kui lihtsalt kliendianalüüsi ühendamine, sest kõik tuleb ise konfigureerida. Seetõttu tasub enne oma süsteemi loomist võrrelda tõsiseltvõetava analüüsisüsteemi vajadust ressurssidega, mida olete nõus sellele eraldama.
Kui olete arvutanud ja leidnud, et kulud on liiga suured, siis järgmises osas räägin sellest, kuidas teha serveripoolsest analüüsist odavamat versiooni.
Täname lugemise eest! Hea meelega esitan kommentaarides küsimusi.
Allikas: www.habr.com