Tämä on analyyttisiä järjestelmiä käsittelevän artikkelisarjan toinen osa ().
Nykyään ei ole epäilystäkään siitä, että tietojen tarkka käsittely ja tulosten tulkinta voivat auttaa lähes kaiken tyyppistä liiketoimintaa. Tässä suhteessa analyyttiset järjestelmät ovat yhä enemmän kuormitettuja parametreilla, laukaisujen ja käyttäjätapahtumien määrä sovelluksissa kasvaa.
Tämän vuoksi yritykset antavat analyytikoilleen yhä enemmän "raaka" tietoa analysoitavaksi ja muuttamiseksi oikeiksi päätöksiksi. Analyysijärjestelmän merkitystä yritykselle ei pidä aliarvioida, ja itse järjestelmän tulee olla luotettava ja kestävä.
Asiakasanalyytikot
Asiakasanalytiikka on palvelu, jonka yritys yhdistää verkkosivustoonsa tai sovellukseensa virallisen SDK:n kautta, integroi sen omaan koodikantaansa ja valitsee tapahtumatriggerit. Tällä lähestymistavalla on ilmeinen haittapuoli: kaikkia kerättyjä tietoja ei ehkä käsitellä juuri niin kuin haluaisit minkä tahansa valitsemasi palvelun rajoitusten vuoksi. Esimerkiksi yhdessä järjestelmässä MapReduce-tehtävien suorittaminen ei ole helppoa, toisessa et voi ajaa malliasi. Toinen haittapuoli on tavallinen (vaikuttava) palvelulasku.
Markkinoilla on monia asiakasanalytiikkaratkaisuja, mutta ennemmin tai myöhemmin analyytikot kohtaavat sen tosiasian, että mihinkään tehtävään sopivaa yleispalvelua ei ole olemassa (kaikkien palveluiden hinnat nousevat jatkuvasti). Tällaisessa tilanteessa yritykset päättävät usein luoda oman analytiikkajärjestelmän, jossa on kaikki tarvittavat mukautetut asetukset ja ominaisuudet.
Palvelinanalyytikot
Palvelinpuolen analytiikka on palvelu, joka voidaan ottaa käyttöön yrityksen sisällä sen omilla palvelimilla ja (yleensä) omin voimin. Tässä mallissa kaikki käyttäjätapahtumat tallennetaan sisäisille palvelimille, jolloin kehittäjät voivat kokeilla erilaisia tallennustietokantoja ja valita sopivimman arkkitehtuurin. Ja vaikka haluaisit edelleen käyttää kolmannen osapuolen asiakasanalytiikkaa joihinkin tehtäviin, se on silti mahdollista.
Palvelinpuolen analytiikkaa voidaan ottaa käyttöön kahdella tavalla. Ensinnäkin: valitse joitain avoimen lähdekoodin apuohjelmia, ota ne käyttöön koneillasi ja kehitä liiketoimintalogiikkaa.
Pros
Miinukset
Voit muokata mitä haluat
Tämä on usein erittäin vaikeaa ja vaatii erilliset kehittäjät
Toiseksi: ota SaaS-palvelut (Amazon, Google, Azure) sen sijaan, että otat sen käyttöön itse. Puhumme SaaS:sta tarkemmin kolmannessa osassa.
Pros
Miinukset
Se voi olla halvempi keskisuurilla volyymeillä, mutta suurella korotuksella siitä tulee silti liian kallis
Kaikkia parametreja ei ole mahdollista hallita
Hallinto siirtyy kokonaan palveluntarjoajan harteille
Aina ei tiedetä, mitä palvelussa on (ei välttämättä tarvita)
Kuinka kerätä palvelinanalytiikkaa
Jos haluamme päästä eroon asiakasanalytiikan käytöstä ja rakentaa omaa, meidän on ensin mietittävä uuden järjestelmän arkkitehtuuria. Alla kerron sinulle vaihe vaiheelta, mitä sinun tulee ottaa huomioon, miksi kutakin vaihetta tarvitaan ja mitä työkaluja voit käyttää.
1. Tiedonkeruu
Aivan kuten asiakasanalytiikan tapauksessa, yritysanalyytikot valitsevat ensin tapahtumatyypit, joita he haluavat tutkia tarkemmin ja keräävät ne luetteloon. Yleensä nämä tapahtumat tapahtuvat tietyssä järjestyksessä, jota kutsutaan "tapahtumaohjelmaksi".
Kuvitellaan edelleen, että mobiilisovelluksella (verkkosivustolla) on tavallisia käyttäjiä (laitteita) ja useita palvelimia. Jotta tapahtumia voidaan siirtää turvallisesti laitteilta palvelimille, tarvitaan välitaso. Arkkitehtuurista riippuen voi esiintyä useita erilaisia tapahtumajonoja.
- Onko , jota käytetään jonona tapahtumien keräämiseen.
Mukaan Vuonna 2014 Apache Kafkan luoja päätti nimetä ohjelmiston Franz Kafkan mukaan, koska "se on kirjoittamiseen optimoitu järjestelmä" ja koska hän rakasti Kafkan teoksia. —
Esimerkissämme on monia tiedontuottajia ja heidän kuluttajiaan (laitteita ja palvelimia), ja Kafka auttaa yhdistämään heidät toisiinsa. Kuluttajia kuvataan tarkemmin seuraavissa vaiheissa, joissa he ovat päätoimijoita. Nyt otetaan huomioon vain tiedon tuottajat (tapahtumat).
Kafka kiteyttää jonon ja osion käsitteet, tarkemmin tästä on parempi lukea muualta (esim. ). Yksityiskohtiin menemättä kuvitellaan, että mobiilisovellus käynnistetään kahdelle eri käyttöjärjestelmälle. Sitten jokainen versio luo oman erillisen tapahtumavirran. Tuottajat lähettävät tapahtumia Kafkaan, ne tallennetaan sopivaan jonoon.
(kuva )
Samaan aikaan Kafka antaa sinun lukea paloina ja käsitellä tapahtumien kulkua pienissä erissä. Kafka on erittäin kätevä työkalu, joka skaalautuu hyvin kasvaviin tarpeisiin (esimerkiksi tapahtumien paikantamiseen).
Yleensä yksi sirpale riittää, mutta asiat muuttuvat monimutkaisemmiksi skaalattaessa (kuten aina). Todennäköisesti kukaan ei halua käyttää tuotannossa vain yhtä fyysistä sirpaletta, koska arkkitehtuurin on oltava vikasietoinen. Kafkan lisäksi on olemassa toinenkin tunnettu ratkaisu - RabbitMQ. Emme käyttäneet sitä tuotannossa tapahtumaanalytiikan jonona (jos sinulla on kokemusta, kerro siitä meille kommenteissa!). Kuitenkin AWS Kinesis käytettiin.
Ennen kuin siirrymme seuraavaan vaiheeseen, meidän on mainittava vielä yksi järjestelmän lisäkerros - raakalokin varastointi. Tämä ei ole pakollinen taso, mutta siitä on hyötyä, jos jokin menee pieleen ja Kafkan tapahtumajonot nollataan. Raakalokien tallentaminen ei vaadi monimutkaista ja kallista ratkaisua, voit kirjoittaa ne jonnekin oikeassa järjestyksessä (jopa kiintolevylle).
2. Tapahtumavirtojen käsittely
Kun kaikki tapahtumat on valmisteltu ja asetettu jonoihin, siirrytään käsittelyvaiheeseen. Tässä kerron sinulle kahdesta yleisimmästä käsittelyvaihtoehdosta.
Ensimmäinen vaihtoehto on ottaa Spark Streaming käyttöön Apache-järjestelmässä. Kaikki Apache-tuotteet toimivat HDFS:ssä, turvallisessa kopiotiedostojärjestelmässä. Spark Streaming on helppokäyttöinen työkalu, joka käsittelee suoratoistodataa ja skaalautuu hyvin. Sen ylläpitäminen voi kuitenkin olla vaikeaa.
Toinen vaihtoehto on rakentaa oma tapahtumakäsittelijä. Tätä varten sinun on esimerkiksi kirjoitettava Python-sovellus, rakennettava se Dockerissa ja tilattava Kafkan jonot. Kun laukaisimet tulevat telakointiaseman käsittelijöille, käsittely alkaa. Tällä menetelmällä sinun on pidettävä sovelluksia jatkuvasti käynnissä.
Oletetaan, että olemme valinneet jonkin yllä kuvatuista vaihtoehdoista ja siirrytään itse käsittelyyn. Prosessorien tulee aloittaa tarkistamalla tietojen oikeellisuus, suodattamalla pois roskat ja "rikkinäiset" tapahtumat. Käytämme yleensä validointiin . Tämän jälkeen voidaan tehdä datakartoitus: eri lähteistä tulevat tiedot normalisoidaan ja standardoidaan, jotta ne voidaan lisätä yhteiseen taulukkoon.
3. Tietokanta
Kolmas askel on ylläpitää normalisoituja tapahtumia. Kun työskentelemme valmiin analyysijärjestelmän kanssa, joudumme usein käyttämään niitä, joten on tärkeää valita kätevä tietokanta.
Jos tiedot sopivat hyvin kiinteään kaavioon, voit valita tai jokin muu saraketietokanta. Näin aggregaatit toimivat hyvin nopeasti. Haittapuolena on, että järjestelmä on jäykästi kiinteä ja siksi ei ole mahdollista lisätä mielivaltaisia objekteja ilman muutoksia (esimerkiksi kun tapahtuu epästandardi tapahtuma). Mutta osaat laskea todella nopeasti.
Strukturoimattomille tiedoille voit ottaa esimerkiksi NoSQL:n . Se toimii HDFS:llä, replikoituu hyvin, voit nostaa useita esiintymiä ja on vikasietoinen.
Voit myös nostaa jotain yksinkertaisempaa, esim. . Se on melko hidas pienilläkin määrillä. Mutta plussa on, että se on hyvin yksinkertainen ja siksi sopii aloittamiseen.
4. Aggregaatiot
Kun kaikki tapahtumat on tallennettu huolellisesti, haluamme kerätä kaikki tärkeät tiedot saapuneesta erästä ja päivittää tietokannan. Maailmanlaajuisesti haluamme saada asiaankuuluvia kojetauluja ja mittareita. Kerää esimerkiksi tapahtumista käyttäjäprofiili ja mittaa käyttäytymistä jollain tavalla. Tapahtumat kootaan, kerätään ja tallennetaan uudelleen (käyttäjätaulukoihin). Samalla voit rakentaa järjestelmän niin, että voit myös liittää suodattimen aggregaattori-koordinaattoriin: kerää käyttäjiä vain tietyntyyppisestä tapahtumasta.
Sen jälkeen, jos joku tiimistä tarvitsee vain korkean tason analytiikkaa, voit liittää ulkoisia analytiikkajärjestelmiä. Voit ottaa Mixpanelin uudelleen. mutta koska se on melko kallista, kaikkia käyttäjätapahtumia ei lähetetä sinne, vaan vain sitä mitä tarvitaan. Tätä varten meidän on luotava koordinaattori, joka siirtää joitain raakatapahtumia tai jotain, mitä olemme itse aiemmin aggregoineet ulkoisille järjestelmille, API:ille tai mainosalustoille.
5. Käyttöliittymä
Sinun on yhdistettävä käyttöliittymä luotuun järjestelmään. Hyvä esimerkki on palvelu. , on tietokantakäyttöliittymä, joka auttaa rakentamaan kojelaudat. Miten vuorovaikutus toimii:
- Käyttäjä tekee SQL-kyselyn.
- Vastauksena hän saa merkin.
- Luo sille "uuden visualisoinnin" ja saa kauniin kaavion, jonka voit jo tallentaa itse.
Palvelun visualisoinnit päivittyvät automaattisesti, voit konfiguroida ja seurata seurantaasi. Redash on ilmainen, jos se on itseisännöity, mutta SaaS-palveluna se maksaa 50 dollaria kuukaudessa.
Johtopäätös
Kun olet suorittanut kaikki yllä olevat vaiheet, luot palvelinpuolen analytiikan. Huomaa, että tämä ei ole niin helppoa kuin pelkkä asiakasanalytiikan yhdistäminen, koska kaikki on määritettävä itse. Siksi ennen oman järjestelmän luomista kannattaa verrata vakavan analytiikkajärjestelmän tarvetta siihen resursseihin, jotka olet valmis siihen osoittamaan.
Jos suoritit kaiken laskelman ja huomasit, että kustannukset ovat liian korkeat, seuraavassa osassa puhun siitä, kuinka voit tehdä halvemman version taustaanalytiikasta.
Kiitos lukemisesta! Vastaan mielelläni kysymyksiin kommenteissa.
Lähde: will.com