Sistem analitik server

Iki minangka bagean kapindho saka seri artikel babagan sistem analitik (link menyang bagean 1).

Saiki ora ana keraguan manawa pangolahan data sing ati-ati lan interpretasi asil bisa mbantu meh kabeh jinis bisnis. Ing babagan iki, sistem analitis saya tambah akeh karo paramèter, lan jumlah pemicu lan acara pangguna ing aplikasi saya tambah akeh.
Amarga iki, perusahaan menehi analis luwih akeh informasi mentah kanggo nganalisa lan dadi keputusan sing apik. Pentinge sistem analytics kanggo perusahaan ora kena disepelekake, lan sistem kasebut kudu dipercaya lan stabil.

Analis klien

Analitik pelanggan minangka layanan sing disambungake perusahaan menyang situs web utawa aplikasi liwat SDK resmi, digabungake menyang basis kode dhewe lan milih pemicu acara. Ana kekurangan sing jelas kanggo pendekatan iki: kabeh data sing diklumpukake bisa uga ora diproses persis kaya sing dikarepake amarga watesan layanan sing sampeyan pilih. Contone, ing siji sistem ora bakal gampang kanggo mbukak tugas MapReduce, ing liyane sampeyan ora bakal bisa kanggo mbukak model. Kerugian liyane yaiku tagihan reguler (nyengsemaken) kanggo layanan.
Ana akeh solusi analytics pelanggan ing pasar, nanging cepet utawa mengko analis ngadhepi kasunyatan sing ora ana siji layanan universal sing cocok kanggo saben tugas (nalika prices kanggo kabeh layanan iki mundhak kabeh wektu). Ing kahanan kaya mengkono, perusahaan kerep mutusake nggawe sistem analytics dhewe kanthi kabeh setelan lan kemampuan khusus sing dibutuhake.

Analis server

Analytics sisih server minangka layanan sing bisa disebarake ing perusahaan ing server dhewe lan (biasane) kanthi usaha dhewe. Ing model iki, kabeh acara pangguna disimpen ing server internal, ngidini pangembang nyoba database panyimpenan sing beda lan milih arsitektur sing paling trep. Lan sanajan sampeyan isih pengin nggunakake analytics klien pihak katelu kanggo sawetara tugas, iku isih bisa.
Analytics sisih server bisa disebarake kanthi rong cara. Pisanan: pilih sawetara utilitas open source, pasang ing mesin sampeyan lan gawe logika bisnis.

Плюсы
Минусы

Sampeyan bisa ngatur apa wae sing dikarepake
Iki asring banget angel lan mbutuhake pangembang sing kapisah

Kapindho: njupuk layanan SaaS (Amazon, Google, Azure) tinimbang nggunakake dhewe. Kita bakal ngomong babagan SaaS kanthi luwih rinci ing bagean katelu.

Плюсы
Минусы

Bisa uga luwih murah ing volume sedheng, nanging kanthi wutah gedhe isih bakal larang banget
Ora bakal bisa ngontrol kabeh parameter

Administrasi tanggung ditransfer menyang pundhak panyedhiya layanan
Ora mesthi dingerteni apa sing ana ing njero layanan (bisa uga ora dibutuhake)

Carane ngumpulake analytics server

Yen kita pengin pindhah saka nggunakake analytics klien lan mbangun dhewe, pisanan kabeh kita kudu mikir liwat arsitektur sistem anyar. Ing ngisor iki aku bakal ngandhani langkah demi langkah apa sing kudu ditimbang, kenapa saben langkah dibutuhake lan alat apa sing bisa digunakake.

1. Nampa data

Kaya ing kasus analytics pelanggan, pisanan, analis perusahaan milih jinis acara sing pengin disinaoni ing mangsa ngarep lan ngumpulake menyang dhaptar. Biasane, acara kasebut dumadi ing urutan tartamtu, sing diarani "pola acara."
Sabanjure, bayangake yen aplikasi seluler (situs web) nduweni pangguna biasa (piranti) lan akeh server. Kanggo nransfer acara kanthi aman saka piranti menyang server, perlu lapisan penengah. Gumantung ing arsitektur, bisa uga ana sawetara antrian acara sing beda.
Apache Kafka Punika pub / sub antrian, sing digunakake minangka antrian kanggo ngumpulake acara.

Miturut kirim ing Quora ing 2014, pangripta Apache Kafka mutusake kanggo menehi jeneng piranti lunak kasebut miturut Franz Kafka amarga "iku sistem sing dioptimalake kanggo nulis" lan amarga dheweke seneng karya Kafka. — Wikipedia

Ing conto kita, ana akeh produser data lan konsumen data (piranti lan server), lan Kafka mbantu nyambungake siji liyane. Konsumen bakal diterangake kanthi luwih rinci ing langkah-langkah ing ngisor iki, ing ngendi dheweke bakal dadi subyek utama. Saiki kita bakal nimbang mung produser data (acara).
Kafka nyakup konsep antrian lan partisi; luwih becik maca luwih khusus babagan iki ing papan liya (contone, ing dokumentasi). Tanpa nerangake rincian, ayo bayangake manawa aplikasi seluler diluncurake kanggo rong OS sing beda. Banjur saben versi nggawe stream acara dhewe. Produser ngirim acara menyang Kafka, direkam ing antrian sing cocog.

(gambar saka kene)

Ing wektu sing padha, Kafka ngidini sampeyan maca ing potongan-potongan lan ngolah aliran acara ing mini-batch. Kafka minangka alat sing trep banget sing cocog karo kabutuhan (contone, kanthi geolokasi acara).
Biasane siji shard cukup, nanging dadi luwih rumit nalika skala (kaya biasane). Mbokmenawa ora ana sing pengin nggunakake mung siji serpihan fisik ing produksi, amarga arsitektur kasebut kudu tahan kesalahan. Saliyane Kafka, ana solusi liyane sing kondhang - RabbitMQ. Kita ora nggunakake ing produksi minangka antrian kanggo analytics acara (yen sampeyan duwe pengalaman kuwi, marang kita ing komentar!). Nanging, kita nggunakake AWS Kinesis.

Sadurunge pindhah menyang langkah sabanjure, kita kudu nyebutake siji lapisan tambahan sistem - raw log storage. Iki dudu lapisan sing dibutuhake, nanging bakal migunani yen ana sing salah lan antrian acara ing Kafka direset. Nyimpen log mentah ora mbutuhake solusi sing rumit lan larang, sampeyan mung bisa nulis ing endi wae kanthi urutan sing bener (sanajan ing hard drive).

2. Ngolah acara stream

Sawise kita wis nyiapake kabeh acara lan diselehake ing antrian cocok, kita pindhah menyang langkah Processing. Ing kene aku bakal pitutur marang kowe babagan rong pilihan pangolahan sing paling umum.
Opsi pisanan yaiku ngaktifake Spark Streaming ing sistem Apache. Kabeh produk Apache urip ing HDFS, sistem file aman karo replika file. Spark Streaming minangka alat sing gampang digunakake sing nangani data streaming lan timbangan kanthi apik. Nanging, bisa uga angel kanggo njaga.
Pilihan liyane yaiku nggawe pawang acara sampeyan dhewe. Kanggo nindakake iki, sampeyan kudu, contone, kanggo nulis aplikasi Python, mbangun ing Docker lan langganan antrian Kafka. Nalika pemicu teka ing panangan docker, pangolahan bakal diwiwiti. Kanthi cara iki, sampeyan kudu terus-terusan mbukak aplikasi.
Ayo nganggep manawa kita wis milih salah sawijining opsi sing diterangake ing ndhuwur lan pindhah menyang proses kasebut. Prosesor kudu diwiwiti kanthi mriksa validitas data, nyaring sampah lan acara "rusak". Kanggo validasi biasane digunakake Cerberus. Sawise iki, sampeyan bisa nindakake pemetaan data: data saka macem-macem sumber dinormalisasi lan standar supaya bisa ditambahake menyang tabel umum.

3. Database

Langkah katelu yaiku njaga acara sing normal. Nalika nggarap sistem analitik sing wis siap, kita kudu kerep ngakses, mula penting kanggo milih database sing trep.
Yen data mathuk uga menyang rencana tetep, sampeyan bisa milih clickhouse utawa sawetara database columnar liyane. Kanthi cara iki, agregasi bakal cepet banget. Kelemahane yaiku skema kasebut tetep kaku lan mulane ora bisa nambah obyek sing sewenang-wenang tanpa modifikasi (contone, nalika kedadeyan sing ora standar). Nanging sampeyan bisa ngetung kanthi cepet banget.
Kanggo data sing ora terstruktur, sampeyan bisa njupuk NoSQL, contone, Apache cassandra. Iku mlaku ing HDFS, replikasi uga, sampeyan bisa mundhakaken akeh kedadean, lan fault-tolerant.
Sampeyan uga bisa ngunggahake sing luwih gampang, contone, MongoDB. Iku cukup alon lan kanggo volume cilik. Nanging plus iku banget prasaja lan mulane cocok kanggo miwiti.

4. Kumpul-kumpul

Sawise disimpen kanthi ati-ati kabeh acara, kita pengin ngumpulake kabeh informasi penting saka kumpulan sing teka lan nganyari database. Sacara global, kita pengin entuk dashboard lan metrik sing relevan. Contone, ngumpulake profil pangguna saka acara lan ngukur prilaku. Acara dikumpulake, diklumpukake, lan disimpen maneh (ing tabel pangguna). Ing wektu sing padha, sampeyan bisa mbangun sistem supaya sampeyan uga bisa nyambungake saringan menyang aggregator-koordinator: ngumpulake pangguna mung saka jinis acara tartamtu.
Sawise iku, yen ana wong ing tim mung butuh analytics tingkat dhuwur, sistem analytics eksternal bisa disambungake. Sampeyan bisa njupuk Mixpanel maneh. nanging wiwit iku cukup larang, ora kabeh acara pangguna dikirim ana, nanging mung apa perlu. Kanggo nindakake iki, kita kudu nggawe koordinator sing bakal nransfer sawetara acara mentah utawa soko sing awake dhewe dikumpulake sadurunge menyang sistem eksternal, API utawa platform iklan.

5. Ngarep

Sampeyan kudu nyambungake frontend menyang sistem sing digawe. Conto apik yaiku layanan redash, minangka GUI basis data sing mbantu mbangun dashboard. Cara kerjane interaksi:

1. Pangguna nggawe query SQL.
2. Kanggo nanggepi dheweke nampa tandha.
3. Iki nggawe 'visualisasi anyar' lan entuk grafik sing apik sing bisa disimpen dhewe.

Visualisasi ing layanan kasebut nganyari otomatis, sampeyan bisa ngatur lan nglacak pemantauan sampeyan. Redash gratis yen dadi tuan rumah dhewe, nanging minangka SaaS bakal biaya $ 50 saben wulan.

kesimpulan

Sawise ngrampungake kabeh langkah ing ndhuwur, sampeyan bakal nggawe analytics server. Elinga yen iki ora gampang kaya mung nyambungake analytics pelanggan, amarga kabeh kudu dikonfigurasi dhewe. Mulane, sadurunge nggawe sistem sampeyan dhewe, sampeyan kudu mbandhingake kabutuhan sistem analitik serius karo sumber daya sing sampeyan pengin nyedhiyakake.
Yen sampeyan wis rampung math lan ketemu sing biaya dhuwur banget, ing sisih sabanjure aku bakal pirembagan bab carane nggawe versi luwih murah saka analytics sisih server.

Matur nuwun kanggo maca! Aku bakal seneng takon pitakonan ing komentar.

Source: www.habr.com