Ieu bagian kadua runtuyan artikel ngeunaan sistem analitik ().
Kiwari, henteu aya ragu yén ngolah data anu akurat sareng interpretasi hasil tiasa ngabantosan ampir sagala jinis usaha. Dina hal ieu, sistem analitik beuki dieusian ku parameter, jumlah pemicu sareng acara pangguna dina aplikasi naék.
Kusabab ieu, perusahaan masihan analis langkung seueur inpormasi "atah" pikeun nganalisis sareng janten kaputusan anu leres. Pentingna sistem analitik pikeun perusahaan henteu kedah diémutan, sareng sistem éta sorangan kedah dipercaya sareng lestari.
analis klien
Analitik klien mangrupikeun jasa anu dihubungkeun ku perusahaan pikeun halaman wéb atanapi aplikasina ngalangkungan SDK resmi, ngahijikeun kana basis kode sorangan, sareng milih pemicu acara. Pendekatan ieu ngagaduhan kalemahan anu écés: sadaya data anu dikumpulkeun henteu tiasa diolah ku cara anu anjeun pikahoyong, kusabab keterbatasan jasa anu dipilih. Salaku conto, dina hiji sistem éta moal gampang pikeun ngajalankeun tugas MapReduce, dina anu sanés anjeun moal tiasa ngajalankeun modél anjeun. disadvantage sejen bakal tagihan biasa (impressive) pikeun layanan.
Aya seueur solusi analitik klien di pasar, tapi engké atanapi engké, analis disanghareupan kanyataan yén teu aya hiji layanan universal anu cocog pikeun tugas naon waé (bari harga pikeun sadaya jasa ieu terus ningkat). Dina kaayaan kitu, pausahaan mindeng mutuskeun nyieun sistem analytics sorangan kalawan sagala setélan custom perlu jeung fitur.
Analis Server
Analitik sisi server mangrupikeun jasa anu tiasa disebarkeun sacara internal dina server perusahaan sorangan sareng (biasana) di-imah. Dina modél ieu, sadaya acara pangguna disimpen dina server internal, anu ngamungkinkeun para pamekar nyobian database anu béda pikeun neundeun sareng milih arsitéktur anu paling merenah. Sareng upami anjeun masih hoyong nganggo analytics sisi klien pihak katilu pikeun sababaraha pancén, éta bakal tiasa waé.
Analytics sisi server tiasa disebarkeun ku dua cara. Kahiji: milih sababaraha utilitas open source, nyebarkeun aranjeunna dina mesin anjeun sarta ngamekarkeun logika bisnis.
Плюсы
Минусы
Anjeun tiasa nyaluyukeun naon waé
Sering pisan sesah sareng pamekar anu misah diperyogikeun
Kadua: nyandak jasa SaaS (Amazon, Google, Azure) tinimbang nyebarkeunana sorangan. Urang bakal ngobrol ngeunaan SaaS sacara langkung rinci dina bagian katilu.
Плюсы
Минусы
Éta tiasa langkung mirah dina volume sedeng, tapi kalayan paningkatan anu ageung éta masih bakal mahal teuing
Henteu tiasa ngontrol sadaya parameter
Administrasi sagemblengna dipindahkeun kana taktak panyadia ladenan
Henteu salawasna dipikanyaho naon anu aya di jero jasa (panginten henteu diperyogikeun)
Kumaha carana ngumpulkeun analytics server
Lamun urang hayang meunang jauh ti ngagunakeun analytics klien tur ngawangun sorangan, mimiti sagala urang kudu mikir leuwih arsitektur sistem anyar. Di handap ieu kuring bakal nyarioskeun ka anjeun léngkah-léngkah naon anu anjeun kedah pertimbangkeun, naha masing-masing léngkah diperyogikeun sareng alat naon anu anjeun tiasa dianggo.
1. Ngumpulkeun data
Sapertos dina kasus analytics klien, mimitina, analis perusahaan milih jinis acara anu aranjeunna hoyong diajar langkung jauh sareng ngumpulkeun dina daptar. Biasana acara ieu lumangsung dina urutan nu tangtu, nu disebut "skema acara".
Salajengna, hayu urang ngabayangkeun yén hiji aplikasi mobile (website) boga pamaké biasa (alat) jeung loba server. Pikeun aman nransper acara ti alat ka server, hiji lapisan panengah diperlukeun. Gumantung kana arsitéktur, sababaraha antrian acara béda bisa lumangsung.
- eta , nu dipaké salaku antrian pikeun ngumpulkeun acara.
nurutkeun dina 2014, panyipta Apache Kafka mutuskeun pikeun ngaranan parangkat lunak ku Franz Kafka sabab "éta sistem anu dioptimalkeun pikeun nulis" sareng kusabab anjeunna resep kana tulisan Kafka. —
Dina conto urang, aya loba produser data jeung konsumén maranéhanana (alat jeung server), sarta Kafka mantuan nyambungkeun aranjeunna ka unggal lianna. Konsumén bakal dijelaskeun sacara langkung rinci dina léngkah-léngkah salajengna, dimana aranjeunna bakal janten palaku utama. Ayeuna urang bakal mertimbangkeun ukur produser data (acara).
Kafka ngarangkum konsép antrian sareng partisi, langkung khusus ngeunaan ieu langkung saé maca di tempat sanés (contona, dina ). Tanpa ngintip detil, bayangkeun yén aplikasi sélulér diluncurkeun pikeun dua sistem operasi anu béda. Teras unggal vérsi nyiptakeun aliran acara anu misah. Produser ngirim acara ka Kafka, aranjeunna kacatet dina antrian anu cocog.
(gambar )
Dina waktos anu sami, Kafka ngamungkinkeun anjeun maca dina sakumpulan sareng ngolah aliran acara dina mini bets. Kafka mangrupikeun alat anu panggampangna anu cocog sareng kabutuhan ngembang (contona, ku geolokasi kajadian).
Biasana hiji beling cukup, tapi hal jadi leuwih pajeulit jeung komunikasi nalika skala (sakumaha salawasna). Panginten teu aya anu hoyong nganggo ngan ukur hiji beling fisik dina produksi, sabab arsitékturna kedah toleran. Salian Kafka, aya solusi anu terkenal - RabbitMQ. Kami henteu nganggo éta dina produksi salaku antrian pikeun analitik acara (upami anjeun gaduh pangalaman sapertos kitu, wartosan kami ngeunaan éta dina koméntar!). Nanging, AWS Kinesis dianggo.
Sateuacan ngaléngkah ka léngkah salajengna, hiji deui lapisan tambahan sistem kedah disebatkeun - neundeun log atah. Ieu sanés lapisan wajib, tapi bakal mangpaat upami aya anu salah sareng antrian acara di Kafka direset kana nol. Nyimpen log atah henteu meryogikeun solusi anu rumit sareng mahal, anjeun ngan saukur tiasa nyerat dina tempat anu leres (sanaos kana hard drive).
2. Nanganan aliran acara
Sanggeus kami geus disiapkeun sagala acara sarta nempatkeun eta dina antrian luyu, urang ngaléngkah ka hambalan processing. Di dieu kuring bakal ngobrol ngeunaan dua pilihan pangolahan anu paling umum.
Pilihan kahiji nyaéta ngaktipkeun Spark Streaming dina sistem Apache. Sadaya produk Apache hirup dina HDFS, sistem file réplika anu aman. Spark Streaming mangrupikeun alat anu gampang dianggo anu ngolah data streaming sareng skala ogé. Sanajan kitu, éta bisa jadi teuas pikeun ngajaga.
Pilihan sanésna nyaéta ngawangun panangan acara anjeun nyalira. Jang ngalampahkeun ieu, contona, anjeun kedah nyerat aplikasi Python, ngawangun éta di docker, sareng ngalanggan antrian Kafka. Nalika pemicu datang ka pawang di docker, pamrosésan bakal ngamimitian. Kalayan metodeu ieu, anjeun kedah tetep ngajalankeun aplikasi.
Hayu urang nganggap yen urang geus milih salah sahiji pilihan ditétélakeun di luhur sarta ngaléngkah ka processing sorangan. Prosesor kedah ngamimitian ku mariksa validitas data, nyaring sampah sareng acara "rusak". Pikeun validasi biasana kami nganggo . Saatos éta, pemetaan data tiasa dilakukeun: data tina sumber anu béda-béda dinormalisasi sareng standarisasi supados tiasa ditambah kana tabel umum.
3. Pangkalan data
Léngkah katilu nyaéta nyimpen kajadian anu dinormalisasi. Nalika damel sareng sistem analitik anu siap, urang sering kedah ngaksés éta, janten penting pikeun milih pangkalan data anu merenah.
Lamun data fits ogé dina schema tetep, Anjeun bisa milih atawa sababaraha database kolom séjén. Jadi aggregations bakal dianggo pisan gancang. The downside nyaeta skéma ieu rigidly dibereskeun sarta ku kituna iyeu moal jalan mun nambahkeun objék sawenang tanpa Perbaikan (contona, nalika kajadian non-standar lumangsung). Tapi éta tiasa dilakukeun gancang pisan.
Pikeun data anu henteu terstruktur, anjeun tiasa nyandak NoSQL, contona, . Ieu dijalankeun dina HDFS, réplikasi ogé, anjeun tiasa ngangkat loba instansi, tur mangrupakeun lepat toleran.
Anjeun tiasa ngangkat hal anu langkung saderhana, contona, . Ieu rada slow sanajan keur volume leutik. Tapi tambihanana nyaéta saderhana pisan sahingga cocog pikeun ngamimitian.
4. Gumulung
Saanggeus disimpen taliti sagala acara, urang rék ngumpulkeun sakabeh informasi penting tina bets nu sumping tur ngamutahirkeun database. Sacara global, urang hoyong dasbor sareng métrik anu relevan. Contona, tina acara pikeun ngumpulkeun hiji profil pamaké sarta kumaha bae ukuran kabiasaan. Kajadian dikumpulkeun, dikumpulkeun, sareng disimpen deui (geus aya dina tabel pangguna). Dina waktu nu sarua, kasebut nyaéta dimungkinkeun pikeun ngawangun sistem dina cara sapertos nu saringan ogé disambungkeun ka agrégator koordinat: pikeun ngumpulkeun pamaké ukur ti jenis nu tangtu acara.
Saatos éta, upami batur dina tim ngan ukur peryogi analytics tingkat luhur, anjeun tiasa nyambungkeun sistem analitik éksternal. Anjeun tiasa nyandak Mixpanel deui. tapi saprak éta rada mahal, teu kabeh acara pamaké dikirim aya, tapi ngan naon anu diperlukeun. Jang ngalampahkeun ieu, urang kudu nyieun hiji koordinator anu bakal mindahkeun sababaraha acara atah atawa hal anu urang sorangan geus aggregated saméméhna mun sistem éksternal, API atawa platform iklan.
5. Panghareupna
Anjeun kudu nyambungkeun frontend ka sistem dijieun. Hiji conto alus nyaeta jasa. , mangrupa GUI database nu mantuan ngawangun panels. Kumaha interaksi jalan:
- Pamaké nyieun query SQL.
- Salaku jawaban, anjeunna nampi tanda.
- Nyiptakeun 'visualisasi anyar' pikeun éta sareng kéngingkeun grafik anu saé anu anjeun parantos tiasa nyalametkeun diri anjeun.
Visualisasi dina jasa éta otomatis-ngamutahirkeun, anjeun tiasa ngonpigurasikeun sareng ngalacak monitoring anjeun. Redash gratis, dina kasus anu di-host sorangan, tapi sakumaha SaaS hargana $ 50 per bulan.
kacindekan
Saatos ngalengkepan sadaya léngkah di luhur, anjeun bakal nyiptakeun analytics sisi server anjeun. Punten dicatet yén ieu henteu segampang ngan ukur nyambungkeun analytics klien, sabab sadayana kedah dikonpigurasi ku anjeun nyalira. Kukituna, sateuacan nyiptakeun sistem anjeun nyalira, kedah ngabandingkeun kabutuhan sistem analitik anu serius sareng sumber daya anu anjeun siapkeun pikeun éta.
Upami anjeun ngalakukeun sadayana matematika sareng mendakan biaya anu luhur teuing, dina bagian salajengna kuring bakal ngobrol ngeunaan kumaha carana ngadamel versi anu langkung mirah tina analytics back-end.
Hatur nuhun pikeun maca! Kuring bakal bungah patarosan dina komentar.
sumber: www.habr.com