Sistem analitik pelayan

Ini adalah bahagian kedua siri artikel tentang sistem analisis (pautan ke bahagian 1).

Hari ini, tidak ada keraguan bahawa pemprosesan data yang tepat dan tafsiran keputusan boleh membantu hampir semua jenis perniagaan. Dalam hal ini, sistem analisis semakin sarat dengan parameter, bilangan pencetus dan peristiwa pengguna dalam aplikasi semakin meningkat.
Disebabkan ini, syarikat memberikan lebih banyak maklumat "mentah" kepada penganalisis mereka untuk menganalisis dan mengubahnya menjadi keputusan yang tepat. Kepentingan sistem analitik untuk syarikat tidak boleh dipandang remeh, dan sistem itu sendiri harus boleh dipercayai dan mampan.

Penganalisis pelanggan

Analitis pelanggan ialah perkhidmatan yang disambungkan oleh syarikat untuk tapak web atau aplikasinya melalui SDK rasmi, menyepadukannya ke dalam pangkalan kodnya sendiri dan memilih pencetus peristiwa. Pendekatan ini mempunyai kelemahan yang jelas: semua data yang dikumpul tidak boleh diproses sepenuhnya seperti yang anda mahu, disebabkan oleh pengehadan mana-mana perkhidmatan yang dipilih. Sebagai contoh, pada satu sistem ia tidak akan mudah untuk menjalankan tugas MapReduce, pada yang lain anda tidak akan dapat menjalankan model anda. Satu lagi kelemahan ialah bil biasa (mengagumkan) untuk perkhidmatan.
Terdapat banyak penyelesaian analitik pelanggan di pasaran, tetapi lambat laun, penganalisis berhadapan dengan hakikat bahawa tidak ada satu perkhidmatan universal yang sesuai untuk sebarang tugas (sementara harga untuk semua perkhidmatan ini sentiasa meningkat). Dalam keadaan sedemikian, syarikat sering membuat keputusan untuk mencipta sistem analitik mereka sendiri dengan semua tetapan dan ciri tersuai yang diperlukan.

Penganalisis Pelayan

Analitis sisi pelayan ialah perkhidmatan yang boleh digunakan secara dalaman pada pelayan syarikat sendiri dan (biasanya) dalaman. Dalam model ini, semua acara pengguna disimpan pada pelayan dalaman, membolehkan pembangun mencuba pangkalan data yang berbeza untuk penyimpanan dan memilih seni bina yang paling mudah. Dan walaupun anda masih mahu menggunakan analitis pihak pelanggan pihak ketiga untuk beberapa tugas, ia masih boleh dilakukan.
Analitis sisi pelayan boleh digunakan dalam dua cara. Pertama: pilih beberapa utiliti sumber terbuka, gunakannya pada mesin anda dan bangunkan logik perniagaan.

Kelebihan
Kekurangan

Anda boleh menyesuaikan apa sahaja
Selalunya ia sangat sukar dan pembangun yang berasingan diperlukan

Kedua: ambil perkhidmatan SaaS (Amazon, Google, Azure) dan bukannya menggunakan perkhidmatan itu sendiri. Kami akan bercakap tentang SaaS dengan lebih terperinci di bahagian ketiga.

Kelebihan
Kekurangan

Ia boleh menjadi lebih murah pada volum sederhana, tetapi dengan peningkatan yang besar ia masih akan menjadi terlalu mahal
Tidak dapat mengawal semua parameter

Pentadbiran dipindahkan sepenuhnya ke bahu pembekal perkhidmatan
Ia tidak selalu diketahui apa yang ada di dalam perkhidmatan (mungkin tidak diperlukan)

Bagaimana untuk mengumpul analitik pelayan

Jika kita ingin menjauhkan diri daripada menggunakan analitik pelanggan dan membina sendiri, pertama sekali kita perlu memikirkan seni bina sistem baharu. Di bawah saya akan memberitahu anda langkah demi langkah apa yang anda perlu pertimbangkan, mengapa setiap langkah itu diperlukan dan alat yang anda boleh gunakan.

1. Pemerolehan data

Sama seperti dalam kes analitik pelanggan, pertama sekali, penganalisis syarikat memilih jenis acara yang mereka ingin kaji lebih lanjut dan mengumpulkannya dalam senarai. Biasanya, peristiwa ini berlaku dalam susunan tertentu, yang dipanggil "skim peristiwa".
Selanjutnya, mari kita bayangkan bahawa aplikasi mudah alih (laman web) mempunyai pengguna tetap (peranti) dan banyak pelayan. Untuk memindahkan acara dengan selamat dari peranti ke pelayan, lapisan perantaraan diperlukan. Bergantung pada seni bina, beberapa baris gilir acara yang berbeza boleh berlaku.
Apache Kafka - Adakah baris gilir pub/sub, yang digunakan sebagai baris gilir untuk mengumpul acara.

Menurut siarkan di Quora pada tahun 2014, pencipta Apache Kafka memutuskan untuk menamakan perisian itu selepas Franz Kafka kerana "ia adalah sistem yang dioptimumkan menulis" dan kerana dia menyukai tulisan Kafka. — Wikipedia

Dalam contoh kami, terdapat banyak pengeluar data dan pengguna mereka (peranti dan pelayan), dan Kafka membantu menyambungkannya antara satu sama lain. Pengguna akan diterangkan dengan lebih terperinci dalam langkah seterusnya, di mana mereka akan menjadi pelakon utama. Sekarang kami akan mempertimbangkan hanya pengeluar data (peristiwa).
Kafka merangkum konsep baris gilir dan partition, lebih khusus tentang ini adalah lebih baik untuk membaca di tempat lain (contohnya, dalam dokumentasi). Tanpa pergi ke butiran, mari bayangkan bahawa aplikasi mudah alih dilancarkan untuk dua sistem pengendalian yang berbeza. Kemudian setiap versi mencipta strim acara tersendiri. Pengeluar menghantar acara ke Kafka, mereka direkodkan dalam baris gilir yang sesuai.

(gambar oleh itu)

Pada masa yang sama, Kafka membenarkan anda membaca dalam ketulan dan memproses aliran acara dalam kelompok mini. Kafka ialah alat yang sangat mudah yang berskala baik dengan keperluan yang semakin meningkat (contohnya, mengikut geolokasi acara).
Biasanya satu serpihan sudah mencukupi, tetapi perkara menjadi lebih rumit dengan komunikasi apabila menskalakan (seperti biasa). Mungkin tiada siapa yang mahu menggunakan hanya satu serpihan fizikal dalam pengeluaran, kerana seni bina mestilah tahan terhadap kesalahan. Selain Kafka, terdapat satu lagi penyelesaian yang terkenal - RabbitMQ. Kami tidak menggunakannya dalam pengeluaran sebagai baris gilir untuk analitis acara (jika anda mempunyai pengalaman sedemikian, beritahu kami mengenainya dalam ulasan!). Walau bagaimanapun, AWS Kinesis telah digunakan.

Sebelum meneruskan ke langkah seterusnya, satu lagi lapisan tambahan sistem perlu disebutkan - penyimpanan log mentah. Ini bukan lapisan wajib, tetapi ia akan berguna sekiranya berlaku masalah dan baris gilir acara dalam Kafka ditetapkan semula kepada sifar. Menyimpan log mentah tidak memerlukan penyelesaian yang kompleks dan mahal, anda boleh menulisnya di suatu tempat dalam susunan yang betul (walaupun pada cakera keras).

2. Mengendalikan aliran acara

Selepas kami menyediakan semua acara dan meletakkannya dalam baris gilir yang sesuai, kami meneruskan ke langkah pemprosesan. Di sini saya akan bercakap mengenai dua pilihan pemprosesan yang paling biasa.
Pilihan pertama adalah untuk mendayakan Spark Streaming pada sistem Apache. Semua produk Apache hidup di HDFS, sistem fail replika yang selamat. Spark Streaming ialah alat yang mudah digunakan yang memproses data penstriman dan skala dengan baik. Walau bagaimanapun, ia boleh menjadi sukar untuk dikekalkan.
Pilihan lain ialah membina pengendali acara anda sendiri. Untuk melakukan ini, sebagai contoh, anda perlu menulis aplikasi Python, membinanya dalam docker, dan melanggan baris gilir Kafka. Apabila pencetus datang kepada pengendali dalam docker, pemprosesan akan bermula. Dengan kaedah ini, anda perlu sentiasa menjalankan aplikasi.
Mari kita anggap bahawa kita telah memilih salah satu daripada pilihan yang diterangkan di atas dan beralih kepada pemprosesan itu sendiri. Pemproses harus bermula dengan menyemak kesahihan data, menapis sampah dan peristiwa "pecah". Untuk pengesahan biasanya kami gunakan Cerberus. Selepas itu, pemetaan data boleh dilakukan: data daripada sumber yang berbeza dinormalisasi dan diseragamkan untuk ditambahkan pada jadual biasa.

3. Pangkalan Data

Langkah ketiga ialah menyimpan peristiwa ternormal. Apabila bekerja dengan sistem analisis siap sedia, kita selalunya perlu mengaksesnya, jadi adalah penting untuk memilih pangkalan data yang mudah.
Jika data sesuai dengan baik pada skema tetap, anda boleh memilih clickhouse atau beberapa pangkalan data lajur lain. Jadi pengagregatan akan berfungsi dengan cepat. Kelemahannya ialah skema itu ditetapkan secara tegar dan oleh itu ia tidak akan berfungsi untuk menambah objek sewenang-wenangnya tanpa penghalusan (contohnya, apabila peristiwa bukan standard berlaku). Tetapi ia boleh dilakukan dengan cepat.
Untuk data tidak berstruktur, anda boleh mengambil NoSQL, sebagai contoh, Apache Cassandra. Ia berjalan pada HDFS, mereplikasi dengan baik, anda boleh membangkitkan banyak contoh, dan bertolak ansur dengan kesalahan.
Anda boleh membangkitkan sesuatu yang lebih mudah, contohnya, MongoDB. Ia agak perlahan walaupun untuk volum kecil. Tetapi kelebihannya ialah ia sangat mudah dan oleh itu sesuai untuk bermula.

4. Agregasi

Setelah menyimpan semua acara dengan teliti, kami ingin mengumpul semua maklumat penting daripada kumpulan yang datang dan mengemas kini pangkalan data. Di peringkat global, kami mahukan papan pemuka dan metrik yang berkaitan. Contohnya, daripada acara untuk mengumpul profil pengguna dan entah bagaimana mengukur tingkah laku. Acara diagregatkan, dikumpulkan dan disimpan semula (sudah dalam jadual pengguna). Pada masa yang sama, adalah mungkin untuk membina sistem sedemikian rupa sehingga penapis juga disambungkan kepada agregator penyelaras: untuk mengumpul pengguna hanya dari jenis acara tertentu.
Selepas itu, jika seseorang dalam pasukan hanya memerlukan analitis peringkat tinggi, anda boleh menyambungkan sistem analitis luaran. Anda boleh mengambil Mixpanel sekali lagi. tetapi memandangkan ia agak mahal, tidak semua acara pengguna dihantar ke sana, tetapi hanya apa yang diperlukan. Untuk melakukan ini, kami perlu mencipta penyelaras yang akan memindahkan beberapa acara mentah atau sesuatu yang kami sendiri telah agregatkan sebelum ini kepada sistem luaran, API atau platform pengiklanan.

5. Bahagian hadapan

Anda perlu menyambungkan bahagian hadapan ke sistem yang dibuat. Contoh yang baik ialah perkhidmatan. redash, ialah GUI pangkalan data yang membantu membina panel. Cara interaksi berfungsi:

1. Pengguna membuat pertanyaan SQL.
2. Sebagai tindak balas, dia menerima tanda.
3. Mencipta 'visualisasi baharu' untuknya dan mendapat graf cantik yang anda sudah boleh simpan sendiri.

Visualisasi dalam perkhidmatan dikemas kini secara automatik, anda boleh mengkonfigurasi dan menjejaki pemantauan anda. Redash adalah percuma, dalam kes yang dihoskan sendiri, tetapi sebagai SaaS ia akan menelan kos $50 sebulan.

Kesimpulan

Selepas melengkapkan semua langkah di atas, anda akan membuat analitis sebelah pelayan anda. Sila ambil perhatian bahawa ini tidak semudah hanya menyambungkan analitik pelanggan, kerana semuanya perlu dikonfigurasikan sendiri. Oleh itu, sebelum mencipta sistem anda sendiri, adalah wajar membandingkan keperluan untuk sistem analitik yang serius dengan sumber yang anda sedia untuk memperuntukkannya.
Jika anda melakukan semua matematik dan mendapati bahawa kosnya terlalu tinggi, dalam bahagian seterusnya saya akan bercakap tentang cara membuat versi analisis belakang yang lebih murah.

Terima kasih untuk membaca! Saya akan gembira untuk soalan dalam komen.

Sumber: www.habr.com