Ito ang pangalawang bahagi ng serye ng mga artikulo tungkol sa mga sistemang analitikal ().
Ngayon ay wala nang duda na ang maingat na pagproseso ng data at interpretasyon ng mga resulta ay makakatulong sa halos anumang uri ng negosyo. Sa pagsasaalang-alang na ito, ang mga analytical system ay lalong nagiging puno ng mga parameter, at ang bilang ng mga nag-trigger at mga kaganapan ng user sa mga application ay lumalaki.
Dahil dito, binibigyan ng mga kumpanya ang kanilang mga analyst ng higit at higit pang hilaw na impormasyon upang pag-aralan at maging maayos na mga desisyon. Ang kahalagahan ng isang analytics system para sa isang kumpanya ay hindi dapat maliitin, at ang system mismo ay dapat na maaasahan at matatag.
Mga analyst ng kliyente
Ang customer analytics ay isang serbisyong ikinokonekta ng isang kumpanya sa website o application nito sa pamamagitan ng opisyal na SDK, isinasama sa sarili nitong codebase at pumipili ng mga trigger ng kaganapan. May malinaw na downside sa diskarteng ito: ang lahat ng data na nakolekta ay maaaring hindi maproseso nang eksakto tulad ng gusto mo dahil sa mga limitasyon ng anumang serbisyo na iyong pipiliin. Halimbawa, sa isang sistema ay hindi magiging madali ang pagpapatakbo ng mga gawain sa MapReduce, sa isa pa ay hindi mo magagawang patakbuhin ang iyong modelo. Ang isa pang disbentaha ay ang regular (kahanga-hangang) bill para sa mga serbisyo.
Mayroong maraming mga solusyon sa analytics ng customer sa merkado, ngunit maaga o huli ang mga analyst ay nahaharap sa katotohanan na walang isang unibersal na serbisyo na angkop para sa bawat gawain (habang ang mga presyo para sa lahat ng mga serbisyong ito ay tumataas sa lahat ng oras). Sa ganoong sitwasyon, madalas na nagpapasya ang mga kumpanya na lumikha ng sarili nilang analytics system kasama ang lahat ng kinakailangang custom na setting at kakayahan.
Mga analyst ng server
Ang server-side analytics ay isang serbisyo na maaaring i-deploy sa loob ng isang kumpanya sa sarili nitong mga server at (karaniwan) gamit ang sarili nitong pagsisikap. Sa modelong ito, ang lahat ng mga kaganapan ng gumagamit ay naka-imbak sa mga panloob na server, na nagpapahintulot sa mga developer na subukan ang iba't ibang mga database ng imbakan at piliin ang pinaka-maginhawang arkitektura. At kahit na gusto mo pa ring gumamit ng third-party na analytics ng kliyente para sa ilang gawain, magiging posible pa rin ito.
Maaaring i-deploy ang server-side analytics sa dalawang paraan. Una: pumili ng ilang open source utility, i-deploy ang mga ito sa iyong mga makina at bumuo ng lohika ng negosyo.
Pros
Cons
Maaari mong i-customize ang anumang gusto mo
Ito ay kadalasang napakahirap at nangangailangan ng hiwalay na mga developer
Pangalawa: kumuha ng mga serbisyo ng SaaS (Amazon, Google, Azure) sa halip na ikaw mismo ang mag-deploy nito. Pag-uusapan natin ang tungkol sa SaaS nang mas detalyado sa ikatlong bahagi.
Pros
Cons
Maaaring ito ay mas mura sa katamtamang dami, ngunit sa malaking paglaki ito ay magiging masyadong mahal
Hindi posible na kontrolin ang lahat ng mga parameter
Ang pangangasiwa ay ganap na inililipat sa mga balikat ng tagapagbigay ng serbisyo
Hindi laging alam kung ano ang nasa loob ng serbisyo (maaaring hindi ito kailangan)
Paano mangolekta ng analytics ng server
Kung gusto nating lumayo sa paggamit ng client analytics at bumuo ng sarili natin, una sa lahat kailangan nating pag-isipan ang arkitektura ng bagong system. Sa ibaba ay sasabihin ko sa iyo ang hakbang-hakbang kung ano ang kailangan mong isaalang-alang, kung bakit kailangan ang bawat hakbang at kung anong mga tool ang maaari mong gamitin.
1. Pagtanggap ng data
Tulad ng sa kaso ng customer analytics, una sa lahat, pinipili ng mga analyst ng kumpanya ang mga uri ng mga kaganapan na gusto nilang pag-aralan sa hinaharap at kolektahin ang mga ito sa isang listahan. Karaniwan, ang mga kaganapang ito ay nangyayari sa isang partikular na pagkakasunud-sunod, na tinatawag na "patern ng kaganapan."
Susunod, isipin na ang isang mobile application (website) ay may mga regular na user (device) at maraming server. Upang ligtas na ilipat ang mga kaganapan mula sa mga device patungo sa mga server, kailangan ng isang intermediate na layer. Depende sa arkitektura, maaaring mayroong iba't ibang pila ng kaganapan.
- Ay , na ginagamit bilang isang pila para sa pagkolekta ng mga kaganapan.
Ayon sa noong 2014, nagpasya ang lumikha ng Apache Kafka na pangalanan ang software pagkatapos ng Franz Kafka dahil "ito ay isang sistemang na-optimize para sa pagsusulat" at dahil mahal niya ang mga gawa ni Kafka. β
Sa aming halimbawa, maraming producer ng data at consumer ng data (mga device at server), at tinutulungan sila ng Kafka na ikonekta ang mga ito sa isa't isa. Ang mga mamimili ay ilalarawan nang mas detalyado sa mga sumusunod na hakbang, kung saan sila ang magiging pangunahing paksa. Ngayon ay isasaalang-alang lamang namin ang mga producer ng data (mga kaganapan).
Inilalagay ng Kafka ang mga konsepto ng queue at partition; mas mahusay na magbasa nang mas partikular tungkol dito sa ibang lugar (halimbawa, sa ). Nang hindi pumunta sa mga detalye, isipin natin na ang isang mobile application ay inilunsad para sa dalawang magkaibang OS. Pagkatapos, ang bawat bersyon ay gumagawa ng sarili nitong hiwalay na stream ng kaganapan. Ang mga producer ay nagpapadala ng mga kaganapan sa Kafka, sila ay naitala sa isang angkop na pila.
(larawan )
Kasabay nito, pinapayagan ka ng Kafka na magbasa nang paunti-unti at magproseso ng isang stream ng mga kaganapan sa mga mini-batch. Ang Kafka ay isang napaka-maginhawang tool na mahusay na sumusukat sa lumalaking pangangailangan (halimbawa, sa pamamagitan ng geolocation ng mga kaganapan).
Karaniwan ang isang shard ay sapat, ngunit ang mga bagay ay nagiging mas kumplikado kapag nag-scale (tulad ng lagi nilang ginagawa). Malamang na walang gustong gumamit lamang ng isang pisikal na shard sa produksyon, dahil ang arkitektura ay dapat na fault-tolerant. Bilang karagdagan sa Kafka, mayroong isa pang kilalang solusyon - RabbitMQ. Hindi namin ito ginamit sa produksyon bilang isang pila para sa analytics ng kaganapan (kung mayroon kang ganoong karanasan, sabihin sa amin ang tungkol dito sa mga komento!). Gayunpaman, ginamit namin ang AWS Kinesis.
Bago lumipat sa susunod na hakbang, kailangan nating banggitin ang isa pang karagdagang layer ng system - raw log storage. Ito ay hindi kinakailangang layer, ngunit ito ay magiging kapaki-pakinabang kung may mali at ang mga queue ng kaganapan sa Kafka ay na-reset. Ang pag-iimbak ng mga hilaw na log ay hindi nangangailangan ng isang kumplikado at mahal na solusyon; maaari mo lamang isulat ang mga ito sa isang lugar sa tamang pagkakasunud-sunod (kahit na sa isang hard drive).
2. Pagproseso ng mga stream ng kaganapan
Pagkatapos naming maihanda ang lahat ng mga kaganapan at ilagay ang mga ito sa naaangkop na mga pila, kami ay nagpapatuloy sa hakbang sa pagproseso. Dito sasabihin ko sa iyo ang tungkol sa dalawang pinakakaraniwang opsyon sa pagproseso.
Ang unang opsyon ay paganahin ang Spark Streaming sa Apache system. Lahat ng produkto ng Apache ay nakatira sa HDFS, isang secure na file system na may mga replika ng file. Ang Spark Streaming ay isang madaling gamitin na tool na mahusay na humahawak ng streaming data at mga sukat. Gayunpaman, maaaring mahirap itong mapanatili.
Ang isa pang pagpipilian ay ang bumuo ng iyong sariling tagapangasiwa ng kaganapan. Upang gawin ito, kailangan mo, halimbawa, na magsulat ng isang Python application, itayo ito sa Docker at mag-subscribe sa Kafka queue. Kapag dumating ang mga trigger sa mga tagapangasiwa ng docker, magsisimula ang pagproseso. Sa pamamaraang ito, kailangan mong panatilihing tumatakbo ang mga application sa lahat ng oras.
Ipagpalagay natin na pinili natin ang isa sa mga opsyon na inilarawan sa itaas at magpatuloy sa pagproseso mismo. Dapat magsimula ang mga processor sa pamamagitan ng pagsuri sa validity ng data, pag-filter ng basura at mga "sirang" kaganapan. Para sa pagpapatunay na karaniwan naming ginagamit . Pagkatapos nito, maaari kang gumawa ng pagmamapa ng data: ang data mula sa iba't ibang mapagkukunan ay na-normalize at na-standardize upang maidagdag sa isang karaniwang talahanayan.
3. Database
Ang ikatlong hakbang ay upang mapanatili ang normalized na mga kaganapan. Kapag nagtatrabaho sa isang handa na analytical system, kailangan naming i-access ang mga ito nang madalas, kaya mahalagang pumili ng isang maginhawang database.
Kung ang data ay akma nang maayos sa isang nakapirming scheme, maaari kang pumili o ilang iba pang columnar database. Sa ganitong paraan ang mga pagsasama-sama ay gagana nang napakabilis. Ang downside ay ang scheme ay mahigpit na naayos at samakatuwid ay hindi posible na magdagdag ng mga arbitrary na bagay nang walang pagbabago (halimbawa, kapag nangyari ang isang hindi karaniwang kaganapan). Ngunit napakabilis mong mabilang.
Para sa hindi nakabalangkas na data, maaari mong kunin ang NoSQL, halimbawa, . Gumagana ito sa HDFS, mahusay na umuulit, maaari kang magtaas ng maraming pagkakataon, at hindi mapagparaya.
Maaari ka ring magtaas ng isang bagay na mas simple, halimbawa, . Ito ay medyo mabagal at para sa maliliit na volume. Ngunit ang plus ay na ito ay napaka-simple at samakatuwid ay angkop para sa pagsisimula.
4. Pagsasama-sama
Ang pagkakaroon ng maingat na nai-save ang lahat ng mga kaganapan, gusto naming kolektahin ang lahat ng mahalagang impormasyon mula sa batch na dumating at i-update ang database. Sa buong mundo, gusto naming makakuha ng mga nauugnay na dashboard at sukatan. Halimbawa, mangolekta ng profile ng user mula sa mga kaganapan at kahit papaano ay sukatin ang pag-uugali. Ang mga kaganapan ay pinagsama-sama, kinokolekta, at nai-save muli (sa mga talahanayan ng user). Kasabay nito, maaari kang bumuo ng isang system upang maaari mo ring ikonekta ang isang filter sa aggregator-coordinator: mangolekta lamang ng mga user mula sa isang partikular na uri ng kaganapan.
Pagkatapos noon, kung kailangan lang ng isang tao sa team ng high-level analytics, maaaring ikonekta ang mga external na analytics system. Maaari mong kunin muli ang Mixpanel. ngunit dahil ito ay medyo mahal, hindi lahat ng mga kaganapan ng gumagamit ay ipinadala doon, ngunit kung ano lamang ang kailangan. Upang gawin ito, kailangan naming lumikha ng isang coordinator na maglilipat ng ilang mga raw na kaganapan o isang bagay na kami mismo ang pinagsama-sama nang mas maaga sa mga panlabas na system, API o platform ng advertising.
5. Frontend
Kailangan mong ikonekta ang frontend sa nilikhang system. Ang isang magandang halimbawa ay serbisyo , ay isang database GUI na tumutulong sa pagbuo ng mga dashboard. Paano gumagana ang pakikipag-ugnayan:
- Gumagawa ang user ng SQL query.
- Bilang tugon ay nakatanggap siya ng isang tanda.
- Lumilikha ito ng 'bagong visualization' para dito at nakakakuha ng magandang graph na maaari mong i-save para sa iyong sarili.
Ang mga visualization sa serbisyo ay awtomatikong ina-update, maaari mong i-customize at subaybayan ang iyong pagsubaybay. Ang Redash ay libre kung self-host, ngunit bilang SaaS nagkakahalaga ito ng $50 bawat buwan.
Konklusyon
Pagkatapos makumpleto ang lahat ng mga hakbang sa itaas, gagawa ka ng analytics ng iyong server. Pakitandaan na hindi ito kasing simple ng pagkonekta lamang ng analytics ng customer, dahil kailangan mong i-configure ang lahat. Samakatuwid, bago lumikha ng iyong sariling system, sulit na ihambing ang pangangailangan para sa isang seryosong sistema ng analytics sa mga mapagkukunan na handa mong ilaan dito.
Kung nagawa mo na ang matematika at nalaman mong masyadong mataas ang mga gastos, sa susunod na bahagi ay pag-uusapan ko kung paano gumawa ng mas murang bersyon ng server-side analytics.
Salamat sa pagbabasa! Natutuwa akong magtanong sa mga komento.
Pinagmulan: www.habr.com